The requirement you find in testing

In 2004 a team at NASA’s Johnson Space Center set out to measure the curve rather than assert it. They estimated the relative cost of fixing an error by the phase in which it is first found, using three independent methods: bottom-up cost data from spacecraft modifications across five projects, a breakdown of more than 3,300 changes on a major aircraft program, and a top-down model of a small communications satellite.¹

The authors conclude the escalation is “an exponential function,” and they are candid about the limits: the data was “somewhat limited in quantity,” the real-world figures come from two large aerospace projects, and the model “should be validated by comparison with actual errors.”¹ One more limit matters for this study: on the aircraft program, most errors classed as requirements errors were part-number, reference-designator and labelling mistakes — not missing requirements.¹ So this study uses the curve as the best published price of a late change, not as a measurement of late-discovered requirements.

Program-level data points the same way. In a 2008 assessment of major defense programs, the U.S. Government Accountability Office found that 63% of the 46 programs it surveyed had changed requirements after system development began. Research, development, test and evaluation costs grew 11% over initial estimates for programs without requirement changes, and 72% for programs with them.²

If late change is that expensive, the rational response is to find everything early: analyse harder, review longer, then freeze. For a bridge, a payroll system or an aircraft part number, that works, because the requirements can in principle be known before the build.

For a system that must perceive and act in an open world, the governing standards assume the opposite. ISO 21448, the road-vehicle standard for the safety of the intended functionality, notes that an insufficiency of specification “can be either known or unknown at a given point in the system lifecycle.”³ Among its activities it lists the “modification of vehicle functionality or of sensor performance requirements, driven by identified system insufficiencies or by hazardous scenarios identified during the SOTIF activities” — and it adds field monitoring in operation.³

UL 4600, the standard for evaluating the safety of autonomous products, goes further. It requires safety performance indicators — in its own definition, a metric “that uses a threshold comparison to condition a claim in a safety case” — and it requires that violations be collected and the product improved on that data.⁵ Its principal author summarises the point directly: “Operational feedback will be essential for practical safety.”⁴

Waymo’s published methodology describes the same loop from the operator’s side: on-road miles “reveal previously unknown risks” and feed new scenarios back into structured testing,⁶ and scaling gradually “makes the assessment of risks a continuous activity rather than a one-time occurrence.”⁷ Both Waymo papers describe methods, not outcomes — the 2023 paper states plainly that it is “a methods paper, not a results paper” — so they establish the practice, not its size.⁷

Look again at what NASA measured: the phase in which an error is first found.¹ It is an honest measurement of discovery. It is not a measurement of resolution, and in a real program those are different moments separated by a queue.

A change request discovered during testing does not become a fix at the moment it is discovered. It is logged, triaged, assigned an owner, assessed for scope and impact, argued over, decided, implemented and re-verified. Every one of those steps can wait on a meeting, a person or another team. The argument here is derived, not measured: if that queue is long enough, a change discovered in test is decided after the system has moved into operation — and is then paid for at the operations rate, not the test rate. On NASA’s composite ranges, that is a move from 21–78× to 29–1,615×.¹

Put differently, the cost curve has two inputs, and only one of them is about requirements. The first is when a problem is found, which for an autonomous system is partly fixed by the nature of the work. The second is how long it waits for a decision, which is entirely a property of how the program is run. The second is also the one nobody puts on a chart.

The backlog of undecided changes obeys one of the few exact results in operations research. Little’s law states that the average number of items in a stable system equals the average arrival rate multiplied by the average time each item spends in it: L = λW.⁸ It holds regardless of how the arrivals are distributed or in what order they are served.

Each open change is an unresolved question that engineering, quality and commercial teams must work around — and each one is ageing toward the next phase boundary. The arithmetic says something simple: with discovery held constant, the size of that backlog is set entirely by decision speed. A program that cannot slow its discovery rate, because discovery is the safety process, still controls the other term.

Products built on language models have the same property in a smaller, faster form. Their behaviour is not fully specified in advance; teams learn what “correct” means by running evaluations and watching production. OpenAI’s guidance is explicit: “Evaluate early and often,” “Evaluation is a continuous process,” and “grow the eval set over time.”⁹ Anthropic’s documentation describes the same cycle of testing and refinement as “central to prompt engineering.”¹⁰

Every failure found in an eval or in production is a requirement that was discovered late. The question that decides its cost is the same one as on a driverless system: how quickly does it get an owner, a decision and a regression test? The difference is only the clock. A transit system measures that loop in weeks; an AI product can measure it in days, which makes decision latency even more likely to be the binding constraint.

None of this requires a new tool. It requires treating the path from discovery to decision as a measured process, with the same discipline applied to test results. From timestamps most change logs already carry:

1. 1.Time to owner — from discovery to a named person accountable for the decision.
2. 2.Time to decision — from discovery to an approved disposition, reported as a distribution, not an average.
3. 3.Age of open changes — the current backlog, bucketed by age, reviewed at the same cadence as schedule and risk.
4. 4.Phase crossings — how many changes were discovered in one phase and decided in a later one. This is the direct measure of cost added by waiting.
5. 5.Reopen rate — decisions that came back, a check that speed is not being bought with worse decisions.

The fourth number is the one that ties the argument together. It converts an operational delay into the cost escalation the engineering literature already accepts, using the program’s own data.

The hypothesis is testable on a single program with a reasonably complete change log. Group changes by the phase in which they were discovered. Within each group, compare the eventual cost or effort of changes decided quickly against those that waited long enough to cross into a later phase. If decision latency matters in the way argued here, the second group should cost more even with the discovery phase held constant.

The obvious confounder is that harder changes take longer to decide and also cost more to implement. The comparison therefore needs a complexity control — the number of subsystems affected is a reasonable first proxy — before any difference is attributed to waiting.

• If, with discovery phase and complexity held constant, changes that waited across a phase boundary cost no more than changes decided quickly, the central claim is wrong.
• If late discoveries on autonomous programs turn out to be rare in practice — if nearly all requirements can in fact be frozen early — then the conventional advice is sufficient and decision latency is a second-order concern.
• If shortening decision time reliably raised the reopen rate enough to offset its benefit, speed would be the wrong target and decision quality the right one.

The cost-escalation data is NASA’s.¹ The program cost finding is GAO’s.² Late discovery as a safety activity comes from ISO 21448, UL 4600 and Waymo’s published methods.^{3 4 5 6 7} Little’s law is Little’s.⁸ Eval-driven development is established practice at both major model providers.^9 10 None of it is new.

What I am contributing is the connection: that the cost curve prices discovery while the autonomy standards make late discovery mandatory, so the remaining controllable variable is decision latency — and that it can be measured directly as phase crossings. That view comes from practice. For three years I owned customer requirements, priorities and change decisions within a $4.9B driverless people-mover program, and I now build an AI product where the same loop runs in days. This study draws on no data from that program; everything cited here is public.

The late-change cost curve is real, and for most systems the right response is to find problems earlier. Autonomous systems add a constraint the curve never modelled: some of their requirements are only found by testing and operating them, and their safety frameworks require exactly that.

When discovery cannot be moved earlier, what remains is the time between finding a change and deciding it. That interval is owned by no single team, appears on few dashboards, and — through Little’s law and the phase boundaries it crosses — sets both the size of the backlog and the price of every change in it. It is the requirement nobody writes down: decide fast, and know who decides.