The incident had an author. Nobody knows who.
You are in the post-mortem. Somewhere in the timeline there is a PR — probably three to six weeks ago — where something structural changed. A service started depending directly on another service’s database. A cache was introduced in a way that bypasses circuit breakers. An API surface was extended past its declared contract.
The code passed review. The tests passed. The linter passed. Nobody caught it because nobody was equipped to catch it — not because they weren’t trying, but because no tool in the pipeline checks whether a code change conforms to the architectural intent the system was built against.
The drift was silent. It remained silent for weeks. Until load, or a dependency update, or a perfectly ordinary Tuesday made it matter.
Technical debt you know about. Architectural drift you don’t.
Technical debt is visible. It shows up in code quality scans, in test coverage numbers, in the backlog items nobody wants to pick up. You can see it, track it, and make a deliberate call about when to address it.
Architectural drift is different. It is not visible in any metric you currently track. It does not show up in SonarQube. It does not appear in your error rates until it has already caused an incident. The system is quietly diverging from the architectural intent it was designed around — and by the time the divergence manifests, the causal chain is three sprints long and the original decision is buried in a merged PR with no context attached.
In teams shipping AI-assisted code, this is not an edge case. AI agents make structural decisions — service dependencies, API contracts, data access patterns — without any awareness of the architectural constraints those decisions must respect. The drift is continuous, silent, and accelerating.
What you are flying blind on
Currently: you find out in a post-mortem, not before merge. No tool in your pipeline checks whether a code change violates an architectural boundary or introduces a structural dependency that was explicitly ruled out.
The Architecture Ledger in rkito is continuously updated by every CDA run. The system state is always current — not a diagram someone last updated six months ago. When something breaks, you have a verified baseline to reason from.
Every CDA finding is traceable to the specific PR, the specific diff, the specific Lens from which the violated Steering artifact was drawn, and the specific directive within that Lens. The incident post-mortem now has a named cause, a named PR, and a named decision record — not a six-week archaeological dig.
With CDA running on every PR before merge, you know before a change ships whether it introduced architectural risk. The 3am call is prevented at the gate — not diagnosed after the fact.
The KPIs you should be tracking but aren’t
How rkito changes the on-call equation
The Continuous Design Audit runs on every PR before it merges. Structural violations — service boundary crossings, dependency pattern deviations, API contract extensions — are caught at the gate, not in production at 3am.
The Architecture Ledger is updated by every CDA run. When an incident occurs, you have a verified, current baseline to reason from. The post-mortem question “what changed?” has a precise answer — not a hypothesis.
Every finding is traceable to the specific Steering principle it violated and the specific line of the diff where the violation was introduced. The causal chain is four clicks, not four weeks.
Your metrics — and where they can mislead you.
These are the rkito metrics that matter most to your role. Each one removes a blind spot. Each one can also be misused. Read both.
How many structural changes reached production without any architectural review. High UDR is the leading indicator of future incidents — ungoverned structural changes are the category most likely to produce the systemic failures that page you at 3am.
Every structural PR checked for an approved CHI. No CHI = BLOCKED + UDR increments. Reported per sprint.
UDR should not be a zero-tolerance deployment gate. Some structural PRs are in the correct CHI resolution path — those are healthy transitions. Blocking all deployment on any drift creates organisational paralysis without improving reliability.
How much of the drift you'll deal with operationally in 6 months is being introduced by AI agents right now. ADRIFT is the early warning that appears before it becomes an incident.
Agent attribution from commit signatures and MCP access logs. Reported separately from overall UDR.
ADRIFT with rkito MCP integration trends toward zero for governed agents. Use ADRIFT to justify MCP investment — not to argue against AI tools in production codebases. The cause is ungoverned agents, not the agents themselves.
How long identified architectural risks sit unresolved after detection. MTTCD > 14 days means blocked architectural decisions are accumulating — and other code is building assumptions on top of unresolved questions.
Time from CDA BLOCKED to resolution, averaged across trailing 30 days.
MTTCD elevated before releases is a timing artifact. Track over 90-day windows to separate structural trends from sprint-end noise.
The 3am alarm is not an operations problem. It is a design conformance problem that was never caught at the point where it could have been stopped. rkito is the gate that should have been there — running automatically, on every PR, before the code that woke you up ever merged.