Evidence
Are we operating GOVBRM properly?
A standard an organisation can hold itself to now, and be assessed against later. Not yet used anywhere.
GOVBRM Implementation Standard v0.1
Status: draft v0.1, GOVBRM original, not yet validated.. Not yet used anywhere.. Designed to become an assessed product later.
1. What this standard is
This standard says what an organisation must be able to show to state that it operates GOVBRM. It is written so that a self-declaration today can become an assessed conformance claim later, once an assessment scheme exists. No organisation has declared against it. No assessor has been trained. Not yet demonstrated.
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. Conformance with this standard therefore never means that an organisation has met any of those mechanisms. It means the organisation connects them to AI demand in the way the method describes.
Labels: Established (externally supported), Adapted (existing practice modified), GOVBRM original, Hypothesis (not yet validated). Unless marked otherwise, every requirement below is GOVBRM original and Hypothesis.
Words used:
- "Must" marks a mandatory practice. All must be met for a conformance claim.
- "Should" marks a recommended practice. Gaps must be recorded with a reason.
- "Evidence" is what an assessor would ask to see. It must exist, be dated and be findable.
2. Scope
The standard applies to the whole flow from a request for AI to the review of value after delivery, in any organisation that has public or regulated obligations. It applies to all three lanes. It does not apply to delivery quality, model performance or the internal workings of any governance mechanism it connects to.
An organisation may declare for a named unit rather than the whole. The declaration must say so.
3. Mandatory practices
| Ref | Practice | Evidence |
|---|---|---|
| M1 | One intake route for AI demand (the Request gate) is named, published internally and used. | The route itself. An internal notice. A sample of requests over the period, showing none entered by another route without being redirected. |
| M2 | A demand register records every request with owner, date, stage, gate, lane and status. | The register. Reconciliation against known AI work. |
| M3 | Three lanes (fast, standard, strategic) exist, with written criteria based on blast radius. Each request has a recorded lane and reason. | Lane criteria. Lane field and reason on each register entry. |
| M4 | The six gates (Request, Shape, Rank, Commit, Build, Review) are defined, each with a named decider and a named evidence set. | Gate definitions. Decision records showing decider, date, outcome and evidence set for each gate passed. |
| M5 | Every standard and strategic lane request completes the Discover and Assess stage canvases or equivalents (Opportunity, Intake, Demand Shaping, Readiness, Risk and Ethics) before the Shape gate. | Completed canvases stored against the register entry. |
| M6 | Every standard and strategic lane request has a value hypothesis (outcome, beneficiary, baseline, measure, date) and a named value owner before the Commit gate. | Value Map and Business Case canvases or equivalents. Value owner on the register. |
| M7 | The autonomy ladder is applied to every request, choosing the lowest rung that solves the task, and the four agent questions are answered where any agentic behaviour is proposed. | Agent Assessment canvas or equivalent. Recorded rung and reason. |
| M8 | Existing governance mechanisms are mapped to gates. Each gate names which mechanisms must have been engaged to pass. Mechanisms are engaged, not bypassed. | Governance map. Gate evidence sets. Confirmation from governance owners. |
| M9 | A Value Realisation Review is scheduled for every standard and strategic lane item, by default at month nine after go-live, earlier or later where the value curve needs it, and the reason for any change of date is recorded. | Review schedule on the register. Completed Value Realisation Review canvases for items that have reached the date. Findings reported to the sponsor. |
| M10 | The four role groups are defined and filled: relationship layer, sponsor, value owner, assurance owners. | Role definitions. Names against each role on the register. |
| M11 | A transparency record is drafted at Shape and finalised at Build for every standard and strategic lane item, using the disclosure standard that applies where the organisation operates. (Established: Algorithmic Transparency Recording Standard or equivalent.) | Transparency records. Link from the register. |
| M12 | Gate decisions can be reconstructed from the record by someone who was not present. | An assessor picks three entries at random and reconstructs each. |
| M13 | The organisation reviews its GOVBRM operation at least yearly, records the findings and changes something as a result. | Review record. Change log. |
4. Recommended practices
| Ref | Practice | Evidence |
|---|---|---|
| S1 | Fast-lane requests use a short intake and a pre-approved pattern list rather than full canvases, with the pattern list reviewed yearly. | Pattern list. Fast-lane intake form. Review date. |
| S2 | Demand is reviewed as a portfolio at a set rhythm using the Prioritisation canvas and Portfolio Heatmap. | Portfolio review records. |
| S3 | Commit conditions from governance owners are tracked to closure. | Condition register. |
| S4 | Stakeholder Impact, Adoption and Workforce Impact canvases are completed before Build and adoption is measured after it. | Canvases. Adoption measures. |
| S5 | Vendor Evaluation compares build, buy, reuse and wait before Commit and AI-specific contract terms are required. | Canvas. Contract clauses. |
| S6 | Prompt Governance is in place for shared models. | Canvas. Change records. |
| S7 | Product Ownership is assigned for every item that goes past Build. | Product Ownership canvas. Named owner. |
| S8 | Disbenefits and displaced costs are recorded and measured. | Value Map. Benefits Realisation canvas. |
| S9 | The board or executive states AI risk appetite by lane and reviews it yearly. | The statement. Review date. |
| S10 | A Capability Roadmap is maintained from the demand pipeline. | Canvas. |
| S11 | Role holders have been trained in the method by any route. | Training records. |
| S12 | Evidence is held as structured data and portfolio reporting is generated from it. | The data. A report. |
| S13 | Transparency is published at portfolio level including stopped items. | The publication. |
5. Governance of the operation
- One accountable executive owns the GOVBRM operation and signs the self-declaration.
- The relationship layer runs the front door and the gates day to day.
- Governance owners (security, privacy, equality, procurement, finance, architecture, transparency, legal and any AI management standard owner) are consulted on gate criteria and receive the evidence sets.
- Disputes about lane, gate outcome or value hypothesis escalate from the relationship layer to the sponsor, then to the accountable executive. The escalation route must be written down.
6. Roles
| Role group | What they must do | Evidence they exist |
|---|---|---|
| Relationship layer | Receive, log, shape and route demand. Convene gates. Maintain the register and the governance map. Work with business units ahead of demand. | Role definition. Named people. Register activity. |
| Sponsor | Own the request from Shape to Review. Decide at Commit within their authority. Receive Value Realisation Review findings. | Named on each register entry. Decision records. |
| Value owner | Own the value hypothesis, its baseline and measure. Report at the Value Realisation Review. Continue after the project team disbands. | Named before Commit. Review reports. |
| Assurance owners | Own the governance mechanisms the method connects to. Set what evidence a gate needs from their mechanism. Confirm at Commit and Build. | Governance map. Gate evidence sets. Conditions raised and closed. |
One person may hold more than one role on small items. The relationship layer and the value owner should not be the same person for standard and strategic lane items.
7. Measures
An organisation operating GOVBRM should be able to produce these numbers for the period. They are operating measures, not targets. GOVBRM original, Hypothesis.
| Measure | Source |
|---|---|
| Requests received, by lane | Register |
| Requests reshaped, merged or stopped before Commit | Register |
| Time from Request to Shape, and from Shape to Commit, by lane | Register |
| Items with a value owner named before Commit | Register |
| Value Realisation Reviews due, held, and held late | Register |
| Value hypotheses confirmed, partly confirmed, not confirmed at review | Review canvases |
| Commit conditions open and closed | Condition register |
| Items with a current transparency record | Register |
| Autonomy rung chosen, by rung | Agent Assessment canvases |
| Gate decisions reconstructable at spot check | Assessment |
8. Relationship to the maturity levels
The GOVBRM Maturity Model (initial version, validation required) has five levels: Reactive, Routed, Shaped, Value-managed, Orchestrated.
- Meeting all mandatory practices (M1 to M13) corresponds to level 3 Shaped, with the addition of M9 and M13 which reach into level 4.
- Meeting all mandatory and all recommended practices corresponds to level 4 Value-managed in every dimension, with several level 5 characteristics.
- Level 5 Orchestrated is not required for conformance and is not defined by this standard.
- An organisation at level 2 Routed may not claim conformance. It may state that it is "implementing GOVBRM" and name the mandatory practices still open.
Conformance and maturity are assessed separately. Conformance is a yes or no with exceptions. Maturity is a profile. Both use the same evidence.
9. Exceptions
- An organisation may record an exception to any mandatory practice where statute, policy or an existing governance mechanism requires something different. The exception must name the practice, the reason, the compensating arrangement and a review date.
- Exceptions are listed in the self-declaration. A declaration with more than three open exceptions to mandatory practices is a declaration of partial conformance and must say so.
- "We have not got round to it" is a gap, not an exception.
10. Review cadence
| What | When | Who |
|---|---|---|
| Self-declaration | Yearly, and after any major change to the operation | Accountable executive |
| Gate criteria and governance map | Yearly, and when a governance mechanism changes | Relationship layer with assurance owners |
| Lane criteria and fast-lane pattern list | Yearly | Relationship layer with risk and security owners |
| Register reconciliation against known AI work | Twice a year | Relationship layer |
| Value Realisation Review schedule | Monthly | Relationship layer |
| This standard | Yearly by the owner until a Method Council exists | Owner |
11. Continuous improvement
- Every Value Realisation Review, incident, near miss, audit finding and stopped item is a candidate improvement to the operation. The relationship layer keeps an improvement log.
- The yearly review (M13) must show at least one change made from the log.
- When an assessment scheme exists, assessment findings will feed a published change log for this standard.
12. Conformance self-declaration template
GOVBRM Implementation Standard v0.1: conformance self-declaration
Organisation or unit: [name]
Scope: [whole organisation | named units]
Period covered: [from] to [to]
Declaration date: [date]
Accountable executive: [role title, not personal name if published]
We declare that, for the scope and period above, this organisation operates
GOVBRM in conformance with the mandatory practices M1 to M13 of the GOVBRM
Implementation Standard v0.1, except as listed below.
Exceptions to mandatory practices
| Ref | Reason | Compensating arrangement | Review date |
|---|---|---|---|
Recommended practices not met
| Ref | Reason | Planned date or "not planned" |
|---|---|---|
Maturity profile (from the GOVBRM Maturity Model, initial version)
Organisational level: [1 to 5]. Dimension levels: [list].
Evidence location: [where an assessor would start]
This is a self-declaration. It has not been independently assessed. The
GOVBRM Implementation Standard is an initial, unvalidated standard and no
assessment scheme yet exists. This declaration makes no claim about
conformance with any law, regulation or other standard.
Signed: [accountable executive role title]13. Intended path to an assessed product
This is a plan, not a commitment. Hypothesis throughout.
- Publish v0.1 for comment after owner approval.
- Run the first self-declarations with volunteer organisations and record what was unclear.
- Revise to v0.2 with calibrated evidence requirements.
- Define assessor competence, an assessment procedure and a conflict of interest rule.
- Establish a Method Council to own the standard.
- Open assessed conformance, with a public list of assessed organisations alongside the credential registry at govbrm.com/verify.
14. Change log
- v0.1, initial draft for owner review. Not published. Not yet used anywhere.
Director of Studies, GOVBRM Academy