The sales process keeps a plan of the steps to a first commitment, with a target date, a baseline and a slippage figure on each row. A question about the slippage field turned out to have an awkward answer: nothing computes it, nothing writes it, and every row in the table was empty.
- An always empty field reads exactly like a clean answer. Asked how much a plan had slipped, the honest response was that nothing had ever recorded it, which is not the same as nothing having slipped. This was the second instance of the same shape in two days, after an event log was found holding forty nine rows of a single type, with four of its five types never once written.
- Only one part of the fix had a deadline, and separating that out is most of the value. Slippage is measured from a baseline, and a baseline can only be captured at the moment a customer accepts the plan. The rest of the measurement can be built next month and still be correct. An acceptance that passes uncaptured cannot be reconstructed afterwards.
- The automation that stamps it re-enters every time any watched field changes on an accepted plan, so a stamp without a guard would keep overwriting the baseline with whatever the dates say now. A plan renegotiated twice would then report as perfectly on time. The guard is a filter excluding any row that already carries a baseline, which makes the original survive every later edit.
- A test proving only that the stamp works would pass just as well against the version that overwrites, which is the version that destroys the history. So the fixture plants a row with an old baseline deliberately and fails if it moves, plants a row with no target date and fails if it is written to, then re-enters the trigger and checks both again.