01
A seal is a hash over canonical JSON, checkable offline
You should be able to: Explain what makes a sealed introduction/1 record verifiable without asking the server that issued it.
introduction/1 hashes over canonical JSON using a portable sha256 — pinned by a test against node:crypto, and deliberately kept portable because Magician's own browser demo seals records identically. The same bytes, canonicalised the same way, produce the same hash whether the code runs in a server process or a person's browser tab.
That portability is what makes the seal checkable rather than merely presented. A hash a stranger can only verify by asking the original server is not really a proof — it is a claim with the same server as its only witness. A hash anyone can recompute from the record itself is a proof, because agreement does not depend on trusting the issuer.
Canonical JSON is doing real work here too: two logically-identical records with keys in a different order, or different whitespace, must hash to the SAME value, or the seal would be an accident of formatting rather than a property of the content. Canonicalisation is what makes 'the same record' and 'the same bytes' the same question.
Source: @magician-network/core — introduction/1
02
The log is append-only, and a replayed digest is refused
You should be able to: State what happens when someone tries to write the same sealed digest twice, and why that refusal matters.
Every transition in introduction/1 returns a NEW fragment and re-validates the whole thing — a rule broken anywhere throws with every problem listed, not just the first one it finds. That matters for debugging a broken integration, but the structural guarantee underneath it is what this lesson is about: the log itself is append-only, and a replayed digest is refused outright.
A store whose log fails re-verification refuses to load at all, rather than loading with a warning and letting a caller decide whether to trust a broken chain. That is a strict choice — a softer implementation might load the good entries and flag the bad one — and it is strict on purpose: a partially-trusted log is a log where a caller has to make the same judgement call the loader just refused to make for them.
The practical shape: once an outcome is sealed, it is sealed. There is no edit path, no delete path, and no way to resubmit the same digest as if it were new. A correction, if one is ever needed, is a new entry that supersedes the old one — never a rewrite of history the log already committed to.
03
The notary leaf proves an outcome happened without saying who it was between
You should be able to: Explain what a magician.network notary leaf reveals, and what it is built to never reveal.
Magician serves one content-free introduction/1 leaf per SEALED outcome at `/.well-known/notary.fragment.json` — its contribution to the estate's transparency log. The leaf's hash is taken over a deliberately NON-identifying projection: the record's own opaque digest, the outcome's kind, and when it sealed. Never the record's seal digest itself, which is taken over identifying content.
That distinction is the whole design. A reader of the notary log learns only that AN introduction of a kind was sealed at a time — never who requested it, who the hops were, or what was actually introduced. The mapping from a real record to its notary projection lives once, in the package's own notary module, and a test pins it so the projection cannot quietly widen to reveal more than it was built to.
The surface is honestly empty today, and says so rather than pretending otherwise: local-first means the server holds no introductions of its own to seal a leaf for yet. It fills as real, consent-gated publishing comes online — never from the demo, which is fictional by construction and never a source for anything the notary log treats as real.
Source: Magician — the verification/1 notary source
