Three days before the milestone, status reads green across the board. Every team lead reports ready. Test counts are up. The burndown chart looks healthy. Two days later, integration testing surfaces six issues that should have been caught weeks ago. The milestone slips. In the post-mortem, the same engineering lead who said "ready" on Monday says: "Honestly, I'm not surprised. We didn't really have evidence — just no reason to think otherwise." This is the most uncomfortable pattern in technical delivery. Not that teams fail milestones. That teams fail milestones they were "ready" for.
Readiness is not the absence of failure.
It is the presence of evidence.
01 The activity/evidence gap
Most "ready" verdicts answer the wrong question. They answer: "Did we do the work?" The right question is: "Do we have evidence the system does what we claim it does?" These are not the same.
Activity measures: tests run, tickets closed, story points completed, hours logged, code reviewed, sprints finished. All useful. None of them, individually or in aggregate, answer the readiness question.
Evidence measures: a specific claim about system behaviour, each backed by a verifiable observation. "The payment service handles 200 concurrent requests with p99 under 800ms" is evidence. "We tested payment" is activity.
When activity-based reporting dominates, status meetings become misleading. Everything is "green" because everything is happening on schedule. Nobody is wrong about the activity. But the readiness question has not been asked — much less answered. This is VR — Validation & Readiness at its core: the gap between doing the work and proving the work worked.
Pick a recent "ready" claim. Can you produce, in five minutes, the evidence behind it? Not the activity (commits, tests run, hours logged) — the actual evidence the claim is true? If the answer takes longer than five minutes, the evidence is not at hand.
02 The aggregation problem
"Ready" usually arrives as a roll-up. Each subsystem owner says ready. The program lead aggregates. The verdict is "ready." The roll-up looks rigorous. It is not.
Aggregating opinions is not the same as aggregating evidence. If five team leads each say "we're ready" and one is wrong, the aggregated verdict is still "ready" — because the aggregation has no independent verification at any step. Each lead is doing their best inside their own scope; the cross-system risks they cannot see are nobody's responsibility.
At integration, the system fails if any subsystem is not ready. At the status meeting, the system reports ready if all the leads report ready. The two operations look identical in form and behave differently under uncertainty — because the status meeting measures confidence and integration measures evidence.
Each lead has a small probability of being over-confident in their own scope. With five subsystems, the aggregated probability that at least one is wrong grows fast. The status meeting smooths this out into a single "ready"; integration does not.
This is EC — Execution Control showing up indirectly: when the readiness verdict depends on each lead's individual confidence rather than on a cross-team evidence review, what the team has is confidence aggregated, not readiness verified.
03 The "we tested it" trap
"We tested it" is the most common readiness substitute in technical delivery. It feels close to evidence, but the substitution is silent and consequential.
"We tested it" answers: did the tests pass? Readiness asks: do the tests represent the conditions that will matter at integration, in production, under real load and real adversarial inputs?
A team can run thousands of passing tests and still be unready if those tests don't cover the failure modes the system will actually encounter. The signal "all tests green" gets read as "we're ready" — but those two statements are only equivalent if the test suite is itself a validated representation of the operating envelope.
Most test suites are not validated representations. They are accreted historical artifacts: tests written during feature work, plus tests added after past bugs, plus a few smoke tests on top. Nobody, in most cases, ever sat down and asked: "If we ran every test we have and they all passed, would that justify a readiness claim for this milestone?" That is a different question. Very few teams ask it.
04 Three checks that surface readiness gaps
You can run three targeted checks that expose the highest-cost readiness illusions. None takes more than thirty minutes.
None of these requires new tooling. All three surface the readiness claims that need more evidence before the milestone, not after it.
Most teams that miss milestones were "ready" the week before — not because they lied, but because their definition of "ready" was "we did the work" instead of "we have evidence the system does what we claim it does." Activity is what you can observe in retrospect. Evidence is what you can show on demand. The gap between them is where milestone failures hide.
Readiness is a discipline, not a feeling. Teams that maintain it ask different questions than teams that don't — and the gap shows up most clearly in the moments before a milestone, when the cost of the wrong verdict is highest. The SYS Readiness Check is built to surface exactly that kind of structural exposure across all five dimensions: definition clarity, system structure, validation readiness, change exposure, and execution control.