London governance repository and assurance model

The London architecture repository is organised around seven sections, each serving a specific governance purpose. The sections are not arbitrary file categories. Each one answers a different type of governance question, and together they provide the operational memory that the governance model depends on.

Section 1: Architecture principles

The active principle set (12 principles), each with a name, statement, rationale, and implications statement. Reviewed quarterly by the Architecture Board. The principles answer the question: what are the fundamental rules that constrain design choices across the enterprise? A principle that cannot be used to settle a real design disagreement is too vague to keep.

Section 2: Target-state definitions

Current target architecture for each domain (business, information, application, technology), versioned and dated. Each definition links to the principles that justify it. The target states answer the question: what is the enterprise trying to become, and how does each domain contribute to that becoming?

Section 3: Decision log

Every significant architecture decision, with date, decision text, rationale, owner, and status. Updated within 24 hours of each board meeting. The decision log answers the question: why was this specific choice made? A delivery lead who was not in the room should be able to understand the reasoning behind any constraint by reading the log.

Section 4: Exception register

Active waivers and dispensations, each with the six elements defined in Module 54: deviation description, enterprise consequence, business justification, compensating controls, expiry condition, and governance approval. The exception register answers the question: where has the enterprise deliberately deviated from its own architecture, and what is being done about it?

Section 5: Compliance records

G21H compliance assessment results for each major delivery milestone, showing conformance category and any follow-on conditions. The compliance records answer the question: has the implementation been verified against the architecture, and what was the result?

Section 6: Architecture contracts

Active architecture contracts between the architecture function and delivery programmes, with conformance criteria and review dates. The contracts answer the question: what has the delivery team agreed to build, and what will be used to verify conformance?

Section 7: Board charter and operating procedures

The board charter, composition, decision rights matrix, meeting cadence, and standing agenda. Published and accessible to all stakeholders. The charter answers the question: who decides what, how often, and through what process?

The operational test

A repository is operational when it feeds decisions consistently rather than archiving documents passively. The test from Module 56 applies here: can the repository answer a real question faster than asking a senior architect from memory? If the answer is yes, the repository is operational. If the answer is no, the repository is a document store, regardless of how well-organised it looks.

To show the operating model as one system rather than separate descriptions, consider this scenario. A delivery programme requests approval to replace the existing connection-offer calculation engine with a new microservices-based architecture. The scenario walks through the complete governance path, touching every component of the operating model.

Step 1: Triage against the decision rights matrix

The domain architect assesses the change against the decision rights matrix from the board charter (Section 7). The replacement affects the customer domain and the information authority model, crosses two architectural domains, and changes a component that is part of the regulated connections process. Result: board-level decision. If the change had affected only one domain within the approved target state, the domain architect could have decided under Tier 2 governance from Module 56.

Step 2: Decision paper preparation

The domain architect prepares a decision paper showing alignment with architecture principles (Section 1), impact on the target architecture (Section 2), dependencies on other domains, and proposed conformance criteria. The paper is circulated 48 hours before the board meeting. The paper references the principles by name and the target-state views by version, creating traceability between the request and the governing framework.

Step 3: Board decision

The Architecture Board reviews the paper, asks about the OT/IT boundary impact, queries the cyber implications with reference to the NCSC Cyber Assessment Framework, and conditionally approves the change subject to an architecture contract and a G21H compliance review at the first delivery milestone.

Step 4: Architecture contract

The architecture function and the delivery programme agree an architecture contract (Section 6) specifying the conformance criteria, the review points aligned with delivery milestones, and the exception escalation path. Both sides sign the contract before delivery begins.

Step 5: Compliance review at first milestone

At the first milestone, a G21H compliance review assesses the implementation against the conformance criteria. The review identifies one non-conformance: the integration pattern deviates from the approved API gateway. A waiver is prepared with all six elements and submitted to the board. The compliance finding is recorded in Section 5.

Step 6: Repository update

The decision log (Section 3) records the board decision with rationale. The exception register (Section 4) records the waiver with expiry date and compensating controls. The compliance record (Section 5) captures the G21H conformance assessment. If the board approves a permanent change to the target state, Section 2 is updated. All updates are completed within 24 hours.

Step 7: Ongoing governance

The waiver expiry date is tracked. Before expiry, the architecture team confirms whether the API gateway performance issue has been resolved. If resolved, the waiver is closed. If not resolved, a fresh waiver request is submitted with updated justification. The board reviews at the next meeting.

In a regulated utility, release decisions should draw on three assurance streams, not just architecture compliance. A release that passes architecture compliance but fails cyber assurance is not safe. A release that passes cyber assurance but has no operational readiness assessment will not survive production. All three streams must contribute to the release decision.

Architecture assurance

Does the implementation conform to the target architecture? Are deviations managed through the waiver process with all six elements? Is the architecture contract satisfied? Has the G21H compliance review assigned a conformance category? This stream draws from repository Sections 4, 5, and 6.

Cyber assurance

Does the implementation meet the baseline security controls aligned with the NCSC Cyber Assessment Framework? Are OT/IT boundary controls in place? Has penetration testing been completed? Are monitoring and detection capabilities operational for the new component? In London, cyber assurance is particularly important because the OT/IT boundary directly affects operational safety.

Operational assurance

Can operations support the new component? Are monitoring, alerting, and incident response procedures in place? Has the operational readiness assessment been completed? Does the operations team have the skills and capacity to manage the new component alongside existing responsibilities? Operational assurance prevents the common failure of deploying a well-architected component that nobody can support in production.

How the board uses assurance signals

The Architecture Board receives all three assurance signals before approving a release. If any stream identifies a material concern, the board can attach conditions (proceed with additional monitoring), delay the release (hold until the concern is resolved), or escalate to the investment committee (if the concern has resource or budget implications). The board's authority to act on combined assurance signals is what makes the governance model protective rather than decorative.

A governance operating model is real when it produces observable behaviour, not just documentation. A well-drawn governance diagram can coexist with dysfunctional governance behaviour. Five behavioural tests distinguish real governance from decorative governance.

1. The right forum decides the right question at the right moment. Board items are triaged correctly against the decision rights matrix. Decisions do not queue unnecessarily, and they are not routed around the process by relabelling work as "operational improvements."
2. Repository artefacts feed board decisions consistently. Board members reference the decision log, exception register, and compliance records during discussions. The repository is a live input to governance, not a filing system that is updated after the fact.
3. Exceptions are visible, time-bounded, and reviewed before expiry. The quarterly waiver review is a standing agenda item. Expired waivers are either resolved, extended with fresh approval, or escalated. No waiver exists in an open-ended state.
4. Release conditions reflect combined assurance evidence. Architecture, cyber, and operational assurance all contribute to the release decision. A release is not approved based on architecture sign-off alone.
5. Delivery teams can describe their governance engagement. When asked when and how they engage with governance, delivery teams can provide a concrete answer (sprint-aligned reviews, architecture contract review points, exception escalation path) rather than "we avoid it where possible."

If all five behaviours are observable, the governance model is real. If any behaviour is absent, the governance diagram exists but the governance capability does not.

The London governance model is shaped by its specific context: a regulated utility with OT/IT boundary concerns, regulatory publication obligations, and cross-domain dependencies. Not every element transfers unchanged to a different enterprise. The following elements are transferable and the following need adjustment.

Transferable to most enterprise contexts

• The seven-section repository structure (principles, target states, decision log, exception register, compliance records, contracts, board charter).
• The governance scenario walkthrough pattern (triage, decision paper, board decision, contract, compliance review, repository update).
• The five behavioural tests for real governance.
• The three-tier governance weight model from Module 56 (full, lighter, minimal).
• The waiver process with six required elements.

London-specific elements that would need adjustment

• Regulatory context. The Ofgem obligations, ED3 framework, and LTDS publication requirements are specific to UK energy distribution. A different enterprise would substitute its own regulatory framework.
• OT/IT boundary governance. The three-stream assurance model (architecture, cyber, operational) reflects London's operational technology context. An enterprise without OT would simplify the assurance model, although the principle of combined assurance remains valid.
• Board meeting cadence. London's fortnightly board cadence reflects the pace of its transformation and the volume of cross-domain decisions. A smaller enterprise might meet monthly. A faster-moving enterprise might need weekly reviews with an emergency path.
• Repository tooling. The repository structure is platform-agnostic. Some enterprises will use a dedicated architecture management tool. Others will use a well-organised shared drive. The structure matters more than the tooling.