Substrate

The shared spine — tooling, core architecture, and execution patterns that serve both pillars

Published

April 24, 2026

Substrate

The shared spine both pillars ride on. These components aren’t modernization or compliance — they’re the machinery that lets both exist: the monorepo, the render pipeline, the architecture abstractions, and the execution patterns that distinguish governance from execution.

Splitting these across pillars would duplicate canon. They live here so modernization pages and compliance pages cross-reference them instead of redefining them.

Sub-categories

Section Scope Leaf count
Platform & tooling GitHub/Gitea monorepo · Quarto pipeline · canon sync · CI/CD · Customer Documents portal · CLI · Academy 8
Core architecture Six-Plane Architecture · Three-Layer Rule Model · Drift Engine · Evidence Chain · Boundary Impact Model · Two-Way Governance 6
Execution patterns Two-Brain Execution (Copilot + Execution Substrate) · AODIM · “Instruments vs. Orchestra” positioning 3

Canonical invariants

  • Tenant agnosticism: substrate artifacts carry no tenant-specific identifiers. Values are injected at deployment time.
  • Single source: there is one monorepo, one canon registry, one render pipeline. Mirrors and derived copies are non-canonical.
  • Governance ≠ execution: Copilot reviews and authorizes; the Execution Substrate executes. The two never co-mingle.
Back to top