Treat a drafted or merged pull request as evidence of delivery work, not as a product outcome. It shows that a proposed change has entered or passed part of the engineering process. It does not show that the change reached production, helped a customer, created financial value or moved cash. The leadership decision is to define the route to the intended business event before activity starts, then place an explicit programme gate between delivery evidence and any claim about that event.
Consider an explicitly illustrative change intended to reduce avoidable support contacts around one customer task. A coding agent may produce a credible draft quickly, but the pull-request count says nothing about the effort still required. Review may expose a misunderstood requirement, weak test coverage or a conflict with another change. Rework can consume the drafting gain. A merge records acceptance into the codebase under the applicable controls; it is still not a release, customer use or an outcome.
After merge, the change may wait for testing, dependencies, approval or a suitable release window. Once live, customers may not encounter it or may continue using the old route. Only after meaningful use can the programme look for the selected business event, such as a change in support contacts for that task. Even then, the movement needs a baseline and a credible bridge to the released change. Other product, process and demand changes may offer another explanation. An observed operating event is also distinct from a financial result.
The evidence therefore belongs in separate registers. Capacity is measured time released across the defined work after review, rework and downstream quality are considered; its later use should be recorded separately. Structural value is a durable improvement to the software or delivery system, such as a reusable test or a less fragile handoff. Modeled upside is a prospective operational or commercial benefit supported by stated assumptions. Revenue remains upside until recognised and attributed. Cash requires observed, attributable net money paid or received after relevant costs. None of these registers converts into another, and they should never be added into one return figure. Pricing released hours by salary does not create cash.
Before expanding the programme, the sponsor should choose one bounded class of change and state what completion means at each stage. Name the intended customer use, the business event, the baseline, the likely constraint and the owner of each record. Engineering can establish what was proposed, reviewed, merged and released. Product can define meaningful use. Support or operations can own the selected downstream event. Finance can verify any later financial treatment.
The programme gate authorises the claim, not the deployment. At that gate, leaders state the last stage supported by evidence and the value register that applies. If the record stops at merge, the claim stops at accepted delivery work. If total effort falls within the quality boundary, a capacity claim may stand even when customer use has not been shown. A business-outcome claim advances only when the named event is observed and the link from delivery and use is defensible. Scaling should be justified by that classified result, not by a later forecast borrowed into the present.
What would count as proof?
- A defined population of changes, a baseline and the same completion and quality rules before and during the programme.
- Linked proposal, review, merge and release records, with drafting effort, human review effort, rework, defects and later operational issues kept visible. This shows whether work was removed, displaced or deferred.
- A pre-defined measure of meaningful use and the record for the selected business event, applied to the same change and observed for long enough to capture normal downstream effects.
- Named evidence owners and an attribution check covering other plausible product, process and demand changes. The gate record should state the last observed stage and keep capacity, structural value, cash and modeled upside separate.
The proof should match the claim. Delivery records can support a delivery finding. A net effort comparison can support capacity. A durable operating change needs evidence that it persists. A business or cash claim needs its own observed event and evidence chain.
What remains unclaimed?
A drafted or merged pull request does not establish a product outcome, financial value or cash. More pull requests do not establish net capacity, and faster drafting does not establish better quality. Release does not prove customer use; customer use does not prove a business consequence; an operating consequence does not by itself prove cash. A forecast does not become realised value because upstream activity increased. The evidence may stop honestly at any gate. The useful conclusion may be capacity, structural value or simply a delivery finding, provided it keeps the correct name.