Formula
UDR = (PRs with structural change
and no approved CHI
÷ total PRs with structural change)
× 100Thresholds
Governed
Target stateDrifting
Review requiredUngoverned
Governance incidentReading it
UDR is the governance gap, directly measured. It answers a single question: what percentage of structural changes to your codebase are happening outside the approval process — with no declared intent, no architect review, and no Change Intention on record? It is not a proxy metric or an inference. Every point of UDR represents a real PR that modified a registered architecture entity without any governance trail.
For most organizations adopting AI coding tools, UDR is non-zero and climbing. The agents generating 50 PRs per week have no awareness of the Change Intention process. They modify Systems, Components, Interfaces, and Behaviours registered in the Architecture Ledger because their instructions say to solve a problem — not to govern a change. UDR is the metric that makes this visible before it becomes a post-incident audit question.
A rising UDR sprint-over-sprint is one of the clearest leading indicators in rkito's conformance layer. It means the gap between what is being built and what has been approved is widening. Left unaddressed, it produces a codebase whose architectural state cannot be explained from its approval history — the definition of ungoverned drift.
How rkito produces it
Every PR diff is analyzed against the Architecture Ledger. When a structural change is detected — a modification to a registered Ledger entity (System, Component, Interface, or Behaviour) — rkito checks for a corresponding approved Change Intention on the branch. The result is binary. UDR is computed per sprint as the percentage of all structural PRs that failed this check.
- 01
PR diff analyzed against the Architecture Ledger
rkito maps every changed file path and symbol to registered Ledger entities
- 02
Structural change detected?
Modification to a System, Component, Interface, or Behaviour entity
- 03aOUT OF SCOPE
No structural change
PR exits the UDR pipeline — not counted in denominator
- 03b
Structural change confirmed
PR is now in scope — enters denominator for this sprint
- 04
Approved Change Intention check
Is there a CHI with Approved status linked to this branch?
- 05aGOVERNED
CHI found and approved
PR is governed — not counted in UDR numerator
- 05bBLOCKED · UDR++
No approved CHI
PR is BLOCKED — UDR numerator increments for the sprint
- 06
UDR recalculated at sprint close
(blocked structural PRs ÷ total structural PRs) × 100 → org dashboard
Who reads it
UDR is the governance gap at org level. A non-zero and climbing UDR is the leading indicator of the board-level risk scenario: AI-generated code is changing the architecture without any approval record. That is an audit failure in waiting. UDR puts a number on the exposure before the auditors do.
UDR scoped to security-critical Ledger entities — those registered under the Security Pillar — is the undeclared-change signal. These are structural changes a security audit cannot explain. No CHI means no risk assessment, no sign-off, no trail. That is not a compliance grey area.
Ungoverned structural changes are the category most likely to produce systemic failures. They bypass the review path where operational concerns — backwards compatibility, rollout sequencing, dependency surface — would normally be surfaced. UDR is the pre-incident signal SREs should be watching.
How it misleads
What to do at each threshold
Step-by-step response playbook for each signal state.
Governance is holding. Confirm the signal is real, not a coverage gap.
- Monitor trend at
/changecontrols/dashboard. Watch for sprint-over-sprint creep — a UDR of 3 rising to 8 over three sprints is a trajectory problem, not a current-state pass. - Confirm the low UDR reflects genuine governance discipline and not under-detection. Check Governance Depth — if too few Ledger entities are mapped, structural changes are simply not being caught, not governed.
Ungoverned drift is present. Determine whether the team is responding or routing around the process.
- Navigate to
/changecontrols/changeintentionsand review recent blocked PRs. The critical question: are teams responding to blocks by drafting CHIs (healthy — the governance loop is working) or finding workarounds (dangerous — the block is being bypassed)? - Check ADCR (Auto-Draft CHI Rate) alongside UDR. If ADCR is high and UDR is climbing, the pipeline is generating CHI drafts but they are not being approved quickly enough. The bottleneck is approval velocity, not awareness.
Treat as a governance incident. The approval process is not functioning at scale.
- Freeze all force-merges of blocked PRs immediately. Any force-merge at this UDR level is compounding the problem and destroying the audit trail you will need later.
- Root-cause the failure mode: is this a process awareness problem (teams and agents don't know how to raise a CHI, or don't know one is required) or a tooling problem (the CHI process is too slow and cumbersome to be used before coding starts)? These are different root causes that require different interventions — do not conflate them and do not apply the same fix to both.