One row per boundary that has to be integrated. Uncertainty is how much you would learn that you do not already know; blast radius is how much has to change if the answer is bad. Both are deliberately coarse, because the ordering is not sensitive to the difference between a three and a four.
| Seam | Uncertainty | Blast radius | Days | Only after | Remove |
|---|---|---|---|---|---|
| # | Seam | Information | Effort | Per day | Finishes | Dependency |
|---|---|---|---|---|---|---|
| 1 | Platform to customer IT | 16 | 4d | 4.00 | 4d | |
| 2 | Control plane to vendor firmware | 25 | 8d | 3.13 | 12d | |
| 3 | Application to control plane | 12 | 5d | 2.40 | 17d | |
| 4 | Firmware to sensor board | 12 | 6d | 2.00 | 23d | after Control plane to vendor firmware |
| 5 | Model to application | 4 | 3d | 1.33 | 26d | |
| 6 | Telemetry to the dashboard | 1 | 2d | 0.50 | 28d |
When to integrate a seam, by what it can teach you
Uncertainty against blast radius, which is the framing worth carrying even without the calculator. The last row is the one that matters most in practice, because low uncertainty and low blast radius describes exactly the seam most programmes choose to start with.
| Uncertainty | Blast radius | When to integrate | Why |
|---|---|---|---|
| High uncertainty | High blast | First, always | A bad answer changes the design and you need the time to act on it |
| High uncertainty | Low blast | Early, but after the above | Worth learning, and a bad answer is absorbed locally |
| Low uncertainty | High blast | Middle. Verify, do not explore | You believe you know. Confirm cheaply and move on |
| Low uncertainty | Low blast | Last, or never separately | Confirms what you knew. This is the one teams start with |
The bottom row is not wasted work, it is work that produces no information. Doing it first is what makes a programme feel like it is progressing while the questions that decide it stay unasked.
A worked example
Six seams on a device programme totalling 28 days of integration, against a 20 day horizon set by a hardware order. The plan on the whiteboard starts with telemetry to the dashboard, because it is two days and it demonstrates something to a stakeholder.
Under that easiest-first ordering, 47 percent of the uncertainty is resolved by day 20, and the seam carrying the largest unknown, control plane to vendor firmware, lands on day 22. Two days after the hardware order. If it says something unwelcome, the answer arrives after the decision it should have informed.
Ordering by information per day instead resolves 76 percent by the horizon and puts that firmware seam on day 12, leaving eight days of schedule in hand when it reports. The same six seams, the same 28 days of work, and the only thing that changed is the order.
Note what comes first, though, and that it is not the riskiest seam. Platform to customer IT wins the opening slot at four days for an information score of 16, ahead of the firmware seam at eight days for 25, because the ordering maximises information per day rather than in total. That is the right trade when the horizon binds, and it is worth overriding if the firmware answer is the one a person has to act on first.
The last finding is the uncomfortable one. Even under the best ordering, 24 percent of the uncertainty is still unresolved at the horizon, because 28 days of integration do not fit in 20. No rearrangement fixes that. It is a scope conversation, and it is much cheaper in week one than in month four.
The arithmetic, so you can check it
Information for a seam is uncertainty x blast radius, on one-to-five scales, so it runs from 1 to 25. The scheduler is greedy on information / days, picking the highest available rate at each step among the seams whose dependencies are already satisfied.
The comparison ordering is greedy on 1 / days, which is shortest-first, since that is what teams do in practice when nobody has ranked by uncertainty. Both are then evaluated on the same question: what share of the total information has been resolved by the horizon.
Greedy by rate is not optimal, and it can be beaten by a scheduler that looks ahead, particularly when dependencies are dense. It is used here because the input estimates are one-to-five judgements and a more sophisticated optimiser would apply false precision to numbers that do not support it. The tool also assumes seams are integrated one at a time, which understates what a team with parallel capacity can do, though the ordering it recommends still holds as a priority list.
Why these failures concentrate at boundaries is in signs the failure is in the seams. To count the seams first, use the seam counter, and to record what each side believes crosses one, the interface contract diff.
Questions
The one with the most uncertainty per day of effort, subject to real dependencies. Uncertainty is what you would learn that you do not already know, and it matters more than how hard the seam is, because the purpose of integrating early is to find out whether the design holds while there is still time to change it.
Because it produces a demo rather than information. The easy seam is easy precisely because everybody already understands both sides, so completing it confirms what you knew. Meanwhile the seam nobody understands moves to the end of the schedule, which is where its surprises arrive with no slack left to absorb them.
How much has to change if the answer at that seam turns out badly. A boundary where a bad answer means adjusting a parser has a small blast radius; one where it means a different compute module or a different vendor has a large one. High uncertainty with a small blast radius can wait, and high uncertainty with a large one cannot.
Not very. Uncertainty and blast radius are one-to-five scales because the ordering is insensitive to the difference between a three and a four, and effort estimates in days are good enough. What changes the answer is including a seam nobody had listed, not refining the numbers on the ones you had.
Then the finding is scope, not sequencing, and it is worth having that conversation in week one rather than month four. The tool reports how much uncertainty is still unresolved at the horizon under the best possible ordering, and if that number is large no rearrangement fixes it: something has to be cut, deliberately deferred, or the date has to move.