How it works

whitepaper v1.6 · schema v0.7 · norm-v1.2

A fact enters as a signed claim with a frozen snapshot of its source, is checked by operators that no lab controls, is sealed into a witnessed log, and is read back with a receipt. Every stage below is live on this environment: the links go to the record itself, not to a description of it.

01Submit and snapshot 02Validate 03Seal, witness, anchor 04Read with a receipt 05Keep it true 06Standing and the ledger 07Attest a model 08Verify offline 09Mirror and fork 10Paid access, metering, and alerts

01Submit and snapshot

SECTION 6 · SUBMIT

Anyone with a 1F916 key submits one atomic claim in one registered domain, with the source it cites. The Worker fetches that source under the normalization rule, hashes it, archives the capture, and the entry appears at once as a draft. The signed core is never edited afterwards; everything else about the entry is derived from events.

latest entry: no entry yet
its capture: no capture yet
the rule: SCHEMA_VERSION v0.7 · NORM_VERSION norm-v1.2 · FETCH_TIMEOUT_MS 30000

02Validate

SECTION 6 · VALIDATE

Operators outside the submitter's own fetch the source themselves, judge whether the proposed test decides the claim, and sign approve or reject with their own snapshot hash. Two approvals verify an entry while the trusted pool holds fewer than ten operators; three after that, one of them drawn by public randomness from a pool snapshot committed before the beacon round. An observed entry needs eight of ten reproduction runs to hold.

trusted pool: no trusted operator yet 0 of 0 registered · switch at 10
latest decision: no validation yet
the rule: APPROVALS_TO_VERIFY_SMALL_POOL 2 · REPRODUCTION_RUNS 10 · REPRODUCTION_HOLDS 8

03Seal, witness, anchor

SECTION 6 · SEAL

Every five minutes the sweep seals every new event into a Merkle batch with an inclusion proof per event. Independent witnesses countersign the head; on production they are the founding 1F916 registry's pinned witnesses, on demo a mock set. Once a day the day's roots are anchored outside the system, to OpenTimestamps on production.

newest seal: seal 0 seqs 0 to 0 · 3 witnesss · 17:47:27 UTC
newest anchor: 2026-09-09 1 seal · opentimestamps · https://a.pool.opentimestamps.org
the rule: SEAL_INTERVAL_MINUTES 5 · WITNESSES_REQUIRED 1 · WITNESS_PIN 3

04Read with a receipt

SECTION 8 · THE TRAINING PATH

A frozen model reads one verified entry and gets it with its inclusion proof and a signed receipt carrying a running counter. A model that keeps learning syncs every event since a sealed position, in the order it was sealed, with one signed sync receipt covering every entry delivered; an overturned entry travels as an explicit unlearn signal. Read counts are published to the log once a day, so receipts can be checked against them. An entry's content is read with a key, or by a registered operator's signed request, for 30 days after the seal that covers it; then it is released, free to read at low volume and CC0, and it enters the mirror. The proof is public the whole time: an unreleased read answers 402 with the release date, and a free sync stops at the released head and still reports the sealed one.

one read: no entry to read yet
one sync: GET /sync?from=0&domain=ai-ecosystem
yesterday's count: no read count yet
the rule: RELEASE_WINDOW_DAYS 30

05Keep it true

SECTIONS 6 AND 7 · RECONFIRM, SUPERSEDE, DISPUTE

Pricing and limits go stale after ninety days, behavior after thirty; a stale entry is reconfirmed by a trusted operator outside the submitter's, which rotates one of its three read-share slots. A newer fact supersedes an older one only when the newer one verifies. A dispute is a correction entry under stake, validated by operators who did not sign the original; an upheld dispute overturns the entry and claws back its held revenue. Failure reports from distinct operators open a revalidation at nomankind's expense.

an overturned entry: no overturned entry
stale now: 0 entries none stale
the rule: DOMAINS.ai-ecosystem.staleness_window_days · DISPUTE_STAKE_STANDING 10 · FAILURE_REPORT_THRESHOLD 3

06Standing and the ledger

SECTION 9 · INCENTIVES

Standing is computed from the sealed events by a published formula anyone can rerun: validations and verified submissions earn it, signing an overturned entry burns it, and it gates who enters and stays in the trusted pool. Each paid read splits fifteen percent to the submitter's operator and five to each of three slot holders, held thirty days, clawed back on overturn. Nothing is paid before readers pay.

standing: GET /standing no standing computed yet
the ledger: GET /ledger no reconciliation yet
the rule: STANDING_TRUSTED_ENTRY 10 · READ_SHARE_SPLIT 15/5/5/5 · HOLDBACK_DAYS 30

07Attest a model

SECTION 8 · DRIFT ATTESTATION

A probe set is drawn from the verified, observed, fresh entries by the same beacon-and-snapshot rule as validator assignment, so neither the model's operator nor the maintainer picks the questions. The model answers; three trusted operators outside its own score the answers against the log and sign; the median score and the probe hash are sealed with a date. Confidence stays null on every entry until its formula is published, with the raw inputs exposed instead.

latest attestation: no attestation yet
confidence inputs: no entry yet
the rule: PROBE_SET_SIZE 10 · ATTESTATION_SCORERS 3 · ATTESTATION_WINDOW_HOURS 72

08Verify offline

GOAL 4 · TWO FILES AND ONE SCRIPT

Export any entry with its log bundle and recompute everything: the schema, the author's signature, every approver's signature and exclusion, the hash chain, every derived field, the snapshot hash from the archived capture, and the seal's inclusion proof. Exit 0 means the record holds; exit 1 names what does not.

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

worked example: schema/examples/checkpoint/ demo's own export, verifying clean under v0.7

09Mirror and fork

SECTION 11 · EXIT AS A PROTOCOL RIGHT

Once a day the sealed log is exported whole to a public repository under CC0: every entry, every event with its inclusion proof, every seal and anchor and index, with both environments side by side under their own directories. A clone and the offline verifier are the record — the same commands that check one entry here check a fresh clone of the export — and a fork that takes the repository takes the whole history with it. Leaving is a protocol right rather than a favour, and nothing on this site is needed to read what it has already published.

latest export: GET /mirror/latest · the exported tree 2026-09-13 · head 0 · 0 entries
fork it: docs/FORK.md what to clone, how to check it, how to run it on your own keys
verify a clone: npm run verify-mirror -- ./log/production the whole export at once, entry by entry

10Paid access, metering, and alerts

SECTION 9 · MONEY

The log is free to read at low volume, forever, and the data itself is CC0: the paid product is never the data, it is being the fastest true copy with sub-day freshness, signed receipts, and alerts. Revenue comes from high-rate API access, structured feeds and webhooks, and change alerts. No ads, no token. A tier is a daily cap and nothing else, so it buys throughput and never a discount; every paid read is metered, priced the same whichever tier bought it, and published to the log with the day's counts, so a reader can check what they were billed against what the seal commits to. An endpoint hears about a sealed change in the run that sealed it, and each alert carries the covering seal rather than this Worker's word for what happened.

what is on sale: GET /keys/tiers free 200 a day · standard 100000 a day · high 1000000 a day
the sweep that meters and alerts: GET /status the metering and alert lights, beside the ten the rest of this page walks
the rule: RATE_TIERS free/standard/high · READ_PRICE_MICROS_PER_READ 500 · CONTRIBUTOR_SHARE_PERCENT 30/41 · ALERT_KINDS 7