All Metrics
Conformance Health · Layer 3

Ungoverned
Drift Rate

% of structural changes with no approved Change Intention on record.

Target metric — not yet computed

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.

Formula
UDR = (PRs with structural change
and no approved CHI
÷ total PRs with structural change)
× 100
Range: 0 – 100·Lower is better·Per sprint
Thresholds
< 5GovernedTarget state
< 15DriftingReview required
≥ 15UngovernedGovernance incident
01

What it signals

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.

02

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.

1
01
PR diff analyzed against the Architecture Ledger
rkito maps every changed file path and symbol to registered Ledger entities
2
02
Structural change detected?
Modification to a System, Component, Interface, or Behaviour entity
3
03aOUT OF SCOPE
No structural change
PR exits the UDR pipeline — not counted in denominator
4
03b
Structural change confirmed
PR is now in scope — enters denominator for this sprint
5
04
Approved Change Intention check
Is there a CHI with Approved status linked to this branch?
6
05aGOVERNED
CHI found and approved
PR is governed — not counted in UDR numerator
7
05bBLOCKED · UDR++
No approved CHI
PR is BLOCKED — UDR numerator increments for the sprint
8
06
UDR recalculated at sprint close
(blocked structural PRs ÷ total structural PRs) × 100 → org dashboard
03

Who this metric is for

CTO
Executive
The board-level governance gap

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.

CSO
Security
Undeclared changes to security-critical entities

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.

SRE
Reliability
The operational risk leading indicator

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.

04

How this metric gets misused

Do not use this metric to...

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.

05

What to do at each threshold

Step-by-step response playbook for each signal state.

Green< 5Monitor & validate

Governance is holding. Confirm the signal is real, not a coverage gap.

01

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.

02

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.

Yellow< 15Investigate

Ungoverned drift is present. Determine whether the team is responding or routing around the process.

01

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)?

02

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.

Red≥ 15Governance incident

Treat as a governance incident. The approval process is not functioning at scale.

01

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.

02

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.

Start measuring yours

What is your org's UDR?

rkito calculates UDR automatically on every structural PR. Connect your repo and see your ungoverned drift rate within minutes.