Never Infer Past the Last Known State

The examples below are deliberately generalized and may use simplified or hypothetical scenarios. They are not descriptions of any identifiable organisation's current systems, architecture or control state.

Operators enter the same information repeatedly, and most of it is derivable. How long a vehicle has been on the yard is the gap since it arrived. The price to charge is usually the price charged last time. The quantity on hand is the last count plus what has moved. Systems that fill these in are faster to use and easier to sell, so almost every operational system grows an inference somewhere.

The inference is nearly always right in the middle of the data and wrong at the edges, and the edges are where the money is. A prefilled figure carries the authority of the system that produced it. An operator under time pressure accepts it, and the wrong number travels downstream into an invoice, a stock position or a statutory return.

The rule

Derive the inferred value only from the entity's most recent qualifying record. If that record is not of a kind that can seed the inference, prefill nothing. Do not search backwards for an older record that would produce an answer.

This sounds obviously correct and is routinely violated, because the violation looks like helpfulness. A query written as "the most recent arrival for this asset" will happily reach back eight months past a departure nobody recorded, and return a duration measured in thousands of hours. A query written as "the most recent movement for this asset, and use it only if it is an arrival" returns nothing in the same situation, which is the correct answer.

Deciding what counts toward state

The last known state is only meaningful once you have said which records establish it. That decision is business logic and belongs in one documented place, because several kinds of record look like events and are not.

• Cancelled and voided records describe something that did not happen, so they cannot establish state.
• Placeholder or provisional records created to reserve a sequence number are just structure.
• Records that pass through without stopping, such as a transit movement, do not change presence at a location.
• Rejected records are evidence of an attempt and must not feed a calculation.
• Drafts are the interesting case: they usually should count, because the operator knows the event happened, and they should be visibly marked as unconfirmed wherever the derived value appears.

Write the inclusion rule once and have both the state timeline and the inference use it. When those two diverge, a screen shows one history and the prefilled number reflects a different one, and the resulting support conversation is very difficult.

A prefill is a suggestion, not a commitment

Three properties keep an inferred value honest. It is always editable. It is never committed without a person seeing it. And it is distinguishable, after the fact, from a value somebody typed.

The third is the one that gets dropped, because a column is less visible work than a component. Record the provenance of the value on the record: entered by a person, inferred from a specific source record, or imported from a named file. Six months later, when a figure is queried, the difference between "an operator typed this" and "the system suggested this and nobody changed it" is the whole investigation.

Blank beats plausible

The instinct to always show something is worth resisting. An empty field with a short explanation asks a person for thirty seconds of attention. A confidently wrong prefill costs a correction, a credit note and a conversation with a customer who now checks every figure you send them.

Say why the field is empty, in the interface, at the moment it matters: no prior arrival on record for this asset at this location. That sentence turns a gap into information. It also surfaces the missing record, which is the actual problem, and gives the operator a chance to fix it before the charge is raised.

Where the same rule applies

• Duration on site, computed from the last movement rather than the last arrival of the right kind.
• Last price paid, where the previous line was a credit, a sample or a written-off item.
• Quantity on hand, where the last count was a partial stock take covering some locations only.
• Warranty or service intervals, where the last service record was cancelled after booking.
• Next due date on a recurring obligation, where the previous period was formally waived.
• Contact details carried forward, where the most recent record was an enquiry from a different person at the same organisation.

What to test

• An entity whose last qualifying record is the right kind, asserting the value is inferred and marked as inferred.
• An entity whose last record is the wrong kind, asserting nothing is prefilled and the reason is shown.
• An entity with an older record that would produce a value, asserting the system does not reach past the most recent one.
• An entity with no history at all, asserting a clean empty state and no exception.
• A draft as the most recent record, asserting the value is inferred and flagged as unconfirmed.
• A cancelled record as the most recent, asserting it is skipped for state and still visible in history.
• Two records with identical timestamps, asserting a deterministic tie-break and not whichever row the database happens to return first.
• An operator overriding an inferred value, asserting the stored provenance changes to entered.

The tie-break case deserves attention. Operational systems capture events at whole-minute precision often enough that two records genuinely share a timestamp, and an unordered query then returns them in whatever order the storage engine finds convenient. Order by timestamp and then by a monotonic identifier, so the same data always yields the same last known state.

The general principle

Inference is a claim about the world made from incomplete records. The safe version of that claim is narrow: this is what the most recent evidence says, and where the evidence does not cover the question, the system declines to answer. The unsafe version searches until it finds something that supports an answer, which is a description of how bad data becomes confident data.

Any system that prefills a number a customer will eventually be charged for should be able to show, for every such number, which record it came from and whether a person looked at it. Building that in from the start costs a column and a provenance enum. Retrofitting it after the first disputed invoice costs considerably more.