“Not released” can be the gate working

A copy that lost fields

An order line had to move to the end of an order when the order was edited. The first version rebuilt the moved line from a short allow-list of nine fields. It silently lost every other field on the line: the ship date, costing, the sales employee, the line's own custom fields, the ship-to.

An allow-list fails quietly. Any field nobody thought of disappears without a trace, including fields a future version of the ERP will add. So we inverted it. The line is now copied whole, and a deny-list names only the fields the ERP computes or owns and must never be sent. It has 84 entries.

Every entry backed by a measurement

The first live run on the test company found five fields the ERP computes itself, which nobody had guessed. Each deny-list entry is backed by a live measurement, and the final list was re-checked offline against saved read-backs.

Then a review by a different model found the only major issue: when a person emptied a value, the copy quietly brought the old value back. It was fixed red first and green within minutes.

Then the clock ran out

The work was done and proven when a forced logoff on the host left 44 minutes. The full test run takes about 95. A run of only the changed area was green, and a small, well-proven change is exactly where skipping the full run feels safe.

The agent reported NOT RELEASED. The code stayed on its branch. Master, the shared repository and every desk were untouched, and nothing was left behind a half-on switch.

Why that was right

A changed-area run is evidence. It is not a release gate, because it cannot see a break in an area the change did not touch. The gate exists for the days when skipping feels safe.

It has held more than once since. Two packets stopped at clean points before a Saturday-night logoff and shipped together in the next release. Another stopped on a failing smoke test with 22 minutes left; the next packet proved the cause, fixed the test and shipped it.

The mistake was in the packet

The clock was the planner's mistake, not the run's. The packet had been written with a deadline that could not fit, and I direct the planner.

A deadline is a sum of measured durations, not a feeling about the size of a change. A one-decision change pays the same fixed costs as a nineteen-decision one: full suites about 95 minutes, the release about 23, the end-of-run steps about 15. That is about 2 hours 15 minutes before anything ships. Every packet's clock is now built from the last measured run, and when it does not fit, the packet says so before it is sent.