Recent entries

What the evidence audit establishes

Authenticated feasibility queries return the governing rule, corpus digest and consulted events, plus all evaluated absences and contradictions. A supported result means the structural checks held; factual verification remains unassessed. The official verdict uses the first failing factor, so later contrary evidence remains visible in the audit.

Offline checks report integrity separately from quality and usefulness. Those evaluations need external labels and matched observations. Corpus contributions require reviewed model terms permitting downstream training; code changes do not create historical records.

Bitcoin confirmation was still pending when checked on September 7, 2026. A timestamp commitment establishes neither historical truth nor independent corroboration.

Developer access and service health

Checking a card

Each card carries the hash that was signed, the signature, and the public key that made it. Those three are enough to check the signature yourself, with any Ed25519 library:

const msg = hexToBytes(Event id from the card);
const sig = hexToBytes(Signature from the card);
const key = await crypto.subtle.importKey(
  'raw', hexToBytes(Author key), 'Ed25519', true, ['verify']);

await crypto.subtle.verify('Ed25519', key, sig, msg);   // true

The signed message is the event id, as 32 raw bytes — hex-decode it. No prefix, no context string, no second hash at the signing step.

What that proves: whoever holds that key signed that exact event id.

What it does not prove: that the fields above are the content behind that id — that requires recomputing SHA-256(canon_event(content)), which needs the canon, not a browser. The format is published.

The node verifies with verify_strict, which rejects non-canonical signatures. A stock library accepts a superset, so it returns true for every legitimate card here. The difference matters to someone constructing a variant, not to someone checking one.