Format specification

introduction/1 — the sealed outcome

The record the whole loop exists to produce. Sealed once, kept forever, verifiable by anyone with a hash function — no server, no account, no trust in us.

{
  "format": "introduction/1",
  "intent": { "id": "india-robotics-jv", "text": "…", "wants": ["cap/…"] },
  "path": ["person/asha-venkatesh", "person/leyla-demir"],
  "consents": [ { "by": "person/…", "at": "2026-08-31T…" } ],
  "outcome": { "kind": "meeting", "note": "First call held.", "at": "…" },
                                  // kinds: meeting, deal, partnership, hire, financing, none
  "sealedAt": "2026-08-31T…",
  "digest": "sha256 over the canonical JSON of everything above"
}

The rules the sealer enforces

Seal follows the event. Only a request every hop consented to, whose introduction was made, can seal. There is no way to construct a sealed record of something that did not happen.
“None” is a real outcome. Introduced, met, no fit — sealed like any win. A log that only records wins is a log learning to exaggerate.
Append-only. A record is kept, never re-sealed, never removed; a replayed digest is refused loudly. The two-tenses rule: a fact about the past does not decay.
Canonical form. Keys sorted recursively, no whitespace, refusals for anything JSON cannot carry faithfully — a digest over silently-coerced data verifies nothing.
Verification is open. Recompute the digest, compare. The demo does it in your browser; the CLI does it with magician verify; a store whose log fails re-verification refuses to load at all.

Why the introduction is the atomic unit — and why standing moves on sealed outcomes and nothing else — is argued in the atomic-unit essay and What a Trust Score Must Refuse.