One row per condition that moves in the field. Field states is how many distinct regimes it has out there, bench states is how many of them your rig can actually produce, and field time covered is the share of operating hours that fall inside what the bench reproduces.
| Condition | Field states | Bench states | Field time covered % | Days to extend | Remove |
|---|---|---|---|---|---|
| # | Condition | Covered | States | Gain | Effort | Running | Cumulative |
|---|---|---|---|---|---|---|---|
| 1 | Input rate | 74% | 2 of 3 | +2.8 pp | 1d | 11% | 1d |
| 2 | Network latency and loss | 55% | 2 of 4 | +8.8 pp | 3d | 20% | 4d |
| 3 | Device hardware revision | 45% | 1 of 3 | +24.0 pp | 6d | 44% | 10d |
| 4 | Ambient temperature | 62% | 1 of 4 | +26.8 pp | 4d | 70% | 14d |
| 5 | Supply voltage quality | 88% | 1 of 3 | +9.6 pp | 2d | 80% | 16d |
| 6 | Operator behaviour mode | 80% | 2 of 3 | +20.0 pp | 5d | 100% | 21d |
What coverage on each axis is worth across all of them
Read down the 90 percent row. A bench that reproduces each of six conditions nine times out of ten reproduces all six at once just over half the time, and that is before anything is said about the combinations. This is the table to keep, because it settles the argument with no inputs at all.
| Coverage per condition | 2 conditions | 4 conditions | 6 conditions | 8 conditions |
|---|---|---|---|---|
| 95% each | 90% | 81% | 74% | 66% |
| 90% each | 81% | 66% | 53% | 43% |
| 80% each | 64% | 41% | 26% | 17% |
| 70% each | 49% | 24% | 12% | 5.8% |
| 60% each | 36% | 13% | 4.7% | 1.7% |
Simultaneous coverage, which is the share of field operating time with every condition inside the bench envelope at once. Nobody reports this number, because nobody owns all the axes: each is reported separately by whoever owns it, and each of them is telling the truth.
A worked example
A connected device on a plant floor, with six conditions that vary in the field. Ambient temperature covered 62 percent of the time, supply voltage quality 88, network conditions 55, input rate 74, hardware revision 45, operator behaviour 80. Every one of those is a number a team would report without embarrassment.
Multiplied, the bench reproduces the field 8.0 percent of the time. Ninety-two percent of operating hours are outside the envelope on at least one axis, and every hour of bench testing says nothing about them.
The combination figure is worse. Across the six conditions the field presents 1,296 joint states and the bench can produce 8 of them, which is 0.6 percent. Three of the six conditions are pinned at a single fixed value, so the bench is varying one factor at a time and interactions are essentially untested. That is where the failure that survives validation comes from: not a condition nobody thought of, but two conditions nobody put together.
The extension order is the useful part, and it is not the order of how bad each row is. Input rate goes first at one day for 2.8 points; network conditions second at three days for 6.5; hardware revision third at six days for 9.8. Ten days of bench work takes coverage from 8 percent to 44, and four more days of thermal work takes it to 70. The last two conditions cost seven days for the remaining thirty points.
The decision that matters is where on that curve you stop, made once and written down. Most programmes never make it: the bench stops growing when the budget runs out, and nobody records what that bought.
The arithmetic, so you can check it
Simultaneous coverage is the product of the per-condition shares. Combination coverage is product of bench states / product of field states. Extending a condition takes its share to one, so the gain is multiplicative, and the extension order is greedy on coverage gained per day.
The product assumes conditions vary independently, and they usually do not. Hot days bring brownouts; peak input rate arrives with the shift that has the least experienced operator. Positive correlation means the off-nominal conditions co-occur, so the true simultaneous coverage is higher than the product and the combination count is smaller than the multiplication suggests. The direction of the finding survives that; the exact percentage does not. The deeper limit is that coverage is measured against your own list of conditions, so it bounds what testing can tell you rather than establishing that anything works.
Why this gap shows up as a production failure is in why AI works in testing but fails in production. For the data half of the same question, use the eval design planner, and for what the bench cannot show about failure modes, the failure mode coverage tool.
Questions
Because conditions have to hold simultaneously, so the shares multiply rather than average. Six conditions each covered 80 percent of the time gives 26 percent of field operating hours where all six are inside the envelope at once. Every individual number looks acceptable in a report, and the product never appears in one.
Condition coverage asks how much of each axis you can reach. Combination coverage asks how many of the field's joint states you have ever produced at the same time. A bench that varies one factor at a time can score well on the first and near zero on the second, and interactions are where the failures that survive validation live.
The one that gains the most coverage per day of work, which is usually not the worst one. The narrowest condition is often the most expensive to fix, so it earns its place third or fourth while two cheap extensions go ahead of it. The tool orders them that way and shows the running coverage as each lands.
Device or board revision, firmware version, the network path rather than just its bandwidth, time of day, which operator is on shift, and whatever the customer reconfigured last month without telling anyone. These share a property: they are not physical quantities, so they do not appear on a test plan built from a datasheet.
No. It means the bench can produce the conditions you listed, and the list is the part that is wrong. Coverage is a measure of your test rig against your own model of the field, so it bounds what testing can tell you rather than establishing that the system works.