Topics / Engineering practice
Keep verification effort visible as delivery grows.
More changes, teams and agents increase the cost of reconstructing context. Scale the reusable agreement and evidence, then measure whether work actually disappears.
Measure a complete change, not only the coding step.
Include clarification, implementation supervision, verification, review and rework. Track elapsed time separately from active human effort. Count blocked and rejected changes too; otherwise an easy batch can make the process look better than it is.
| Measure | Why it is useful |
|---|---|
| Human time per accepted change | Shows the engineering capacity consumed |
| Later regressions and rework | Checks whether faster acceptance was justified |
| Repeated investigation | Reveals context the system failed to retain |
| Second change through the workflow | Tests whether the process is worth reusing |
Start with a bounded component.
Illustrative example
Every billing change needs the same staff engineer.
That engineer remembers rounding decisions, legacy customers and old retry failures. Recover those promises and retain their authority, links and checks. The next change should retrieve the relevant subset, with stale results identified, rather than requiring another oral history.
Do not model the entire estate before testing value. Expand along actual dependencies as the work exposes them. Include the cost of maintaining those links.
Make autonomy a measured outcome.
Proof aims to reduce repeated evidence preparation and make more work safely delegatable. A pilot should test those aims against the existing workflow, not assume them from the size of the graph.
Keep consequential exceptions and intent changes under the applicable authority. Routine evidence collection is a good place to remove repeated manual work first.
Try it on your software
Find one component that consumes disproportionate review time.
Use its next few changes to measure the work removed and the obligations retained.