EMS Seal — Ledger and Authority Surface

Seal is the permanent record of the EMS Federation. It is the append‑only ledger where law, evaluation, lineage, and correction become durable. Micro executes; Seal remembers. Nothing in the federation is considered real, admissible, or historically anchored until it is written to Seal.

PURPOSE

Seal provides the canonical audit surface for the entire system. It stores RuleSets, receipts, rejections, lineage pointers, and operator corrections. Seal does not evaluate or execute. It records. Its authority comes from immutability, content‑addressing, and the fact that Micro is the only writer.

SCOPE

Seal holds four classes of information:

1. RuleSets: the signed, hashed documents that define constitutional law.

2. Receipts: the evaluation proofs issued by Micro during admit().

3. Reject Reports: the HARD‑failure outcomes that cannot exist under the RuleSet.

4. Lineage Records: the structural pointers that bind artifacts to their origin and history.

RULESETS

A RuleSet is stored in Seal as a content‑addressed object. Its identity is its hash. Seal does not interpret RuleSets; it preserves them. Each RuleSet entry includes its ruleset_id, version, rs_hash, and predicate metadata. Seal guarantees that law is immutable once published.

RECEIPTS

Receipts are the cryptographic evidence that an artifact was evaluated under a specific RuleSet at a specific moment. Seal stores every receipt issued by Micro, including ADMISSIBLE and BASECELL outcomes. A receipt binds the artifact to the RuleSet hash, evaluator ID, evaluation status, checked predicates, reasons, and timestamp. Seal makes receipts durable and discoverable.

REJECT REPORTS

When Micro issues a REJECT, Seal records the rejection as a permanent fact. A reject report includes the artifact identifier, the RuleSet hash, the failing HARD predicate, and the reason. Rejects are not reversible. They are part of the constitutional history of the system.

LINEAGE

Seal stores lineage pointers for artifacts. Lineage binds an artifact to its parents, its merkle root, and its historical chain. Seal does not validate lineage; it preserves it. Lineage is the structural memory of the federation and the basis for migration, deprecation, and audit.

APPEND‑ONLY MODEL

Seal is strictly append‑only. Nothing is overwritten, deleted, or mutated. New RuleSets are added. New receipts are added. New reject reports are added. Lineage grows. Corrections and migrations appear as new entries, not edits. Seal is the historical truth of the system.

RELATIONSHIP TO MICRO

Micro evaluates. Seal records. Micro writes to Seal; Seal never writes to Micro. Micro cannot execute without Seal, because receipts and RuleSets must be retrieved from it. Seal cannot evaluate without Micro, because only Micro issues receipts. Together they form the execution‑audit pair.

RELATIONSHIP TO BASECELL

BASECELL is reversible; Seal is permanent. BASECELL holds contested artifacts; Seal holds the record of why they were contested. When an artifact is re‑hammered or corrected, the event is written to Seal as a new lineage entry. BASECELL is the workshop; Seal is the archive.

INVARIANT

Seal is the permanent ledger of the federation. Nothing is real until it is written to Seal.

--