Intent-First Rate
The percentage of structural PRs where design approval preceded engineering effort.
This page describes the intended design. It requires tracking whether a CHI was approved before the first commit landed, which isn't built yet. It doesn't appear on your dashboard yet, and no org currently has a live value for it.
< agent/developer first commit date
÷ total PRs with structural change)
× 100
What it signals
IFR is the process maturity signal. It measures whether architectural approval precedes engineering effort — or ratifies it after the fact. A post-hoc CHI — reviewed after the code is written — is a rubber stamp on a decision already made. A pre-commit CHI — reviewed before the first line — is genuine design governance. IFR is the percentage of structural PRs that went through the real thing.
The distinction is not semantic. When a Change Intention is approved before a branch is created, the design review shapes the implementation. When it is approved after the first commit, the implementation has already shaped the design — the review is resolving cognitive dissonance, not exercising judgment. High IFR means your architects are influencing code before it is written. Low IFR means they are reading it after.
Low IFR is the leading cause of sprint-level delivery unpredictability. When design approval arrives late, rework is structurally guaranteed. The feature is already in progress when the architectural concern surfaces — and the cost of addressing it is measured in days, not comments. Teams with IFR below 60 reliably report unexpected blockers in sprint review, not because the blockers were unforeseeable, but because the governance process that would have surfaced them early was bypassed.
How rkito produces it
Change Intention approval timestamps are compared against first commit timestamps per branch. A branch where the CHI approval date is before the earliest commit date on that branch is an IFR hit. A branch where the CHI was approved after the first commit — or was never approved, producing a block — is an IFR miss. Reported per sprint as a percentage of all structural branches.
Who this metric is for
IFR is the direct measurement of whether sprint planning accounts for architectural approval time or gets surprised by it. Low IFR is the upstream cause of unpredictable sprint completion rates — the blocker that appears mid-sprint was never inevitable. It was foreseeable if the CHI had been filed first.
IFR tells whether the design review workflow is being invoked before effort is invested or after. Post-hoc CHI approval is theatre, not governance. An architect reviewing a CHI after the branch already exists is not influencing the design — they are auditing a fait accompli.
IFR is the explanation for why features in development keep hitting unexpected architectural blockers. When IFR is high, architectural surprises arrive before the first commit, not after the PR. High IFR converts architectural governance from a delivery hazard into a delivery enabler.
How this metric gets misused
IFR is the most gameable metric in the rkito system. Teams under IFR pressure start rubber-stamping CHIs — approving in under 2 minutes with no reviewer comments — just to start a branch with a technically approved design. This produces a high IFR number and zero actual governance value.
Always track CRPR (Comment Resolution Rate per Review) alongside IFR. A CHI with an approval time under 5 minutes and zero resolved comments is a signal the process was bypassed in form rather than substance.
A product manager or VP Eng who uses IFR as a team performance target without monitoring CRPR is optimizing for a metric while destroying the process it was meant to measure. IFR is a health signal, not a KPI. Teams should not be ranked or rewarded by it.
What to do at each threshold
Step-by-step response playbook for each signal state.
The CHI process is running ahead of the code. Confirm it is genuine governance, not fast-approvals.
Check CRPR alongside IFR. High IFR with low CRPR is a rubber-stamp signal. Investigate any CHI approved in under 5 minutes with zero resolved comments.
If both IFR and CRPR are healthy, IFR is a genuine signal. Sprint predictability should be measurably better — correlate against sprint completion rate to confirm.
Governance is slipping on a subset of branches. Find the pattern before it becomes the default.
Identify which teams or branches are the IFR misses. The most common cause: developers start coding while the CHI is still in review, not after it has been rejected.
Introduce a branch creation hook or pre-commit check that surfaces pending CHI status before the first commit.
The Change Intention process is being systematically bypassed. Do not default to enforcement.
Determine root cause before acting. Is the CHI process too slow (MTTCD > 7 days)? Too unfamiliar? Or actively being avoided? Each cause requires a different fix.
Do not default to enforcement. Fix the process first — then monitor whether IFR follows.
IFR measures timing of approval. UDR measures presence. A branch can have a late CHI (IFR miss) and still have one (not a UDR miss).
High IFR is a prerequisite for consistently high DCS — late approvals allow drift to start before governance can prevent it.
The speed of the CHI approval process. High MTTCD is the most common structural cause of low IFR.
What is your org's IFR?
rkito calculates IFR automatically from CHI approval timestamps and first commit dates. Connect your repo and see where your governance process stands in minutes.