Frequently asked
Questions about cost per accepted change
What counts as a change?
The default unit is a merged commit to the production branch. Teams can substitute another unit — accepted pull request, deployed increment, or shipped feature flag — as long as it is applied consistently across the measurement window and across the baseline.
The unit is less important than the consistency. Whatever you pick, document it and stick with it. Switching units mid-window inflates or deflates the result.
What does "stayed there" mean?
A change has stayed in production if, by the end of the measurement window, it has not been:
- Reverted via a follow-up commit, revert, or rollback,
- Substantively rewritten by a subsequent change addressing a defect introduced by the original, or
- Disabled by feature flag to neutralize harm.
Cosmetic follow-ups (formatting, renames, comment edits) do not invalidate acceptance. Defect-driven rewrites do.
How is "acceptance" different from "correctness"?
Acceptance is observable. Correctness is aspirational. CPAC measures whether a change survived contact with production for the duration of the window — that is a real, auditable signal. A change can be incorrect in some absolute sense and still "stay there"; CPAC will count it.
The defense against this is the "stayed there" window and the rework cost line. Lengthening the window catches more silent escapes. Counting fix-up cost in the numerator catches the rest. CPAC is a defensible proxy for correctness, not a claim of perfect correctness.
What measurement window should I use?
Choose a window long enough that most rework would have surfaced. Two weeks is a minimum; four weeks is the practical default; one quarter is the most defensible.
Report CPAC for the same window length consistently. Quarter-over-quarter comparisons are sound; quarter-versus-sprint comparisons are not.
How do I value engineering and review time?
Use a fully-loaded hourly rate — salary, benefits, tooling allocation, overhead. Most organizations already have this number for capacity planning. If you do not, $150/hour is a reasonable starting estimate for senior engineers in high-cost markets; adjust to your context.
The absolute value matters less than the relative trend. If your assumptions are consistent across windows, CPAC will move in the right direction when your delivery system improves.
How do I split costs across teams or features?
Allocate by the most defensible signal available — time tracked, story points completed, branch ownership. Perfect attribution is not required; consistent attribution is.
Does CPAC work for non-code work?
The same shape applies wherever AI produces artifacts that must be reviewed before use — drafts, designs, recommendations, plans. The components rename naturally ("accepted recommendations," "accepted designs"). The "stayed there" clause becomes "still in use after N days." The metric generalizes; this site focuses on code because that is where the literature and the measurement infrastructure are best developed.
How does CPAC relate to DORA metrics?
DORA metrics describe how a delivery system behaves: how often it ships, how quickly, with what failure rate. CPAC describes what that behavior costs. The two are complementary. A team can have excellent DORA numbers and a terrible CPAC if its velocity is bought with disproportionate review and rework cost — which is exactly the AI-augmented failure mode.
How does CPAC relate to FinOps?
CPAC is FinOps cost-to-serve, moved one layer upstream. FinOps measures the unit cost of running software. CPAC measures the unit cost of producing trusted software. Organizations with mature FinOps practices already have most of the inputs; CPAC just rearranges them around the accepted-change denominator.
Can I gaze at CPAC alone?
No. CPAC is the bottom-line cost metric. Pair it with change failure rate, lead time to accepted change, and machine catch rate to see the full picture of the Verification Triangle. CPAC alone tells you what the system costs; the others tell you why.
Where does the metric come from?
Cost per accepted change was defined in The Delivery Gap (Brenn Hill, 2026) as the cost vertex of the Verification Triangle. See how to cite.
How do I propose a change to the definition?
Open an issue or a pull request at github.com/brennhill/cost-per-accepted-change. The goal is for the definition to remain stable; refinements, worked examples, and translations are welcome.