AI Capability Maturity Assessment · Part II. The eight domains
Domain 7 · Ways of working layerUse-case delivery and value
In this chapter
Covers how AI use cases are chosen, delivered, scaled and measured: intake and portfolio, lifecycle execution, pilot-to-scale discipline, benefits realisation and reuse.
What this domain covers
Covers how AI use cases are chosen, delivered, scaled and measured: intake and portfolio, lifecycle execution, pilot-to-scale discipline, benefits realisation and reuse.
Governance without delivery produces no value, and delivery without discipline produces pilots that never scale. A single intake, a graduation test for pilots and benefits measured against baselines are what turn enthusiasm into services that work, and what let leaders decide where to invest next on evidence rather than advocacy.
Initiatives for this domain are run through the Use-case portfolio and value playbook.
The domain at each level
A summary of what the domain looks like at each level. Each criterion below has its own descriptors and pass tests: score the criteria, not this summary. The domain score is calculated from them (see domain aggregation).
| Level | What it looks like |
|---|---|
| 1Initial | Use cases start wherever someone has budget or enthusiasm. There are no stages, no graduation test and no benefit measures. Each team builds from scratch. |
| 2Repeatable | An ideas list exists but is not the required route. Pilots report results without criteria set in advance and rarely scale. Benefits are estimated in business cases but not measured. Sharing is informal. |
| 3Defined | All use cases enter through one intake and a prioritised portfolio with recorded refusals. Every use case shows its lifecycle stage with evidence. Pilots have success criteria and decision dates, benefits are baselined and reported, and a maintained pattern catalogue is checked before new builds. |
| 4Managed | Intake and graduation decisions are made within target times on measured results. Benefits are measured from operational data and reported quarterly, shortfalls included. Scaled services have operating owners before go-live. Reuse is measured, and patterns carry assurance evidence that shortens gates. |
| 5Optimising | The portfolio is balanced across value, risk and capability building, and realised benefits are reinvested deliberately. Proven patterns scale to new areas in weeks as shared services, and lifecycle data is used to remove friction each year. |
Risks when it is weak
- Pilot purgatory: money and goodwill spent on pilots that never decide
- Benefits claimed but never realised or measured
- Duplicated effort as teams build the same thing
- Lost executive and staff confidence when value cannot be shown
- Investment directed by advocacy rather than evidence
The five criteria
| No. | Criterion | Importance | Scope |
|---|---|---|---|
| 7.1 | Portfolio and intake | Core | Enterprise arrangement, applied locally |
| 7.2 | Lifecycle execution | Enabling | Local practice |
| 7.3 | Pilot to scale | Enabling | Local practice |
| 7.4 | Benefits realisation | Core | Local practice |
| 7.5 | Reuse and patterns | Enabling | Enterprise arrangement, applied locally |
Criterion 7.1
Portfolio and intake
Ideas for AI use enter through one intake that captures value, risk and feasibility, assigns a tier, and routes them to a prioritised portfolio with deliberate choices about what to do, defer or refuse.
Why it matters
A single front door is what lets an organisation see its AI demand, apply its strategy and risk appetite consistently, and refuse what does not fit. Without it, use cases start through vendor deals and executive requests that nobody assessed.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | There is no intake process. AI use cases start wherever someone has budget, a vendor offer or enthusiasm, and nobody sees the whole picture. | The starting point: no test. |
| 2Repeatable | An ideas list or form exists but is not the required route. Prioritisation follows the seniority of the sponsor, and refusals are not recorded. | An ideas list or intake form exists. |
| 3Defined | All new AI use cases enter through a single intake that records value, risk, feasibility and tier. The portfolio is prioritised against the strategy’s priority areas at least quarterly, and deferred and refused ideas are recorded with reasons. | Intake records for every use case started in the last 12 months, quarterly prioritisation minutes, and a log of deferred and refused ideas with reasons. |
| 4Managed | Intake decisions are made within a target time, prioritisation uses consistent value and risk scoring, and demand, throughput and conversion are measured. | Intake cycle-time measures, and a scoring model applied consistently across a sample of five intake decisions. |
| 5Optimising | The portfolio is balanced deliberately across value, risk and capability building. Operating use cases generate new candidates, and staff ideas receive a visible response. | A documented portfolio balance review, and published responses to staff ideas. |
Evidence to request
Documents
- Intake form or workflow
- Prioritisation criteria and scoring model
Records of it operating
- Intake records
- Portfolio prioritisation minutes
- Deferred and refused log
- Throughput measures
In systems
- Intake workflow (optional)
In the evidence request: ER-1-05, ER-7-01.
Interview probes
- Use-case owner or business leadHow did your idea become a funded use case?
- Executive sponsor or Chief AI OfficerWhat was the last AI idea the organisation decided not to pursue, and why?
- Frontline staffIf you had an idea for using AI in your work, where would you take it?
Staff survey items: S05 If my team wanted to use AI for a new task, I know the process we would follow.
Red flags
- Use cases arriving through vendor deals that bypass intake
- No idea has ever been refused
- Executive requests exempt from intake
Standards crosswalk
- ISO/IEC 42001
- Clause 6.2Annex A.5
- EU AI Act
- No direct mapping
- NIST AI RMF
- MAP 1
Government and organisation editions
Australian Government edition
Policy v2.0’s responsible AI practices require a process for adopting AI use cases by 15 December 2026. The APS AI Plan encourages agencies to identify and adopt use cases deliberately, and the portfolio is where that happens.
References
- Policy for the responsible use of AI in government, version 2.0A process for adopting AI use cases
- AI Plan for the Australian Public Service 2025
Organisation edition
ISO/IEC 42001 requires AI objectives and planning to achieve them. The NIST AI RMF MAP function starts by establishing the context and intended purpose of each AI system.
References
- ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management systemClause 6.2
- Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1MAP 1
- Guidance for AI AdoptionUnderstand impacts and plan accordingly
In Governing Intelligence
In the AI governance assessment: A prioritised use-case portfolio exists, and the governance committee reviews it.
Initiatives that lift it
Criterion 7.2
Lifecycle execution
Use cases actually move through the defined lifecycle from intake to retirement, with evidence for each stage and scheduled reviews in operation, rather than the lifecycle existing only on paper.
Why it matters
A lifecycle standard that use cases bypass is worse than none, because it creates false assurance. What matters is whether every use case can show where it is and what evidence moved it there.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | Use cases have no defined stages. Their status is whatever the project manager reports, and nothing records how they reached production. | The starting point: no test. |
| 2Repeatable | Stages are tracked for some projects, but many use cases in operation skipped stages, and nobody owns retirement. | Stage status is recorded for at least some use cases. |
| 3Defined | Every use case on the register shows its current lifecycle stage with evidence for completed stages. Stage transitions are recorded with dates, and operating use cases have scheduled reviews. | A current stage with evidence links for at least 90 percent of register entries, and a scheduled review date for every operating use case. |
| 4Managed | An independent function samples stage evidence. Overdue reviews and stalled stages are escalated, and use cases are retired deliberately with records. | An independent sample review of stage evidence, escalation records for overdue reviews, and at least one retirement record. |
| 5Optimising | Lifecycle data is analysed to remove friction (where use cases stall, which evidence is redundant), and the lifecycle is improved on that evidence each year. | A documented lifecycle improvement based on cycle-time or friction analysis. |
Evidence to request
Documents
- Lifecycle standard (from 3.3)
Records of it operating
- Register stage fields with evidence links
- Stage transition history
- Review schedule
- Retirement records
- Independent sample review
In systems
- Register workflow showing stage transitions
In the evidence request: ER-3-03, ER-7-02.
Interview probes
- Use-case owner or business leadWhat stage is your use case in, and what evidence moved it there?
- Executive sponsor or Chief AI OfficerWhich use cases are overdue for review right now?
- Risk, compliance and internal auditWhen was a use case last retired, and how was it done?
Red flags
- Everything has been ‘in pilot’ for more than a year
- Production systems with no stage record
- No use case has ever been retired
Standards crosswalk
- ISO/IEC 42001
- Annex A.6
- EU AI Act
- No direct mapping
- NIST AI RMF
- MANAGE 1MANAGE 4
Government and organisation editions
Australian Government edition
The AI technical standard’s Discover, Operate and Retire phases give the stage structure. Existing use cases not yet assessed must be brought into line with Policy v2.0 by 30 April 2027, which requires knowing their current stage.
References
Organisation edition
ISO/IEC 42001 Annex A covers the AI system life cycle from requirements to retirement.
References
In Governing Intelligence
Initiatives that lift it
Criterion 7.3
Pilot to scale
Pilots have a graduation test (value, risk, operability and whole-of-life cost) set at the start, and are scaled, reshaped or stopped on evidence within a set time.
Why it matters
Most AI pilots neither fail nor succeed: they continue. A graduation test set in advance forces a decision, protects the organisation from scaling something that does not work, and frees resources from pilots that never will.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | Pilots run indefinitely or simply end when funding stops, with no success criteria set and no decision recorded. | The starting point: no test. |
| 2Repeatable | Some pilots report results, but success criteria were not set in advance, and scaling decisions depend on enthusiasm. | At least one pilot has a written results report. |
| 3Defined | Every pilot has success criteria and a decision date set at the start. A graduation test covers value, risk, operational readiness and whole-of-life cost, and decisions to scale, reshape or stop are recorded. | Pilot charters with success criteria and decision dates for every pilot started in the last 12 months, and recorded graduation decisions. |
| 4Managed | Graduation decisions are made on measured results within the planned time, scaled services have an operating owner and support model before go-live, and the rate and time to scale are tracked. | Graduation decisions made within the planned time, operating handover records for scaled services, and time-to-scale measures. |
| 5Optimising | Pilots are designed for scale from the start using shared patterns, lessons from stopped pilots are captured and reused, and a proven pattern can be scaled to a new area in weeks. | A pattern scaled to a new area with its elapsed time recorded, and a lessons register from stopped pilots. |
Evidence to request
Documents
- Pilot charter template with success criteria and decision date
- Graduation test
Records of it operating
- Pilot charters
- Graduation decisions
- Operating handover records
- Time-to-scale measures
In the evidence request: ER-7-03.
Interview probes
- Use-case owner or business leadWhat result would have stopped your pilot?
- Executive sponsor or Chief AI OfficerWhich pilots did not graduate, and what did the organisation learn from them?
- CIO or CTOWhat has to be in place before a pilot becomes a supported service?
Red flags
- Pilots running for more than a year with no decision
- Success defined after the results came in
- Scaled services with no operating owner
Standards crosswalk
- ISO/IEC 42001
- Annex A.6
- EU AI Act
- No direct mapping
- NIST AI RMF
- MANAGE 1
Government and organisation editions
Australian Government edition
Governing Intelligence identifies the step from approving each output to supervising autonomous action as the point where most pilots fail to scale. The graduation test should check readiness for that step explicitly.
References
Organisation edition
The NIST AI RMF expects a documented decision on whether a system achieves its intended purpose and whether deployment should proceed.
References
In Governing Intelligence
Initiatives that lift it
Criterion 7.4
Benefits realisation
Benefits are defined in measurable terms before investment, baselined before go-live, measured in operation and reported, including benefits not realised.
Why it matters
AI is sold on productivity. Unless benefits are baselined and measured, the organisation cannot tell which investments work, cannot stop the ones that do not, and loses the case for the next investment.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | Benefits of AI are asserted in general terms such as productivity or efficiency, and nobody measures whether they arrive. | The starting point: no test. |
| 2Repeatable | Business cases estimate benefits, but no baselines are taken, and post-implementation measurement is rare or anecdotal (‘users like it’). | At least one business case states expected AI benefits. |
| 3Defined | Each funded use case has measurable benefits with a baseline taken before go-live, an owner and a measurement method. A benefits register is reported to the executive at least twice a year. | A benefits register with baselines, owners and methods for every funded use case, and two executive reports in the last 12 months. |
| 4Managed | Benefits are measured from operational data, not surveys alone, and reported quarterly against targets with shortfalls and their causes. Benefit evidence informs scale and stop decisions. | Quarterly benefit measures drawn from operational data, reported shortfalls, and a scale or stop decision citing benefit evidence. |
| 5Optimising | Benefits are tracked at portfolio level with attribution methods agreed with finance, and realised benefits are reinvested deliberately and reported externally where appropriate. | A finance-agreed attribution method, and a documented reinvestment decision. |
Evidence to request
Documents
- Benefits definitions and measurement methods
- Attribution method agreed with finance
Records of it operating
- Benefits register with baselines
- Quarterly benefit reports
- Decisions citing benefit evidence
In systems
- Operational data sources for benefit measures
In the evidence request: ER-7-04.
Interview probes
- Use-case owner or business leadWhat was the baseline before AI, and what does the measure show now?
- Executive sponsor or Chief AI OfficerWhich AI investment delivered less than planned, and what was done about it?
- Risk, compliance and internal auditHas anyone independent checked the benefit figures?
Staff survey items: S22 AI has made a measurable difference to the quality or speed of my work.
Red flags
- Benefits measured only by licence uptake or logins
- No baseline taken before go-live
- Time saved claimed with no account of what the time was used for
Standards crosswalk
- ISO/IEC 42001
- Clause 6.2Clause 9.1
- EU AI Act
- No direct mapping
- NIST AI RMF
- MANAGE 1
Government and organisation editions
Australian Government edition
The APS AI Plan integrates AI use cases and benefits into standard reporting, and the PGPA Act’s performance framework expects agencies to measure what their activities achieve.
References
- AI Plan for the Australian Public Service 2025Use cases and benefits in standard reporting
- Public Governance, Performance and Accountability Act 2013
Organisation edition
ISO/IEC 42001 requires AI objectives to be measurable and their achievement to be monitored and evaluated.
References
In Governing Intelligence
Initiatives that lift it
Criterion 7.5
Reuse and patterns
Proven solutions are captured as reusable patterns, templates, components and services, each with an owner and its assurance evidence, and new use cases are expected to reuse them.
Why it matters
Reuse is where AI value compounds. A pattern that already carries its assessment, tests and controls lets the next use case pass gates faster and more safely than a fresh build.
The five levels
| Level | What it looks like | To score this level |
|---|---|---|
| 1Initial | Every use case is built from scratch, and teams do not know what others have built. | The starting point: no test. |
| 2Repeatable | Some sharing happens informally (a community of practice or a shared prompt library), but nothing is maintained or expected. | A shared library or community of practice exists. |
| 3Defined | A maintained catalogue of approved patterns (for example a retrieval assistant, document summarisation or case triage), templates and shared components exists with owners, and intake checks for reuse before a new build. | A catalogue with owners, and intake records showing the reuse check. |
| 4Managed | Reuse is measured (the share of new use cases built on catalogue patterns), patterns carry their assurance evidence so reuse shortens gates, and patterns are versioned and retired. | A reuse measure, and a gate shortened because a pattern carried its assurance evidence. |
| 5Optimising | Patterns are run as shared services with self-service onboarding, contributions come from across the organisation, and improvements in reuse and time to deliver are reported. | A pattern run as a shared service with self-service onboarding records. |
Evidence to request
Documents
- Pattern catalogue with owners and versions
Records of it operating
- Intake reuse checks
- Reuse measures
- Gate records citing pattern evidence
In systems
- Shared components or services (optional)
In the evidence request: ER-7-05.
Interview probes
- Engineering or architecture leadWhat did the last use case reuse from earlier work?
- Use-case owner or business leadWere you shown existing patterns before you started?
- CIO or CTOWhich shared AI components do you maintain, and who funds them?
Red flags
- Several teams building the same assistant
- Prompt libraries with no owner
- Patterns reused without their assurance evidence
Standards crosswalk
- ISO/IEC 42001
- Annex A.4
- EU AI Act
- No direct mapping
- NIST AI RMF
- No direct mapping
Government and organisation editions
Australian Government edition
The APS AI Plan provides shared whole-of-government services such as GovAI, and agencies can reuse patterns and guidance from the DTA and other agencies before building their own.
References
- AI Plan for the Australian Public Service 2025GovAI shared services
Organisation edition
Reusable patterns are an efficiency practice rather than a compliance requirement; carrying assurance evidence with each pattern is what makes reuse safe.
References
In Governing Intelligence
Initiatives that lift it
In Governing Intelligence
The framework chapters that describe the practice this domain measures, and the governance assessment questions that test it at a higher level.
- 5.3Risk appetite and the use-case portfolio
- 11.2A phased roadmap
- 11.3Measuring progress
- 13.2Find the AI you already have
In the AI governance assessment: A prioritised use-case portfolio exists, and the governance committee reviews it.
This assessment is not legal advice and is not a certification. Obligations and dates were checked against official sources on 15 October 2026; confirm them against the source instruments, which can change.