Your canal-gate worker re-derives the operator's authority at 04:00, is denied, and the water is already promised downstream — what should it do?

## The moment two good answers collide The gate job was approved at 16:00 and the worker picks it up at 04:00. It holds a decision record — subject, one action, one resource, the rule that allowed it — and it has a choice: **act on the record**, or **ask the authorization system again, now, whether this subject may still open gate 14**. Both are defensible, which is exactly why interviewers push here: the two fail in opposite directions. Acting on the record executes a decision the world has since withdrawn. Re-deriving can refuse work the district has already committed to. ## Why re-derivation is the default The argument is one sentence: **a decision is a statement about the moment it was taken.** Between 16:00 and 04:00 the operator can be moved off gate duty, have their authorization withdrawn, or leave the district. If the worker acts on the record alone, the queue becomes a way to schedule actions that outlive a revocation, and your revocation lag is now whatever the backlog happens to be — a number nobody agreed to and nobody monitors. Re-deriving means taking the subject and the action-plus-resource out of the record and asking the authority you treat as current whether that is allowed *now*. In practice: - the record supplies **what** and **for whom**; current state supplies **whether**; - the question is one narrow action, so the check is cheap and a denial is unambiguous; - a denial at 04:00 is the system working, not an error condition to be retried away. Note which component does which thing. The service that handled the 16:00 request made the decision and wrote the record; the worker makes no new decision at 04:00 — it re-asks the same question and then acts or refuses. A design that blurs those two ends up unable to say who authorized anything. ## Where the recorded decision has to count There is one honest exception, and a candidate who cannot name it has half the answer: **the action was already promised outside your system.** The district told the neighbouring farm the water arrives at 04:00, and that farm has arranged its own morning around a commitment your service made on the strength of the 16:00 decision. Withdrawing an operator's entitlement is a statement about *who may decide*. It is not, on its own, a statement that a commitment already made to a third party is void — that is a business call above the worker's pay grade. So the record counts in the sense that **the work is not silently abandoned**; it does not count in the sense of "run it anyway". The move is to take it to someone who holds current authority, with the deadline attached, and let them decide while the window is still open. | situation at 04:00 | what the worker does | who hears about it | |---|---|---| | authority still holds | performs the recorded action, unchanged | nobody beyond the normal records | | authority withdrawn, nothing promised downstream | drops the job | the owning team, and whoever inherited the duty | | authority withdrawn, commitment already made | parks it and escalates before the window closes | a named human who holds current authority | | the job's own deadline already passed | drops it without re-checking anything | the owning team, as a missed-window event | ## Silence is the real failure mode Of the outcomes above, the one that becomes an incident is none of the refusals — it is a refusal **nobody sees**. A job denied, swallowed and counted as complete leaves the operator believing the field will be watered. Three rules keep it honest: 1. a run-time denial is a **distinct outcome**, never folded into a generic failure counter; 2. every parked item has a **named owner and a deadline of its own**, so parking cannot silently become a queue nobody reads; 3. retrying a denial is pointless and dangerous — authority did not fail transiently, it changed, so the loop just burns the window while telling no one. That also rules out the opposite over-correction: parking *everything* for a human is not a safe default. It converts a cheap automatic decision into a backlog of human judgement calls that arrive faster than anyone can clear them, and the windows pass anyway. ## The lag you bound but cannot remove Re-deriving at 04:00 shrinks the window in which a withdrawn authority can still act — from twelve hours down to the gap between the check returning and the actuator moving. It does not close it. The check and the effect are not atomic, so a revocation landing in those few seconds still lets the gate open. That is the sentence a senior answer says out loud: **you bound the exposure, you do not eliminate it.** What you do with the residue is make the action observable and reversible — report the gate's actual position back, alert on a position change with no matching allowed decision, and keep the gate closable — rather than pretending the check and the effect happened at the same instant. ## What you owe the approver Someone approved a change at 16:00 and has a reasonable expectation of learning whether it happened. Re-derivation deliberately makes "approved" and "executed" two separate events hours apart, so the approval surface has to show both. Skip that and the safest design you can build is also the one that quietly loses work — which is how teams end up disabling the re-check.