% of structural changes with no approved Change Intention on record.
This page describes the intended design. It requires correlating structural code changes with CHI approvals, which isn't built yet. It doesn't appear on your dashboard yet, and no org currently has a live value for 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.
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.
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.
UDR is a system metric before a people metric. High UDR almost always means the Change Intention process is not embedded in the team's development workflow — engineers and agents are not reaching for the CHI step because it is friction-heavy or unfamiliar. The first remediation is workflow tooling and education, not enforcement or escalation against individuals.
Do not use UDR as a zero-tolerance deployment gate.
Some structural PRs in a high-UDR state are already in the correct resolution path — a CHI has been drafted and is awaiting approval. These transitions are healthy: the team detected the gap and is filling it. Blocking all deployment of any PR with detected drift creates organizational paralysis without improving governance quality. The metric signals where to intervene; it is not a binary deployment lock.
Do not read a low UDR as proof of a well-governed architecture if your Architecture Ledger is sparsely populated. An org with five Ledger entities will report a low UDR by default — most structural changes simply have no registered entity to trigger against. Always read UDR alongside Governance Depth (GD) to confirm coverage is adequate.
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/changeintentions and 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.
The complementary signal: what percentage of structural PRs had design approved before the first commit was written.
UDR scoped to AI agent PRs specifically — the metric that isolates the agentic governance gap from the human one.
The rate at which the CDA pipeline is actively blocking PRs. High ABR alongside high UDR means blocks are happening but not resolving.
rkito calculates UDR automatically on every structural PR. Connect your repo and see your ungoverned drift rate within minutes.