From reactive to orchestrated.

GOVBRM Maturity Model, initial version, validation required

Status: draft v0.1, GOVBRM original, not yet validated.

1. Purpose and standing

This model describes how well an organisation shapes AI demand before it becomes AI delivery. It sits on the GOVBRM method: six stages (Discover, Assess, Prioritise, Design, Adopt, Realise), six gates (Request, Shape, Rank, Commit, Build, Review), three lanes (fast, standard, strategic), the autonomy ladder and the Value Realisation Review. GOVBRM is the operating layer between AI demand and AI delivery. It orchestrates existing governance (business cases, appraisal, procurement, security assurance, privacy and equality assessments, transparency records, service assessments, AI management standards) and never replaces them. The maturity model follows the same rule: it measures how well those existing mechanisms are connected to demand, not whether the organisation has adopted GOVBRM branding.

Labels used in this document:

• Established: externally supported by a published framework or common practice.
• Adapted: an existing practice modified for AI demand.
• GOVBRM original: created for this method.
• Hypothesis: not yet validated.

The five-level ladder is Adapted (staged maturity ladders are a long-standing pattern in capability and process maturity models). The dimensions, descriptors, questions and scoring are GOVBRM original and Hypothesis. No organisation has been assessed against this model. Not yet demonstrated.

2. The five levels

Design rules (GOVBRM original):

• A level is held only when every dimension is at that level or above. A single dimension at a lower level pulls the organisational level down. This is deliberate: an organisation with strong value management and no risk practice is not value-managed, it is exposed.
• Level 3 is the intended target for most organisations within 12 to 24 months of starting. Level 5 is not a target for everyone. Hypothesis.
• Fast-lane work is not exempt. A mature organisation can show that fast-lane requests were routed and shaped in proportion to their blast radius, not skipped.

3. Dimensions and characteristics

Each dimension lists what should be observable at each level. Characteristics are written so that an assessor could ask "show me". Where a characteristic depends on an external framework the label says so. Everything else is GOVBRM original and Hypothesis.

3.1 Demand management

3.2 Governance integration

3.3 Value management

3.4 Risk

3.5 Adoption

3.6 Architecture

3.7 Procurement

3.8 Transparency

3.9 Public value

3.10 Evidence

3.11 Organisational capability

4. Assessment questionnaire

Each dimension has three questions and each question has five descriptors. Pick the one that best describes current practice, not intended practice. Where two apply, pick the lower. Evidence must exist for the level chosen (see section 6). The same questions are machine-readable in the maturity model data file for the website self-assessment.

Questions are GOVBRM original and Hypothesis.

4.1 Demand management

D1. How does AI demand enter the organisation?

1. By any route, unrecorded.
2. Through one named intake route, logged.
3. Through the intake route, with the Opportunity, Intake and Demand Shaping canvases (or equivalents) completed before Shape.
4. As above, and demand is reviewed as a portfolio at a set rhythm.
5. As above, and the relationship layer engages business units before requests exist.

D2. What happens to a request after it is received?

1. Whatever the recipient decides.
2. It is acknowledged, logged and given a lane.
3. It is shaped, and requests merged, reshaped or stopped before Rank are counted.
4. It is ranked with comparable scoring against other demand.
5. Its pattern informs capacity, skills and supplier planning.

D3. How are lanes assigned?

1. There are no lanes.
2. Lanes exist but assignment is informal.
3. Lane assignment is recorded with a blast radius reason.
4. Lane assignment is audited and challenged at Rank.
5. Lane criteria are reviewed using outcome evidence.

4.2 Governance integration

G1. When do existing governance mechanisms find out about AI work?

1. Late, by audit or incident.
2. At intake, by notification.
3. At each gate, as named pass criteria.
4. At Commit, as tracked conditions.
5. Continuously, from one shared evidence set.

G2. How much governance work is repeated between mechanisms?

1. Unknown.
2. Most artefacts are rewritten for each mechanism.
3. Artefacts are reused between gates.
4. Conditions and findings are shared across mechanisms.
5. One evidence set feeds every mechanism.

G3. Who sets the gate criteria?

1. Nobody.
2. The relationship layer alone.
3. The relationship layer with governance owners consulted.
4. Governance owners approve the criteria.
5. Governance owners co-design and jointly review the criteria.

4.3 Value management

V1. How is intended value stated?

1. In the pitch, if at all.
2. As an outcome and a beneficiary.
3. As a hypothesis with baseline, measure and date.
4. As above, tracked after Build.
5. As above, compared at portfolio level with the original ranking.

V2. Who owns value?

1. Nobody.
2. The sponsor by default.
3. A named value owner before Commit.
4. A value owner who reports at the Value Realisation Review.
5. Value owners who are accountable at portfolio level.

V3. Does a Value Realisation Review happen?

1. No.
2. Sometimes, informally.
3. Planned for every standard and strategic lane item.
4. Held (default month nine, earlier or later if the value curve needs it) with findings reported.
5. Findings change future Rank decisions and funding.

4.4 Risk

R1. How is AI-specific risk identified?

1. It is not.
2. A screen at Request sets the lane.
3. The Risk and Ethics canvas is completed before Shape.
4. Risk is reviewed at every gate and at the review.
5. Risk practice is integrated with enterprise risk and an AI management standard.

R2. Are mitigations enforced?

1. No.
2. Recommended.
3. Conditions on Commit.
4. Tracked to closure with a named owner.
5. Verified after Build and at the review.

R3. Is AI risk appetite stated?

1. No.
2. Implied by policy.
3. Stated by the executive for each lane.
4. Stated and reviewed yearly by the board or executive.
5. Stated, reviewed and tested against incidents.

4.5 Adoption

A1. Is workforce impact assessed?

1. No.
2. Users are named.
3. Workforce Impact and Adoption canvases are completed before Build.
4. Adoption is measured against plan.
5. Workforce planning is driven by the pipeline.

A2. Are training and support funded?

1. No.
2. Sometimes.
3. Always, before Build.
4. Reviewed at the Value Realisation Review.
5. Shared across the portfolio.

A3. Are affected staff and their representatives consulted?

1. No.
2. Told.
3. Consulted before Build where policy or statute requires.
4. Consulted as a matter of practice.
5. Standing partners in the method.

4.6 Architecture

T1. How is the autonomy level chosen?

1. By the supplier or team.
2. Architecture is informed.
3. The autonomy ladder and four agent questions are applied for every request.
4. Autonomy decisions are compared across the portfolio.
5. Autonomy policy is a maintained product.

T2. Is data readiness assessed?

1. No.
2. Informally.
3. On the Readiness canvas before Shape.
4. With shared data preferred and recorded.
5. As part of maintained data governance.

T3. Is prompt and model governance in place?

1. No.
2. Ad hoc.
3. Prompt Governance canvas for each shared model.
4. Reviewed after change.
5. Integrated into reference architecture.

4.7 Procurement

P1. When does procurement learn of AI demand?

1. When a contract is needed.
2. At intake.
3. Before Commit, with the Vendor Evaluation canvas.
4. With contract value linked to the value hypothesis.
5. Through category strategy fed by the pipeline.

P2. Are build, buy, reuse and wait compared?

1. No.
2. Sometimes.
3. Always, before Commit.
4. With the comparison revisited at review.
5. With portfolio reuse preferred and recorded.

P3. Are AI-specific contract terms required?

1. No.
2. Sometimes.
3. Required for every AI contract.
4. Monitored during the contract.
5. Improved from supplier performance evidence.

4.8 Transparency

X1. Can you say where AI is in use?

1. No.
2. Partly, from the register.
3. Yes, with transparency records for standard and strategic lanes.
4. Yes, kept current after change.
5. Yes, published proactively including stopped items.

X2. Are people told when they interact with AI?

1. No.
2. Sometimes.
3. Always, by design.
4. With tested explanations and challenge routes.
5. With public and regulator scrutiny invited.

X3. Can information requests be answered from the record?

1. No.
2. With effort.
3. Yes, for most items.
4. Yes, within the statutory or policy period.
5. Yes, and answers are published.

4.9 Public value

U1. Is fairness and harm assessed?

1. No.
2. Beneficiaries and possible harms are named.
3. Equality, fairness and accessibility impact assessed before Shape.
4. Public value measures sit beside efficiency measures.
5. Public value evidence is reported to the board and public.

U2. Can AI be stopped on public value grounds?

1. There is no route.
2. In theory.
3. Yes, at any gate, with the decision recorded.
4. Yes, and stop decisions are reviewed.
5. Yes, and stop decisions are published.

U3. Are affected groups involved?

1. No.
2. Identified.
3. Consulted before Build.
4. Involved in measuring value.
5. Involved in setting gate criteria.

4.10 Evidence

E1. How are gate decisions recorded?

1. Not recorded.
2. Date, decider, outcome.
3. With a defined evidence set per gate.
4. With evidence quality checked.
5. As structured data used for reporting.

E2. Could someone who was not there reconstruct a decision?

1. No.
2. With help.
3. Yes, from the record.
4. Yes, including the conditions and their closure.
5. Yes, within days, to audit or inquiry standard.

E3. Is evidence reused across governance mechanisms?

1. No.
2. Copied by hand.
3. Reused between gates.
4. Reused across mechanisms.
5. Generated from one structured source.

4.11 Organisational capability

C1. Who owns AI demand?

1. Nobody.
2. A named relationship layer.
3. Defined roles: relationship layer, sponsor, value owner, assurance owners.
4. Roles with succession and cover.
5. Roles measured and reported.

C2. Are practitioners trained in the method?

1. No.
2. Some, informally.
3. All role holders trained (any route).
4. Training refreshed and assessed.
5. Practitioners contribute to the method.

C3. Is the method itself reviewed?

1. No.
2. When something goes wrong.
3. Yearly.
4. Yearly with recorded changes.
5. Continuously, with improvements shared outside the organisation.

5. Scoring method (initial calibration parameter)

Everything in this section is an initial calibration parameter. It is GOVBRM original, Hypothesis, and expected to change after the first assessments. Not yet demonstrated.

1. Score each question 1 to 5 using the descriptor chosen.
2. Dimension score: the lowest question score in that dimension. (The weakest link rule. Averages hide gaps.)
3. Dimension level: equal to the dimension score.
4. Organisational level: the lowest dimension level across all eleven dimensions.
5. Organisational profile: report all eleven dimension levels alongside the organisational level. The profile matters more than the single number.
6. Indicative average: the mean of the eleven dimension scores, reported to one decimal place, used only to show direction of travel between assessments. It never sets the level.

• Whether the weakest-link rule should tolerate one dimension one level below the others (a "one exception" rule).
• Whether dimension scores should be the lowest question or a median.
• Whether any dimension should be weighted.
• Whether the fast lane should be assessed separately.

6. Evidence requirements per level

A level can be claimed only when the evidence exists and can be shown to an assessor. Self-assessment without evidence is an opinion and should be labelled as such. GOVBRM original, Hypothesis.

Assessment period: the previous twelve months unless the organisation is younger than that in the method, in which case the period since the front door opened.

7. Maturity report template

Use this structure for a self-assessment or a facilitated assessment. Keep the report short. The profile table is the product.

# AI demand maturity assessment: [organisation or unit]

Status: [self-assessment | facilitated assessment], [date], assessment period [from] to [to].. Assessed against GOVBRM Maturity Model v0.1 (initial version, validation required).

## 1. Summary
Organisational level: [1 to 5] [name]
Indicative average: [x.x] (direction of travel only)
Previous assessment: [level and date, or none]
Scope: [whole organisation | named units | named lanes]

## 2. Profile
| Dimension | Level | Lowest question | Evidence seen | Evidence missing |
|---|---|---|---|---|
| Demand management | | | | |
| Governance integration | | | | |
| Value management | | | | |
| Risk | | | | |
| Adoption | | | | |
| Architecture | | | | |
| Procurement | | | | |
| Transparency | | | | |
| Public value | | | | |
| Evidence | | | | |
| Organisational capability | | | | |

## 3. What is holding the level down
[The one to three dimensions that set the organisational level, and why.]

## 4. What is working
[Dimensions above the organisational level, and what can be reused from them.]

## 5. Recommended next actions
[From section 8 of the model, tailored. Owner, date, and the evidence that will show it is done.]

## 6. Evidence register
[List of documents, records and systems examined, with location.]

## 8. Caveat
This assessment uses an initial, unvalidated model. Scores are for internal improvement and comparison with the organisation's own earlier assessments. They are not a certification and make no claim about the organisation relative to any other.

8. Recommended next actions per level

These are starting points. Each organisation should tailor them in the report. GOVBRM original, Hypothesis. Time horizons are planning guesses, not evidence.

From level 1 Reactive to level 2 Routed (typical horizon 3 to 6 months)

• Name the relationship layer. One person is enough to start.
• Open a single intake route and tell the organisation about it. Close the others.
• Start the demand register. Capture owner, date, status and lane for every request, including the ones already in flight.
• Agree the three lanes and a simple blast radius screen with the risk and security owners.
• Tell governance owners (business case, security, privacy, equality, procurement, transparency) that the front door exists and what they will receive from it.

From level 2 Routed to level 3 Shaped (typical horizon 6 to 12 months)

• Adopt the Discover and Assess canvases (or map existing equivalents). Use them on every standard and strategic lane request.
• Define the Request, Shape and Commit gates with named evidence sets and named deciders.
• Define the four role groups and fill them for current work.
• Train role holders. Any route counts.
• Apply the autonomy ladder and the four agent questions to every request.
• Draft transparency records at Shape.
• Record every gate decision so someone else could reconstruct it.

From level 3 Shaped to level 4 Value-managed (typical horizon 12 to 18 months)

• Set the portfolio rhythm and run the Rank gate on comparable scoring.
• Require a value hypothesis with baseline, measure, date and owner before Commit.
• Schedule the Value Realisation Review for every standard and strategic lane item (default month nine). Hold the first one and use it at the next Rank gate.
• Track Commit conditions to closure.
• Ask the board or executive to state AI risk appetite by lane.
• Measure adoption and treat shortfall as a value risk.
• Link contract value to the value hypothesis.
• Review the method yearly and record what changed.

From level 4 Value-managed to level 5 Orchestrated (typical horizon 18 to 36 months)

• Map every governance mechanism to the gate evidence set and remove duplicate collection.
• Move the register to structured data and generate portfolio reporting from it.
• Publish transparency at portfolio level, including stopped items.
• Maintain reference architecture and autonomy policy as products fed by demand.
• Bring procurement, people and architecture in as standing partners with category, workforce and platform plans driven by the pipeline.
• Share improvements to the method outside the organisation.
• Consider external assessment against an AI management standard, with the gates as the operating flow.

At level 5 Orchestrated

• Reassess yearly. Level 5 is held only while the evidence is current.
• Test the layer against incidents and near misses and change gate criteria.
• Contribute to the method's validation.

9. Known limitations

• No organisation has been assessed. Descriptors may be miscalibrated in either direction.
• The weakest-link rule is a design choice, not a validated finding.
• The model assumes the organisation has, or is subject to, existing governance mechanisms. Very small organisations may find levels 4 and 5 disproportionate.
• The model does not assess delivery quality. That belongs to delivery methods and service standards.

10. Change log

• v0.1, initial draft for owner review. Not published. Not yet used anywhere.

Director of Studies, GOVBRM Academy

Self-assessment

Thirty-three questions, three per dimension. Choose the descriptor that fits today, not the one you are aiming for. The tool scores by the weakest-link rule and keeps your answers in this browser only; print the report for your own records.