Design Conformance
Score
% of PR evaluations that passed all Lens checks.
÷ total completed audits)
× 100
What it signals
DCS is the headline architectural conformance metric for an engineering organization. An 85% DCS means that 85 of every 100 PRs evaluated by the CDA system conformed to the org's architectural intent. The remaining 15 introduced at least one Lens violation — a divergence from design rules your architects explicitly encoded.
A declining DCS is the clearest signal that the codebase is diverging from its design. No other metric in rkito communicates this as directly. When DCS trends downward sprint over sprint, it means either the architecture is changing faster than the Steering layer is being updated — or real violations are merging.
DCS is not a code quality metric. It does not measure test coverage, complexity, or performance. It measures design intent conformance — something no other tool in the market currently produces. A codebase can have 90% test coverage, zero SonarQube warnings, and a DCS of 40.
How rkito produces it
The CDA pipeline evaluates every PR diff against applicable Lenses — binary pass/fail design rules derived from the Steering layer. Each Lens evaluation produces a pass or fail. An audit passes when all Lenses pass. DCS is the aggregate pass rate over a rolling window, surfaced on the org profile at /orgs/:uid via governance health tiles.
Who this metric is for
Is the org's architecture getting better or worse sprint over sprint? DCS is the single number that answers that question at the executive level — no interpretation required.
Which teams are producing the most violations, and is it improving? DCS per team surfaces where to focus engineering management attention before the architecture becomes a delivery problem.
Which specific Lenses are failing? That is the signal for where to author new guidance or recalibrate existing rules via the CHI. DCS points the way; the audit log names the rule.
How this metric gets misused
DCS is not a performance metric for individual engineers. An engineer working on the most complex architectural boundaries will naturally produce more Lens findings than one making routine changes in well-understood areas of the codebase. Using DCS to evaluate individual contributors is a misuse. DCS is a system health signal, not an engineering performance signal.
The hidden DCS trap: A high DCS with low Governance Depth (GD) means almost nothing is being checked. A DCS of 94 with only 2 active Lenses is not evidence of good architecture — it is evidence that the architecture is barely governed. Always read DCS alongside GD. DCS without GD is vanity.
What to do at each threshold
Step-by-step response playbook for each signal state.
Architecture is conforming. Focus shifts from firefighting to calibration accuracy.
Navigate to /changecontrols/designaudits, filter by FAIL, identify which Lenses are contributing to remaining failures.
Run team awareness sessions for confirmed real violations. Recalibrate via CHI for false positives — high DCS should not come from ignoring real architectural issues.
Drift is present. Root-cause before it compounds.
Build a lens-by-lens failure breakdown from /changecontrols/designaudits.
For each top-failing Lens, determine: real architectural problem that needs an awareness campaign — or Lens miscalibration that needs a recalibration sprint via CHI. Do not conflate the two.
Treat as a conformance incident. Architecture is diverging at scale.
Declare a conformance incident. Freeze force-merges of blocked PRs immediately.
Triage: are violations real (awareness campaign + leadership escalation) or are Lenses systematically misfiring (immediate recalibration sprint via CHI)? A DCS this low warrants both tracks in parallel.
Composite org health signal that incorporates DCS alongside other governance dimensions.
The number of active Lenses covering the codebase. DCS is meaningless without adequate GD.
The proportion of flagged violations that remain open — a measure of resolution velocity.
What is your org's DCS?
rkito calculates DCS automatically from your first design audit. Connect your repo and see where your architecture stands within minutes.