The adverse outcome you are building toward
None of these scenarios require negligence. They require only the absence of a gate.
A production incident is traced to an architectural decision an AI agent made three sprints ago. No architect reviewed it. The PR passed all code quality gates. The design intent gate did not exist.
A regulatory audit asks for evidence that your security policies were applied to every code change over the past 12 months. You have test results. You have SAST reports. You have no record of which Lenses were evaluated per PR, which Steering directives were checked, what was found, or what decision was made. The auditor asks a follow-up.
A senior engineer leaves. The system state they held in their head — the boundaries they knew not to cross, the patterns they maintained without documenting them — leaves with them. You have no externalised architecture record. The next hire ships without that context.
Your AI tool adoption made your engineers faster and your architects blind. Velocity is up. Architecture visibility is down. You find this out when something breaks that no one on the team can reason about.
Every sprint, someone approves a corner cut to meet a release date. The PR merges with a comment: 'tech debt — revisit.' No owner. No stated justification. No documented risk. Six months later, when that decision causes an incident, the post-mortem cannot identify who made it or why.
The common thread: no AI agent is truly conformant. Agents complete tasks. They do not enforce architectural intent. Each PR is generated without memory of the 500 PRs before it. The agent that crossed a service boundary in sprint 14 had no knowledge of the ADR that prohibited it in sprint 3. That is not a defect in the agent. It is a gap in your pipeline.
What you are currently flying blind on
Four KPIs every CTO should track. None of them are currently visible at most organisations shipping AI-generated code.
The percentage of PRs in each sprint that violated your design intent — crossed a Steering-defined boundary, violated a Lens directive, introduced an undocumented dependency, deviated from an established pattern.
The elapsed time between a design violation being introduced and it being detected. In CI/CD pipelines with no design gate, detection happens at incident review — if at all.
One architect against 50+ AI-generated PRs per week, each containing structural decisions the agent made without architectural context. Manual review at this volume is not a process. It is theatre.
Is the system getting cleaner or dirtier sprint over sprint? Are violations increasing or decreasing? Is drift accelerating? Without a Lens-based CDA gate producing sprint-over-sprint conformance data, there is no data source for this question.
How rkito makes these visible
The Continuous Design Audit gate runs on every PR. It evaluates the change against the full Steering corpus — assembled into Lenses scoped to the team and service context of each PR — and the Architecture Ledger, the live baseline of every system component and boundary continuously updated by each CDA run. It produces a finding or a pass. It does not require an architect to be present.
Architecture conformance rate becomes a tracked metric. Every sprint produces a number. The first time you see it, the number will be uncomfortable. That discomfort is diagnostic information you did not previously have.
Design violation discovery latency collapses from weeks to minutes. The violation is flagged at the PR, before it enters the codebase, before it compounds into an incident.
The architect-to-PR ratio problem is solved structurally. The system handles the pattern-matching. The architect handles the exceptions — the genuine design decisions that require judgment, not the 47 PRs that were compliant.
Architecture health trend becomes real data. The Ledger maintains the live baseline of your system. Sprint-over-sprint conformance data tells you whether the system is getting cleaner or dirtier — without waiting for an incident to find out.
When an architect approves a CDA finding rather than blocking it, the approval is a formal debt acceptance record in the Architecture Ledger: named approver, timestamp, specific Steering artifact violated, stated justification, known risk, resolution commitment. The 'tech debt — revisit' comment becomes a traceable decision. The post-mortem has an answer.
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.
Whether your architecture is getting healthier or sicker sprint over sprint. Currently answered with gut feel and post-incident retrospectives.
Weighted composite of DCS (40%), ADI (25%), IFR (20%), UDR (15%). Rolled up to org level. Trended sprint-over-sprint on the org dashboard.
DHS with GD=2 means only 2 rules are being checked. Never present DHS without contextualising Governance Depth alongside it. "Our DHS is 94" alone is a misleading statement.
How much architectural drift specifically comes from AI agents versus humans. No current tool attributes design violations to agent-authored code separately.
Agent-authored PRs identified by commit signatures and MCP access logs. ADRIFT = % of those PRs with violations and no approved CHI.
ADRIFT is not an argument against AI tools. High ADRIFT means agents are ungoverned, not ungovernable. The remediation is rkito MCP integration — not restricting the tools.
What fraction of structural changes are happening outside the governance process. Currently unknown at most organisations.
Every structural PR checked for an approved CHI. No CHI = BLOCKED + UDR increments. Reported per sprint.
UDR is a system metric before a people metric. High UDR means the CHI process is not embedded in the workflow — fix the workflow before escalating to individuals.
On the roadmap
The current rkito CDA gate produces per-PR findings and a conformance result. The following reporting capabilities are on the product roadmap and are not yet available.
Sprint-over-sprint conformance rate, violation trend lines, and drift incident frequency in a single view. Designed for the engineering leadership layer.
A structured summary delivered weekly: conformance rate for the sprint, drift incidents detected, architect call rate. The numbers your board will eventually ask for, surfaced before they ask.
A board-reportable metric expressing system architectural health as a single tracked number over time — the engineering equivalent of a code coverage report, applied to design conformance.
The question is not whether AI tools introduce architectural risk. They do — by design. Agents complete tasks. They do not verify conformance. The question is whether you have a gate before that code enters your system. Right now, you do not.