Governance
Depth
Count of Lenses with statusCode = ACTIVE.
statusCode = ACTIVE)
What it signals
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.
Who this metric is for
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 this metric gets misused
An architect who authors 50 trivially-passing Lenses will have a high GD with zero diagnostic value. More Lenses is only better if each Lens is genuinely evaluating a real architectural boundary that matters. The quality signal: track DCS alongside GD. If DCS remains high as GD grows, the new Lenses are effective — they evaluate real boundaries and PRs are passing them. If DCS crashes as GD grows, either the new Lenses are miscalibrated (firing on benign code) or correctly identifying previously invisible drift. Investigate before adjusting either metric.
Lens redundancy trap: Overlapping Lenses that evaluate the same architectural property will generate correlated failures — making it look like a pillar has a problem when one structural issue is triggering multiple Lenses. rkito does not currently auto-detect Lens redundancy. Review Lens prompts manually when GD grows rapidly.
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.
Track DCS alongside GD. If DCS remains high as GD grows, the new Lenses are effective.
Measures how completely the Steering layer describes the architecture GD is enforcing.
Tracks how evenly GD is distributed across architectural pillars rather than concentrated.
What is your org's GD?
rkito calculates GD automatically from your Steering layer. Connect your repo and see how much of your architecture is enforceable today.