Tool-belt series · Playbook · Copilot & Claude × Power BI

Clean the model, modernize the reports —
drive it all with an agent, and win it for Treasury.

A working plan for optimizing a Power BI semantic model and rebuilding its reports with agentic AI — without breaking things. Start from a defensible baseline, let VertiPaq Analyzer point at the weight, delete only what is provably dead, then turn a lean model into reports Treasury actually opens. Check items off as you go; every section, part, and the top bar tracks progress, and collapsed sections stay collapsed the next time you open this file.

How to use this page

This is a review-and-do playbook, built to be read the way you work: top to bottom. Part A pressure-tests your plan and locks in the safety setup, Part B is the VertiPaq-driven model cleanup, Part C modernizes the reports, and Part D turns it into Treasury value and a way to out-deliver the outside vendor. Check items off as you complete them — sections, parts, and the top bar all track progress.

The prompts assume you have the PBIP folder open in VS Code with GitHub Copilot in agent mode (or Claude), referencing files with #file / #folder and the whole project with @workspace. Progress and collapsed-section state save automatically in this browser on this device; they reset if you clear browser data or open the file elsewhere.

When a new situation comes up that this page doesn't cover, bring it back to Claude and ask for another section — it's built to be extended like the rest of the tool belt.

Part A · Strategy & safe change

Are you thinking about this right?

Your instinct is sound — but the order of operations is everything. Lock in a defensible baseline and a safe-change loop before you delete a single table, so every cut is provable and reversible.

0 / 0

Yes — feeding the VPAX into Copilot and letting it point at bloated tables and measures is exactly the right raw material. The VertiPaq Analyzer view tells you where the bytes and cardinality actually live, which is far better than guessing. The one risk in your plan is sequencing: “identify and delete tables not used at all” is the last step, not an early one. VPAX shows you what is expensive; it does not prove what is unused. A table can be tiny and still feed a critical measure, an RLS rule, or a downstream report. Prove it is orphaned and check what consumes it before it goes.

Reframe the effort into phases

Phase 1 — Baseline & safety: source control, a known-good backup, and metrics you can defend (A2–A3).
Phase 2 — Find waste: use VPAX to rank tables/columns by size & cardinality; flag candidates, decide nothing yet.
Phase 3 — Remove/shrink safely: drop high-cardinality unused columns first, then orphaned tables — only after dependency checks.
Phase 4 — Optimize measures: fix the DAX and relationships that VPAX and query traces flag as costly.
Phase 5 — Re-verify against baseline, capture a fresh VPAX, then move on to the reports.

Field noteDeleting last is not slower — it is what lets you delete confidently. Every phase before it is what turns a scary delete into a boring one.

The whole reason PBIP exists is that it saves the model as plain-text TMDL and the report as PBIR — both diffable, both Git-friendly. That is your safety net. The agent edits text files; Git records every change; you review before anything is committed or opened in Desktop. Never let the agent operate against the published/live dataset in the Service — work only against the local PBIP folder on a branch.

Save as a .pbip project (TMDL + PBIR enabled) and commit the whole folder to Git as your starting point.
Cut a working branch (e.g. model-cleanup); never edit the published/live model directly.
One logical change per commit — “remove column X”, not “cleaned up model” — so any single change can be reverted in isolation.
Review the TMDL diff before you save/open in Desktop; if a change touched files you did not expect, stop and read them.
Keep a rollback: a known-good .pbix (or clean commit) plus a saved .vpax snapshot of the starting model.
Add a .gitignore for cache/local artifacts (e.g. .pbi/localSettings.json, cache.abf) so diffs stay meaningful.

Field noteThe TMDL diff is your real review surface — a clean delete shows as removed lines in one table’s .tmdl file. If a “small” change rewrites half the model, that is the model warning you.

You cannot claim an improvement you never measured. Before the first edit, capture the current state and write down where you intend to land. This does double duty: it protects you (regressions are obvious) and it is your scoreboard against the external vendor — when Treasury asks who delivered more, you have hard numbers, not a story.

Capture & record

Save the current .vpax and note total model size, plus the largest tables/columns by size and cardinality.
Record refresh duration (full and, if used, incremental) from the current dataset.
Time report/page load for the two or three heaviest report pages Treasury actually uses.
Write down target metrics — e.g. “model −30%, refresh under N min, page load under N s” — before you start.
Keep the baseline in the repo (a short markdown scoreboard) so before/after is one glance away.

Field noteCapture the baseline VPAX on the same refreshed data you will re-measure against — comparing a stale model to a fresh one invents savings you did not earn and hides regressions you did.

The agent is fast and confident — which is exactly why you gate it. Make it justify a change before it makes it, and never accept a bulk delete on faith. For anything destructive, stage it: hide the object first, watch it survive a refresh and a report render, then delete. Keep a decision log so every removal has a reason attached — future-you (and the audit) will need it.

Prompt to try

@workspace Using #file:model.vpax and the TMDL in #folder:Model,
list every table & column that is NOT referenced by any measure,
relationship, RLS role, calc group, or report visual.
For each candidate: show what DOES reference it (or state "none"),
its size & cardinality, and a risk rating.
Do NOT edit anything yet — output the analysis as a table.

Verification loop

Before any delete, make the agent explain what references the object and why it believes it is safe to remove.
Never accept a bulk delete blindly — require a per-object list with dependencies, and approve them one at a time.
Stage risky changes: hide the object → observe a full refresh cycle and a report render → then delete in a later commit.
Keep a decision log (object, size, what referenced it, decision, date) committed alongside the change.
After each destructive commit, refresh and re-render before moving on — catch breakage while the change is still small.

Field noteTreat “the agent said it was unused” as a hypothesis, not a verdict. Hiding first costs you one refresh cycle; a wrong delete costs you a broken Treasury report and your credibility against the vendor.

Part B · VertiPaq-driven cleanup

Data model cleanup — the VertiPaq-driven sequence

Feed the agent the metrics, not just the model. VertiPaq Analyzer tells you where the weight is; the report layer and model metadata tell you what is safe to cut. Work top-down: triage with data, delete what is provably dead, shrink what stays, then prove the gain.

0 / 0

The agent can only triage what it can see. Give it the measured cost (the exported .vpax), the full model definition (the TMDL), and the constraints it must respect (star schema, what has already changed). Precise file references keep it grounded instead of guessing.

Context to load

Export the model with VertiPaq Analyzer (DAX Studio → Advanced → Export Metrics, or Tabular Editor) and add the .vpax to the workspace so Copilot can read Cardinality, Total Size, Dictionary/Data Size and % of model per column.
Point the agent at the model TMDL folder so it reads every table, column, relationship, role and measure definition — the source of truth, not a screenshot.
State the design intent: this is a star schema (fact tables + conformed dimensions) for the Treasury group, so it does not propose changes that break the grain or the dimensional model.
Tell it hidden report pages were already deleted, so “no longer referenced” findings account for that and it does not re-flag them as risk.
Use #file for a single file, #folder for the TMDL/PBIR tree, and @workspace when you want it to reason across the whole project.

Prompt to try

@workspace You are helping me clean up a Power BI semantic model (PBIP/TMDL) for
our Treasury group. Attached is the VertiPaq Analyzer export #file:model.vpax and
the model definition in #folder:Model.SemanticModel/definition.

It is a star schema — fact tables plus conformed dimensions; preserve the grain.
Hidden report pages have already been deleted.

Triage, do not change anything yet. Produce a ranked table of the heaviest columns
and tables by Total Size and % of model, note Cardinality for each, and flag
obvious optimization or deletion candidates. Ask me before assuming anything is unused.

Field noteAttach the .vpax and the TMDL together in the first message — the agent triages far better with measured size next to the definition than with either alone.

Two separate questions: what costs the most (VertiPaq), and what is actually referenced (dependency analysis + the report layer). A deletion candidate must be expensive-or-irrelevant and unreferenced everywhere. DAX dependencies alone are not enough.

Surface the cost, then prove non-use

Rank columns by Total Size, Dictionary Size and % of model from the VPAX; the long tail of tiny columns rarely matters, the top handful is where the model lives.
Use dependency analysis — INFO.CALCDEPENDENCY(), INFO.MEASURES(), INFO.COLUMNS(), INFO.RELATIONSHIPS() — to list which columns feed measures, calculated columns and relationships.
Cross-check the report layer (PBIR report.json / visual JSON): a column can be invisible to DAX yet bound to a visual field, slicer, tooltip or drillthrough.
Check model metadata that DAX dependency misses: relationship columns, RLS filter expressions, field parameters, sort-by-column, and any incremental-refresh RangeStart/RangeEnd partitioning column.
Have the agent classify each candidate: confirmed unreferenced (delete), referenced somewhere (keep), or uncertain (needs a human look) — never a blanket “unused” verdict.
Give priority to high-cost + confirmed-unreferenced; a huge column that IS used goes to B4 (shrink), not to the delete list.

Prompt to try

Using #file:model.vpax and #folder:definition, list every column with Total Size
> 1% of the model. For each, tell me whether it is referenced by: any measure or
calculated column (via dependencies), a relationship, an RLS role expression, a
field parameter, a sort-by-column, or the incremental refresh policy. Then scan
#folder:Report/definition for any visual, slicer, tooltip or filter binding.

Return three buckets: confirmed-unreferenced-everywhere, referenced, and uncertain.
Do not call anything unused unless it is clear in all of those places.

Field note“Not used in any measure” is not “not used.” The classic false positive is a column dragged straight onto a visual axis — it never touches DAX but breaks the report the moment you delete it.

Deletion is destructive and version control is your safety net. Move in stages, one table at a time, so every removal is an isolated, reversible commit with a readable diff.

Staged removal

Confirm zero references first: measures, calculated columns, relationships, RLS role filters, incremental-refresh policy, and report visuals — the full B2 sweep, not a subset.
Hide the table first (isHidden: true) rather than deleting; leave it hidden through at least one full refresh + report open to flush out anything that quietly breaks.
If nothing breaks, delete the table’s TMDL and any relationships referencing it in a single change.
Commit one table per commit with a message naming the table and the evidence (“no refs in measures/visuals/RLS/refresh”) so a rollback is surgical.
Review the TMDL diff before committing — confirm only the intended table and its relationships changed, and no measure or role was silently edited.
Refresh and open the report after each delete; a green refresh plus intact visuals is the go/no-go before the next table.

Field noteNever batch-delete tables. One-table commits mean that if a refresh fails three tables later, you revert one clean commit instead of unpicking a tangle.

VertiPaq compresses column by column, and compression works by building a dictionary of distinct values. So size is driven by cardinality (number of distinct values), not the number of rows. A 50M-row table with a low-cardinality column stays tiny; a few million rows of unique GUIDs or full-precision timestamps dominate the model. Attack the highest-cardinality columns first.

Cut cardinality

Split datetime into a Date column + a separate Time column — one datetime to the second can be ~86k× more unique than a date; two lower-cardinality columns compress far better.
Reduce decimal precision where the business does not need it (round rates/amounts); trailing-digit noise inflates distinct counts. Prefer Fixed Decimal (currency) over floating Decimal.
Drop high-cardinality keys that no relationship or visual uses — surrogate IDs, transaction GUIDs, hashes carried in from staging.
Turn off Auto Date/Time (options and per-model) — it silently generates a hidden date table per date column and can bloat the model; use your one shared Date dimension.
Prefer integers over strings for keys and codes; integer columns encode and scan cheaper than text with the same distinct count.
Reduce string uniqueness — trim free-text, normalize casing, move rarely-used descriptive text out of large fact tables into a dimension.

Prompt to try

From #file:model.vpax, list the 10 highest-cardinality columns with their Total
Size and data type. For each, recommend a cardinality reduction (datetime split,
precision/rounding, integer key, move-to-dimension, or drop) and note which
requires a Power Query / source change vs. a model change. Rank by expected
size saving, and flag any that participate in a relationship before proposing a drop.

Field noteIf you only remember one thing: sort by Cardinality, not Rows. The biggest single win is almost always splitting a full-precision datetime out of a fact table.

Measures change results, so correctness comes before speed. Find the expensive ones with real timings, have the agent explain what a measure is supposed to do before touching it, then rewrite and confirm the numbers match.

Rewrite with proof

Identify expensive measures with DAX Studio Server Timings (SE vs FE, scan counts) and Performance Analyzer in the report — optimize what the users actually wait on.
Replace FILTER() over an entire table with a boolean column predicate in CALCULATE where possible; iterating a whole fact table is the most common slow pattern.
Introduce variables (VAR) to compute a value once instead of repeating a subexpression, and to make the logic readable.
Swap iterators (SUMX/AVERAGEX) for a plain aggregation (SUM/AVERAGE) when there is no row-by-row expression that requires the iterator.
Watch for bidirectional-filter surprises; ambiguous or bidi relationships can make a measure both slow and wrong — prefer single-direction filtering plus explicit CROSSFILTER where truly needed.
Consolidate duplicate / near-duplicate measures into one canonical definition, then repoint references; verify each rewrite returns identical results across key filter contexts before committing.

Prompt to try

Look at the measure [Treasury Net Position] in #folder:definition. First, explain
in plain English what it computes and its filter context — do not rewrite yet.

Then propose an optimized version: remove any FILTER over the full fact table, use
variables, and drop unnecessary iterators. Keep semantics identical. Show old vs new
side by side, list the filter contexts I should test, and give me a DAX query that
returns both versions so I can confirm they match before I replace anything.

Field noteMake the agent restate the measure’s intent before it rewrites. If its plain-English summary is wrong, its “faster” version will be confidently wrong too.

The cleanup is only real if you can quantify it. Re-run the same instruments you started with and record the deltas — that decision log is your evidence for stakeholders and your scorecard against the outside vendor.

Close the loop

Re-export the VPAX after the changes and diff it against the baseline: total model size, the largest columns, and their new cardinality.
Re-capture the optimized measures’ timings in DAX Studio / Performance Analyzer and confirm both faster and identical results.
Run Best Practice Analyzer (Tabular Editor) and clear or consciously waive the remaining findings.
Record the deltas in the decision log: what was deleted/shrunk/rewritten, why, and the before→after numbers (MB saved, % smaller, ms faster).
Do a final refresh + full report open to confirm nothing regressed, then tag the commit as the cleaned baseline.

Field noteA one-line summary — “model down from X MB to Y MB, N dead tables removed, slowest measure Z→Z′ ms” — is the single most persuasive artifact you can put in front of Treasury and next to the vendor’s pitch.

Part C · Report layer

Modernize the reports — audit, redesign, build

The model is clean; now the visual layer earns the win. Inventory what exists, modernize the look, and let the agent build new visuals against the PBIR JSON — one reviewed change at a time.

0 / 0

You can't modernize what you haven't measured. Hidden pages were already removed — good. Now take stock of what remains: every page, every visual, and every place the reports contradict themselves. PBIR stores each page, visual, and bookmark as its own JSON file, so the agent can read the whole report and hand you a structured inventory in minutes.

Baseline the reports

Inventory every page and count visuals per page — flag pages carrying more than roughly 8–10 visuals as redesign candidates.
Find redundant or duplicate visuals — same measure shown two ways, near-identical cards, charts no one reads.
List bookmarks and check each is still wired to a button or action; note orphaned or unused ones for removal.
Catalog inconsistent formatting — mixed number/date formats, ad-hoc colors, off-theme fonts, vague titles like “Chart 1”.
Note accessibility gaps — low-contrast text, color-only encoding, missing alt text, no tab order set.
Run Performance Analyzer in Power BI Desktop, interact with each page, and record the slowest visuals by query & render time.

Prompt to try

Read every visual.json under #folder /definition/pages in this .Report.
Build a Markdown inventory table with one row per visual:
page name, visual name/title, visual type, fields/measures used,
and whether the title is meaningful or a default placeholder.
Add a second table listing bookmarks and, for each, whether any
button or visual action references it. Flag likely duplicates
(same measure, same or similar visual type on the same page).
Do not edit anything — read and report only.

Field notePerformance Analyzer lives in Power BI Desktop under View → Performance Analyzer; the agent can't run it, so capture the timings yourself and paste them back in as context for the redesign.

Modern doesn't mean flashy — it means disciplined. A single theme JSON sets colors, fonts, and default formatting once, so every visual inherits consistency instead of being styled by hand. Aim for restrained color (a neutral base plus one or two accents), clear visual hierarchy, generous spacing, and fewer visuals per page. Drive the changes through the agent, keep them small, and review every diff.

Set the design foundation

Define one theme JSON — palette, fonts, default text sizes, and standard number/date formats — and register it in the report's resource package.
Restrain color: neutral background, one primary accent, a second for emphasis; reserve red/green strictly for variance and status.
Establish hierarchy — a clear page title, KPI row up top, supporting detail below; consistent visual heights and gutters.
Give every visual a meaningful, plain-language title that states the takeaway, not the field name.
Standardize number and date formatting through the theme so currency, percentages, and dates read the same everywhere.
Keep changes reversible — work on a branch, commit the theme separately, and review each PBIR diff before applying the next.

Prompt to try

Here is our Treasury theme JSON (attached). Update it to a modern,
restrained scheme: neutral canvas, one primary accent (#hex),
one emphasis accent, and semantic red/green reserved for variance.
Set default fonts, title sizes, and card/label formatting.
Add dataColors, and set default formatString for currency
("\$#,0;(\$#,0)") and percentage where applicable.
Return the full valid theme JSON only — do not modify any
visual.json yet. I'll load it in Desktop and confirm before we
apply it across pages.

Field noteLet the theme do the heavy lifting before editing individual visuals — a good theme JSON restyles the whole report at once and is trivial to roll back if the palette misses.

This is where the agent shines — and where it can bite. Each visual is a JSON file with a public schema, so the agent can add or reshape visuals directly. But PBIR is newer and less forgiving than the model layer: a malformed visual.json can make Desktop drop the visual or refuse to open the report. Move one visual at a time, validate in Power BI Desktop after every edit, and commit only what opens cleanly.

Iterate safely on visuals

Prefer core visuals — they honor the theme, stay accessible, and don't add tenant-approval or certification overhead the way custom visuals do.
Reserve custom/marketplace visuals for genuine gaps, and confirm the org allows them before building around one.
Use small multiples for many-entity comparisons (accounts, currencies, entities) instead of one crowded chart.
Add field parameters so users swap measures or dimensions in a single visual rather than duplicating pages.
Change one visual per iteration, then open the report in Power BI Desktop to confirm it renders and the JSON is valid.
Commit each validated visual on its own so a bad edit is a one-line revert, never a lost afternoon.

Prompt to try

On the Liquidity page, replace the crowded per-currency line chart
with a small-multiples line chart: one small chart per currency,
measure = [Closing Cash], axis = Date, sorted by currency.
Create/modify only that one visual.json, follow the PBIR visual
schema exactly, keep the existing visual's position/size, and
inherit the theme (no hard-coded colors). Show me the JSON diff
and stop — I'll validate in Desktop before you touch anything else.

Field noteField parameters are defined as a table in the semantic model, then dropped into a slicer — so a new parameter touches both layers; add it in the model first, then reference it from the report visual. After every agent edit, the real test is a clean open in Power BI Desktop.

A modern report is fast and easy to move through. Fewer visuals per page cuts query load and cognitive load at once. Use bookmarks and navigation for clean page flow, tooltips and drill-through for detail on demand, and field parameters to let users shape their own view. Finish with a mobile layout, then re-run Performance Analyzer to prove the redesign is actually faster.

Tighten performance and flow

Reduce visuals per page — every visual is a query; move secondary detail to drill-through or tooltip pages.
Add bookmark-driven navigation and buttons so users move between views without hunting through the page tabs.
Build report-page tooltips and drill-through so headline visuals stay clean while detail is one hover or right-click away.
Expose field parameters as slicers so a single page serves multiple stakeholder questions.
Author a mobile layout for the key pages so Treasury can check positions from a phone.
Re-run Performance Analyzer after the changes and compare against your C1 baseline to confirm the wins.

Field noteChase the slowest visual from your baseline first — often one over-scoped table or an unfiltered visual dominates the page's render time, and fixing it beats a dozen cosmetic tweaks.

Part D · Treasury value & the bake-off

Make it matter to Treasury — and win the room

A clean model and modern reports are the means, not the win. This part translates your work into the language Treasury speaks, points you at the visuals worth building, and gives you a plan to out-deliver the outside vendor on trust, speed, and fit.

0 / 0

Treasury does not want dashboards — it wants answers to a short list of recurring questions about cash, liquidity, and risk. Frame every report around the question, not the visual, and your work will land with the people who fund it.

Anchor each report to a real Treasury question

Cash position & visibility — “How much cash do we have right now, in which banks, accounts, and currencies, and how much is actually available today?”
Liquidity — “Can we cover near-term obligations, and how much headroom sits in cash plus committed facilities?”
Short-term cash forecast — “What will our cash position be over the next 13 weeks, and where did last week’s forecast miss?”
Bank account & bank fee analysis — “How many accounts do we run, are they all needed, and what are we paying each bank in fees?”
FX exposure — “Where are we exposed by currency, and how much is that moving our reported cash and results?”
Debt, investment & counterparty risk — “When does debt mature, what are we earning on investments, and how concentrated is our exposure to any one bank or counterparty?”

Field noteSit with a treasury analyst for 30 minutes and write down the exact phrasing they use for these questions. Your report titles should echo their words back to them.

Concrete builds, each mapped to a core visual type and the decision it unlocks. Pick one, ship it end-to-end, then expand — a working artifact beats a backlog of ideas.

Candidate reports — visual × decision

Daily cash position dashboard — KPI cards plus a by-bank/by-currency matrix and a trend line. Drives the morning decision: sweep, fund, or invest today’s balances.
Rolling short-term cash forecast — a 13-week line/area chart with an actual-vs-forecast variance bar. Drives borrowing and investment timing, and exposes forecast bias.
Liquidity / cash waterfall — a waterfall from opening cash through inflows and outflows to closing available liquidity. Drives the “what moved our cash” conversation.
Bank fee analysis — a ranked bar by bank/service with a fee-per-account trend. Drives account rationalization and fee negotiations.
FX exposure view — a stacked/diverging bar of net exposure by currency with a concentration measure. Drives where hedging attention is needed (reporting the exposure, not advising the trade).
Debt maturity ladder — a bar chart of principal due by time bucket with a cumulative overlay. Drives refinancing planning and refunding timing.

Prompt to try

Act as a senior Power BI developer for a corporate treasury team.
Draft a DAX measure for a 13-week rolling cash forecast that returns
forecast-vs-actual variance by week. Assumptions:
- Fact table 'CashFlow'[Amount], [Date], [Scenario] = "Actual" | "Forecast"
- A marked Date table 'Calendar'[Date]
Return: (1) the measure, (2) a short comment on each step,
(3) how to guard against blanks in weeks with no actuals yet.
Do NOT give financial advice — reporting logic only.

Field noteStart with the daily cash position dashboard. It is the report Treasury opens every morning, so it earns trust fastest and becomes your demo centerpiece.

The vendor may bring polish and scale — be candid about that. But you own advantages a vendor structurally cannot match. Do not try to boil the ocean; build one polished dashboard on real data that is undeniable, and let it argue for you.

Differentiators you own — lean into them

Internal context & relationships — you know the accounts, the quirks, and the people; a vendor spends weeks learning what you already carry.
Faster iteration — you can turn feedback in hours, not change-order cycles.
Lower / no incremental cost — no license, SOW, or per-seat markup on top of tooling you already run.
Ownership & maintainability — the model and measures stay legible and fixable in-house instead of a black box.
Governance & security in-house — sensitive cash and bank data never leaves your tenant or its access controls.
No vendor lock-in — no dependency on an outside roadmap, renewal, or their staffing to keep the lights on.

Field noteConcede polish gracefully — then out-fit them. One real dashboard on live company data, delivered next week, beats a glossy vendor demo on sample data delivered next quarter.

Stakeholders fund momentum they can see. Package your model cleanup and new reports as a scoreboard, a rhythm, and a simple roadmap — framed in business outcomes, not technical effort.

Make the work legible to decision-makers

Before/after scoreboard — put the model metrics side by side: model size, refresh time, report count, broken visuals fixed. Concrete numbers read as progress.
Short demo cadence — a standing 15-minute biweekly showing one new thing that works, on real data, every time.
One-pager of wins — a single page a sponsor can forward: what shipped, what it saves, what’s next.
Simple phased roadmap — now / next / later, with the daily cash dashboard as the flagship “now” item.
Business framing — translate every item into a Treasury outcome (“faster morning cash decision,” not “optimized DAX”).
Name a sponsor — recruit one Treasury stakeholder who wants this to win and will say so in the room.

Prompt to try

You are my analytics-engineering mentor. Draft a one-page
stakeholder update for a corporate Treasury audience.
Inputs I'll paste: before/after model metrics, reports shipped
this sprint, and next-sprint plan.
Rules:
- Lead with business outcomes, not technical detail.
- Include a small before & after scoreboard table.
- End with a 3-item now/next/later roadmap.
- Tone: confident, concise, no jargon, no financial advice.

Field noteKeep a running before/after scoreboard from day one — the numbers you capture cleaning the model are the same numbers that win the bake-off later.

← Back to all roadmaps

Clean the model, modernize the reports —
drive it all with an agent, and win it for Treasury.

How to use this page

Are you thinking about this right?

Is this the right approach?

Source control & the safe-change loop

Set a baseline you can defend

Drive the agent without breaking things

Data model cleanup — the VertiPaq-driven sequence

Give the agent the right context

Find unused tables & columns

Remove dead tables safely

Shrink what stays: cardinality & encoding

Optimize measures & DAX

Re-verify and lock the gain

Modernize the reports — audit, redesign, build

Audit the current reports first

Modernize the look

Build new visuals with the agent

Performance & UX polish

Make it matter to Treasury — and win the room

Speak Treasury

High-value report & visual ideas

Win vs the external vendor

Show progress like a pro