Implement
One record, many outputs.
A concept, not a product. It will be built when the pilots show which parts of the method earn automation.
GOVBRM platform architecture concept
Status: draft v0.1, GOVBRM original, Hypothesis.. Not to be built yet.
Why this document exists
The method runs today on twenty canvases stored on the practitioner's own device, exported and filed by hand into the organisation's records. That is deliberate. This document records what a platform would be, so that pilot evidence can be tested against it, and states why building it now would be premature.
The concept in one sentence
One demand record producing multiple governance outputs.
A request is captured once. Everything the organisation's governance later needs, the privacy assessment, the equality assessment, the transparency record, the security case, the commercial case, the appraisal, the service assessment, the architecture review and the AI assurance record, is generated from that one record and its evidence, rather than re-keyed into separate forms by separate people at separate times.
The flow
| Step | What happens | Canvases today | Output of the step |
|---|---|---|---|
| AI request | A request or opportunity is captured as facts | 01, 03 | Demand record opened with an identifier |
| Shape | The need beneath the request, the value range, the counterfactual, the route | 02 | Need sentence, value hypothesis, route |
| Evidence | Readiness scored on what was seen | 04 | Readiness score, weakest dimension |
| Risk and autonomy | Flags, floors, exposure rating; the lowest rung that solves the task; the four agent questions | 05, 11 | Risk rating, lane, rung, accountable role |
| Route | Lane and gate sequence set by consequence | 02, 10 | Lane, playbook match, gate plan |
| Governance outputs | The record is compiled into each receiving process's input | 05, 09, 11, 12, 13, 14 | Draft inputs for: data protection impact assessment, equality assessment, transparency record (Algorithmic Transparency Recording Standard or equivalent), security assurance, commercial and procurement, appraisal (Green Book or equivalent), Service Standard assessment, architecture review, AI assurance (ISO/IEC 42001, NIST AI RMF or equivalent) |
| Decision | Rank and Commit gates; a named owner and a committed number | 06, 07, 08, 09 | Gate records with reasons |
| Delivery | Build under the rung and controls committed | 12, 13 | Supplier conditions, prompt governance, build status |
| Adoption | Who changes how they work and how it is seen | 15, 16, 17 | Adoption measures, task changes, released time |
| Benefits | The evidence ledger fills | 18 | Measured value with confidence |
| Value Realisation Review | Measured value beside the committed number; Scale, Continue, Adjust, Stop | 19 | Review decision, countersigned |
| Learning | What the front door must learn | 10, 20 | Playbook and roadmap changes |
| New demand | The loop closes; learning reshapes the next request | 01 | Next demand record |
Data model sketch
Entities, with the relationships that matter. Fields are illustrative, not a schema.
| Entity | Key fields | Relationships |
|---|---|---|
| DemandRecord | identifier, requester role, date, need sentence, route, lane, status | has many CanvasVersions, GateDecisions, GovernanceOutputs, Handoffs; belongs to Portfolio |
| CanvasVersion | canvas number and title, version, signed by role, signed date, content | belongs to DemandRecord; immutable once signed |
| ValueHypothesis | benefit type, unit, lower bound, upper bound, conditions, owner role | belongs to DemandRecord; measured by BenefitReading |
| RiskFlag | flag, floor, exposure rating, accountable role, data and population affected | belongs to DemandRecord; feeds GovernanceOutput |
| AutonomyAssessment | rung, systems touched, decisions taken alone, human review, evaluation plan | belongs to DemandRecord |
| GateDecision | gate (Request, Shape, Rank, Commit, Build, Review), decision, reasons, decided by role, date | belongs to DemandRecord |
| GovernanceOutput | type (privacy, equality, transparency, security, commercial, appraisal, service, architecture, AI assurance), generated fields, source canvas versions, receiving reference, status | belongs to DemandRecord; compiled from CanvasVersions by a Compiler rule set |
| CompilerRule | governance output type, target field, source canvas and field, transformation, jurisdiction | many per GovernanceOutput type; versioned; the cross-framework compiler |
| Owner | role, not person, scope of sole decision | attached to DemandRecord from Commit; a person is resolved from the client's directory at run time, never stored in the record |
| BenefitReading | date, measured value, confidence, measurement owner role, baseline reference | belongs to ValueHypothesis |
| ReviewDecision | decision, the two facts that decided it, next review date, countersigned by role | belongs to DemandRecord |
| Playbook | request category, routing rules, lane defaults, learned from ReviewDecisions | belongs to Portfolio |
| Portfolio | organisation unit, heatmap position, value map quadrant, roadmap horizon | has many DemandRecords |
Design rules. Every signed canvas is immutable; changes create a new version. Every governance output records which canvas versions it was compiled from. Every decision records the role that took it and the reasons. The record holds roles, not names.
Integration points
All Hypothesis; none built.
| Point | Direction | Purpose |
|---|---|---|
| Service management or intake platform | In | Requests arrive from the channel the organisation already uses; the record is opened, not duplicated |
| Records management system | Out | Signed canvas versions and gate records filed under the organisation's retention schedule |
| Privacy and equality assessment tooling | Out | Pre-filled assessment drafts from the RiskFlag and DemandRecord fields |
| Transparency register | Out | Draft transparency record entry |
| Security and architecture assurance workflow | Out | Rung, systems touched, controls |
| Procurement and contract management | Out and in | Supplier conditions out; contract reference and exit terms in |
| Portfolio and benefits management | Out and in | Committed numbers out; benefit readings in |
| Identity and directory | In | Roles resolved to people at run time, with the organisation's own access control |
| AI management system (ISO/IEC 42001 or equivalent) | Out | AI inventory entry and impact assessment inputs |
| Model providers and AI platforms | None | The platform never calls a model with record content by default; any assistant feature is a separate, opt-in decision with its own assessment |
Privacy by design
- Data minimisation: the record stores roles, need sentences, scores, flags and decisions. It does not store the personal data that the AI system itself will process, only the categories and populations affected.
- The organisation is the controller of its own records. A platform would be deployed inside the organisation's own tenancy or as a processor under a data processing agreement, never as a shared pool across organisations.
- Requester identity is held as a role and a directory reference; the record can be exported without names.
- Immutable, versioned evidence supports audit without editing history.
- Retention follows the organisation's schedule, set at deployment; deletion is a first-class operation.
- Any feature that sends record content to a model provider is off by default and passes through the organisation's own AI governance before it is enabled.
Why it waits for pilot evidence
- The compiler rules are the product. Which canvas fields map to which governance inputs, in which jurisdiction, is exactly what a pilot must discover. Building the mapping before a pilot would encode guesses.
- The lanes, scales and thresholds are initial calibration, published to be argued with. Software fixes them; a pilot should move them first.
- The value of "one record, many outputs" depends on governance owners accepting compiled inputs. That acceptance is Not yet demonstrated.
- The method runs today on canvases and exports. No client has yet said that the manual path is the constraint.
Gate for starting: at least one pilot with counts of requests routed, governance outputs accepted by their owners without re-keying, and a client willing to co-design the compiler rules on its own frameworks.