A suite's blocking pipeline invocation has a ten-minute budget but takes thirty-five; how do you restructure what each invocation promises?

A feedback budget is a promise about how long a stage's invocation of the suite may take before the waiting itself becomes the problem. When the invocation outgrows it - ten minutes promised, thirty-five delivered - the instinct is to start deleting cases. That is usually the third move, not the first. ## Attribute before you cut A run's duration is not one number. It divides into: - **Fixed cost paid once per invocation** - process start, dependency resolution, data seeding, warm-up, and any wait for a target to be ready. - **Cost that scales with the selection** - the cases themselves, plus whatever each one sets up and tears down. - **Cost that scales with contention** - waiting on shared resources, queueing behind neighbours, throttling. Most teams have never measured the split, because a run's record times *cases* and not the *invocation*: the results say the cases took nine minutes; nobody accounts for the other twenty-six. A third of a blocking run is often preamble. Fixing that is cheaper than any conversation about coverage, and it has to come first. ## The contract change: one promise becomes several One entry point can make only one promise. If a single invocation must be both fast enough to block a change and broad enough to be worth trusting, it will fail at one of the two. The structural move is to **declare several entry points, each with its own budget and verdict rule**: - a **gate** invocation with a strict selection and a hard budget, whose failures stop the stage; - a **broad** invocation with a longer budget, whose failures are reported against the change without stopping it. The pipeline wires both, but the difference between them is written in the suite, not in the stage. Note what this is *not*: not a decision about which trigger each one runs on, and not the mechanics of dividing a run across parallel workers. This is about what each invocation promises and what its result may mean. ## Enforce the budget inside the entry point A budget the entry point does not know about is enforced by something killing the job from outside, producing the worst possible artefact: no results, no attribution, a rerun. Give the entry point its own deadline instead: as it approaches, the run stops itself and returns a **distinct budget-breach status** carrying partial results, the list of what had not run, and phase timings. A breach is a *result*. It tells you whether to buy hardware, cut cases or move the line; a silent kill tells you nothing. ## The trade-off | | One blocking entry point | Several with different promises | | --- | --- | --- | | What the pipeline wires | One command, one meaning | Several, each with a budget and a verdict | | Wait before a change advances | The whole suite | The gate selection only | | Coverage at the merge point | Everything the suite has | Only what the gate selects | | Who owns a failure | Whoever is blocked by it | Must be assigned explicitly | | Characteristic failure | The gate is overridden or skipped | The broad set turns red and nobody looks | | Total machine time | Lower | Higher, by the duplicated fixed cost | Four conditions decide which side you take: 1. **Revert cost.** If a bad change is cheap to unwind, deferring verification is a reasonable bet. If unwinding is expensive - data written, notifications sent, a release cut - more stays inside the budget. 2. **Catch rate of the deferred set.** Measure how often the broad invocation finds something the gate did not. Never, over months, means it is cost rather than insurance. Often means the line is drawn in the wrong place. 3. **Ownership.** A non-blocking invocation with no named owner and no stated response time is not deferred coverage; it is deleted coverage with a report nobody reads. 4. **Shared fixed cost.** This is why attribution comes first. If every invocation pays the same six-minute preamble, splitting one run into two adds six minutes of pure overhead and may raise total machine time while lowering the gate's latency. ## What moves, what is cut, and what is never on the table Whatever leaves the blocking invocation takes three things with it: an owner, a response time, and visibility at the place the change is reviewed. Some work should be cut rather than moved: coverage duplicated more cheaply at a lower level, and cases whose failures nobody has acted on in a year. Which specific cases to delete is a separate decision with its own criteria; the budget only says how much has to go. What is never on the table is meeting the budget by weakening what a result means: letting the gate's failures stop blocking, or reporting success on a run that did not finish. That converts a latency problem into an evidence problem, which surfaces later and costs more. ## Signs the split went wrong - Budget met but overrides rising - you moved risk, not work. - The broad invocation has been red for three weeks - the deferral had no owner. - Total pipeline time went up - duplicated fixed cost, unmeasured. - Nobody can state what the gate covers - the promise was never written down.