Skip to content

SOP-041 — Architecture review & ADR routing

Guide

<!-- last-reviewed: 2026-06-01 · owner: CPTO (Chief Product & Technology Officer) -->

SOP-041 — Architecture review & ADR routing

SOP · owner: CPTO. Layer: SOP/Runbook (docs/canon.md). The CPTO reviews Engineering/AI-Systems architecture proposals with org-wide impact for strategic fit and coherence; implementation mechanics stay with Engineering/Operations. ADR conventions live in docs/adr/ and CONTRIBUTING.md — not restated here.

Interface Contract

  • Inputs: architecture proposal ← from <Engineering or AI Systems Director> · trigger: review requested
  • Outputs: architecture decision (approve/revise/ADR) → to Engineering Director · trigger: review passed
  • Outputs: architecture-decision notification (operational burden) → to COO · trigger: architecture decision notified
  • Outputs: architecture-decision notification (audience-facing) → to CGEO · trigger: architecture decision notified
  • Outputs: load-bearing decision (ADR) → to Archivist · trigger: artifact approved
  • Handoff trigger (in): the Engineering Director (or AI Systems Director, for AI components) surfaces an architecture proposal with org-wide or cross-cluster impact
  • Handoff trigger (out): the CPTO issues a decision (approve / revise-with-Engineering / escalate) and notifies the COO/CGEO where the decision creates operational load or audience-facing consequence
  • Definition of Done before handoff:
    • [ ] Proposal assessed on all four lenses: technical soundness, strategic fit, operational burden on the Process Engineer, AI-system coherence
    • [ ] Counterparty verified against the live .claude/agents/ directory (never the legacy roster; innovation-lead is retired)
    • [ ] COO notified in writing at the point of decision if material operational load (new process/CI-CD/tooling)
    • [ ] CGEO notified if audience-facing/platform-experience consequence
    • [ ] An ADR opened (docs/adr/) if the decision is irreversible or architecturally load-bearing
    • [ ] Learnings captured to docs/knowledge/ if the review surfaced one
    • [ ] Decision/ADR handed to the Archivist (0 drift)

architecture decision notified is now a registered phrase (docs/handoff-triggers.md, Wave-2 block, Operations-approved 2026-06-01); review requested / review passed / artifact approved already exist. The review requested input declares a placeholder producer (<Engineering or AI Systems Director>), making it the CPTO’s architecture-proposal fan-in sink — it absorbs whichever Director surfaces a proposal (interface-contract-spec.md §3.1 R1). The COO/CGEO notification edges are pending (those roles are not yet authored — §3.1.1 R3).

Purpose

Keep architecture decisions that cross Engineering, AI Systems, and Operations coherent with the product strategy and with each other — so an irreversible or cross-cluster choice is reviewed for strategic fit and operational load before it is made, not discovered afterward.

When to use

When the Engineering Director (or AI Systems Director, for AI components) surfaces an architecture proposal with org-wide or cross-cluster impact — a data-layer choice, a framework change, a model-architecture decision, anything irreversible. Routine, unit-internal implementation choices do not route here (that is the Director’s lane); use the tiebreaker below if unsure.

Flow

flowchart LR
  A["Proposal received"] --> B{"Org-wide /<br/>cross-cluster?"}
  B -->|no| R["Route back to<br/>the Director"]
  B -->|yes| C["Assess: soundness ·<br/>fit · op-load · AI coherence"]
  C --> D{"Decision"}
  D -->|approve| E["Notify COO/CGEO<br/>if load / audience-facing"]
  D -->|revise| F["Revise with<br/>Engineering Director"]
  D -->|irreversible /<br/>load-bearing| G["Open ADR +<br/>escalate to Principal"]
  E --> H["Hand decision/ADR<br/>to Archivist"]
  F --> C
  G --> H
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  classDef d fill:#0f766e,color:#fff,stroke:#134e4a
  class A,R,C,E,F,G,H s
  class B,D d

Text fallback: receive the proposal → is it org-wide/cross-cluster? (no → route back to the Director) → assess on the four lenses → decide: approve (then notify COO/CGEO if there is operational load or an audience-facing consequence), revise with the Engineering Director, or — if irreversible/load-bearing — open an ADR and escalate to the Principal → hand the decision/ADR to the Archivist.

Steps

  1. Confirm scope. Org-wide or cross-cluster impact? If not, route back to the owning Director — this SOP is for decisions that span Engineering/AI-Systems/Operations.
  2. Assess on four lenses — (a) technical soundness, (b) strategic fit with docs/concept.md, © operational burden on the Process Engineer (new process, CI/CD, tooling), (d) AI-system coherence (loop in the AI Systems Director if AI components are involved).
  3. Decide: approve · revise-with-Engineering · escalate. State the rationale, not just the verdict.
  4. Notify in parallel — COO in writing at the point of decision if material operational load; CGEO if audience-facing/platform-experience consequence.
  5. Open an ADR (docs/adr/) if the decision is irreversible or load-bearing, and escalate to the Principal with a structured decision brief.
  6. Hand off the decision/ADR to the Archivist; capture any learning.

Roles / approvers

Run by the CPTO. The Engineering Director owns implementation and may co-revise; the AI Systems Director is looped in for AI components; the Process Engineer implements operational mechanics. Tiebreaker: CPTO authority applies when the decision is irreversible or cross-cluster; Process Engineer/Engineering authority applies for the implementation mechanics of that decision. Irreversible-strategic decisions are escalated to the Principal, not decided unilaterally.

Guardrails

  • Must NOT own CI/CD pipeline tooling or write feature code — flag strategic implications; Engineering/Operations implement.
  • Notify, don’t ambush — the COO must not discover a load-creating decision after the fact; notify at the point of decision.
  • Co-create, don’t one-shot — if the decision implies a new rule, route to Golden Rule (GR-3).
  • Best available model always (GR-1) — an architecture that silently downgrades a model is a defect; name the tradeoff.
  • Do not restate ADR conventions — link to docs/adr/ / CONTRIBUTING.md.

See also: docs/units/cpto-cluster/operating-model.md · SOP-042 (phase-gate decision) · docs/adr/ · docs/handoff-triggers.md.