rkitoCHI-less
PR Rate
% of audited PRs with no associated Change Intention, whether or not deviations were found.
This page describes the intended design. It requires linking each design audit to a Change Intention, which isn't tracked yet. It doesn't appear on your dashboard yet, and no org currently has a live value for it.
÷ total audits)
× 100
What it signals
Where UDR focuses on deviating PRs specifically, CLPR captures the full scope of ungoverned work — including PRs that happened to pass. A CLPR of 70% means the majority of engineering work is not going through the Change Intention process.
Even if CDA passes those PRs, the absence of a CHI means no design intent was recorded, no architect reviewed the approach, and the Ledger was not updated. The organisation is conforming accidentally, not by design.
CLPR is the adoption health metric engineering leadership should track over time as rkito is rolled out. A maturing org should see CLPR trending downward as teams internalise the design-first workflow.
How rkito produces it
Every PR evaluated by CDA produces a design audit, and every audit falls into one of five PR–CHI states. CLPR counts every audit with no CHI behind it — including the ones where CDA passed. That last state is what separates CLPR from UDR.
Who this metric is for
CLPR is the metric to track as rkito rolls out. It should trend downward quarter over quarter. A flat CLPR means the design-first workflow is not taking hold, however good the conformance numbers look.
Segmenting CHI-less work by team shows where to invest in adoption. Set improvement targets per lagging team and track them in monthly check-ins rather than one org-wide push.
A PR that passes CDA with no CHI still left no design intent on record and no Ledger update. CLPR shows how much of the codebase is evolving without the architect ever seeing the approach.
How this metric gets misused
Do not dismiss a high CLPR because DCS looks healthy. PRs that pass without a CHI are conforming accidentally. The absence of violations is not the presence of design intent.
Do not read a low UDR as governance success on its own.
UDR only looks at PRs where CDA found deviations. A low UDR with a high CLPR means the deviating PRs are being handled, but most work still never touches the CHI process.
A low CLPR is also not proof that the CHIs were written first. Pair it with IFR to see whether design intent is being recorded before the code, or after.
What to do at each threshold
Step-by-step response playbook for each signal state.
Most work goes through the CHI process. Keep the trend moving down.
Navigate to /changecontrols/dashboard and confirm from the pipeline funnel that PRs without CHIs are trending downward. Use Dashboard → Admin → AdoptionMetricsWidget for month-over-month context.
Continue reinforcing the CHI-first norm, and call out the progress in team communications.
A meaningful share of work is still CHI-less. Find which teams, and set targets.
Navigate to /changecontrols/changeintentions and filter by team or author to identify which teams are most often CHI-less. Use Dashboard → Admin → AdoptionMetricsWidget to track trends per team.
Set a 90-day CLPR improvement target for each lagging team and track progress in monthly check-ins.
A large share of engineering work never enters the design process. Map it before you fix it.
Navigate to /changecontrols/designaudits, filter by audits with no linked CHI, and group by entity type and team to map where CHI-less work is concentrated. Not yet in rkito: an automated adoption audit view that segments CHI-less PRs by team, entity type and change size — today this grouping is manual.
Design a targeted adoption programme for each high-CLPR segment. Prioritise the teams and entity types with the most ungoverned volume.
The mirror image of CLPR: the share of audited PRs that did have an approved CHI linked to the work.
The narrower cut: CHI-less PRs where CDA actually found deviations. CLPR includes the ones that passed.
Once CHIs exist, IFR shows whether they were approved before the first commit or written after the fact.
What is your org's CLPR?
CLPR is built from your design audits and Change Intentions. Connect your repo and start recording both today, so the adoption baseline is there when CLPR ships.