Capture-time truth: why yesterday's evidence must never be judged by today's rules

A reading is not a number

An operator writes 6.95 barg against a compressor discharge point at 05:40 on a Tuesday. On its own that is a measurement, not evidence. It becomes evidence because of everything that was true around it at that moment:

• the acceptable range was 6.8–7.4 barg, so the plant was inside its limits
• the point belonged to that compressor, which was the duty machine that week
• the round asked that question — a particular revision, with a particular wording
• a temporary control was, or was not, in force over the system

Six months later, every one of those can be different. The band may have been widened after a process change. The compressor may have been swapped to standby, or re-tagged. The round may have been revised twice. The temporary control was cleared in March.

What replaying history through today's configuration does

Most systems store the measurement and look everything else up when you ask. It is the obvious design: one row per reading, joined to the point, the equipment, the limits. Reports are simple, the database is small, and nothing looks wrong.

Then somebody widens a limit, and history changes underneath the record:

• A reading that was an exceedance in March — flagged at the time, escalated, acted on — renders today as comfortably in range. The escalation now looks like an overreaction nobody can explain.
• A reading that was perfectly acceptable in March renders today as a breach, because a limit was tightened in June. A year-end report shows a run of alarms that never happened, and somebody has to prove a negative.

Neither report is a lie anyone told. Both are produced by a system doing exactly what it was built to do, and both are wrong about the past. The failure is quiet, arrives long after the change that caused it, and surfaces precisely when the record is being examined most closely.

Five ways the ground moves under a record

1. A limit is widened or tightened

The commonest, and the one with the sharpest consequence: the same number crosses from acceptable to exceedance, or back, without anybody touching the reading.

2. The round is revised

A point is reworded, a new check is inserted, an old one retired. Replay the walk through the current revision and the operator appears to have answered questions they were never asked, and to have skipped ones that did not exist.

3. Equipment moves

A pump is re-tagged, a duty role swaps to the standby machine, an asset is moved to another line. Evidence recorded against the machine that was actually there must not migrate to whatever occupies that position now — or an asset's history becomes the history of a position, which is not the same thing and matters enormously when a failure is investigated.

4. An operator re-reads a point

Somebody notices a mistake and takes the reading again. The honest record keeps both: the first answer, marked as superseded, and the correction beside it. Overwriting is tidier and destroys the most reassuring thing in the record — a person noticing.

5. A temporary control is cleared

While a control is in force, extra checks exist and normal expectations are suspended. Clear it and those conditions vanish from the current configuration. The readings taken under it must still say they were taken under it, or a period of heightened attention reads afterwards as an inexplicable flurry of extra checks.

Three people, one question

These sound like different requests. They are the same one:

• The plant manager: “show me what happened”
• The auditor: “show me what the operator knew”
• The regulator: “show me the evidence as it existed”

Each is asking to see the past on its own terms, not translated into the present. A system that can only answer with today's configuration cannot answer any of them — and, worse, will appear to, confidently, with a number that looks exactly like the truth.

What it costs to do properly

This is not free, and any account that pretends otherwise is selling something:

• More storage. Each reading carries its own context — the range, the limits, the equipment link, the question as asked — rather than pointing at one shared copy.
• Harder writes. The moment of capture has to resolve and freeze everything the reading depends on, which is more work than storing a number and a foreign key.
• You cannot retro-fix a mistake. A limit set wrongly in March stays wrong in March's evidence. It is corrected forwards. Teams used to editing history find this uncomfortable for about a week, and then find it is the entire point.
• Legacy rows stay honest. Evidence recorded before a system started freezing context has to show blanks there, not values back-filled from today's configuration. A blank is a fact; a back-fill is a guess wearing a fact's clothes.

How to test a system for it

You do not need access to the source. Four questions, and any vendor can be asked them in a demo:

• Widen a limit, then look at an old reading. Does its verdict change? It must not.
• Ask for the reading's own copy of the range. Can the export or API show you the band that applied at capture, on the row itself — or only the band as it stands now?
• Correct a reading. Does the original survive, visibly, or does the number simply change?
• Ask what happens to evidence recorded before the feature existed. If the answer involves back-filling, the system is prepared to invent history under some circumstances — and you have just learned which.

Why Amberhold is built this way

Amberhold freezes the judgement at the moment of capture. Every reading carries the expected range and action limits that applied, the equipment it was recorded against, the revision of the round it answered, and whether a temporary control was in force. Those columns are part of the record, not a lookup — they travel into the CSV export, the API and any dashboard built on it.

Corrections append rather than overwrite: a re-read leaves the first answer in place, marked as superseded, next to the one that replaced it. Records are append-only, and that is enforced by the database itself rather than by application discipline — an update or a delete is rejected at the storage layer.

And where evidence predates the freezing, those columns are left blank rather than filled from today's configuration. It is less tidy. It is the only honest answer, and it is the same instinct behind everything else here: the record says what was true when it happened, and nothing later edits it.

Common questions