Architecture
Governance

The checklists that the people running architectural governance use — distinct from the technical review checklists those people apply to code or systems. The audience is the architect-on-duty, the ARB chair, the principal engineer reviewing an exception; the purpose is to make their work consistent, low-friction, and learn-from-itself across cycles.

The templates that structure the recurring artefacts of architecture governance — ADRs, RFCs, design specs, exception requests, post-incident reviews. Each template is an interface contract between the submitter and the reviewer: the submitter promises to address the questions the institution thinks matter; the reviewer commits to evaluating the answers given rather than asking unbounded new questions.

Who has the authority to decide, who must be consulted, who is informed, and who is accountable when a class of architectural decision is made — recognising that "the architects decide" is rarely a complete answer, that authority and accountability must match, and that the role architecture of the governance system is itself a designable property of how the organisation functions at scale.

The metrics that tell you whether the governance system itself is working — not whether the architecture it produces is good (that's a different question covered elsewhere), but whether the governance system is doing its job: making decisions in reasonable time, catching the issues it should catch, adapting as the organisation evolves, and earning its keep without becoming theatre.