UDR as your pre-incident signal
The weekly check that builds the habit:
- 1.Navigate to
/changecontrols/dashboard— check UDR for the trailing 30 days. - 2.UDR > 15%: more than 1 in 7 structural changes entered the codebase without architectural review. These are the changes most likely to produce the systemic failures that produce incidents.
- 3.For each week where UDR was elevated: navigate to
/changecontrols/designaudits, filter by BLOCKED + no approved CHI, review what structural changes happened. These are your unreviewed architectural decisions from that week. - 4.Maintain a mental model: ungoverned structural changes from N weeks ago become incidents in N+X weeks, where X depends on how complex and load-bearing the change was. ADRIFT and UDR are the N weeks window.
ADRIFT — the AI-specific operational risk signal
What to track as AI coding tools scale in your org:
- 1.Navigate to Agent Shepherd — check ADRIFT for the trailing 30 days.
- 2.ADRIFT > 15%: AI agents are generating ungoverned structural changes at a rate that will produce operational surprises.
- 3.The thing to communicate to engineering leadership: “At our current ADRIFT rate and agent PR volume, we are producing approximately X ungoverned structural changes per week. The statistical probability of an operational incident from one of these changes grows with time.”
- 4.ADRIFT is not a reason to restrict AI tools — it is a reason to deploy rkito's MCP integration. Governed agents with MCP context produce near-zero ADRIFT.
Post-incident: tracing architectural root cause
After a production incident, the rkito audit trail surfaces whether the root cause was an architectural governance failure:
- Step 1Identify the commit or PR that introduced the breaking change.
- Step 2Navigate to
/changecontrols/designauditsand search for the PR. Was there a CDA audit? - Step 3If the PR was BLOCKED and force-merged (AGVR > 0 for this PR): a governance bypass caused the incident. The architectural risk was flagged and ignored.
- Step 4If the PR was never audited (no CDA record): the repository or branch was not connected to rkito, or the webhook failed. This is a coverage gap to address.
- Step 5If the PR passed CDA cleanly: either the architectural rule that was violated was not encoded as a Lens (a coverage gap to address by authoring a new Lens), or the violation was not detectable at the structural level.
In all three cases, rkito surfaces the root cause category — governance bypass, coverage gap, or new Lens needed.
Monitoring AGVR — governance bypass
AGVR (Agent Governance Bypass Rate) should be structurally zero. If it is not:
Navigate to Agent Shepherd
→Any non-zero AGVR is an immediate investigation.
→Identify each bypassed PR: force-merge (enforce branch protection), webhook failure (fix webhook), repository not connected (connect it).
→Every bypassed agent PR is a potential future incident that the governance system was not permitted to prevent.
→Work with the platform team to enforce
rkito/cda as a required status check on all repositories where agents are active.MTTCD and risk accumulation
The longer a blocked architectural decision sits unresolved, the more operational risk accumulates:
Navigate to /changecontrols/changeintentions
→Filter by pending status, sort by age.
→Any CHI pending > 14 days: the underlying structural question is unresolved, and other code may be building assumptions on top of it.
→Flag CHIs that are > 14 days old to the VP Eng — these are not just governance process delays, they are open architectural risks.
→MTTCD > 7 days on average: the CHI review process is slower than the safe window for unresolved architectural decisions. Raise with architecture leadership.
Agent Shepherd as operational risk visibility
What Agent Shepherd gives SREs that no other tool does:
- —Which agent sessions are active right now and what Ledger entities they are modifying.
- —Which agent-authored PRs are pending CDA review.
- —Whether agents are loading rkito design context (MCPCAR) before generating code — low MCPCAR means ungoverned agent code is actively being written.
Navigate to Agent Shepherd
→Filter by status = active, sort by lastActivity — this is the live view of agentic architectural risk in your systems right now.
Your role in Steering
SREs bring operational constraints into the Steering layer — the reliability, observability, and incident-prevention rules that need to be enforced at the code level before changes reach production.
/steerings/pillars → Reliability or Infrastructure Pillar
Ensure a Reliability (or Infrastructure/Platform) Pillar exists. This is the domain container for operational Lenses. If reliability constraints are not under a named Pillar, PRs touching infrastructure and deployment code go unevaluated against operational rules.
/steerings/lenses + /steerings/prompts
Author reliability Lenses with the architect. Each Lens should represent an operational boundary — a rule whose violation in the codebase has historically produced or is likely to produce an incident. The Prompt is the binary check: “Does this PR introduce a service dependency without a circuit breaker?”
/steerings/checklists
Create operational pre-deploy Checklists for high-risk change categories — major infra changes, scaling events, new data pipeline deployments. Checklists cover the nuanced operational checks that binary Prompts cannot: “Has the on-call rotation been briefed on this change?”
/steerings/compliances
Map operational compliance requirements (SLA obligations, regulatory uptime requirements, incident response SLOs) to architectural constraints. Compliances create the traceability chain from a regulatory requirement to the Lens that enforces it in code.
/steerings/announcements
Post operational risk Announcements after incidents where architectural root cause was identified — “we are adding a Lens for X because of last week's incident”. This closes the incident → Steering feedback loop.
The SRE Steering loop: incident → root cause → Lens authored → Prompt activated → future PRs that would reproduce the incident are BLOCKED before merge. Steering is your post-incident prevention layer.