Formula
GD = count(Lenses where
statusCode = ACTIVE)Thresholds
Mature
Developing
Low coverage
Reading it
Governance Depth is the answer to the question: “How much of our architectural knowledge has actually been made machine-readable and enforceable?” A 200-page architecture document that no automated system checks is documentation. GD measures how many of those principles are now Lenses — binary evaluation criteria evaluated against every PR, automatically, without an architect in the room.
GD grows as architects encode more of their domain knowledge into evaluable rules. A new Lens authored for the Security Pillar is not just a rule — it is architectural intent that now evaluates every future PR without additional architect time. GD is the compound interest of architectural governance: each Lens authored pays dividends on every subsequent PR.
In the agentic era, GD takes on additional strategic significance. Every active Lens is architectural intent that rkito MCP loads into an agent's session before the first line of code is generated. An org with GD=50 has made 50 aspects of architectural intent machine-readable and enforceable for every agent session. GD is the proxy for “how much of our architecture can we make agents follow by design rather than by instruction.”
How rkito produces it
GD is a live count derived from the Steering layer. It increments when a Lens is approved through a Change Intention review and decrements when a Lens is deprecated through one. The count is surfaced on the org dashboard and on each pillar's detail view.
- 01
Lens authored at /steerings/lenses
Architect writes a binary evaluation rule with a statusCode field
- 02
GD = count of ACTIVE Lenses
Only Lenses where statusCode = ACTIVE contribute to GD
- 03ACTIVE
Change Intention review activates
Lens becomes ACTIVE when approved through a Change Intention
- 04INACTIVE
Change Intention review deprecates
Lens becomes INACTIVE when deprecated through a Change Intention
- 05
GD visible on org dashboard
Count surfaced on org dashboard and each pillar detail view
Who reads it
GD is the direct measure of how much of your architectural knowledge has been operationalised. Low GD means your architecture lives in documents and heads, not in enforceable rules.
GD contextualises every other metric. A DHS of 94 with GD=2 is not evidence of good architecture. Always present GD alongside DCS and DHS.
How it misleads
What to do at each threshold
Step-by-step response playbook for each signal state.
Governance coverage is mature. Shift focus to Lens quality and redundancy elimination.
- Navigate to
/steerings/lenses, sort by pillarId, and manually review prompts for semantic overlap. - Redundant Lenses inflate GD without improving coverage and produce correlated false positives that make PDRP look worse than it is.
Coverage is building. Watch DCS alongside GD as new Lenses activate.
- For each new Lens that produces a high initial failure rate, determine: real violations (architect awareness campaign) or miscalibration (adjust Lens prompt via CHI).
- Track LPP per pillar to ensure coverage is distributed across domains, not concentrated in a single area.
Almost none of your architectural knowledge is machine-readable. Begin encoding it.
- Identify the architectural domains most likely to be violated without automated enforcement — Security, Data Architecture, Service Boundaries are common starting points.
- Author 2–3 Lenses per domain through
/steerings/lenses. Each Lens requires a Change Intention for activation.