Tamper Evidence

Atom grounded on Final Critique 17 — 2026-11-06 at 700b167 9 invariants regulated · via 1 composer composed by 1

Derived card — generated from the corpus (status line, invariant headers, sibling formal-model files, Composes edges). The specification below is canonical. composition graph →

Table of contents

Tamper Evidence

Summary

Tamper Evidence answers one question: has this set of records changed since it was sealed? A seal is a permanent record holding a proof — a mathematical fingerprint of the records as they stood when sealed — and checking the seal recomputes the fingerprint over the records presented and compares the two, so any change since sealing shows. The pattern detects tampering rather than preventing it: someone who can rewrite both the records and the seal can rewrite both, and only a record of the seal kept beyond their reach, which a separate pattern supplies, defeats that. It works the same with any fingerprinting method that has no known way to fake a match and that anyone holding the records and the seal can check, and on its own it does not say when or by whom records were changed, who made a seal, or whether a seal’s time can be trusted; each of those is a separate pattern built on top. This is the mechanism behind sealing financial transaction journals, medical-record change logs and payment-card access logs so auditors can confirm nothing was rewritten, and Git’s commit history (a widely used system for tracking changes to software) rests on the same idea.

Intent

WHY

A regulated record set must answer one question provably: have these been altered since they were sealed? Procedure cannot answer it — a runbook, an access-control list and a developer’s word are all claims about the past made by the party under audit. A cryptographic commitment can: seal the record set, keep the proof, and any later modification is detectable by re-running the mechanism’s own verification over the records the verifier holds. This atom is that commitment and nothing more: it says whether a record set changed since a seal, never when it changed, which belongs to the patterns that own time and reach. It is mechanism-neutral by design — a hash chain, a Merkle tree with a signed root, a timestamp token and a blockchain anchor satisfy one contract — and it is honest about its ceiling: it produces evidence of tampering, never prevention of it. An adversary with write access to both the records and the seals rewrites both. What defeats that is an anchor outside the adversary’s reach, and that is a composing pattern’s, named here and not overclaimed.

Structure

Identity model

Identity 1: The atom MUST identify evidence by the evidence id.
Identity 2: The host MUST allocate an evidence id at the atom's seam.
Deleted: Identity 3. Execution Contract Logic confinement 3 owns it.
Identity 4: The business caller MUST NOT supply an evidence id.
Identity 5: The atom MUST NOT reuse an evidence id.
Identity 6: The atom MUST NOT identify evidence by the record set reference.
Identity 7: The atom MUST NOT identify evidence by sealing instant.
Identity 8: Two seals over one record set MUST carry two evidence ids.

NOTE: open 2026-10-22-a — the evidence id’s source is the host’s allocation under Identity (Identity 2), not a Capability requirement.

NOTE: watch the allocation ban (Identity 3).

Term evidence: one recorded commitment over a record set — an Evidence; carries the proof and nothing that changes.

Term evidence id: the opaque value naming one evidence — an Evidence Id.

Term record set reference: the opaque reference naming what was sealed — a Record Set Reference; the host owns what a record set is.

Term seam: the atom’s I/O boundary; the host injects the clock reading, the evidence id, the cryptographic material and record set match here.

Term transition: the atom’s evaluation of one call against the seal records.

Term business caller: the party whose action the call carries; never the source of an injected value.

NOTE: watch the seam citation (Term seam, Term transition, Term business caller).

Term now: the deployment’s clock reading at the call, as Execution Contract Logic confinement 11 declares it.

State

State 1: EVERY evidence MUST stand in sealed.
State 2: The atom MUST NOT offer a transition out of sealed.
State 3: EVERY evidence MUST carry evidence id, record set reference, proof and sealing instant.
State 4: An evidence MAY carry anchoring instant.
State 5: The atom MUST NOT store the mechanism credential.
State 6: The atom MUST NOT offer a deletion surface.
State 7: The atom MUST NOT offer a revocation surface.

Term sealed: the atom’s one state — recorded, and nothing further to become.

Term proof: the artifact the mechanism produced over the record set — a Proof: a hash chain, a Merkle root, a signed root, a timestamp token, a blockchain transaction id, or a composite.

Term sealing instant: the wall-time instant the evidence was recorded, stamped from the injected now — a Sealing Instant.

Term anchoring instant: the time an external anchor recorded at seal time — an Anchoring Instant; absent where the mechanism anchors nothing.

Term mechanism credential: the material the mechanism consumes to produce the proof — a Mechanism Credential; keying material for a keyed mechanism, and a blank value for an unkeyed one, blank as GRACE-lang Term blank has it: absent, empty, or whitespace alone. A keyed mechanism takes no blank credential (Operation 7); an unkeyed mechanism takes one (Operation 8).

Term unkeyed mechanism: a mechanism that computes the proof from no keying material, such as a hash chain no key signs; a mechanism that is not unkeyed is keyed.

Term evidence field: evidence id

record set reference

proof

sealing instant

anchoring instant.

Term deletion surface: an action that removes an evidence from the seal records.

Term revocation surface: an action that marks an evidence as no longer to be relied on.

Capability requirement

Capability requirement 1: The deployment MUST supply now at the seam.
Capability requirement 2: The deployment MUST supply the seal records PER Execution Contract Database 1, Execution Contract Database 3, Execution Contract Database 4, Execution Contract Database 5, Execution Contract Database 7, Execution Contract Read 1 through 4, Execution Contract Refusal 1 and Execution Contract Conformance 9.
Capability requirement 3: The deployment MUST declare the deployment's mechanism.
Capability requirement 4: The deployment MUST supply the cryptographic material at the seam (Execution Contract Logic confinement 8).
Capability requirement 5: The deployment MUST supply record set match at the seam.
Capability requirement 6: The deployment MAY declare the string cap ONLY IF the string cap EXCEEDS 0 PER Execution Contract Input 2.
Capability requirement 7: The deployment MUST supply, at the seam, a seal check that never answers held over an original record set that differs from the record set presented at [Seal] (Invariant 3.2).
Capability requirement 8: The deployment MUST supply, at the seam, a seal check that never answers failed over an original record set that does not differ from the record set presented at [Seal] while no anchor change EXISTS for the recorded proof (Invariant 3.1).
Capability requirement 9: The deployment MUST supply, at the seam, a seal check that answers unavailable ONLY IF the mechanism's verification function consults the mechanism's own external anchor AND that anchor is unavailable at verify time.

Term cryptographic material: what the deployment’s mechanism computes at the seam — at Seal, the proof, computed from the mechanism credential over the record set the record set reference names, with the anchoring instant where the mechanism anchors at seal time, or the mechanism failure reason where the mechanism cannot compute the proof; at Verify, the seal check.

NOTE: open 2026-11-05-c — a mechanism whose verification fails at the seam with no anchor consulted has no arm: Capability requirement 8 bars failed there and Capability requirement 9 bars unavailable (Operation 17, Operation 18).

Operations

seal(record_set_ref, mechanism_credential)
  answers evidence_id
  refuses invalid-request | mechanism-failure(mechanism failure reason) | storage-failure

verify(evidence_id, original_record_set)
  answers verified | failed-verification(verification failure) | not-known

read()
  answers every evidence

Term mechanism failure reason: unreadable-records

keying-precondition

anchor-unreachable — the reason the deployment’s mechanism gives at the seam where the mechanism cannot compute the proof, and blank where the mechanism computes one; Seal’s mechanism-failure carries the reason (Operation 9).

Term verification failure: proof-invalid

record-set-mismatch

mechanism-verification-unavailable — the reasons Verify gives for a failed verification.

Operation 1: [Seal] MUST record the proof the deployment supplies at the seam.
Operation 2: [Seal] MUST record EXACTLY ONE evidence per successful call.
Operation 3: [Seal] MUST stamp sealing instant from the injected now.
Operation 4: IF the mechanism anchors at seal time THEN [Seal] MUST carry anchoring instant into the evidence.
Operation 5: [Seal] MUST consume the mechanism credential.
Operation 6: IF record set reference EQUALS blank THEN [Seal] MUST answer invalid-request.
Operation 7: IF the mechanism credential EQUALS blank AND the mechanism DOES NOT EQUAL an unkeyed mechanism THEN [Seal] MUST answer invalid-request.
Operation 8: [Seal] MUST accept a blank mechanism credential for an unkeyed mechanism.
Operation 9: IF mechanism failure reason DOES NOT EQUAL blank THEN [Seal] MUST answer mechanism-failure carrying the mechanism failure reason.
Operation 10: IF the database refuses the write THEN [Seal] MUST answer storage-failure.
Operation 11: [Seal] MUST discard the proof on storage-failure.
Deleted: Operation 12. Invariant 1.1 owns it.
Operation 13: [Verify] MUST take the original record set.
Operation 14: [Verify] MUST answer EXACTLY ONE OF verified, failed-verification, not-known.
Operation 15: IF no evidence EXISTS for the evidence id THEN [Verify] MUST answer not-known.
Operation 16: IF evidence EXISTS for the evidence id AND record set match EQUALS no THEN [Verify] MUST answer failed-verification carrying record-set-mismatch.
Operation 17: IF record set match EQUALS yes AND seal check EQUALS unavailable THEN [Verify] MUST answer failed-verification carrying mechanism-verification-unavailable.
Operation 18: IF record set match EQUALS yes AND seal check EQUALS failed THEN [Verify] MUST answer failed-verification carrying proof-invalid.
Operation 19: IF record set match EQUALS yes AND seal check EQUALS held THEN [Verify] MUST answer verified.
Operation 20: [Verify] MUST NOT write.
Deleted: Operation 21. Capability requirement 1 owns it.
Deleted: Operation 22. Capability requirement 4 owns it.
Deleted: Operation 22a. Capability requirement 5 owns it.
Operation 22b: The atom MUST NOT judge record set match.
Deleted: Operation 23. Execution Contract Logic confinement 3 owns it.
Deleted: Operation 24. Execution Contract Logic confinement 3 owns it.
Operation 25: The business caller MUST NOT supply sealing instant.
Operation 26: The implementation MUST own the mechanism.
Operation 27: [Read] MUST answer EVERY evidence.
Operation 28: [Read] MUST answer EVERY evidence field an evidence carries.
Operation 29: [Read] MUST NOT write.
Deleted: Operation 30. Operation 27 and Execution Contract Read 2 own it.
Deleted: Operation 31. Execution Contract Read 1 owns it.
Deleted: Operation 32. Execution Contract Refusal 1 owns it.
Operation 33: [Verify] MUST answer verified ONLY IF seal check EQUALS held.
Operation 34: IF a string input EXCEEDS the string cap THEN [Seal] MUST answer invalid-request.

NOTE: watch the cap’s refusal (Operation 34).

NOTE: watch the cap’s floor (Capability requirement 6).

Term string cap: the bound on a string input’s length in Unicode code points; 4,096 code points where a deployment declares none; the string inputs are the record set reference and the mechanism credential.

Term record set match: yes

no — the host’s answer, injected at the seam, to whether the presented original record set is the record set the evidence’s record set reference names. A different record set answers no; the named record set answers yes even where its content differs, and the content difference is for seal check to decide. The atom cannot judge it: record set reference is opaque and Identity rules forbid interpreting it, so the party that resolved the reference at seal time is the party that answers here (council read 13).

Term seal check: held

failed

unavailable — the mechanism’s verification function, run over the presented record set against the recorded proof. Named for the seal because Actor Identity declares its own proof check over an attestation, and Audit Trail wires both: one name for two judgments is a collision a composition cannot resolve (council read 13).

Term original record set: the record set a verifier presents at Verify — an Original Record Set; the proof commits to content, so the verifier holds the content.

Term verification set: the evidence’s own fields, the presented original record set, the host-injected record set match, where the mechanism’s verification function consults one, that mechanism’s own external anchor, and the seal check computed over them at the seam; everything Verify is allowed to read, and nothing else.

Term anchor change: a change in what the mechanism’s own external anchor answers the mechanism’s verification function for an evidence’s proof, such as a revocation or a withdrawal of trust the anchoring authority records; a mechanism whose verification function consults no external anchor has none.

The case space, and the rule that owns each case:

Call	Case	Answer	Effect on the seal records
Seal	credential and reference well-formed, mechanism computes, database accepts	evidence id	one evidence lands in Sealed (Operation 1, Operation 2)
Seal	blank reference, blank credential for a keyed mechanism, or a string input over the string cap	Invalid Request	none (Operation 6, Operation 7, Operation 34, Execution Contract Input 2)
Seal	mechanism cannot compute the proof	Mechanism Failure	none (Operation 9)
Seal	database refuses the write	Storage Failure	none — the proof is discarded (Operation 10, Operation 11)
Verify	no evidence under that id	Not Known	none — the call reads (Operation 15, Operation 20)
Verify	evidence found, wrong records presented	Record Set Mismatch	none (Operation 16)
Verify	right records, seal check unavailable	Mechanism Verification Unavailable	none (Operation 17)
Verify	right records, proof does not hold	Proof Invalid	none (Operation 18)
Verify	right records, proof holds	Verified	none (Operation 19, Operation 33)
Read	any call	every evidence, with its stored fields	none (Operation 27 through 29)

Where two Seal cases hold at once, the refusal listed first on Seal’s refuses line answers (Execution Contract Refusal 1).

Invariants

Invariant 1 — Evidence immutability.

Invariant 1.1: EVERY evidence field of a recorded evidence MUST NOT change.

Invariant 2 — Detectability of tampering.

Invariant 2.1: IF record set match EQUALS yes AND seal check DOES NOT EQUAL unavailable AND the original record set differs from the record set presented at [Seal] THEN [Verify] MUST answer failed-verification carrying proof-invalid.
Invariant 2.2: A deployment MUST NOT rest detectability on a mechanism that is not sound.
Deleted: Invariant 2.3. Non-goal 17 owns it.

Invariant 3 — Record-set binding.

Invariant 3.1: IF no anchor change EXISTS for a recorded proof AND the seal check DOES NOT EQUAL unavailable THEN the recorded proof MUST verify against the record set presented at [Seal].
Invariant 3.2: A recorded proof MUST NOT verify against a record set that differs from the record set presented at [Seal].

Invariant 4 — Verification self-containment given the originating records.

Invariant 4.1: [Verify] MUST consult the verification set.
Deleted: Invariant 4.2. Invariant 4.3 owns it.
Invariant 4.3: [Verify] MUST NOT consult a source outside the verification set.

Invariant 5 — Id stability.

Invariant 5.1: [Seal] MUST set the evidence id.
Invariant 5.2: An evidence id MUST NOT change.

Invariant 6 — No id reuse.

Invariant 6.1: Two evidence records MUST NOT share an evidence id.

Invariant 7 — Verification consistency under a fixed record set.

Invariant 7.1: IF no verification answering mechanism-verification-unavailable EXISTS among two verifications of one evidence against one record set AND no anchor change EXISTS between the two verifications THEN the two verifications MUST answer alike.

Invariant 8 — Mechanism opacity.

Invariant 8.1: The atom's contract MUST hold for EVERY sound mechanism whose verification function consults no source outside the verification set.
Invariant 8.2: The atom MUST NOT read the proof's internal structure.

Invariant 9 — Seal record durability.

Invariant 9.1: The atom MUST NOT delete an evidence.
Deleted: Invariant 9.2. Invariant 9.1 and Execution Contract Database 6 own it.
Deleted: Invariant 9.3. Execution Contract Database 1 owns it.

NOTE: watch the external answer that moves (Invariant 3.1, Invariant 7.1).

NOTE: watch the host’s state (Invariant 4.3).

NOTE: open 2026-11-05-a — the verification set holds the evidence’s own fields, yet Verify reads the seal records to find no evidence (Operation 15), and the seam’s reads of the proof, the reference and the record set match are placed nowhere (Invariant 4.1, Invariant 4.3).

Term contract: the rules of this specification, which a composing pattern relies on.

Examples

The same atom, five regulated domains, identical mechanic.

Financial — transaction-log anchoring under SOX

A bank’s settlement system seals each day’s transaction journal: seal(journal_2026-05-10, hsm_signing_key) → evidence_a91. The mechanism is a SHA-256 (Secure Hash Algorithm, 256-bit — a standard cryptographic hash function) hash chain over the day’s transactions, with the chain’s tail signed by an HSM-bound (Hardware Security Module — a dedicated tamper-resistant device for keys) key. At seal time, the chain tail is anchored to an RFC (Request for Comments — the Internet’s numbered standards series) 3161 qualified timestamp authority, and the time on the authority’s timestamp token is recorded as Anchoring Instant on the seal. Seven years later, during a SOX (Sarbanes-Oxley Act — US financial reporting law) section 404 audit, the external auditor presents the journal and verify(a91, journal_2026-05-10) → verified — confirming the day’s transactions were not altered since the seal.

Healthcare — EHR change-log integrity under HIPAA and 21 CFR Part 11

A hospital EHR (Electronic Health Record — the digital patient chart system) appends every record amendment (correction, addendum, redaction) to a per-patient change log. The change log is sealed on a rolling Merkle-tree basis — each commit produces a new root and a new seal. verify(seal, patient_change_log) → verified confirms the log has not been silently rewritten since the seal. A correction added today is a new event in the log, not a modification of yesterday’s; if anyone retroactively edited yesterday’s entry, every seal made over that entry before the edit would fail verification. 21 CFR Part 11’s (the US Code of Federal Regulations rule on electronic records and signatures) and HIPAA’s (US Health Insurance Portability and Accountability Act) electronic-record integrity bar is satisfied structurally.

Source control — Git’s commit DAG

A developer pushes a commit. Git computes the cryptographic hash (a fixed-length fingerprint computed from data — any change to the data produces a different fingerprint) of the commit object — which includes the hash of its parent commits — and stores the object under that hash. The hash is the Proof: the commit’s content, its parents, and (transitively) the entire history are committed to in one chain. git fsck is the verification function; tampering anywhere in the history produces a hash mismatch detectable from the repository alone. The commit DAG (directed acyclic graph — each commit points to its parents, and nothing points back) shows this atom’s mechanic without being an instance of it. The analogy keeps the Proof, the chained hashes, and the verification function, git fsck. It does not keep the names or the clock: Git names a commit by its own content hash, where the host allocates an Evidence Id (Identity 2); it names a tree by its content, so a tampered tree loses the name its commit recorded and reads as a different record set, where a Record Set Reference names the record set whatever its content (Term record set match); and the committer sets the commit timestamp, where Sealing Instant is stamped from the injected now (Operation 3, Operation 25). Git is a widely deployed tamper-evident history; the atom names what it does in domain-neutral terms.

Legal — document notarization under RFC 3161 trusted timestamping

A law firm timestamps an executed contract via a qualified Time-Stamp Authority (TSA — a trusted third party that issues signed proofs that data existed at a given time). The mechanism is RFC 3161: a hash of the contract is submitted to the TSA; the TSA returns a signed TimeStampToken binding the hash to a trusted time. The token is the Proof; Anchoring Instant is set from the TSA’s timestamp. Any future dispute — opposing counsel claims the contract was modified post-signing — is resolved by verify(evidence, contract_pdf) → verified | failed-verification(proof-invalid). eIDAS Regulation (Electronic Identification, Authentication and Trust Services — the EU (European Union) regulation governing electronic signatures and timestamps) gives qualified electronic timestamps presumed evidentiary effect across the EU.

Payments — PAN-handling audit under PCI DSS

A payment processor seals each day’s cardholder-data access log: seal(pan_access_log_2026-05-10, processor_key) → evidence_p41. The mechanism is a SHA-256 hash chain — each entry’s hash includes the previous entry’s hash and the entry’s content — whose tail is signed each day under the processor’s key, the Proof carrying the signature and the public key that checks it. A chain keyed by a shared secret, such as an HMAC (Hash-based Message Authentication Code) chain, is outside the contract: checking it needs the secret, which the verification set does not carry (Invariant 8.1). PCI DSS (Payment Card Industry Data Security Standard — the card networks’ mandatory security rules for cardholder data; here applied to PAN, the Primary Account Number) Requirement 10.5 mandates audit-log integrity; the seal is the structural form. A QSA’s (Qualified Security Assessor — a PCI-certified auditor) annual assessment runs verify over the prior year’s daily logs; any tampering — whether to hide a cardholder-data exfiltration or to forge access for a fraudulent dispute — is detected from the logs themselves.

The mechanic is identical across all five. What differs: the mechanism family (hash chain, Merkle tree, qualified timestamp), the frequency of sealing (per-commit, per-amendment, per-document, per-day), the anchoring story (none, RFC 3161 TSA, blockchain), and the composing patterns active around it (Actor Identity for authored seals, Trusted Timestamping for qualified anchors, External Anchoring for tamper-proof reach, Forensic Attribution for when and by whom a record set changed).

Rejection and verification-failure paths

Tampering detected — Proof Invalid. An incident response team queries a transaction journal seal and presents the journal as it exists now — after a discovered alteration:

verify(evidence_id: "evidence_a91", original_record_set: journal_2026-05-10_altered)
→ failed-verification(proof-invalid)

The Proof no longer matches the altered record set. The team then presents the prior day’s backup copy of the journal:

verify(evidence_id: "evidence_a91", original_record_set: journal_2026-05-10_backup)
→ verified

verified confirms the backup matches what was sealed; proof-invalid on the altered version confirms the journal changed since the seal.

Wrong record set presented — Record Set Mismatch. A verifier accidentally presents the wrong day’s journal to a seal:

verify(evidence_id: "evidence_a91", original_record_set: journal_2026-05-11)
→ failed-verification(record-set-mismatch)

The presented record set does not match the Record Set Reference the Evidence was made over. This is not a tampering signal — it is a caller error, structurally distinguishable from proof-invalid.

Regulated adversarial scenarios

Three scenarios the atom must survive in regulated contexts:

Regulator integrity audit. A regulator asks “how do I know these records weren’t rewritten after the fact?” The auditor takes the original record set from the host, the Evidence Id from the seal records, and runs Verify — independently, with their own implementation of the mechanism’s verification function. Verified is a structural guarantee, not a procedural promise. Invariants 2 and 3 are the structural answer. A bound on when the records could have been forged is not the atom’s to give: a qualified TSA’s time on the Evidence sets one only through Trusted Timestamping (forthcoming) (Non-goal 9).
Breach forensics — “when was the record altered?” An incident responder discovers anomalous data. They query the seal records for every Evidence whose Record Set Reference covers the suspect records and run Verify on each over the suspect records as they now stand: Proof Invalid says the records changed since that seal, where no anchor change has reached its proof, and Verified says they have not. The atom answers that much for each seal and no more. When the records were altered, and who altered them, is Forensic Attribution’s (forthcoming), which reads these answers against the times a trusted-timestamping pattern vouches for (Non-goal 9, Non-goal 15, Non-goal 16).
False-tamper-claim disproof. A counterparty claims “you modified the contract after I signed.” The system presents the contract and the Evidence; verify(evidence, contract) → verified. The claim is structurally disproven against the unmodified record set the system retains; the counterparty’s burden shifts to producing a different record set they claim is the authoritative one, at which point the dispute becomes about which version is canonical rather than whether it was tampered with. The atom answers the second question; the first belongs to the Content Lock or Document Versioning composing pattern.

NOTE: open 2026-11-05-e — the example names Content Lock and Document Versioning, which roadmap.md carries no row for.

Generation acceptance

This atom’s acceptance is provable: an external auditor clears the conformance checks from the seal records, the originating record sets and the deployment’s declared mechanism (External check 4), and the external checks from the records each one names.

Conformance checks

Check 1.1: An auditor MUST reconstruct EVERY seal from the evidence's stored fields (Invariant 1.1, State 3).
Check 1.2: An auditor MUST NOT need state beyond those fields and the originating record set (Invariant 4.1, Invariant 4.3).
Check 1.3: An auditor MUST confirm that EVERY evidence field of an evidence EQUALS the evidence field in EVERY committed version of the evidence (Invariant 1.1, Execution Contract Generation acceptance 1, Execution Contract Database 5).
Check 2.1: An auditor MUST verify an evidence with the auditor's own implementation of the mechanism's verification function (Invariant 4.1, Operation 13).
Check 2.2: An auditor MUST NOT need privileged access to the system to verify (Invariant 4.3).
Check 3.1: IF the record set match of a verification over an original record set carrying a single-byte change to the record set presented at [Seal] EQUALS yes AND the seal check of that verification DOES NOT EQUAL unavailable THEN an auditor MUST confirm that the verification answers failed-verification carrying proof-invalid (Invariant 2.1, Operation 18).

NOTE: open 2026-11-02-a — Check 3.1 exercises the failure direction alone, over one named differing set (a single-byte change) where Invariant 2.1 covers any, and no check has the record set presented at [Seal] answer verified (Operation 19, Invariant 3.1).
Check 4.1: An auditor MUST read verified, failed-verification and not-known as three distinct answers (Operation 14).
Check 4.2: An auditor MUST read record-set-mismatch, proof-invalid and mechanism-verification-unavailable as three distinct reasons (Operation 16, Operation 17, Operation 18).
Deleted: Check 5.1. A trusted-timestamping pattern owns it (Non-goal 9, Non-goal 15): an anchored bound on when a record set changed.
Deleted: Check 5.2. A forensic-attribution pattern owns it (Non-goal 15, Non-goal 16): a bound between two seals on when a record set changed.
Deleted: Check 6.1. Execution Contract Conformance 9 owns it.
Deleted: Check 6.2. External check 4 owns it.

External checks

External check 1: An auditor MUST read whether the mechanism is sound from the Mechanism Registry's evidence (Invariant 2.2).
External check 2: An auditor MUST read the anchor's trust from the anchoring authority's own records (Non-goal 1, Non-goal 2).
Deleted: External check 3. Execution Contract Conformance 9 owns it.
External check 4: An auditor MUST read the deployment's mechanism from the deployment's own declaration (Operation 26, Capability requirement 3).

NOTE: whether the mechanism is sound, anchor trust and the mechanism itself are what the seal records do not carry — the External check family v0.35 declares exists for exactly this (council read 13).

NOTE: EVERY check names the rule the check tests. The bar is the regulator’s question — can you prove these records were not altered? — answered provably.

Non-goals

Non-goal 1: The atom MUST NOT prevent tampering.
Non-goal 2: A deployment needing reach beyond detection MUST compose an external-anchoring pattern.
Non-goal 3: The atom MUST NOT anchor a proof once the seal lands.
Non-goal 4: The atom MUST NOT choose the mechanism's hash function.
Non-goal 5: The atom MUST NOT choose the mechanism's signature scheme.
Non-goal 6: The atom MUST NOT bind a proof to a named actor.
Non-goal 7: A deployment needing an attributable seal MUST compose Actor Identity.
Non-goal 8: The atom MUST NOT vouch for the clock.
Non-goal 9: A deployment whose time of seal carries legal force MUST compose a trusted-timestamping pattern.
Non-goal 10: The atom MUST NOT purge an evidence alongside purged records.
Non-goal 11: The atom MUST NOT define a record set.
Non-goal 12: The host MUST present a record set alike at seal time and at verify time.
Non-goal 13: The atom MUST NOT deduplicate two seals over one record set.
Non-goal 14: A pattern needing one seal per record set per cadence MUST own that coordination.
Non-goal 15: The atom MUST NOT bound when a record set changed.
Non-goal 16: A deployment needing when a record set changed MUST compose a forensic-attribution pattern.
Non-goal 17: A deployment needing a record set re-sealed under a sound mechanism MUST compose a mechanism-registry pattern.

NOTE: open 2026-11-05-b — the record set presented at Seal is declared by no Term, Seal taking a reference and no set, and Non-goal 12 obliges the host to present it alike at both times under a Non-goal heading.

Where the atom breaks down: when the host cannot supply a record set reference whose contents are reproducibly addressable at verify time; when the chosen mechanism commits to the records’ identity and not their content; when the proof records and the sealed records share an adversary with write access to both and no external anchor exists.

Edge cases

NOTE: open 2026-11-05-d — the headings Atomicity of a seal and Retention coupling stand beside spec-format’s Atomic writes and Retention asymmetry rows, and the rule labels follow the headings.

Atomicity of a seal

Deleted: Seal atomicity 1. Execution Contract Database 1 owns it.
Deleted: Seal atomicity 2. Execution Contract Database 1 and Execution Contract Database 3 own it.
Deleted: Seal atomicity 3. Execution Contract Database 3 owns it.

Concurrent seals

Concurrent seal 1: Two seals over one record set MUST stand as independent evidence.
Concurrent seal 2: The atom MUST NOT order two seals over one record set.

NOTE: the evidence a Read answers come in the order Execution Contract Read 5 states; no rule of this atom names another, since the atom orders no seal (Concurrent seal 2, Operation 27).

NOTE: watch the order an atom forbids (Concurrent seal 2).

NOTE: open 2026-10-21-f — seal names both the action Seal and the evidence it records (Identity 8, Concurrent seal 1).

Retention coupling

Deleted: Retention coupling 1. The composing pattern that owns the purge owns it (Retention coupling 2): a copy of a purged record set can still verify.
Retention coupling 2: A composing pattern MUST own the cascading purge of an evidence alongside the records.
Deleted: Retention coupling 3. The composing pattern that owns the purge owns it (Retention coupling 2): what a seal over destroyed records proves.

Verification caching

Verification caching 1: An implementation MAY cache a verification result ONLY IF the mechanism's verification function consults no external anchor.
Verification caching 2: An implementation MAY answer a cached verification result ONLY IF the evidence id, the original record set and the record set match of the call EQUAL the evidence id, the original record set and the record set match the cached result was verified over.
Deleted: Verification caching 3. An external-anchoring pattern owns it (Non-goal 2): what a seal answers once its anchor changes.

Composition notes

Composition note 1: A deployment MUST declare which composing patterns the deployment wired in.
Composition note 2: An integrity-relevant Event Log instance MUST compose this atom.
Composition note 3: A deployment needing an attributable seal MUST supply an actor's credential as the mechanism credential.
Composition note 4: A composing pattern MUST own the decision to purge an evidence alongside the records the evidence commits to.
Deleted: Composition note 5. GRACE-lang Hard invariant 26 owns it.

NOTE: composing patterns — Audit Trail. Forthcoming: External Anchoring, Trusted Timestamping, Forensic Attribution, Mechanism Registry.

Terms

Each [Term] marker above links to its term entry here; a term entry states what the concept is and its Kind.

Vocabulary

Term actors: the atom; the host; the transition; the implementation; the deployment; a composing pattern (also: a pattern, a writer); a business caller; a verifier; an auditor; an adversary; the mechanism; the seal records; an evidence; a seal; a verification.

Term records: evidence — one commitment, carrying evidence id, record set reference, proof, sealing instant and, where the mechanism anchors, anchoring instant.

Term record verbs: judge, identify, allocate, supply, reuse, carry, stand, order, offer, store, compute, record, stamp, consume, accept, answer, discard, alter, take, read, own, write, change, verify, consult, set, share, hold, delete, shrink, leave, reconstruct, need, confirm, bound, prevent, compose, anchor, choose, bind, vouch, purge, define, present, deduplicate, rest, re-seal, cache, declare, renumber, add, refuse, evaluate.

Term value sets: record set match = yes

no. seal check = held

failed

unavailable. evidence field = evidence id

record set reference

proof

sealing instant

anchoring instant. evidence state = sealed.

Term bounds: string cap.

Term cadences: empty — a seal cadence is the composing pattern’s (Composition note 1).

Term qualifiers: migrated — rewritten in GRACE lang v0.35 (2026-09-11); sound — a mechanism with no known practical collision or forgery attack.

Term terms: now, evidence, evidence id, record set reference, seam, transition, business caller, sealed, proof, sealing instant, anchoring instant, mechanism credential, unkeyed mechanism, evidence field, deletion surface, revocation surface, cryptographic material, record set match, seal check, original record set, verification set, anchor change, contract, mechanism failure reason, verification failure, string cap.

Evidence

The record this atom defines: a permanent, verifiable seal over a record set — cryptographic evidence of whether the set has been altered since it was sealed. It is produced by Seal and carries its Evidence Id, Record Set Reference, Proof, Sealing Instant, and optional Anchoring Instant; nothing about it changes once recorded, and the atom offers no surface to revoke, modify, or re-anchor it.

Kind: Type

Seal

The behavior a composing pattern invokes at seal time to record a new Evidence over a record set. It consumes the supplied Mechanism Credential, records the Proof the deployment’s mechanism computed from it over the record set at the seam, stamps Sealing Instant (and Anchoring Instant if the mechanism anchors synchronously), and returns the Evidence Id. It always creates a new record — it never modifies an existing one — and never persists the Mechanism Credential.

Kind: Operation

Verify

The read-only behavior an auditor or composing pattern invokes to confirm a recorded Evidence, by id, against a presented record set. It reads the seal check the deployment’s mechanism runs at the seam, the mechanism’s verification function over the Original Record Set against the stored Proof, and returns Verified, Failed Verification, or Not Known. It changes nothing. Unlike Actor Identity’s verify, it requires the originating record set as input, because the Proof commits to the records’ content.

Kind: Operation

Read

The read-only query answering every evidence the database holds, each with its stored fields. It changes nothing.

Kind: Operation

Evidence Id

The opaque, immutable identity of an Evidence, host-allocated at the I/O seam on Seal and never reused. The Record Set Reference, Proof, Sealing Instant, and Anchoring Instant are properties of the Evidence, not its identity.

Kind: Field Field of: Evidence Projection: evidence_id

Record Set Reference

The opaque reference to what the Evidence commits to — the record set the Proof is computed over. The atom does not interpret it; the host pattern defines what a record set is and how to present it to Verify later. Set on Seal, immutable thereafter.

Kind: Field Field of: Evidence Projection: record_set_ref

Proof

The cryptographic artifact that commits to the record set’s content — a hash chain, Merkle root, signed root, RFC 3161 timestamp token, blockchain transaction id, or composite. Computed from the Mechanism Credential over the record set at the seam by the deployment’s mechanism, recorded by Seal on the Evidence, and re-checked by the seal check at Verify. Set on Seal, immutable thereafter.

Kind: Field Field of: Evidence Projection: proof

Sealing Instant

The wall-time the Evidence was recorded, stamped from the host-injected Now on Seal. Immutable thereafter; best-effort, since clock quality is a deployment concern.

Kind: Field Field of: Evidence Projection: sealed_at

Anchoring Instant

The wall-time of an external anchor, present only when the chosen mechanism produced one synchronously at seal time (for example, an RFC 3161 timestamp authority called during Seal). Set on Seal if produced, immutable thereafter, and absent otherwise. Later, asynchronous anchoring belongs to a separate External Anchoring composition.

Kind: Field Field of: Evidence Projection: anchored_at

Mechanism Credential

The opaque material the chosen mechanism supplies to Seal to produce the Proof — keying material for keyed mechanisms, possibly empty or a configuration handle for unkeyed ones. It is consumed per call — used to compute the Proof and then discarded — and never persisted under this name (or any name) by the atom. It is the only caller-supplied secret.

Kind: Parameter Parameter of: Seal Projection: mechanism_credential

Original Record Set

The originating record set the verifier presents to Verify, re-checked against the stored Proof to detect modification. It is supplied per call and not stored under this name; the asymmetry from Actor Identity’s verify is that this content must be re-presented, because the Proof commits to the records’ content.

Kind: Parameter Parameter of: Verify Projection: original_record_set

Now

The current wall-time reading Seal stamps Sealing Instant from, supplied to the pure transition by the host at the I/O seam (never read inside the transition, never supplied by the business caller).

Kind: Parameter Parameter of: Seal Projection: now

Sealed

The atom’s single stable state: an Evidence that has been recorded. There are no transitions out of it — the atom has no surface to revoke, invalidate, modify, or re-anchor an Evidence once recorded.

Kind: Member Member of: the evidence state Role: Outcome

Verified

The outcome Verify returns when the stored Proof checks out against the presented Original Record Set under the chosen mechanism’s verification function. It is the structural confirmation that the records were not altered since the Evidence sealed them (conditional on a cryptographically sound mechanism).

Kind: Member Member of: the Verify outcome Role: Outcome Projection: verified

Failed Verification

The outcome Verify returns when the Evidence exists but does not verify, carrying a reason — Proof Invalid, Record Set Mismatch, or Mechanism Verification Unavailable. Distinct from Not Known, which is a lookup miss.

Kind: Member Member of: the Verify outcome Role: Outcome Projection: failed-verification

Not Known

The outcome Verify returns when the supplied Evidence Id references no recorded Evidence — a lookup miss, not a verification failure. It is exclusively an Evidence Id lookup miss; an absent or wrong record set routes to Failed Verification for reason Record Set Mismatch instead.

Kind: Member Member of: the Verify outcome Role: Outcome Projection: not-known

Proof Invalid

The Failed Verification reason returned when the mechanism’s verification function, run over the presented record set against the stored Proof, does not check out — the structural signal of tampering, where no anchor change has reached the proof (Invariant 3.1).

Kind: Member Member of: the Failed Verification reason Role: Outcome Projection: proof-invalid

Record Set Mismatch

The Failed Verification reason returned when the presented Original Record Set does not refer to the record set the Evidence was made over — a caller error, structurally distinct from Proof Invalid (tampering) and from Not Known (lookup miss).

Kind: Member Member of: the Failed Verification reason Role: Outcome Projection: record-set-mismatch

Mechanism Verification Unavailable

The Failed Verification reason returned when the mechanism’s verification function requires an external service (for example, an RFC 3161 TSA’s published certificate chain) that is unavailable at verify time — a transient, retryable condition, distinct from Proof Invalid and Record Set Mismatch.

Kind: Member Member of: the Failed Verification reason Role: Outcome Projection: mechanism-verification-unavailable

Invalid Request

The refusal Seal returns when Record Set Reference is blank, Mechanism Credential is blank for a keyed mechanism, or a string input exceeds the string cap (Execution Contract Input 2). A guard rejection that fails before any database write; no Evidence is recorded.

Kind: Member Member of: the Seal rejection Role: Outcome Projection: invalid-request

Mechanism Failure

The refusal Seal returns when the deployment’s mechanism cannot compute a Proof against the record set at the seam, carrying the reason the mechanism gives — the underlying records are unreadable, the keying material fails the mechanism’s preconditions, or a required synchronous anchor service is unreachable. No Evidence is recorded.

Kind: Member Member of: the Seal rejection Role: Outcome Projection: mechanism-failure

Storage Failure

The refusal Seal returns when the database write fails after the Proof is computed. The computed Proof is discarded — the caller must treat it as definitive.

Kind: Member Member of: the Seal rejection Role: Outcome Projection: storage-failure

Standards references

Tamper Evidence is a foundational compliance primitive with deep cryptographic and regulatory anchoring:

ISO/IEC 27001 clause A.12.4 (Logging and Monitoring) — the International Organization for Standardization / International Electrotechnical Commission information-security baseline for log integrity. The atom’s no-silent-rewrite guarantee is the structural form.
FIPS 180-4 (Secure Hash Standard) — a Federal Information Processing Standard (mandatory US government computing standard); the cryptographic foundation for hash-chain and Merkle-tree mechanisms. The atom is hash-function-neutral; FIPS 180-4 is the canonical family anchor.
RFC 3161 (Time-Stamp Protocol) — the IETF (Internet Engineering Task Force) standard for trusted timestamping. Qualified RFC 3161 timestamps are the canonical external-anchoring mechanism for time-of-seal verifiability under eIDAS and elsewhere.
NIST (National Institute of Standards and Technology — US federal standards body) SP 800-92 (Guide to Computer Security Log Management) — names log-integrity protection as a baseline requirement; tamper-evidence is the structural mechanism.
21 CFR Part 11 — FDA (US Food and Drug Administration) electronic records and electronic signatures — requires electronic records to be protected against unauthorized modification and to bear evidence of any change. Composes with Actor Identity for the attribution of any modification (which Part 11 also requires).
DoD (US Department of Defense) 5015.02-STD — Design criteria for electronic records management software — requires records-management systems to protect against unauthorized alteration of records and audit data.
GDPR (EU General Data Protection Regulation) Article 32 (Security of Processing) — names integrity as a property of processing that controllers must ensure with appropriate technical measures.
W3C (World Wide Web Consortium — the web standards body) Verifiable Credentials Data Model — a standards-track format for tamper-evident attestations, with cryptographic proofs that travel with the data.
Certificate Transparency (RFC 9162) — a worked public Merkle-tree append-only (records can be added but never changed or deleted) log; the canonical real-world deployment of public, verifiable, externally-anchored tamper-evidence at internet scale.
Git’s commit DAG — a widely deployed open-source reference for hash-chain tamper-evidence. Every modern source-control system inherits the design.
PCI DSS Requirement 10 (Track and monitor all access to network resources and cardholder data) — including 10.5 (secure audit trails so they cannot be altered). The atom is the structural form.
eIDAS Regulation (EU 910/2014) — qualified electronic timestamps carry presumed evidentiary effect; the atom’s Anchoring Instant carries such a timestamp’s time, and what that time proves is a trusted-timestamping pattern’s (Non-goal 9).

It inherits from:

Daniel Jackson, The Essence of Software — the freestanding-atom posture; the discipline of composing external anchoring, actor attribution, time-anchor, and mechanism-registry concepts as separate atoms.
Eiffel’s design-by-contract — preconditions on seal; named rejection and verification reasons.
Cryptographic hash-function literature (Merkle’s tree commitments, the Merkle-Damgård construction, the SHA family) — the foundational mechanism for tamper-evident commitments.
Tamper-evident logging literature (Schneier and Kelsey, Secure Audit Logs to Support Computer Forensics, 1999) — the formal framing of hash-chain audit logs as forensically-useful primitives.

Status

grounded on Final Critique 17 — 2026-11-06 at 700b167 — see the Ledger.

Ledger

status: grounded on Final Critique 17 — 2026-11-06 at 700b167
formal: not applicable — vote no 2026-06-03
last gate: 2026-11-06 — Final Critique 17, a delta round, frozen at 700b167 — foundational count 0, clean, one sample; 2026-11-05 — Final Critique 16, a full round, frozen at cd7c4bb — foundational count 3, all cured, not clean, no sample; 2026-11-05 — Final Critique 15, a delta round, frozen at b1ae778 — foundational count 1, cured, not clean, no sample; 2026-11-04 — Final Critique 14, a delta round, frozen at 36e6d47 — foundational count 1, cured, not clean, no sample; 2026-11-03 — Final Critique 13, a delta round, frozen at f84da63 — foundational count 1, cured, not clean, no sample; 2026-11-02 — Final Critique 12, a delta round, frozen at dd11876 — foundational count 1, cured, not clean, no sample; 2026-11-02 — Final Critique 11, a delta round, frozen at d28642a — foundational count 3, all cured, not clean, no sample; 2026-10-24 — Final Critique 10 — foundational count 0, clean, one sample

open:
- 2026-11-05-a · refining · Invariant 4.1, 4.3; Operation 15; Term verification set; Term seam · the verification set holds the evidence's own fields, yet [Verify] reads the seal records to find that no evidence exists for an id (Operation 15), and where the seam gets the proof, the record set reference and the record set match is placed nowhere, nor what [Verify] answers when that read fails beyond Execution Contract Read 1; a host-injected value is received, not consulted, and no rule says so → decide what the verification set holds for a lookup miss and for the seam's reads
- 2026-11-05-b · refining · Non-goal 12; Invariant 2.1, 3.1, 3.2; Capability requirement 7, 8; Check 3.1 · *the record set presented at [Seal]* is declared by no Term, since [Seal] takes a reference and no set, and seven rules rest on it; Non-goal 12 obliges the host to present a record set alike at seal time and at verify time under a Non-goal heading → declare the record set the reference names at the call of [Seal], and place the host's obligation as a capability requirement
- 2026-11-05-c · refining · Capability requirement 8, 9; Operation 17, 18 · a mechanism whose verification function fails at the seam where no anchor is consulted has no arm: Capability requirement 8 bars failed over an unchanged record set while no anchor change exists, Capability requirement 9 bars unavailable unless an anchor is consulted, and [Seal]'s mechanism-failure has no verify counterpart → decide the arm, or a reason of the mechanism verification failure
- 2026-11-05-d · refining · Edge cases headings; Seal atomicity, Concurrent seal, Retention coupling labels · the headings *Atomicity of a seal* and *Retention coupling* stand beside spec-format's table rows *Atomic writes* and *Retention asymmetry*, and the tombstoned and live labels follow the headings, each cited by name in other pages → decide whether the table's spellings bind headings and labels, and what renumbering the citations take
- 2026-11-05-e · refining · Examples (false-tamper-claim disproof) · the example names Content Lock and Document Versioning as the composing patterns, with no link and no roadmap row to mark them forthcoming (M-orphan-forthcoming), so a reader cannot tell whether either exists → decide whether the roadmap lists the two patterns, or the example names the home in words
- 2026-10-21-f · refining · Summary; Identity 8; Concurrent seal 1 · seal names both the action [Seal] and the evidence it records → one name each
- 2026-11-02-a · refining · Check 3.1; Operation 19; Invariant 2.1; Invariant 3.1 · Check 3.1 confirms the failure direction alone, over the one differing set of a single-byte change though Invariant 2.1 covers any differing set (Final Critique 17), so a mechanism answering failed on the record set presented at [Seal] meets it, though Operation 19 and Invariant 3.1 oblige verified there; no rule of the corpus says a spec's checks cover each direction of an invariant, and a positive check carries the same conditions Check 3.1 has just been cured to name (record set match, seal check not unavailable, no anchor change) → decide whether the atom's acceptance tests the positive direction, and write the check on the verification's own record set match and seal check
- 2026-10-22-a · refining · Identity 2; Capability requirement · the evidence id's source is named as the host's allocation under Identity and not among the Capability requirements, where spec-format's atom shape lists an id source under Capability requirement; Event Log routed the same form (its 2026-10-22-b), twenty atoms writing the host's allocation under Identity and four having the deployment supply id material under Capability requirement 2 → one form for the corpus, as the seam normalization made one for now

Decisions

Directional changes only — the turns a future reader must know the pattern took, and why. Everything smaller lives in the commit that made it: git log -- atoms/tamper-evidence.md; the rounds and the migration that got it here are in its history.

2026-11-02 — The string cap has a default. Chose: the string cap stated as 4,096 Unicode code points where a deployment declares none, Capability requirement 6 added, citing Execution Contract Input 2. Over: a bound the deployment must supply, or silence. Because: the maintainer ruled on 2026-11-01 that what the host must bound takes one posture, a corpus default a deployment may override; the string inputs are a record set reference and a mechanism credential, which is keying material, and a PEM-encoded 4096-bit RSA private key runs to about 3,200 code points; the credential sets the cap.
2026-10-19 — The store’s guarantees cited, not restated. Chose: the seal store supplied under Execution Contract Store 1, Store 3 and Store 4 (Capability requirement 2), and the four rules that restated them tombstoned to their owner — Invariant 9.3, no partial evidence on a storage-failure, and Seal atomicity 1, a seal atomic, to Store 1; Seal atomicity 2, no evidence left by a crash with a proof the mechanism did not produce, to Store 1 and Store 3; Seal atomicity 3, the deployment owning the seal store’s durability, to Store 3; rules 106 to 103. Over: the atom restating, for its own store, what every deployment’s store guarantees. Because: the maintainer ruled 2026-10-12 that the corpus takes a store’s specification, never the store, and execution-contract.md writes it once as the Store contract. Discarding the proof on a storage-failure stays (Operation 11): it binds the proof outside the store as well. What the atom does for its domain is unchanged.
2026-10-21 — Record set match decides which record set and the seal check its content; the contract covers mechanisms checkable from the verification set; a failed read answers on every action. Chose: record set match answering yes for the named record set whatever its content, the content left to the seal check (Term record set match), so a change is detected where the right records are presented and the check can run (Invariant 2.1), the proof is bound to the record set presented at Seal (Invariant 3.1), two verifications answer alike unless one answers mechanism-verification-unavailable or state-unavailable (Invariant 7.1), and the verification set names the record set match the verdict rules read; verified obliged for the right records under a seal check that holds (Operation 19, Operation 33); the contract held for every sound mechanism whose verification function consults no source outside the verification set, so a chain keyed by a shared secret is outside it and the payments example is a signed hash chain (Invariant 8.1); state-unavailable on all three actions where the read of the seal store fails, the Execution Contract’s Step 1 failure (Operation 31, Term store read), with Seal’s refusals in one stated order, the store read first (Operation 32, Term seal refusal order); the composing patterns and the mechanism read from the deployment’s own declaration (External check 3, External check 4, Capability requirement 3). Over: a match a host could decide by content, which reports tampering as a caller error; detectability and binding rules that the page’s own wrong-record and altered-record examples break; no answer obliged for a proof that holds; a neutrality claim taking in mechanisms no auditor can check from the records; a read forbidden to refuse a store it cannot read; conformance checks reading what the records do not carry. Because: Final Critique 5 found each a divergence between conforming builds or a rule no conforming build could keep, and the page already held the line: its Summary rests the guarantee on what is detectable from the records alone, and its Intent names only mechanisms a verifier checks without a secret; Actor Identity’s fifth round cured a failed store read, a one-way verified rule and a declaration-reading check the same way. Compositions affected: Audit Trail, which presents its seals to this atom, routes state-unavailable from Verify and Read when its round reads them.
2026-10-21 — A failed read answers as the Execution Contract says. Chose: the failed read cited from the Execution Contract (Capability requirement 2, Execution Contract Read 1 through 3) and the two rules that restated it deleted to it: the atom-wide state-unavailable (Operation 31) to Read 1, and Read’s state-unavailable on a failed read alone (Operation 30) to Read 2 beside Operation 27; the read’s condition off the rules it held to an answered read (Operation 14, Operation 15, Operation 27), the failed read off the verifications Invariant 7.1 compares, which Read 2 holds to verifications whose reads answered, the read off the seal refusal order, Term database read deleted, state-unavailable off every signature and off the answers Check 4.1 tells apart; rules 106 to 104. Over: the page stating for itself what every action answers when the seal records cannot be read. Because: the maintainer ruled on 2026-10-21 that the Execution Contract states the failed read once; this page’s fifth Final Critique had made one of the cures the contract’s Read family is written from. A mechanism that cannot verify keeps its own answer, mechanism-verification-unavailable: the mechanism is no read of the database. What each action answers on an answered read is unchanged.
2026-10-21 — Which refusal answers is the Execution Contract’s. Chose: Seal’s refuses line kept as the page wrote it, already in the order the seal refusal order gave — invalid-request, mechanism-failure, then storage-failure, which answers only at the write — and the order cited from the Execution Contract (Capability requirement 2, Execution Contract Refusal 1); Operation 32, which evaluated the seal refusal order, deleted to Refusal 1, and Term seal refusal order deleted with it; rules 104 to 103. Over: the page stating for itself which of Seal’s refusals answers when both apply. Because: the maintainer ruled on 2026-10-21 that the Execution Contract states once that the refusal listed first on an action’s refuses line answers; this page’s fifth Final Critique had made the cure one specification at a time. What each action answers on every call is unchanged.
2026-10-22 — The wiring is read outside the records, as the Execution Contract says. Chose: External check 3, the auditor reading which composing patterns a deployment wired in from the deployment’s own declaration, deleted to Execution Contract Conformance 9, with Check 6.1’s tombstone, which named it, now naming the contract, the wiring off the NOTE listing what the seal records do not carry, and the label cited on Capability requirement 2; rules 103 to 102. Over: the page stating for itself that the wiring is an external check. Because: the maintainer ruled on 2026-10-22 that five repeated cures are each stated once, the wiring declaration among them; this page’s fifth Final Critique had made the cure one specification at a time. What each action does and answers is unchanged.
2026-10-22 — The external anchor’s answer can change, and the invariants that read the seal check say so. Chose: a change in what the mechanism’s own external anchor answers its verification function for an evidence’s proof, such as a revocation or a withdrawal of trust the anchoring authority records, named once (Term anchor change); two verifications of one evidence against one record set held to one answer only where no anchor change falls between them (Invariant 7.1), a recorded proof held to verifying against the record set presented at Seal only where no anchor change has reached it (Invariant 3.1), and no cached result carried across an anchor change (Verification caching 3). Over: a consistency invariant and a binding invariant that a lawful revocation at the anchoring authority breaks on a mechanism the contract covers, with a cache free to answer verified across the change where a fresh verification answers proof-invalid. Because: Final Critique 6 found the two answers parting, and the verification set already takes in the mechanism’s own external anchor, whose records the atom does not own (External check 2); a mechanism judging expiry against the verify-time clock stays outside the contract, since the verification set does not take in now (Invariant 4.3, Invariant 8.1). Actor Identity’s sixth round held its consistency invariant to one registry view and its binding invariants to the material in force at attestation instant, the same shape. The round also moved the cryptographic material and record set match into the Capability requirements the deployment supplies (Capability requirement 4, Capability requirement 5; Operation 22 and Operation 22a tombstoned to them), as the seam normalization moved now. Compositions affected: Audit Trail, which rests on Invariant 3 and Invariant 7, reads them under an unchanged anchor when its round reads them.
2026-10-22 — A detected tampering is bounded below by each seal it fails. Chose: the anchored bound an auditor draws for a detected tampering stated as the one the records always give: the anchoring instant of every evidence over the record set whose verification answers proof-invalid bounds the tampering below (Check 5.1, now citing Invariant 2.1 and Operation 4), since such an evidence sealed the records as they stood before the alteration; the Breach forensics scenario closing the window at the next evidence that verifies the altered records, where one exists, and the Rejection paths’ journal, which one seal covers, leaving it open. Over: a check obliging a bound between two adjacent anchoring instants, which a record set sealed once cannot give and a tampering made after the last seal over a record set never has, and a scenario reading the window from a verifying seal to the failing seal after it, a pair that brackets when the altered records were written rather than when they were altered. Because: Final Critique 7 found a conforming deployment failing the page’s own check: nothing obliges a second seal over a record set (Term cadences, Non-goal 14), and the Financial and Payments examples seal each day’s records once. The round also deleted Invariant 4.2, Verify MUST NOT consult the host’s state, to Invariant 4.3, as Actor Identity’s seventh round deleted its twin: on every reading of Term verification set the rule either forbade the host-injected record set match Invariant 4.1 has Verify consult or restated Invariant 4.3. Compositions affected: none; Audit Trail rests on Invariant 4 as a family, which keeps Invariant 4.1 and Invariant 4.3.
2026-10-23 — A detected tampering is bounded below only by the seals the altered records fail, and a seal over purged records is no proof of their content. Chose: Check 5.1 bounding a detected tampering below by the anchoring instant of every evidence over the record set whose verification over the altered record set answers proof-invalid, where no anchor change exists for the evidence’s proof, now citing Invariant 3.1; the Breach forensics scenario running each seal over the suspect records as they now stand, and the Proof Invalid entry naming the anchor change; Retention coupling 1, A purged record set MUST leave Verify unable to hold, deleted to Retention coupling 3; Operation 12, which restated Invariant 1.1 for Seal alone, deleted to it; the Generation acceptance introduction naming the deployment’s declared mechanism among what the conformance checks read; rules 102 to 100. Over: a check that took any verification answering proof-invalid as a seal made before the alteration, so a backup presented to a seal made after the alteration, as the Rejection paths present one, or a seal whose anchor was later revoked, put the bound above the alteration, the previous round’s own cure failing two histories the page permits (Identity 8, Non-goal 13, Term anchor change); and a rule no party the page names could keep: Verify may not read a purge (Invariant 4.3), and a host answering record set match for a copy of a purged record set as it answers for the Rejection paths’ backup answers yes, so the copy verifies. Because: Final Critique 8 found both, and Retention coupling 3 already says what stays true after a purge: no seal over destroyed records is proof of their content. The anchor condition is the watched shape the external answer that moves, flagged after the checks. Compositions affected: none; Audit Trail cites Invariant 1, 3, 4 and 8, all unchanged.
2026-10-23 — The atom answers only whether a record set changed since its seal; when it changed belongs to the composing patterns. Chose: the atom bounding no time of change (Non-goal 15), a deployment needing one composing a forensic-attribution pattern (Non-goal 16); Check 5.1, the anchored lower bound on a detected tampering, deleted to a trusted-timestamping pattern (Non-goal 9), and Check 5.2, the bound between two seals, to a forensic-attribution pattern; Verification caching 3, no cached result across an anchor change, deleted to an external-anchoring pattern (Non-goal 2), whose question is what a seal answers once its anchor changes; Retention coupling 3, no seal over destroyed records read as proof of their content, deleted to the composing pattern that owns the purge (Retention coupling 2), and Retention coupling 1’s tombstone re-pointed there; the Breach forensics scenario answering, for each seal, whether the suspect records changed since it, with the window and the attribution left to Forensic Attribution; the Rejection paths, the Regulator integrity audit, the Financial and Healthcare examples, the Evidence and Verified entries and the eIDAS reference no longer placing a change in time; the Summary and the Intent saying the same; rules 100 to 98. The anchor change stays on Invariant 3.1 and Invariant 7.1 and in the Proof Invalid entry: it keeps the binding and consistency claims Verify makes against one seal true for a mechanism whose anchor can change, and says nothing of what such a seal then means. The anchoring instant stays a field the evidence carries (State 4, Operation 4); a bound drawn from it is the trusted-timestamping pattern’s. Over: the atom keeping a forensic bound on when records changed, which three rounds cured and the next found broken on histories the page permits (Final Critique 6 through 8). Because: the maintainer ruled on 2026-10-23, direction (b) of the 02:44Z escalation, that the atom answers only has this record set changed since this seal, and that when it changed leaves the atom for Trusted Timestamping, External Anchoring and Forensic Attribution, all forthcoming. Compositions affected: none; Audit Trail’s own forensic window (its Check 4.1, seal cadence 1 and 2, seal mechanism 2) rests on Verify’s answers and the seal stamps, which stand, and on none of the deleted rules.

NOTE: End of Tamper Evidence.