LockChain Core §1

Four different questions, four different ways to fail

The blueprint is explicit that a mature LockChain implementation should have four different integrity layers, and that this is “substantially stronger than simply putting a SHA-256 hash next to a document.” Each layer answers a different question. Each one can fail on its own. So the verifier reports them separately rather than collapsing them into a single green tick, because one boolean would hide which one broke.

1. Record integrity

Question: Has an individual event changed since it was recorded?
Method: Recompute canonical_event_hash over the hashed field set and compare.
Defeated by: An attacker who can rewrite the stored event AND its stored hash.

2. Sequence integrity

Question: Have events been removed, inserted or reordered relative to the committed chain?
Method: Walk previous_event_hash from genesis; every link must name its predecessor.
Defeated by: An attacker who can rewrite the whole chain from the edit point forward.

3. Signer / accountability integrity

Question: Which protected signing identity authorised this receipt?
Method: Ed25519 verification of the checkpoint against a registered, non-revoked key.
Defeated by: An attacker who holds the signing key. This is why keys must not sit in the application database.

4. Storage / retention integrity

Question: Was anything deleted inside a required retention period or a legal hold?
Method: Compare the sequence range a checkpoint committed against what the store can still produce.
Defeated by: An attacker who can delete records AND the checkpoints that counted them.

Generated at build time from assets/lockchain.mjs — 4 layers, each with its own defeatedBy field. The browser demonstrations, the Node gates and this page all read the same file.

The honest limit, shipped to the reader

What `describeLimits()` returns

These four statements are not marketing copy written beside the engine. They are the literal return value of a function in the engine, printed here exactly as it returns them, and the engine test asserts the word that overclaims never appears in any of them.

The claim: Tamper-evident: alteration of the recorded bytes, of their order, or of who signed for them is detectable.
Not the claim: Not tamper-proof, and not a claim that anything recorded is true.
The privileged attacker: A privileged attacker who possesses every database, signing key, checkpoint and backup could potentially fabricate a replacement history. Separation of signing keys from application databases, key rotation and audit, protected checkpoints, retained independent verification material and separate backup/retention controls are what make that expensive — not the hash chain by itself.
The truth boundary: Cryptography can demonstrate that recorded bytes have not been altered in defined ways. It cannot prove that an allegation contained inside those bytes is true.

The word we use, and the word we refuse

Tamper-evident. Not tamper-proof, and never a claim that what was recorded is true.

Why the word matters

The blueprint says it plainly: even four layers “should be described publicly as tamper-evident, not magically” something stronger. A privileged attacker who possesses every database, signing key, checkpoint and backup could potentially fabricate a replacement history. That is not a hypothetical worth hiding in a footnote; it is the reason the production design exists in the shape it does.

So the countermeasures are structural, not verbal. Signing keys are separated from application databases. Keys are rotated and audited. Checkpoints are protected. Independent verification material is preserved. Backup and retention controls are held separately from the store they cover. Those controls are what make a fabricated history expensive — not the hash chain by itself.

Every layer names what defeats it. That is deliberate. A layer whose failure mode is never stated is a layer whose failure mode is never designed against. Read the fourth column of every card above as the specification for the control that has to sit beside it.

The rule that keeps the record honest

The critical design rule in the blueprint is an imperative, and it is implemented as one:

Never edit the historical event to “fix” it.

A correction becomes a new event: CORRECTS → event_abc123

There is no update() and no delete() on the ledger. A correction appends and points at the original, which stays exactly where it was — still hashed, still linked, still verifiable. That preserves the original record while giving the system a legally and operationally understandable correction history. The correction history is the record.

What a green result actually says

When all four layers pass, the verifier does not say “verified”, “authentic” or “valid”. It says what was tested: no alteration, removal, reordering or unregistered signer was detected in the material supplied. And every result carries the boundary sentence with it, so a green panel can never be read as a statement about whether what was recorded is true.

The permanent doctrine. LockChain proves provenance, sequence, integrity and accountable handling. It does not manufacture truth. Cryptography can demonstrate that recorded bytes have not been altered in defined ways. It cannot prove that an allegation contained inside those bytes is true — which is what the evidence ladder exists to keep straight.