The Governance Layers
SGD is not a single check or a single tool. It is a stack of governance layers, each adding a distinct type of governance — from the Vision that fixes shared intent, up through the change protocol that enforces everything at PR time, to Cortex, the persistent memory that carries learning across sessions and repos.
SGD began as six layers. As the methodology matured it grew to nine — Layer 0 through Layer 8: the Vision layer was added beneath as the shared statement of intent everything else is judged against, and the Alerts and Cortex layers were added above to catch slow drift early and to make organisational learning persistent. You do not need all nine on day one — most teams start with the Vision plus layers 1–3 and add the rest as they mature.
Layer 0: Vision
What it is: A short, public document — typically docs/vision.md in each governed repo — that fixes the shared intent every other layer is judged against. It captures the vision in one sentence, why the product exists, what good looks like, the MVP framing for the next committed milestone, explicit non-goals, and three to five outcome-level success measures.
Why it sits at the base: Without Layer 0, every prioritisation debate devolves into opinion because "priority" has no reference point. With it, capabilities filter against MVP vs post-MVP, feature specs cite which success measure they move, ADRs show which vision element they protect, and any change that contradicts a non-goal requires an explicit vision update first. Everything above cascades from here.
Layer 1: Capability Model
What it is: A structured map of your organisation's software capabilities — the logical groupings of repositories that together deliver a business function.
A capability like "Payment Processing" might span three repos: a payment API, a payment gateway adapter, and a shared payment types library. The capability model makes this relationship explicit rather than tribal knowledge.
The platform infers an initial capability model from your repository names, dependencies, and code analysis. You review it, adjust groupings, and confirm. From that point on, governance applies at the capability level — not just individual repos.
Learn more about the Capability Model →
Layer 2: Design System
What it is: The set of structural and naming rules that define "how we build things here" — file layouts, naming conventions, dependency constraints, required configurations.
This is not a UI component library (though it can include one). It is the broader set of engineering standards: "API services use this folder structure," "all repos must have a CI workflow," "shared packages use this naming scheme."
Design system rules are checked automatically on every PR. Violations appear as GitHub check annotations with specific remediation guidance.
Learn more about the Design System →
Layer 3: Feature Specs
What it is: Structured specifications that define what a change should accomplish, which repos it affects, and what the acceptance criteria are.
Feature specs bridge the gap between "someone filed a Jira ticket" and "someone opened a PR." They capture the intent of a change in enough detail that both human reviewers and AI agents can verify whether a PR actually implements what was asked for.
Specs are linked to Jira/ADO tickets (if you use them) and to the PRs that implement them, creating the traceability chain that auditors need.
Write your first Feature Spec →
Layer 4: ADRs (Architecture Decision Records)
What it is: Lightweight records of significant architectural decisions — the "why" behind your standards.
ADRs answer questions like: "Why do we use PostgreSQL instead of MongoDB?", "Why is authentication handled by a shared library?", "Why did we choose event-driven over synchronous communication?"
SGD tracks active ADRs and checks PRs against them. If a PR introduces a pattern that contradicts an active ADR, the governance check flags it. ADRs can also be superseded — when you change your mind, the decision trail is preserved.
Learn more about Impact Analysis →
Layer 5: DAG Manifest
What it is: A directed acyclic graph that maps the dependencies and execution order across your capabilities — which services depend on which, what order deployments should follow, where a failure would cascade.
The DAG manifest is partially inferred from repository dependencies and partially defined by your team. It powers impact analysis: when a PR changes a shared library, the platform can tell you exactly which capabilities are affected and in what order.
For organisations with complex service architectures, this is the layer that turns "we think this change is safe" into "we can prove which systems are affected."
Learn more about Impact Analysis →
Layer 6: Change Protocol
What it is: The enforcement layer that ties everything together. The change protocol defines the rules for how changes flow through your system — what checks must pass, what approvals are required, and what evidence is recorded.
The change protocol is what runs on every pull request. It evaluates the PR against all applicable layers: Does it match the feature spec? Does it follow the design system? Does it respect active ADRs? Does the impact analysis show acceptable risk?
Results appear as GitHub status checks. Pass or fail, the evidence is recorded for traceability.
Layer 7: SGD Alerts
What it is: Continuous trend detection over the coherence metrics — the early-warning layer that catches the slow kind of drift no single PR is responsible for.
Layers 1–6 check a change at PR time. Layer 7 watches the codebase over time: a capability model that gains entries while specs lag behind, a journey that gets regenerated once and never again, ADRs that accumulate without supersession review, cross-repo data contracts that erode silently. A daily job snapshots seven coherence metrics per product, raises alerts when a threshold is breached or a trend degrades, and rolls them into a single composite Coherence Score (0–100) a CTO can show their board.
Learn more about Coherence Scoring →
Layer 8: Cortex
What it is: Persistent, cross-session, cross-repo memory. Layers 0–7 govern a single repo in a single session; Cortex makes the organisation's collective development intelligence available to every session, in every repo.
Without persistent memory every new AI session is amnesiac — the same decisions are re-explained, the same mistakes rediscovered, team conventions erode. Cortex is an evidence-weighted, time-decaying, contradiction-aware knowledge graph anchored to real artefacts (commits, test results, PR reviews, spec files). Each fact carries a confidence score derived from the evidence behind it, decaying over time unless reinforced. When the same pattern is independently observed in three or more repos, Cortex promotes it to an org-level truth and injects it into every repo — spreading proven approaches without central coordination.
Learn more about AI Integration →
How the layers work together
The layers are designed to be additive. Start with the Vision (layer 0) and the capability model and design system (layers 1–2) to get immediate value from shared intent, health scoring, and structural checks. Add feature specs (layer 3) when you want traceability. Add ADRs and the DAG manifest (layers 4–5) when you need impact analysis. The change protocol (layer 6) ties them together at PR time, Alerts (layer 7) watch for drift over time, and Cortex (layer 8) makes the learning persist across sessions and repos.
Each layer strengthens the others. Feature specs are more useful when they reference the capability model and cite a Vision success measure. ADRs are more enforceable when the change protocol checks against them. The DAG manifest is more accurate when the capability model is well-defined. And every layer feeds Cortex, which feeds context back into the next session.
Next: SGD & Your Delivery Framework — see how these layers map to Scrum, Kanban, SAFe, and the Spotify model.