Chapter 14 — Practice-on-your-own solutions

The one-paragraph counter-argument.

«The disclosure standard is not a claim about the team’s capability; it is an evidence trail the audience needs in order to challenge the artefact. When a decision-maker acts on a chart, they have to know what was human-authored, what was AI-generated, and what verification was applied — because those three facts determine how much weight to give the chart in their decision. Teams that don’t disclose are shipping artefacts that look authoritative but cannot be challenged: when the chart is wrong, the audience has no way to trace the error back to the responsible discipline, and no way to distinguish a genuinely careful piece of AI-directed work from a Copilot output that was accepted on first draft. That is a bigger reputational risk than the appearance-of-capability risk you’re worried about, because it is a risk that materialises only when the chart is already wrong — at which point the team looks reckless rather than uncredentialled. Disclosure is what makes AI-directed work defensible; the alternative is that every future error becomes a surprise the team has no recourse against. If the team next door is producing better-looking artefacts without disclosure, they are borrowing credibility from an appearance of hand-authorship they cannot actually cash. The first time one of their charts fails in a leadership readout, that credit line closes.»

Three moves the counter-argument makes.

1. Reframes disclosure as audience-facing, not analyst-facing. The colleague is thinking about disclosure as a signal about the team; the discipline is about giving the audience the evidence trail they need to make their own judgement.
2. Names the risk asymmetry. The «we look less capable» risk materialises immediately (visible on every artefact) but is low-severity. The «chart is wrong and we can’t trace the error» risk materialises rarely but is high-severity. Trading a high-severity rare risk for a low-severity constant risk is the right direction, not the wrong one.
3. Predicts the failure mode of the non-disclosing team. The credibility the non-disclosing team appears to borrow is contingent on their charts never being caught wrong. When one is (and one will be), the credit line closes with interest — the team’s reputation suffers more than a disclosing team’s would, because the audience feels misled rather than merely inconvenienced.

The move to avoid. Do not argue the counter as a moral claim («disclosure is the right thing to do»). Moral claims lose ground to competitive framing. Argue it as a risk-management claim: disclosure is a cheap constant cost that prevents a rare-but-catastrophic downstream failure. That framing wins the argument on the colleague’s own terms.

The escalation move — add decision-artefact-grade verification.

1. Rebuild the numbers from raw source in a second tool. Whatever tool produced the current dashboard (Power BI, Excel, direct SQL against the data warehouse), rebuild the load-bearing numbers in a second, independent tool. If the dashboard is Power BI against a semantic model, run a direct SQL query against the underlying fact tables and confirm the number reconciles. Divergence at this step is diagnostic: measure-definition drift, source-table drift, or filter-context drift — all three of which the previous analyst may never have caught because the recommendation-tier discipline doesn’t require this check.
2. Verify every derived metric against a finance-partner source of truth. Sit down with the finance partner who owns the forecast process. For every derived metric the dashboard exposes (revenue growth rate, churn, margin), confirm the formula matches the finance-partner definition and the finance-partner-reported number. Document each confirmation with the metric name, the definition, the finance-partner-reported number, and the date of confirmation.
3. Establish a version-controlled audit trail. Put the dashboard’s data model, measure definitions, and any DAX or SQL in a version-control system (Git, or the ADO/DevOps equivalent your organisation uses). Every future change to a load-bearing measure now has a commit, a diff, and an author. Without this, decision-artefact-grade verification is impossible to sustain past the first person who touches the dashboard.
4. Book a quarterly re-verification cadence. Decision artefacts drift because the underlying data model changes: new fields get added, source tables get renamed, business definitions get refined. A quarterly check — rerun the second-tool reconciliation, reconfirm with the finance partner, note any drift and its cause — is what keeps the verification from decaying to zero.

The disclosure amendment.

«Disclosure: originally authored 2026-XX-XX as AI-directed reference with recommendation-tier verification. Escalated 2026-07-XX to decision-artefact grade after review revealed six quarters of forecasts had been anchored to this dashboard’s outputs. Verification tier now includes cross-tool rebuild, finance-partner sign-off on every load-bearing measure, and version-controlled audit trail for the data model. Next scheduled re-verification: [date].»

The one message to the manager who inherited the workflow.

«Hi [manager], I inherited [name of dashboard] from [previous analyst] and reviewed the disclosure and role classification against how it’s actually being used. The disclosure says AI-directed reference with recommendation-tier verification, but I traced back and found six quarters of forecasts have been anchored to its numbers — which makes it a decision artefact by function, not a reference. That means it needs decision-artefact-grade verification (independent rebuild, finance-partner sign-off on every metric, version-controlled audit trail), which the current dashboard doesn’t have. Two asks: (1) I’ll do the escalation over the next two weeks and update the disclosure to name the role change; (2) can we agree that any forecasts anchored to this dashboard’s numbers before the re-verification date carry a caveat in the next planning committee? Not to redo the forecasts — the numbers may well be right — but to be transparent about which forecast cohort was built on unverified numbers vs verified numbers. Let me know if you want to walk through the plan.»

Why the message is worded this way. Three moves. First, it names the finding factually without assigning blame to the previous analyst (they authored to the tier they knew they were in). Second, it commits to the fix with a specific timeline rather than asking permission (the escalation is not optional; the ask is about the caveat process). Third, it explicitly separates «the numbers may well be right» from «the process that produced the numbers was not decision-artefact grade» — because those are two different claims and the manager needs both to make a defensible call on how to handle the historical forecasts.