Formula
PCR = (passing Lens evaluations for this pillar
÷ total Lens evaluations for this pillar)
× 100Thresholds
Healthy
Caution
Critical
Reading it
PCR is the primary health signal for a pillar owner — the VP or domain lead accountable for a specific architectural domain. A Security Pillar at 91% PCR is well-governed. The same pillar at 54% PCR means nearly half of all PRs are violating security architectural design intent. Not code vulnerabilities — architectural security decisions.
PCR is distinct from DCS (the org-level conformance score) because it isolates conformance to a specific domain. An org with DCS=82 and Security PCR=54 knows exactly where the problem is. PCR makes the aggregate visible per domain, enabling targeted remediation rather than org-wide responses.
PCR per pillar enables accountability without ambiguity. Each pillar has a named owner. PCR gives that owner a number. A Security Pillar owner with PCR trending from 85 to 54 over 3 sprints has a specific, attributable signal to investigate — not a vague sense that "security quality is declining."
How rkito produces it
- 01
Lens is associated with a Pillar
Every Lens is linked to a pillar via pillarId at authoring time
- 02
CDA Lens evaluation runs
Each evaluation against a PR diff produces a pass or fail result
- 03
PCR computed per Pillar
PCR = (passing evaluations for that pillar's Lenses ÷ total evaluations for that pillar's Lenses) × 100
- 04
Computed per sprint, trended over time
Each sprint's PCR is stored, enabling directional trend analysis via PDT
- 05
Navigate for detail
Go to /changecontrols/designaudits, filter by FAIL, cross-reference lensId and pillarId
Who reads it
Security Pillar PCR is the architectural security conformance rate. SAST/DAST measure code vulnerabilities. Security PCR measures whether architectural security decisions — service boundaries, data access patterns, authentication flows — conform to the org's security design intent. These are complementary, not competing measures.
PCR per pillar tells where to focus architect time — not where people are loudest but where conformance is actually declining. PDT (Pillar Drift Trend) provides the directional signal alongside PCR's current state.
PCR breakdown across all pillars shows which architectural domains need team enablement vs which need Lens recalibration. Not all low-PCR pillars have the same root cause — the audit log distinguishes them.
How it misleads
What to do at each threshold
Step-by-step response playbook for each signal state.
Pillar is well-governed. Confirm LPP is meaningful and trend is stable before standing down.
- Confirm LPP is meaningful (≥3 active Lenses). A high PCR on a sparse pillar is not evidence of good governance.
- Check PDT is stable or positive. If both healthy, no action required — confirm with pillar owner on next review cycle.
Pillar is drifting. Determine whether the cause is concentrated or systemic before escalating.
- Navigate to
/changecontrols/designaudits, filter by FAIL and this pillar's Lenses, review failing evaluations. - Determine if failures are concentrated in one team (targeted enablement) or spread broadly (systemic issue or Lens miscalibration). Each diagnosis requires a different response.
Immediate pillar owner engagement required. Root-cause the decline before prescribing a response.
- New team onboarding (awareness gap), new tech stack (Lenses not updated for new patterns), outdated Lenses (now misfiring on legitimate patterns), or genuine architectural drift — each requires a different response.
- Do not conflate root causes. A PCR decline from new-team onboarding needs an awareness campaign. A PCR decline from outdated Lenses needs a recalibration sprint. Treating one as the other wastes time and erodes trust in the system.