Architecture Governance

How the ecosystem evolves — how future work is designed, reviewed, approved, and incorporated. Where the Operating Model describes how work flows today, this section describes how change is governed. Evidence-first; implemented governance is separated from recommended future governance.

This is the Architecture Governance section. Its pages:

1 · Governance objectives

1. Keep the ecosystem coherent as it grows — one layered model, one capability registry, one glossary.
2. Make change deliberate and reversible-on-paper — every significant decision is an ADR.
3. Preserve the evidence-first philosophy — decisions cite documented evidence; uncertainty is recorded, not invented (Principle 8).
4. Protect reuse — prevent capabilities being trapped in venture repos and prevent duplication (Capability Reuse Map).
5. Keep humans accountable — capture, review, approval, and architectural governance stay human (Operating Principles O1–O2).
6. Keep the portal true — documentation stays synchronised with reality (today manual; future automated).

2 · Architectural decision-making process

Grounded in the ADR practice already in use (ADR 0001):

graph LR
    P["Proposal<br/>(problem + options)"] --> G{"Four-part test<br/>(Principle 7)"}
    G -->|fails| WAIT[Wait / reject — record why]
    G -->|passes| DEC["Draft ADR<br/>(status: proposed)"]
    DEC --> REV["Architecture review<br/>(checklist)"]
    REV -->|not ready| DEC
    REV -->|accepted| ACC["ADR accepted<br/>+ update affected pages"]
    ACC --> INC["Incorporated<br/>(digests, diagrams, registries, changelog)"]
    ACC -.superseded later.-> NEW[New ADR supersedes]

The four-part test (a hard gate — Principle 7): a new concept, service, or repository ships only if it (a) solves a real, present problem, (b) reduces future coupling, © has a clear owner, and (d) is explainable in one paragraph. All four, or it waits.

3 · Ownership responsibilities

4 · Review process

Significant changes pass an architecture review before acceptance (see the full Architecture Review Lifecycle). This mirrors the ecosystem’s existing phase-gated, reviewable change discipline (Principle 10; WIL “each phase ends with an architecture review and does not continue until reviewed”).

5 · Approval workflow

graph TD
    A[Change proposed] --> B{Significant?<br/>structural / cross-repo / new repo / new capability}
    B -->|no| C[Normal change — follow update conventions + Definition of Done]
    B -->|yes| D[ADR proposed]
    D --> E[Architecture review vs checklist]
    E --> F{Founder approves?}
    F -->|no| D
    F -->|yes| G[ADR accepted → incorporate → changelog]
    C --> H[Consistency check — no orphans / dead links]
    G --> H

Non-negotiable approvals (evidenced): nothing customer-facing is auto-sent (O2); no knowledge asset becomes canonical without founder approval; no ADR is “accepted” without human sign-off.

6 · Architectural quality gates

A change must pass all applicable gates:

7 · Change management principles

• Deliberate over fast — the four-part test and review gate apply to structure.
• Immutable decisions — accepted ADRs are superseded, never edited (ADR practice).
• One-way, versioned change — evolve by publishing new versions, not mutating consumed artefacts (O9).
• Reversible on paper — every direction change is an ADR that a later ADR can supersede.
• Preserve the human boundary — automation may expand within gates; approval stays human.

Implemented vs recommended governance

Related

• Architecture Principles · Operating Principles · Decisions (ADRs)
• Governance decision: ADR 0006