Understand
GOVBRM is not another AI governance framework.
It is the operating layer between AI demand and AI delivery: one demand, one decision journey, many governance outputs. This page draws the boundary plainly.
What GOVBRM is and is not
Status: draft v0.1, GOVBRM original, not yet validated.. Written as two columns, ready for a web page.
Two columns
| GOVBRM is | GOVBRM is not |
|---|---|
| Demand-shaping. It finds the need beneath an AI request, states the value as a range with conditions, asks whether a model is needed at all, and gives every request one of six routes, including an honest decline. | A replacement for statutory governance. Privacy, equality, security, transparency, appraisal and service assessments keep their owners, their forms and their sign-offs. GOVBRM routes into them; it never signs for them. |
| Value orchestration. It puts a named business owner and a committed number on every item that passes Commit, books the Value Realisation Review at the same moment, and puts measured value beside the committed number when the review falls due. | A risk-management standard. It flags risk at the Shape gate and sets a lane by consequence, then hands the flags to the organisation's risk process and to frameworks such as NIST AI RMF, ISO/IEC 42001 or their equivalents. |
| Decision structuring. It gives the Request, Shape, Rank, Commit, Build and Review gates a fixed set of questions, scales and reasons, so that two people would reach the same decision and a sponsor could repeat it. | A security standard. It records which systems an AI item touches and what rung of autonomy it needs; the security case is written and assured under ISO/IEC 27001 or the organisation's own regime. |
| Governance routing. It sends each item into the governance the organisation already runs, in the right order and with the inputs each process needs, and records the reference each process returns. | A business-case standard. It produces the need sentence, typed and ranged benefits, alternatives and owner that a business case needs; the case itself follows the Green Book or the local appraisal rules. |
| Autonomy shaping. It picks the lowest rung of autonomy that solves the task and answers four agent questions before any money or build team is committed. | An AI management system. ISO/IEC 42001 and its equivalents govern the organisation's AI as a whole; GOVBRM feeds them one record at a time. |
| Adoption and value management. It plans, task by task, who will change how they work, how that will be seen, and the point at which the organisation admits it has not happened. | A procurement framework. It states the conditions on which a supplier would be supported and hands them to procurement, which runs its own process under its own rules. |
| Evidence orchestration. It keeps one demand record, versioned and signed, from request to realised value, so that audit, benefits management and the next request can all read the same facts. | An architecture method. It records rung, systems and data touched; architecture review decides the design. |
| An accreditation body. GOVBRM Academy issues its own certificates against a published rubric and a public registry. No external body has accredited them and no claim of accreditation is made. | |
| A government organisation. GOVBRM is an independent publication and a personal project, not affiliated with, endorsed by or produced on behalf of any government, department, agency or public body anywhere. |
Labels. The seven things GOVBRM is are GOVBRM original, drawing on Business Relationship Management practice (Established) and benefits management (Established), and none is yet validated. Each item in the right-hand column names an Established external domain with its own owners.
Why use GOVBRM rather than applying the frameworks directly
Because the frameworks are each right about their own question and silent about the line between them.
Applied directly, a single AI request meets a privacy form, a security questionnaire, a business case template, a procurement route, a transparency record, a service assessment and an AI assurance checklist, each with its own owner, its own timing and its own version of the facts. The request is described five or six times, slightly differently each time. Nobody owns the question of whether it should have been asked at all, whether it needs a model, what rung of autonomy it needs, where it ranks against everything else, who will own the outcome, or whether the value arrived.
GOVBRM turns fragmented requirements into one operating journey from request to realised value and learning. The request is captured once. The need, the value range, the risk flags and the rung are decided once, at the Shape gate, and each framework then receives the inputs it needs from that one record, in the order that makes sense. The decision to commit carries a named owner and a number. The review checks the number. What is learned changes how the next request is shaped.
The frameworks stay exactly where they are. What changes is that they are reached through one door, fed from one record, and joined by one question that none of them asks alone: did the value arrive.
Not yet demonstrated: no organisation has yet run the front door alongside its frameworks, so the reduction in re-keying, delay and contradiction is a Hypothesis until a pilot reports it.