Audit Block
Rate
% of completed CDA audits where the PR was actively blocked from merging.
= BLOCKED
÷ total completed audits)
× 100
What it signals
ABR measures the enforcement activity of the CDA system — specifically, how often the pipeline is exercising its hard-gate capability rather than issuing advisory warnings. A PR lands in the BLOCKED bucket when at least one CRITICAL Lens fires and that Lens is configured to act, not just advise.
A very low ABR, particularly below 5%, should be read with suspicion. It does not necessarily mean your codebase is healthy — it may mean your Lenses are configured to warn rather than block, and PRs are slipping through without hard gates. The enforcement layer exists but is not enforcing.
A moderate ABR of 5–30% indicates the system is actively engaged. The CDA pipeline is detecting violations and stopping them before they merge. This is the intended operating state early in adoption, when teams are still internalising architectural rules. A very high ABR above 50% suggests something is miscalibrated — either Lenses are firing on legitimate code, or teams are working in persistent conflict with the encoded design intent.
How rkito produces it
Every completed CDA audit has a statusCode. When one or more CRITICAL Lenses evaluate as FAIL and the Lens action is set to BLOCK, the audit resolves with statusCode = BLOCKED and the PR is prevented from merging. ABR is the fraction of completed audits that produced this outcome. Navigate to /changecontrols/designaudits and filter by BLOCKED status to inspect individual audits.
Who this metric is for
ABR shows whether the enforcement layer is actually blocking or just advising. A well-governed org should see ABR rise early in adoption — as the Lenses engage and teams encounter hard gates for the first time — then fall as teams internalise architectural rules and stop triggering them. A flat, near-zero ABR from day one almost always means Lenses are misconfigured to warn-only. An ABR that never falls after the initial period means something structural is wrong: either the Lenses are firing on legitimate work, or the architectural rules themselves are out of sync with how the codebase is actually evolving.
Watch
ABR trending down over time is healthy. It means teams have internalised the architectural rules — violations are becoming rarer because developers and agents have adapted, not because enforcement was turned off.
ABR that never rises initially is a configuration warning. If the system is running but never blocking, check that CRITICAL Lenses are set to BLOCK action, not WARN. A warn-only setup produces zero ABR regardless of how many real violations are occurring.
ABR that stays high indefinitely is either a calibration problem or a cultural problem — and the distinction matters. If Lenses are firing on code that architects consider legitimate, the Lens prompts need recalibration via CHI. If the blocks are accurate but teams keep triggering them, the architecture is not being internalised and a more systemic intervention is required.
What to do at each threshold
Step-by-step response playbook for each signal state.
Lenses may be configured to warn rather than block. PRs are likely slipping through without hard gates.
Navigate to /steerings/lenses and confirm that CRITICAL Lenses are configured to BLOCK, not WARN. If all critical Lenses are warn-only, reconfigure with pillar owner approval.
Cross-reference with DCS. If DCS is also high and ABR is near zero, the system may genuinely be in a healthy state — but confirm enforcement is on, not just quiet.
Active enforcement is in place. The CDA system is blocking real violations.
Confirm that ADCR (Auto-Draft CHI Rate) is high alongside ABR. Blocked PRs should be producing Change Intention drafts for architect review — if they are not, the resolution loop is broken.
Watch the trend. ABR in the 5–30 range is expected early in adoption and should decline over time as teams internalise the rules. If it is not declining after several sprints, investigate which Lenses are firing most.
Lenses may be miscalibrated, or teams are consistently working against design intent. Either scenario requires immediate action.
Navigate to /changecontrols/designaudits, filter by BLOCKED, and open individual audits to identify which Lenses are firing most frequently.
For each top-firing Lens, assess: are the blocks on legitimate code (Lens needs recalibration via CHI) or are they accurately catching real violations (cultural or process intervention required)? These are different root causes and require different fixes — do not conflate them.
The headline conformance metric — % of PR evaluations that passed all Lens checks. ABR is the enforcement complement to DCS.
% of structural changes with no approved Change Intention. High ABR alongside high UDR means blocks are happening but not resolving.
% of blocked PRs that triggered an automatic CHI draft. Should be high when ABR is in the moderate healthy range.
Is your enforcement layer blocking or just advising?
rkito calculates ABR automatically from your first design audit. Connect your repo and see whether your Lenses are enforcing within minutes.