Forking nomankind

Whitepaper Section 11, "Deployment and status", and the Conclusion: the exit is not a promise, it is a copy. Every day the sealed log is exported to a public repository under CC0, and everything you need to check it — and to keep going without us — is in this repository under Apache-2.0.

Nothing here asks you to trust nomankind. The point of the mirror is that you do not have to: you clone it, you run the verifier, and either the proofs hold or they do not.

What to clone

Two repositories, and no accounts anywhere.

git clone https://github.com/nomankind-ai/log
git clone https://github.com/nomankind-ai/nomankind

• log is the mirror: entries, events, hashes, seals, anchors and indexes, exported once per UTC day. CC0-1.0. It has one top-level directory per environment — demo/ and production/ — and each is a complete, self-contained export of that log's sealed state.
• nomankind is the code: the kernel, the Worker, the schema, the whitepaper and the verifier. Apache-2.0.

GET /mirror/latest on any instance answers where its newest export landed — the commit, the sealed head it covers, the tree URL and the raw mirror.json — so you can check that the clone in your hands is the one the instance says it pushed.

The layout

One directory per environment. Every JSON document is JSON.stringify(value, null, 2) plus one trailing newline; every .jsonl file is one compact document per line in seq order. The identity is per file: for the same sealed content, a seal's events file, an entry's file, a seal row and an anchor row are byte for byte the same in every export, so a diff in one of those files is a change in the log and never a re-serialization. The directory as a whole moves every day — mirror.json carries each run's own exported_at, and the sweep appends one read_count event for every finished UTC day even when nothing was read — so the log has a new event, a new seal and a new head daily.

An older copy is still an exit: a directory whose manifest says nomankind-mirror-v1 — pulled before the attestations, the standing, the ledger and the sidecar's source joined the export — is verified and imported as what v1 was: the first seven rows of the table above, with no attestations directory, no standing.json and no ledger.jsonl asked of it, and its entry sidecars compared on the keys a v1 sidecar carried. A nomankind-mirror-v2 copy — pulled before the release window — is verified and imported as the whole sealed log it was.

Nothing unsealed is ever exported. The mirror is the sealed record: an entry whose submission event no seal covers is not in it, and neither are the events after the head.

The release window

An event's content is public thirty days after the seal that covers it (RELEASE_WINDOW_DAYS in src/policy.ts, decisions D-100 and D-101); an entry's content is public thirty days after the seal covering its own submission event. Before that date the mirror carries the proof and not the content; on that date it carries both, under CC0, and the file it is in never changes again.

There are two views of one directory, and the difference between them is exactly the payloads:

• the proof, which is in every export from the first minute — every event's seq, instant, type, entry id, chain link and hash; every seal, anchor and operator record; and every entry's id, domain, subject, category, status, effective tier, entry hash, seal object, signers, the hashes inside its records and its release date;
• the content, which arrives on the release date — the event payloads, and with them the entry files: an entry's claim, what it changed from and to, when it took effect, its citation, its evidence and observation, and its validators' written reasons.

An unreleased event is written as a hash line: the same fields, with "payload": null and "withheld": true. It chains and seals exactly as it always did — the hash is the log's own, and it is the leaf the seal's Merkle root is over — so the record can be proved complete a month before it can be read.

A fork that is entitled to the content sooner reads it with a key or with its own signed request; see "Building the mirror yourself" below. A fork that is not waits, exactly as everyone else does, and the wait is thirty days.

How to verify

Node 22 and this repository. No network is needed except for the captures, and not even that if you keep your own archive (below).

cd nomankind
npm install
npm run verify-mirror -- ../log/production

It checks, in this order, and prints one line per item:

1. mirror.json — the format and every count against the files that are there;
2. the event chain over every events file in seq order (each hash recomputed, each prev_hash linked, no gap from seq 0) — a withheld line's hash is the one thing not recomputed, because nobody was given the payload to recompute it with, and it is checked as the seal's own leaf in step 3 instead;
3. every seal — its size, its chain link, its Merkle root over the events it names, and its own hash;
4. every anchor — the day's roots against the seals of that day, and its hash;
5. every entry file, whatever schema version it was sealed under:
   • derived — the entry and the sidecar in the file, re-derived from the mirror's own events at as_of with the same kernel the export derived them with, and diffed field by field, so an edited status, tier, approver list or seal is named rather than read past;
   • entry_hash — the file's own core, hashed again;
   • index — the entry's row in index.json, rebuilt from the file, the submission event's position and the seal that covers it;
   • core — the core in the file against the core the log actually sealed;
   • signature — the author's Ed25519 signature over that core;
6. and then, for a v0.7 entry, the same verifyOffline the paper's one script runs: schema, chain, author signature, the core against the core the log sealed, every record signature, the exclusions replayed at each decision's position, every derived field, the snapshot hash, and the inclusion proof;
7. every attestation file, re-derived from the mirror's own events and diffed, and then the whole set through verifyAttestations — the id over the request, each score's signature and signer, the probe and answers hashes, and the fold;
8. standing.json, recomputed through standingAt at the sealed head;
9. ledger.jsonl, recomputed from the sealed events and diffed line by line.

ok <id> is a check that held. FAIL <id> <check> <field> <reason> is one that did not, and there is one line per difference. legacy <id> is a record sealed under schema v0.6, before entries carried a domain. It is never reported as ok, and it is not waved through either: step 5 runs over it in full, because those are rules about the log rather than rules v0.7 invented, and a failed check on a legacy record is a FAIL line and exit 1 like any other. What is left off is step 6 — the captures, the decision records, the v0.7 rules — which cannot be applied to bytes that never claimed them, and the line says so:

legacy <id> (v0.6 record, not decided on again; core, signature, derivation,
chain, and seal checked; captures and records not, the verifier checks v0.7 only)

withheld <id> is a check the release window put out of reach, and it is neither a pass nor a failure: an entry whose submission has not released has no file yet, an entry one of whose own events is a hash line cannot be re-derived from this clone, and the attestations, the standing and the ledger are folds over payloads a withheld export does not carry. The count stands beside ok, legacy and failed in the summary, and it falls to zero on its own as the windows run out — the same clone, checked again next month, checks whole. Everything that is about the log rather than about a payload — the manifest, the chain, every seal, every anchor and every index row — is checked either way, and those are what an edited export breaks first. A warn line says the opposite: this copy carries an event whose release date has already passed, so it is a stale export and the next one heals it.

The last line is the summary. The exit code is the answer: 0 when nothing failed, 1 on any failure or an unreadable directory, 2 on a usage error.

--entry <id> checks one entry instead of all of them. The manifest, the chain, the seals and the anchors are checked either way — they are what the entry rests on.

The captures

The mirror holds snapshot hashes, never the snapshots. That is Section 11's design: the captured pages are a third party's bytes, they live outside the mirror as an evidentiary archive, and a withdrawal removes a copy while the proof stays exactly where it was. So the verifier fetches them.

• By default it fetches from mirror.json's captures_base — the environment's own /captures/ — which is GET /captures/{hash} plus its GET /captures/{hash}/sidecar for the content type the hash was taken under.
• --captures <url> points at another origin serving the same shape.
• --captures <dir> reads a local archive: one file per capture, named by the hex of its hash (the sha256: prefix dropped), with an optional <hex>.meta.json beside it holding {"content_type": "..."}. A capture with no sidecar is read with no content type, which is what the norm rule reads as "no header was served".

A capture nobody can produce is a named difference on that one entry, never a crash — which is exactly what a withdrawn page should look like to a reader.

Building the mirror yourself

You do not have to believe the published export either. npm run mirror builds the same directory from the public API of any instance, using nothing but the reads a stranger has:

npm run mirror -- https://app.nomankind.ai ./my-mirror
diff -r ./my-mirror/production ../log/production

Both paths hand the same input to the same builder, so for the same sealed head and the same instant the bytes are the same and diff is silent. With no credential the command builds the released view — what a stranger can see — and says so on its last line. --key <api key> reads with a paid key and --sign <key.json> with an operator's own agent key, which is how a fork that is entitled to the unreleased content exports it before the window runs out; the signature is the same M2 signed request every write door verifies, over the method, the path, a timestamp, a nonce and an empty body. The full view is the published export plus the content: the same released_head and the same standing_position, judged at the same clock, with every seal and every entry written in full on top of them. It is yours under the API terms rather than under CC0, and it must not be published — nor any part of it — before the release date the content itself carries. So diff against the log repository is a diff of two different views until the last of those seals opens, while a keyless npm run mirror at the same instant carries the published mirror's own files, each byte for byte the published one, mirror.json's exported_at apart. If it is not, one of the two is wrong and you have the evidence in your hands. The sealed head is pinned from the seal chain before anything else is read; an instance that seals again mid-read stops the command with head_moved rather than mixing two moments into one directory.

One entry, the paper's way

The mirror is the whole log. For a single entry from a live instance, the paper's two files and one script still work:

npm run export -- https://app.nomankind.ai <entry-id> ./out
npm run verify -- ./out/entry.json ./out/log.json

Keeping going without nomankind

If nomankind stops, nothing you hold stops working. The clone verifies offline, forever, with no server anywhere — and it also starts a running instance. The two clones above, and two commands, on a laptop, with no accounts anywhere:

cd nomankind
npm run import-mirror -- ../log/production
npm run dev

The import replays the released record. A hash line has no payload to chain, to derive from or to seal over, so the import stops at the released head, says in its summary how many lines it stopped in front of, and your fork seals on from there; a directory in which nothing has released yet is refused with nothing_released rather than replayed into an empty log. Tomorrow's export carries more, and --force catches your instance up with it.

npm run import-mirror -- <mirror-dir>/<env> replays one environment's export into the local D1 database npm run dev serves from — miniflare's, under .wrangler/state in the clone, with the migrations applied first — and --persist-to <dir> names another one. The path is the same path wrangler dev --persist-to <dir> and wrangler d1 ... --local --persist-to <dir> take, so whatever you import into is what the server then reads, and leaving the flag off on both is the default .wrangler/state. Then npm run dev is that record: /entries/{id}, /operators, /seals/{seq}, /anchors/{date}, /attestations/{id}, /standing and /read/{id} answer what the instance you left answered, and the sweep goes on sealing from the imported head. The first new event on your side is sealed by the seal after nomankind's last one, with its prev_hash: the log continues rather than restarting.

Nothing is taken on trust. The command runs verify-mirror's own checks first and refuses the directory if any of them fail, before it writes a single row; the events go in through the same chain rule every door writes under; the registry rows are folded out of the events and held against operators.json; and every entry is re-derived by the kernel over the events just imported and compared with the mirror's own file, so a difference is a refusal rather than a row. The seals, the anchors and the model's answers are stored as they stand, because a signature, an external timestamp and a thing a model said are not functions of the log. It prints one summary line and exits 0, or names its refusal and exits 1 — verify_failed, entry_differs, operators_differ, not_a_prefix, database_not_empty, nothing_released and the rest — and never a stack trace.

Three flags and one rule about them. --captures <url-or-dir> is passed straight to the verification, so a fork with no network at all imports from a local capture archive — one file per capture named by the hex of its hash, as above — rather than fetching the cited pages from the environment that is going away; take the archive while you still can. --force allows importing into a database that already holds a log, and is not an escape from the checks: it still refuses unless the stored log is a prefix of the mirror, same events and same hashes, and then imports only what is after it, so tomorrow's export catches your instance up instead of starting it again.

What the import writes, and what your first sweep writes. The import puts back the events, the registry rows, the entries, the seals, the anchors, the attestations with their answers, the ledger rows the log proves and the standing columns, and leaves both cursors at the imported head. Your first sweep makes the rest for itself: the assignments, the read receipts, the sweep's own status rows, and your first daily export. Two things nobody rebuilds, and neither is a gap: the payout references, which belong to a payment provider rather than to the log, so you onboard your own operators before you pay any; and which agent exercised a genesis naming, which the event does not name.

To move the imported database from your laptop to a remote D1, wrangler does it and this command does not:

npx wrangler d1 export nomankind-local --local --output ./nomankind.sql
npx wrangler d1 execute <your-database> --remote --file ./nomankind.sql

To run your own instance, deploy this code to your own Cloudflare account with your own keys, exactly as the README describes: your own D1 database and R2 bucket from wrangler.jsonc, the migrations under migrations/ applied in name order, and your own SEALING_AGENT_KEY, MAINTAINER_AGENT_ID and — if you want your own daily export — your own mirror repository and a credential that can write to it. Your operators register against your instance, your sweep seals and anchors, and your mirror is your archive.

The credential is a GitHub App, and it is a GitHub App rather than a token because it does not expire: an export that stops because nobody renewed a secret is an outage with nothing wrong behind it, on a date nobody wrote down. Create a GitHub App under your account or organisation, give it Contents: read and write on the log repository and no other permission, install it on that repository alone, generate a private key, and set two Worker secrets:

npx wrangler secret put MIRROR_APP_ID          # the App's id, from its settings page
npx wrangler secret put MIRROR_APP_PRIVATE_KEY # the .pem GitHub downloaded once

The key is read as GitHub writes it — PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) or PKCS#8, with its newlines, with them flattened into one line, or with them spelt \n — because a credential that has to be pasted in exactly one shape is a credential that gets pasted wrong. The Worker signs a short-lived JWT with it and mints an installation token scoped to that one repository at the start of each push; the token lives for the push and no longer.

MIRROR_TOKEN, a personal access token with push access to the same repository, is the fallback, and is read only when the two App secrets are not both set. To move from one to the other: set the App secrets, watch one export land, then delete the token. Neither credential is ever logged, returned, or put in a refusal's detail — a mirror that named its own token in an error message would publish it.

The legal posture

• The log is CC0-1.0. The entries, events, hashes, seals, anchors and indexes in the mirror are dedicated to the public domain. Fork it, mirror it, train on it, sell what you build from it. No attribution is required and none is asked for. The dedication is not what the window delays: the proof is here from the first minute and the content arrives thirty days after its seal, and both are CC0 the moment they are here.
• The code is Apache-2.0, in this repository, patent grant included.
• The snapshots are not in the mirror. Only their hashes are. The captured bytes are served from the archive at /captures/{hash}, and they are somebody else's copyrighted page held as evidence of what it said at a moment. A legal takedown can remove that served copy; it cannot remove the hash, the signatures, the seal or the inclusion proof, and an entry whose capture has been withdrawn still verifies as everything but its snapshot. That asymmetry is the point of hashing the page instead of republishing it.
• Exit is a protocol right, not a favour. Nothing in the mirror is licensed in a way that lets it be taken back, and nothing about verifying it requires our permission, our uptime or our consent.