rkitoDesign Process
Adherence Rate
% of audited PRs that had an approved Change Intention linked to the work.
This page describes the intended design. It requires linking each design audit to an approved 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
Conformance metrics like DCS, ADI and ABR measure whether code conformed to design intent. DPAR measures something that comes before that: did the team engage the design process at all?
DPAR is the broadest measure of whether engineering teams treat design governance as part of their workflow or bypass it. A DPAR of 40% means 60% of all PRs going through CDA had no design intent documented before the code was written.
This is an organisational adoption signal, not a code quality signal. It tells leadership whether the governance investment is being used. A deviation found against an approved CHI is a conformance failure: the team governed the change but the implementation drifted. A deviation found with no CHI at all is a process failure. They are different problems and need different responses.
How rkito produces it
Every PR evaluated by CDA produces a design audit. DPAR asks one question of each audit: was an approved Change Intention associated with the work when the audit ran? Every audit falls into one of five PR–CHI states. DPAR counts the first two.
Who this metric is for
DPAR answers the adoption question directly. Before asking whether code conforms, leadership needs to know whether teams are documenting design intent at all. A low DPAR means the governance model exists on paper but not in the workflow.
Filtering CHIs by team or author shows where CHI creation lags. That is where onboarding, templates and a simpler CHI path will move the number — not enforcement against individuals.
A deviation against an approved CHI and a deviation with no CHI at all need different responses. DPAR tells the architect which of the two problems dominates before deciding whether to recalibrate Lenses or fix the process.
How this metric gets misused
Do not read a high DPAR as proof that design comes first. DPAR only asks whether an approved CHI was linked when the audit ran — not when it was written. An org with 90% DPAR but 20% IFR has teams that are writing CHIs, but writing them after the fact. The governance is nominal, not real.
Do not treat DPAR as a code quality score.
DPAR says nothing about whether the code conformed. It measures whether the team used the design process. Read it alongside DCS for conformance and IFR for timing.
What to do at each threshold
Step-by-step response playbook for each signal state.
CHIs exist. Confirm they are created before the first commit, not after.
Navigate to /changecontrols/changeintentions and check the IFR signal. Review CHI creation dates against audit submission dates.
No action required on DPAR itself. Focus team attention on improving IFR.
Adoption is uneven. Find the lagging teams and lower the cost of creating a CHI.
Navigate to /changecontrols/changeintentions and filter by team or author to identify which teams have the lowest CHI creation rates. Use Dashboard → Admin → AdoptionMetricsWidget for adoption trends.
Run CHI process onboarding for lagging teams. Simplify CHI creation with the Quick-Create button and pre-filled templates at /changecontrols/changeintentions.
Most work is bypassing design governance. Make the gap visible to leadership.
Surface the DPAR gap from the pipeline funnel at /changecontrols/dashboard and share it with engineering leadership. Use Dashboard → Admin → AdoptionMetricsWidget to show month-over-month adoption trends.
Escalate to engineering leadership. Pair any CI warning rollout with enablement — office hours, worked examples — so developers know how to create a CHI before they are blocked. Not yet in rkito: a CI warning for CHI-less branches. rkito cannot yet emit a GitHub check when a branch touches governed entities without a CHI.
DPAR asks whether a CHI exists. IFR asks whether it was approved before the first commit — the difference between real and nominal governance.
The complement of DPAR: the share of audited PRs with no linked CHI at all, whether or not they passed.
Narrows the view to PRs where CDA found deviations and no CHI was ever associated with the work.
What is your org's DPAR?
DPAR is built from your design audits and Change Intentions. Connect your repo and start recording both today, so the history is there when DPAR ships.