D2 — what would change the decision

The portfolio review is running late.

One pilot has been live for nine months. It started cleanly enough: a plausible use case, a willing sponsor, a vendor roadmap, a benefits case that survived the first investment forum. The team can still recite the expected savings. They know the original process pain. They know the launch date, the training completion rate, and the number of licences provisioned.

Adoption is weak.

Not zero. Weak. Enough use to keep the story alive, not enough to prove the work has changed. The evaluation results are mixed. The unit cost has drifted. The risk team has added conditions. The business owner says the workflow still matters, which is true. The technology owner says the next release will improve performance, which may also be true.

Then someone asks the question the portfolio has been avoiding.

What evidence would justify ending it?

The room gets quieter. Not because the question is hostile. Because the organisation has built the front door and not the exit. It can ask for a benefits case before funding. It can rank ideas, allocate seed money, run a pilot, and report activity. But it cannot say what would change the decision once the work has become familiar, sponsored, and mildly politically protected.

That is accumulation. It is the same recurring conversation from the opening essay in this thesis, just seen through the value lens. The artefacts exist. The governance forums meet. The work has a name. But when the organisation needs the operating model to change a decision, the evidence is not ready.

D2 — AI-to-Value in the framework is the discipline that stops demand becoming a queue of plausible ideas. Its differentiator is D2.2, stop/pivot evidence. Without it, the portfolio accumulates. With it, the portfolio has negative space.

The sharp claim is this: stop/pivot evidence is what makes an AI portfolio governable. Most maturity models can test whether a benefits case exists. Fewer test whether stop criteria exist before the pilot begins, while the work is still reversible and before the sponsor has had to defend it twice.

D2.1, use-case discovery and demand pipeline, is the front end of that discipline. It is not an ideation workshop that produces a longer list. It is intake, triage, ownership, and evidence. The operating model has to see enough of the queue early enough to choose deliberately: which workflow, which affected stakeholder, which judgement is being assisted or automated, which data dependency is material, which value hypothesis is being tested, and who owns the decision to proceed. A search assistant, a claims triage workflow, a finance reconciliation tool, and an autonomous remediation agent do not belong in the same queue just because all four use AI. The demand pipeline has to separate them before the organisation starts inventing exceptions for each one.

D2.2 is where the discipline hardens. Before the pilot begins, the operating model should name the stop and pivot signals: weak adoption, poor evaluation, cost drift, risk movement, and strategic mismatch. These are not post-hoc reasons to make an awkward ending look rational. They are pre-commitments. Weak adoption means the tool is not becoming part of work, even if access numbers look tidy. Poor evaluation means performance is not good enough for the decision, task, or control class. Cost drift means the economics have moved since the benefits case was written. Risk movement means the residual-risk profile has changed, or a control assumption has failed. Strategic mismatch means the use case no longer fits the organisation’s AI posture, even if it remains technically interesting.

That last point matters. A portfolio without negative space is not a portfolio. It is an accumulation with better labels.

D2.3, the AI portfolio register, is the artefact that survives executive turnover. Not a decorative inventory of models. A working memory. It should connect use case, owner, vendor or model dependency, data source, risk tier, affected stakeholder, value hypothesis, evaluation evidence, human review design, cost profile, operating status, decision history, and stop/pivot trigger. The register is what lets a new CFO, CIO, risk chair, or business executive see concentration, duplication, drift, and exception patterns without reconstructing the last eighteen months from meeting papers. In the Strategy pillar, it is the difference between locally reasonable commitments and an accountable portfolio.

There is a boundary here. The operating model should not pretend to answer specialist questions it is not qualified to answer.

Accounting treatment for AI costs belongs with the people applying AASB and IFRS requirements to the organisation’s facts. Capitalisation, expense recognition, impairment, cloud arrangements, internally generated software, and vendor implementation costs are not solved by a maturity model. The operating-model obligation is narrower and more useful: make sure the value case, cost profile, decision history, and stop criteria are visible enough for the accounting judgement to be made properly.

The same is true for adoption. Statisticians and product analytics specialists should determine the methodology: cohort design, activity thresholds, task completion measures, counterfactuals, confidence, survivorship bias, and the difference between access, active use, abandonment, override, and realised value. The operating model should insist that adoption has a method before adoption is used as evidence. Otherwise the portfolio review ends up debating anecdotes.

Vendor lock-in has its own specialist edge. Procurement and commercial counsel should determine unwind costs, termination rights, data extraction obligations, renewal traps, transition assistance, service credits, and embedded dependency risk. Those costs belong in the stop calculation. A pilot that is cheap to start but expensive to unwind is not cheap. It is deferred commitment.

Privacy also shapes value. Where personal information is part of the use case, the Privacy Act 1988 (as amended by the Privacy and Other Legislation Amendment Act 2024) can affect what data may be used, how it may be used, what transparency is required, and whether the claimed value rests on an assumption the organisation cannot sustain. Privacy specialists own that legal judgement. The operating model owns the evidence trail that lets the judgement arrive before the benefits case hardens.

This is why the cascade in the dependency map closes into a loop, not a line. D2.2 depends on D12.1 adoption instrumentation in Pillar 3 Enablement. Stop/pivot evidence cannot be stronger than the instrumentation underneath it. If the organisation cannot distinguish licence access from active use, active use from task completion, task completion from value realised, and value realised from risk movement, then the stop criteria will be ceremonial. The value gate needs telemetry from the work itself. Then the telemetry needs to be governed by the value gate.

That loop is the operating model doing its job.

The useful CFO question is not only whether the pilot still has a benefits case. Benefits cases can survive long after the work has stopped deserving capital, attention, risk appetite, or executive patience. The better question is sharper.

What would change the decision?

Not what would justify continuing. What would justify stopping.