Formula
ABR = (audits with statusCode
= BLOCKED
÷ total completed audits)
× 100Thresholds
Possibly warn-only
Check Lens action settingsHealthy enforcement
Active blocking in placeMiscalibration or systemic drift
Audit individual blocksReading it
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.
- 01
PR diff evaluated by CDA pipeline
All applicable Lenses are executed against the PR changeset
- 02
Lens results collected
Each Lens returns PASS or FAIL with an associated action: WARN or BLOCK
- 03aNOT BLOCKED
All Lenses pass, or failures are WARN-only
Audit statusCode = PASS or WARNED — not counted in ABR numerator
- 03bBLOCKED · ABR++
At least one CRITICAL Lens fails with BLOCK action
Audit statusCode = BLOCKED — PR prevented from merging
- 04
ABR recalculated
(BLOCKED audits ÷ total completed audits) × 100 → org dashboard
Who reads it
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.
How it misleads
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/lensesand 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.