Method Specification v1.0.

GOVBRM Method Specification v1.0

Status: draft v1.0, GOVBRM original with adapted and established components labelled throughout, not yet validated.

1. Purpose

This document is the written specification of the GOVBRM method. It fixes, in one place and under change control, what the method is: its stages, gates, canvases, lanes, models and rules. Everything else GOVBRM publishes (the AI Demand Toolkit, the AI Demand Framework, the courses, the workbook, the crosswalk and the provenance page) is an expression of what is written here. Where a published artefact and this specification disagree, this specification is the reference and the artefact is corrected.

It exists for four readers:

• practitioners who run a front door and want the rules stated once, without the teaching around them;
• sponsors, finance partners and assurance colleagues who want to know what the method will ask of them and when;
• people building tools, courses or assessments on the method, who need a stable definition to build against;
• reviewers, now and later a Method Council, who need a baseline to argue with and a process for changing it.

Label: GOVBRM original.

2. Scope

In scope:

• demand for AI capability arriving in a public or regulated organisation by any route, including demand nobody has yet requested;
• the decisions between an observation and a funded build, and between a handover and a review of the value that arrived;
• the records those decisions leave behind, and what those records feed.

Out of scope, and never replaced by GOVBRM:

• business cases and their appraisal method;
• procurement and commercial assurance;
• security assurance and information risk;
• privacy and data protection assessments;
• equality, anti-discrimination and human rights assessments;
• transparency records and registers;
• service and delivery assessments;
• AI management systems such as those built to ISO/IEC 42001;
• delivery methods, whether agile, stage-gated or product-led;
• the engineering of the solution itself.

GOVBRM is written for public and regulated organisations anywhere. Wherever this document names a framework it is as one version of a type of instrument; the reader substitutes their own jurisdiction's equivalent.

Label: GOVBRM original (the scope boundary); Established (the existence and purpose of the governance it routes into).

3. Definitions

4. Principles

Each principle is a rule the method is built to enforce. Where two principles pull against each other, the earlier one in this list takes precedence.

5. The six stages

A stage is a phase of work. Each stage hangs on a gate: the stage's work produces what the gate needs to answer its question. Items do not have to pass through every stage; the lane decides which stages are touched and how deeply.

Between the stages sit the three value conversations, which are bookable and do not belong to any one gate: value planning (what will this be worth, to whom, by when), value realisation (is the number arriving, and who is changing how they work) and value optimisation (what would make it worth more or cost less). Label: Adapted (BRM value lifecycle).

6. The six gates

A gate is a decision with a question, a signatory and a record. Four of the six gates sit with nobody in most organisations; the relationship layer signs them. Delivery signs Build. Anyone may knock at Request.

Gate rules:

1. A gate is signed by a role that exists in the organisation. If no role exists, the ownership table names one before the gate is signed.
2. A gate is never signed with an open Significant flag unless the residual risk has been accepted in writing by the accountable executive.
3. Where a gate returns an item, it returns it to a named canvas with a named reason, not to a queue.
4. Every gate record is re-run when scope, rung or data source changes. Label: GOVBRM original.

7. The twenty canvases

Each canvas leads to one decision, names the role that completes it, and states which canvases feed it and which it feeds. All twenty are GOVBRM original in their fields, prompts and scales; the practices several of them adapt are noted in the label column.

Lane columns: M is mandatory in that lane; O is optional; C is conditional, mandatory when the stated condition holds; P is a portfolio-level canvas run periodically, not per item. Section 8 sets the conditions.

Each canvas ends in a decision with a fixed set of options. The options are part of the specification; adding, removing or renaming one is a change under section 17.

Canvas conventions (GOVBRM original): one page when printed; a stated completing role and the people in the room; inputs from and feeds into stated on the canvas; a "good looks like" hint against every field; a decision and rationale field written for someone who was not in the room.

8. Routing rules for the three lanes

The lane is decided at the Request gate from the intake record and confirmed or changed at the Shape gate once the rung is known. It can move up at any gate; it moves down only at Shape or Review with the reason recorded.

8.1 Criteria

Seven criteria decide the lane. Each is answered from the intake record and the demand shaping canvas, not inferred from the size of the request.

Label: GOVBRM original; the thresholds inside each cell are Hypothesis.

8.2 Assignment rule

1. An item is fast lane only if every criterion gives the fast lane answer and the request matches a published playbook pattern (canvas 10).
2. An item is strategic lane if any one criterion gives the strategic lane answer.
3. Everything else is standard lane.
4. A Significant exposure rating from canvas 05 moves an item to the strategic lane regardless of the other criteria.
5. The lane sets the minimum. The relationship layer may raise an item's lane with a recorded reason; it may not lower one below the rule.

Label: GOVBRM original.

8.3 What each lane carries

Label: GOVBRM original; the proportion of demand that lands in each lane is Not yet demonstrated.

9. Risk methodology

GOVBRM's risk methodology is a triage and routing system. It decides how much attention an item needs and which assessments it goes to, in which order. It does not replace a full risk assessment, weigh likelihood against impact quantitatively, or produce a residual risk figure. The assessments it routes to do that.

9.1 Dimensions

Each dimension is assessed separately and recorded separately. No dimension is derived from another, and no single dimension stands in for the rest. An item is triaged on the dimensions that apply; the highest floor among the raised flags sets the exposure rating.

9.2 Autonomy is one dimension of risk

Autonomy is recorded as one dimension among the nineteen above. It is not a proxy for risk and it does not set the exposure rating on its own. A rung 2 system that drafts letters to every citizen or customer of a service carries more consequence, scale and reputational exposure than a rung 4 agent that tidies an internal filing queue. Governance that tiers by autonomy alone will over-govern the second and under-govern the first. GOVBRM raises attention at rung 4 and 5 (the four agent questions become mandatory) and still assesses consequence, scale, reversibility, affected population and detectability separately from the rung, whatever the rung is. Label: GOVBRM original; as a claim about better outcomes, Hypothesis.

9.3 Flags, floors and exposure rating

Canvas 05 carries sixteen flags in two groups: governance flags (sensitivity class, personal data, third-party processing, cross-boundary sharing, live procurement, executive or political decision-making, public-facing output, security assurance) and ethics and accountability flags (bias potential, consequential and hard to reverse, human oversight and override, explainability, accountability chain undefined, training data provenance, proportionality, AI policy compliance). A flag is ticked when the statement is true or when nobody in the room can say it is false.

Each flag carries a floor, the lowest exposure rating an item can receive while the flag is raised. Four flags carry a Significant floor: cross-boundary sharing, live procurement, public-facing output, and consequential and hard to reverse. The rest carry an Elevated floor. The exposure rating is the highest floor among the flags raised; the count of flags does not change it.

Label: the flag list is Adapted (from privacy, equality, transparency and AI assurance practice); the floor mechanism and the three ratings are GOVBRM original; the assignment of floors to flags is Hypothesis.

9.4 Routing to assurance

A raised flag routes to the assessment that owns the dimension, in this order: privacy or data protection first where personal data is involved, because it constrains everything after it; then equality and human rights; then security; then commercial; then transparency; then the service or delivery assessment. The shaped item's single description is the input to each. Label: GOVBRM original (the ordering); Established (the assessments).

10. Autonomy model

10.1 The ladder

Five rungs. Cost per task, blast radius and difficulty of evaluation rise with each rung.

Label: GOVBRM original.

10.2 The shaping rule: the lowest rung that solves the task

At the Shape gate the relationship layer records the rung requested, the lowest rung that solves the need sentence, why the rung below cannot do it, and what a wrong output touches at the chosen rung. If nobody in the room can name what the rung below cannot do, the rung comes down and the answer is rewritten. Everything downstream is governed at the chosen rung. The line that matters most is between a system that answers and a system that acts; most requests that arrive as "build us an agent" describe a system that answers. Label: GOVBRM original.

10.3 The four agent questions

Asked of anything that acts rather than only answers, at the Commit gate, before a build team exists. They are the same four questions as canvas 11, the practitioner guide and the courses. Each answer becomes a condition on the commitment and an input to security assurance.

1. What is it allowed to touch? What it reads, writes, sends and spends, and against which systems. The list is the scope; everything not on it is out of scope until a person adds it.
2. Who approves what it does, and at which step? Every action gets an approver that is a role that exists, and a threshold at which a person steps in.
3. What does a single task cost, and what does that become at volume? A range per task, at planned volume and at peak, in the unit the supplier charges.
4. How will we know it worked, before we find out that it did not? A pre-live evaluation set with awkward cases, a live success signal with an owner, and a design that makes a silent failure visible.

Two conditions follow from the answers and sit on the same canvas: who can stop it, how quickly and what happens to work in flight; and how its actions are rolled back and repaired. If a condition cannot be met, the rung comes down. An agent that cannot be stopped is an assistant with a person pressing the button, and the method prefers that to an agent nobody can stop. Label: GOVBRM original.

11. Value model

12. Adoption model

Deployment is not use. The adoption model is what stands between a go-live and a number that arrives.

13. Review model

13.1 The Value Realisation Review

The Review gate is where the loop closes. The review sets the measured value from the benefits ledger against the committed number, records what was not expected, reviews the shaping decisions that were made, decides what to do with the capability now, and writes what returns to the front door. Its decision is one of Scale, Continue, Adjust, Stop or Retire, and the gate result is passed or held. The relationship layer signs; a change to funding is countersigned by the sponsoring executive. Label: GOVBRM original.

13.2 Timing

The default review point is month nine after go-live, booked at the Commit gate. Nine months of use is long enough for adoption to have happened or failed, and short enough that the people who shaped the item are still in post and the money can still be redirected. It is a default, not a rule. The review date is fixed on canvas 14 before the build is funded, and it is set from the item's own value curve.

Where the factors disagree, consequence and benefits dependency take precedence. Whatever date is chosen, an interim reading of the benefits ledger (18) is taken at the earlier of month three or the first expected outcome. Label: GOVBRM original; the month-nine default is Hypothesis.

13.3 What returns to the front door

14. Governance interfaces

GOVBRM produces inputs; it does not produce the assessments. The table names the interface, what GOVBRM hands over and at which gate.

15. External framework relationships

This section is short by design. The detailed mapping, principle by principle, is the crosswalk and its compiler, which are separate documents under their own change control.

GOVBRM sits before and around the frameworks an organisation already uses. Each of them answers its own question; GOVBRM answers the one before them: which AI demand should receive attention, money, autonomy and change, and did the value arrive.

GOVBRM reproduces none of their text, is not certified against, affiliated with or endorsed by any of their publishers, and claims none of their names.

16. Provenance

GOVBRM was written by one practitioner from the receiving end of AI requests in public and regulated organisations, worked out in public through the GOVBRM Newsletter during 2026, and turned into the toolkit, the framework, the courses and the workbook. Written from practice is a claim about provenance, not about validation, and the two are kept apart.

What is original to GOVBRM: the six-gate front door as a model of AI demand rather than of delivery; the twenty canvases, their fields, prompts and scales; the autonomy ladder as a shaping question; the four agent questions; the three lanes and the seven routing criteria; the flag and floor mechanism; the three value conversations as distinct bookable conversations; the month-nine default and the review that sends lessons back; the AI Value Operating Model.

What is adapted: demand shaping, value realisation and value optimisation from the BRM Body of Knowledge; value as a range and benefit typing from appraisal and benefits management; adoption measured from the work from change management; intake as a record from service management; stakeholder and workforce analysis from change and consultation practice.

What is established and used as found: the assessments GOVBRM routes into and the questions they ask.

Label: statement of fact about provenance, GOVBRM original.

17. Known limitations

1. The risk methodology is a triage and routing system. It records nineteen dimensions separately but does not weigh them against one another quantitatively, does not produce a residual risk figure and does not model systemic or velocity effects. It routes to the assessments that do.
2. The value range is not an appraisal and the business case canvas does not replace a full business case.
3. Public value, and who has no seat at the table, is asked of every item but not yet modelled.
4. Sustainability and enterprise architecture are routed to, not covered.
5. The lane criteria thresholds, the readiness weights, the prioritisation weights, the vendor bands, the flag floors and the month-nine default are initial calibration parameters.
6. The method is founder-led. There is no Method Council or external advisory group yet.
7. Accessibility of the published artefacts is built to WCAG 2.2 AA and has not been audited.
8. Non-UK framework mappings were made from the publicly documented purpose of each instrument, not from a principle-by-principle reading.

Label: GOVBRM original (statement of limitations).

18. Evidence status

No pilots have run. No controlled comparisons, inter-rater studies or outcome measurements exist. No customer, testimonial or endorsement exists. The verification registry is empty. None of this is concealed in any published artefact.

19. Change-control process

19.1 Versioning

The specification carries a semantic version: major.minor.patch.

A breaking change requires a migration note stating what a practitioner mid-way through an item must do. Published artefacts state which specification version they implement.

19.2 Approval

19.3 Evidence-driven change

Calibration parameters change on evidence from the Review gate and from implementations, recorded anonymised. A change to a label from Hypothesis to Adapted or Established requires the evidence to be cited in the version history. A label never moves in that direction on argument alone.

Label: GOVBRM original.

20. Version history