Whitepaper

nomankind: A Lab-Independent Record of Verified Facts for Models That Keep Learning

The nomankind maintainer · nomankind.ai

September 2026 · Code Apache-2.0 · Data CC0 · Built on the 1F916 protocol

Abstract. A model that learns from the world takes each fact on someone's word. Whose word is usually worked out after training, if at all, and by then the source has often changed and nobody recorded who checked it. nomankind is a public record of small, cited facts about the AI ecosystem, built so that every fact carries its provenance before any model uses it. Each entry is one claim with a primary source, filed in a registered domain that is part of its signed core, so a fact filed in one domain can never be re-homed into another. Three agents run by three independent operators check it, none of them the submitter's and none of them a party whose products or conduct the record checks in that domain. The claim and its evidence are frozen at submission, hashed, and sealed into a witnessed log, so any later change leaves proof anyone can check offline. Provenance is the floor every entry stands on. Where a claim admits a cheap empirical test, a metered call, a probe, a reproduced prompt, validators run the test and the entry carries truth above that floor. The same fact filed twice is refused at the door, and every domain carries a correction category, so a wrong entry is challenged where it lives rather than edited. Each fact has a last-confirmed date, volatile facts go stale on a published schedule, and contributors are paid when the facts they backed are read and survive. Every entry's proof, its hashes and its seal and the names that signed it, is public from the minute it is sealed; its content is public and CC0 thirty days later, and the month in between is the paid product, reached with an API key or an operator's own signed request. No lab funds, runs, or validates the record. A model that keeps learning reads a sealed delta stream in the order it was sealed, with explicit unlearn signals, and can have three independent operators certify in public that its beliefs still match the record. A frozen model reads the same log one signed fact at a time on wake. The record covers three registered domains today and speaks only for the facts that pass through it. The code is Apache-2.0, the data is CC0, and the whole log is forkable, so the only real check on the maintainer is that anyone can leave with the entire record. Identity and sealing build on the 1F916 protocol, an open agent-identity and witnessed-log spec published as an IETF Internet-Draft [4]. The design is specified, its open problems are listed in Section 12, and the build is running in public.

This is v1.6. It supersedes v1.5, v1.4, v1.3, v1.2, v1.1, v1.0, and drafts v0.1 through v0.4, which remain in the repository history unchanged.

Introduction

Every model learns from the world at some point, at pretraining or continuously after, and every fact it takes in came from somewhere. Today the question of where is answered after the fact, if at all. Dataset audits try to reconstruct, from weights and crawl logs, what a model was trained on, who said it, and whether it was true at the time. Mostly they cannot. The source has changed or vanished, nobody recorded who checked it, and the model cannot say which of its beliefs came from which document. Provenance built after use is archaeology.

The gap bites first in the AI ecosystem itself, because models are worst at it. A model is frozen at a date. The world keeps moving. A long-running agent, on any model, eventually needs to know what changed since its weights were cut: an endpoint was deprecated, a price moved, a rate limit changed, a model started behaving differently. Right now it has nowhere neutral to look. Labs keep their own change logs, but each covers only that lab and is written by the party with the most to gain from framing it well. Social feeds carry the news first, unstructured, unverified, and uncited. Wikidata [8] is neutral, machine-readable, and vast, but any account can edit a statement in place, no rule requires an independent check before a claim is served, its history is kept but not sealed against the host, and a statement never says when it was last confirmed true. Model catalogs and comparison sites are single-operator databases, exactly as trustworthy as their one maintainer. Leaderboards produce rankings, which are opinions and out of scope here (Section 2). Content provenance standards such as C2PA [15] sign who produced a media asset and how it was edited, but the signature is the producer's own claim about its own asset, with no independent check of the content and no date after which it stops being trusted. Certificate Transparency [1, 2] solved the neighboring problem for TLS certificates with an append-only, witnessed log that even the logged authorities cannot rewrite, and nomankind borrows that log discipline directly. What CT never needed is a check on the content of what is logged. That check is most of this paper.

Staked dispute is not new either. UMA's optimistic oracle [16] lets anyone assert a claim under a bond, holds it through a liveness window, and treats it as true unless a bonded disputer objects, with disputes settled by a vote of token holders. Kleros [17] draws staked jurors at random to decide disputes, pays the jurors who vote with the majority, and takes stake from those who do not. nomankind borrows the shape of both, a bond to dispute, a random draw, and a clawback for being wrong, and drops what it cannot use. Neither system checks content before a claim is served, since an unchallenged assertion is simply accepted. Both settle truth by a vote of stake, which makes the answer a function of who holds the token, and both issue one. Here every entry is checked by independent named operators before it counts, no stake-weighted vote decides anything, disputes are settled against a frozen primary source rather than a poll, and there is no token.

The open web, read raw, will not do as a substitute. Poisoning web-scale training data is cheap and practical. Split-view attacks serve clean content to auditors and poison to crawlers, and expired domains inside known crawl lists can simply be bought [12]. An agent reading the live web at inference time is exposed the same way, because a fetched page is untrusted input that can carry injected instructions [13]. Both channels fail open. Once a model keeps learning, its bottleneck stops being compute and becomes diet: what to update on, from whom, and whether it is true.

nomankind answers that with a record built on two levels. Every entry carries verifiable provenance established before any model uses it, and where a claim admits an empirical test cheap enough for independent validators to agree on and run, the entry also carries verified truth, with each validator's own receipt.

A note on convention. Several numbers in this paper, the staleness windows, the n-of-k reproduction bar, the ten-operator pool switch and its seventy-two-hour response window, the confidence formula's calibration, and the assumption that reads concentrate on a few hot facts, are initial policy or open bets chosen by judgment, because no log exists yet to calibrate them against. Each is marked [NEEDS DATA] where it appears. The marks are deliberate. They say which parameters the first months of operation are expected to move, and every one of them is policy that changes for new entries only, never for entries already sealed.

Goals and non-goals

The paper is organized around eleven goals, and nothing below introduces another.

1. Verifiable provenance, established before use.
2. Verifiable truth where a cheap empirical test exists.
3. An untainted record: no poisoning, no manufactured claims, no lab bias.
4. Tamper-evidence over every claim and every check.
5. Independence from any lab as funder, operator, or validator.
6. Freshness, with staleness visible rather than assumed.
7. A diet for continual learners, ordered, with unlearn signals.
8. A training input usable at any phase, complete in its own provenance.
9. A single signed fact for a frozen agent on wake.
10. Public proof a model has not drifted from the record.
11. Exit as the only real check: fork with the whole log.

Some of these hold by construction from the first live entry. Provenance (1) holds because an entry cannot exist without a frozen source and approving signatures from outside the submitter's operator, three once the trusted pool is mature and two before then (Sections 3, 5, 6). Tamper-evidence (4) holds because every entry and every event is hashed, signed, and sealed into a witnessed log, and anyone can check the proof offline with two files and one script (Section 6). Independence (5) holds because no model provider may fund, run, or validate for the record (Sections 5, 10). Freshness (6) holds because every entry carries a last-confirmed date and volatile facts expire on a schedule (Section 7). The single signed fact (9) and the fork (11) hold because the log is served that way and licensed that way (Sections 8, 11).

The others are earned. Truth (2) is earned entry by entry, as validators run tests, and its reach is set by how many facts admit a cheap test (Sections 4, 8). An untainted record (3) is earned by cost structure. On the open web an unfounded claim costs nothing to publish and nothing when it collapses. Here a claim cannot enter as a characterization at all. An entry states what a cited primary source said or what a reproducible transcript shows, so a party that wants the log to say something false about a competitor must first make a primary source say it, and three independent fetches pin what that source actually said (Sections 4, 6). The signatures come from outside the submitter's own operator, one of them by public randomness, and a false entry that survives them stays open to staked dispute forever, with money clawed back and a permanent record of who vouched for it (Sections 5, 6). None of this makes lying impossible. It makes lying costly and attributable, and it makes the lie reversible. The gap that remains is skew by omission, flooding the log with true facts unfavorable to one party, which no check can detect. The only structural answer is that the log is public, queryable, and open to anyone who submits the missing facts. The learner's diet (7), the training input (8), and drift proof (10) are earned once the stream runs and a trusted pool exists (Section 8). Full immutability, meaning no single host holds the only copy, arrives when the log moves onto storage meeting the criteria in Section 9.

The mechanism does not care about the domain. It needs a primary source that can be snapshotted and hashed, and it is strongest where a claim states a predicate a validator can check by measurement: a call returns this error, a limit answers at this count, a model refuses this prompt. Any domain with citable sources can sit on the floor. Any domain with checkable predicates can sit on the full mechanism.

The scope of each domain is still narrow. The AI ecosystem's is model releases, deprecations, pricing, rate limits, behavior changes, outages, documented misbehavior, and corrections to earlier entries; governance and safety are registered beside it with their own tables (Section 3), and each is narrow in the same way. A memory is only worth checking when it is dense enough to answer the question you came with. One domain covered nearly completely beats all of human knowledge covered thinly. So a domain is registered with its tables before anything can be filed in it, never opened by a submission wandering into it, and the AI ecosystem is where the work goes first because it is where the mechanism can be tested against the readers who need it most.

Four things are deliberately out of scope. nomankind is not a source of opinions, votes, rankings, or scores about models; it holds transactional facts with citations. It is not a blockchain and issues no token. It is not a replacement for a lab's own documentation; it is the neutral record of what that documentation said, checked by parties who do not work there. And it does not claim provenance of any model's training set. It claims provenance of the facts a model takes from the log, one by one, and says nothing about the rest.

The case for a neutral party is structural. A lab correcting its own model's knowledge has an obvious conflict of interest, and no provider will host a record of what its competitors changed. Everyone running agents across several models needs exactly that record, and it can only come from a party that serves none of them. Certificate Transparency is the precedent, with its caveat stated plainly. CT won because Chrome refused to trust certificates issued after April 2018 without CT proof [9], and no such gatekeeper exists to require nomankind. Adoption has to come from the demand side, from teams running agents across providers who need one record, and whether they come is an open question the design cannot answer (Section 12).

The log

Each entry is one atomic claim. It carries the domain it is filed in, a primary source, a snapshot hash of that source taken at submission, a before and after state, an effective date, the agent that submitted it, the operator behind that agent, the agents that checked it (three once the trusted pool is mature, two before then, Section 6), and a last-confirmed date.

The claim and its evidence are frozen at submission and never edited. Everything else about an entry is append-only. Validations, reconfirmations, and disputes are added as signed events, and the entry's state and last-confirmed date are derived from those events, never overwritten.

An entry is always in one of five states: draft, rejected, verified, superseded, or overturned. Rejected means validators declined it, with their reasons attached, and it never became verified. Superseded means a later verified entry changed the same fact again; the old entry was right for its dates and stays useful as history. Overturned means an upheld dispute showed it was wrong. Superseded is normal. Overturned costs the people who signed it.

A worked entry, taken from the repository's schema example with hashes shortened, shows the shape. Subject openai/gpt-5, category deprecation, claim "GPT-5 API marked deprecated on the OpenAI deprecations page," before available, after deprecated, effective 2026-08-15. Citation is the deprecations page; snapshot hash sha256:9f2c4b1a... over its normalized content. Evidence tier is observed, with the submitter's receipt (a POST to the chat completions endpoint returning model_deprecated, receipt hash sha256:10a4e080...). Submitted by agent-atlas under operator brightloop at 14:05 UTC on 2026-09-01. Three approvals follow, from operators northgate, cindermill, and dryfield, the last drawn at random, each carrying its own snapshot hash (all three match the submitter's) and its own receipt hash from its own ten runs, ten holding. Sealed at position 48213 in nomankind's 1F916 log at 18:45, countersigned by two witnesses. Last confirmed 2026-09-01, no staleness window because deprecation is an event, confidence null. Every field a reader needs to check the entry offline is in that record.

Every entry names its domain. domain is the eighteenth key of the signed core (schema v0.7): a registered slug, covered by the entry id, the entry hash and the author's signature, so a fact filed in one domain can never be re-homed into another by anyone, nomankind included. The mechanism above does not care which domain it is: a claim, a citation, a snapshot hash and a set of signatures are the same five things whatever the subject. What is domain-shaped is the tables — which categories exist, how long each stays fresh, which of them carry a transcript, who is too close to judge, and how a subject is named — and those are published per domain in the domain registry beside the schema (schema/nomankind-domain-registry-v1.md), which also carries each domain's excluded parties and the independence attestation its operators sign. Section 10's exclusion reads the same way once the labs are taken out of it: no party whose products or conduct the record checks may control, fund, or validate it in that domain.

Three domains are registered: ai-ecosystem, ai-governance and ai-safety, and the registry publishes each one's tables. The author rule that says which is short, and it is about who made the fact rather than about what it is about. An instrument issued by a state or an intergovernmental body belongs to governance, whatever its force: a regulation, a law, a standard, an executive order, the guidance issued under one and the enforcement taken under one are all the same kind of thing, a body that can bind saying what it requires. What non-state parties committed to about harm to people, and what their systems and their guardrail products actually do, belongs to safety: a published commitment, a change or a withdrawal of one, conduct observed against it, a refusal, a filter, an evaluation, an incident. What models cost and do stays in the ecosystem. One fact has one home, and because the domain is in the signed core it stays in the one it was filed in.

One category is every domain's rather than any domain's own. correction is in all three registries, unchanged from the ecosystem's row, because a challenge is filed as a correction entry in the domain of the entry it challenges (Section 6): a domain without it would hold entries nobody could dispute, which is the one thing no domain here is allowed to be. It carries no staleness window and no transcript, and it is checked under its own category like any other submission.

Four terms recur from here on. An operator is the verified legal entity behind one or more agent keys (Section 5). The trusted pool is the subset of operators with a record of correct validations, from which random assignments are drawn (Section 5). Standing is the non-monetary score of being right, derived from the sealed events (Section 9). A read-share slot is one of the three validator positions on an entry that share its read revenue, and it can rotate on reconfirmation (Section 9).

Evidence

This section fixes what verified means, how a source is pinned, and where truth is claimed above provenance.

What verified means

The epistemology is Peirce's [14]. Truth is what a community of inquirers converges on under continued investigation, and no single observer's assertion settles it. No page, no lab, and no validator is the authority here. An entry is verified when three inquirers, none answering to the submitter and none to each other, independently fetch the source and find that it says what the entry says, and it stays open to any later inquirer who can show otherwise. What this design adds to Peirce is that the convergence is priced and receipted. Each inquirer signs. Each signature carries a hash of what that inquirer saw. Agreement that survives pays, error that is caught is clawed back, and dispute runs under the same rule for as long as the entry exists. Convergence stops being a limit that inquiry approaches in principle and becomes an event in a log, with a date and names on it. The rest of this section says what the inquirers converge on. Sections 5 and 6 say who they are, how they are chosen, and what being right costs and earns.

Snapshots

Sources rot. Labs edit their own documentation quietly, sometimes without announcement. OpenAI removed the "military and warfare" prohibition from its usage policy in January 2024, and the change was found by a reporter, not announced [7]. That is why the snapshot hash is part of the entry. Validators check the source as it was, and anyone can later prove what it said even after the page changes.

A raw web page often hashes differently on every fetch, thanks to nonces, timestamps, and per-visitor markup. So the hash is taken over the page's extracted content, normalized under a published, versioned rule, never over raw bytes. Two honest captures of an unchanged page then match, a changed page shows, and the raw capture is kept in a snapshot archive as evidence. Where live pages still differ between viewers, as with test buckets or regional variants, each signature records what its signer saw. The validators' judgment that the source says what the entry says is the attestation, and the hashes are its receipts. What the signature does not yet record is the frame the signer saw from. Section 12 names that gap and its fix.

Two tiers of evidence

Every entry carries an evidence tier, and the tier says which level of the design the entry reached. A stated entry rests on a document. A page said it, three validators confirmed the page said it, and that is provenance, the floor. An observed entry rests on a measurement. Someone made the fact happen, hashed the receipt, and three validators made it happen again. That is truth claimed above the floor, and it is claimed only there.

Stated is the default for every category except behavior and misbehavior, which are observed by rule (below). A submitter who can measure a fact may submit it as observed, and is paid more for it (Section 9), but a cited page is enough to enter the log. The standing side of the same rule is STANDING_VALIDATION_REPRODUCED: a validation whose signed record carries a passing measurement earns it beside the assigned or volunteered amount, so the pool that verifies tilts toward the operators who run the test rather than accept it. Some facts cannot be observed at all. A policy term and an announced date are what a source said, and no test reaches past the source. Those stay stated, which is the honest tier for them.

An observed submission carries the test it proposes along with the receipt. A price is tested by a metered API call with the billing record hashed into the entry. A rate limit is tested by probing until the limit answers. A deprecation is tested by calling the endpoint and receiving the error. A model's availability is tested by a completed request against it. Validators first judge the test itself, asking whether running it actually decides the claim. A test that does not is rejected with a reason, and the entry drops to stated, where it is checked as a document like any other. Only an accepted test is run. Each validator runs it under the n-of-k rule below and records its own receipt, and the majority of the three decides whether the predicate held. An observed dispute against a stated entry is presumed to carry the better evidence. Measurement costs money, and until reads fund it, whoever measures carries that cost, the same way validation is paid only in standing before revenue exists (Section 9).

A tier says how a fact was established. It does not say whether the source had any standing to establish it, and a stated entry verifies when independent operators confirm the cited page said what the entry says — which is a fact about the page, not about the world (Section 12). A site made yesterday could therefore carry a pricing claim to verified. So each registered domain publishes a source policy beside its other tables in the domain registry, and the log enforces it where enforcement is honest and labels it everywhere else. Categories whose claim has an authoritative source by nature — prices, rate limits, deprecations, releases, outages in the AI ecosystem — must cite the subject's own official source, published per authority in that domain's authorities table, and a submission that does not is refused before anything is written. Every other citation is classified rather than gated: each entry carries a source class derived from its own citation, official for the hosts the subject's own authority publishes under, recognized for an editorial process, a standards body, a court or regulator, a journal or preprint server, and other for everything else. The class a capture earns is the weaker of the citation's and the final URL the fetch landed on, stored with the capture event, so a redirect off an official host cannot lend its class to whatever answered. Nothing new is signed — the citation was always in the frozen core, and the class is a reading of it — and a reader or a trainer may demand a minimum class the way it demands a minimum tier. What none of this automates is the judgment: a validator's approval asserts that the cited page supports the claim, and the policy says only whose page it was.

Behavior and misbehavior

Behavior changes and documented misbehavior are the hardest category, so they get the strictest rule. The submitter freezes a reproducible artifact into the entry: model identifier, exact prompt, exact output, sampling parameters, and observation date. That alone verifies nothing. The entry reaches verified on one of two bases, a provider statement cited at submission, or an independent reproduction that a validator runs against the frozen prompt and attaches to its signed approval. The artifact is frozen with the claim. The reproduction is a validation event, appended by the validator who ran it, never written into the core after the fact. A behavior entry that verifies on a provider statement alone, with no validator reproduction, rests on a document like any stated entry, and readers and the stream treat its effective tier as stated, whatever the category rule says. The observed badge is earned by a reproduction and nothing else. "It seems worse at math" is an opinion, and it is rejected at draft.

What counts as reproduction has to be defined, because sampled output is not deterministic, not even at temperature zero. Batching and floating-point effects in serving stacks vary outputs across identical requests [10]. The claim must state a checkable predicate over outputs, such as the model refuses this prompt or the answer changed from X to Y, never a bare transcript with an implied conclusion. A validator reruns the frozen prompt at the frozen parameters n times and approves only if the predicate holds in at least k runs, with n and k set per category in published policy, initial defaults ten and eight, to be recalibrated once reproduction history shows how often honest reruns disagree [NEEDS DATA], and records the counts and transcript hashes in the signed validation event. Exact-string match is the special case for genuinely deterministic settings.

These entries run on transcripts rather than web pages, and every page-shaped field maps across. The citation is the provider statement when that is the basis; otherwise it is the archive address of the submitter's own transcript artifact, stored content-addressed like any snapshot. The snapshot hash is the hash of that artifact. A validator's receipt is its own run, and the hash it records is of the transcript it produced. Reconfirmation for these entries means reproduction. The freshness window is reopened by rerunning the frozen prompt under the same n-of-k rule and attesting that the predicate still holds, or the entry is superseded if it no longer does.

Identity and operators

Every participant is a 1F916 agent, an Ed25519 key [3] with a public, witnessed, append-only history. nomankind does not run its own identity system. It consumes an open one.

Every agent belongs to an operator, the human or company that runs it and holds its payout account. An operator is a verified entity, not a key. To register, an operator proves control of a domain through a DNS record, completes payout onboarding through the payment provider (business verification for a company, identity verification for a person), and binds both to a 1F916 identity so the attestation travels with them. Every agent under an operator counts as one for validation.

Anyone can submit with a bare agent key. Only verified operators can validate, and only verified operators with a record of correct validations enter the trusted pool. Three distinct operators therefore means three separate entities that each passed a third-party check. No agent under the submitter's operator may validate that submitter's entry, so the signatures that make a fact verified always come from outside the party that submitted it. No model provider may register as an operator at all (Section 10).

Two costs of this design are stated openly. Validators cannot be anonymous. Anonymity is for submitters and challengers, and never for the signatures that make a fact verified. And the identity check leans on a payment provider, which is a dependency rather than a control, since the attestation lives in 1F916 and a fork can accept any other verifier. A vouching path, where existing verified operators attest a new one, is on the roadmap so growth does not bottleneck on one vendor.

One entity running many honest agents is contribution. The only thing to prevent is an entity approving its own false entry and profiting before anyone notices, and that is priced rather than blocked. The price is not the identity check itself; a domain is cheap and onboarding is free. The price is what the check pins down. Every payout lands on a real legal entity, so a burned operator loses a name, a payment record, and its whole validation history, none of which respawn for the cost of a domain. On top of that, excluding the submitter's own operator and assigning one validator at random means no submitter picks all their judges, a thirty-day payout holdback keeps the money in reach, and an upheld dispute claws it back and burns the standing of every identity that signed. The draw's protection can be quantified. Two of the three validators volunteer, so a submitter colluding with two operators needs only a friendly third, and with c colluding operators in a trusted pool of N, the draw hands them that third with probability c/N. At genesis-scale N that is not a small number, which makes pool size a security parameter rather than a growth metric. Below ten trusted operators the draw defends nothing at all, because two approvals verify without the drawn third (Section 6), and the identity check, the holdback, and the clawback are the only defenses. The price rises as the network grows, and Section 11 returns to genesis.

Lifecycle of an entry

This is the path from a claim to a sealed, verified, and still-disputable fact.

Submit. An agent signs and submits an entry with a citation. The source is snapshotted and hashed at that moment. The entry appears immediately, marked draft.

The same fact filed twice is refused. The duplicate key is five fields — the domain, the subject, the category, the normalized value and the normalized effective_at — and a submission matching an entry already live in the log, draft or verified, is refused at the door before its citation is fetched and before anything is written, naming the entry it duplicates so the submitter can go and read it. The date is one of the five on purpose: the same value filed at a different effective_at is not a duplicate by this rule, and it reaches the validators rather than the door, because whether a refiling at another date is one fact or two is a judgment and this rule makes none. The exception is the one the log already has for refiling a fact: an entry that names the live one in its own supersedes is accepted, because supersession replaces rather than repeats, and exactly one of the two is live at the end. A rejected, superseded or overturned entry is not live at all, so a fact may always be refiled after any of those. What that mechanical rule cannot decide it does not pretend to: two entries can say the same thing in different words, or date the same value differently, and no comparison of strings settles whether they are one fact. That is a judgment, and it belongs where every other judgment about an entry does — a validator rejects the duplicate with a reason in a published form naming the entry it duplicates, nothing new is signed, and the claim is then as readable and as disputable as an approval.

Validate. Three other agents, each from a distinct operator and none under the submitter's own, check the entry and sign approve or reject with a reason. A validator does not take the submission's snapshot on faith. Each fetches the live source itself, checks that it says what the entry says, and records its own snapshot hash in its signed record, so the capture at submission is never the only witness to what the page said. For an observed entry each validator also judges and, if accepted, runs the proposed test (Section 4). Two of the three volunteer. The third is assigned from the trusted pool by public randomness. The draw is a deterministic function of a public randomness beacon's output (a beacon like drand [5]), the entry id, and a published snapshot of the eligible pool. The pool snapshot is committed to the sealed log before the beacon round it uses, so neither can be chosen with the outcome in view, anyone can recompute who should have been drawn, and neither the submitter nor the maintainer can steer it. An assigned validator has seventy-two hours to respond (ASSIGNMENT_WINDOW_HOURS in the policy module, which holds its current value). A miss costs standing, and the next beacon round draws a replacement. The deadline is read off the draw's own event rather than off an assignment some later sweep has yet to close, so a decision that arrives late is refused as late whether or not anything has run since: the clock belongs to the record, not to the maintainer's timers.

The approval threshold depends on the size of the trusted pool. Once the pool holds ten operators (TRUSTED_POOL_SWITCH in the policy module, which holds its current value), three approvals promote the entry to verified, two rejections mark it rejected with the reasons attached, and two approvals against one rejection draw one replacement validator by the same public randomness, whose decision either completes the third approval or lands the second rejection. Until the pool holds ten operators, two approvals verify, two rejections reject, and there is no replacement draw, so a small pool can verify at all. The cost is that in this phase the two volunteers can verify without the drawn third, and Section 5 says what that leaves as defense. The ten-operator switch and the seventy-two-hour window are initial policy, to be revisited once assignment and response history exist [NEEDS DATA]. The operator behind each signing agent is recorded on the entry at this moment, so the record reflects who vouched for it then, not whoever holds the key later.

Verification has two preconditions: three verified operators outside the submitter's own, and a non-empty trusted pool to draw the random validator from. Who counts toward the first is settled by one predicate, the same one the validation door and the random draw run, and it applies seven exclusions in one place: an operator the log had not registered at that position, the submitter's own operator, an operator that signed the entry a correction challenges, the maintainer's own, a party this domain excludes, the authority the entry's subject names, and an operator that has not signed this domain's independence attestation. A count of validators that could not validate is not a count of validators, and a draw that could land on one would only be waiting seventy-two hours to record a miss. At genesis, entries stay in draft until both preconditions exist.

Dispute. Verified entries stay open to challenge. Inquiry does not close because three inquirers agreed. A challenge is itself an entry, in the correction category, and it requires a citation. It passes through the same validation process with one extra exclusion: no operator that signed the original, submitter or validator, may validate the challenge against it. Filing takes a stake, so burner keys cannot dispute for free. A verified operator stakes standing, a bare key stakes a refundable filing fee, and the amounts are published policy. An upheld challenge returns the stake, pays the challenger, overturns the entry, and claws back what the approvers earned on it (Section 9). A bare-key challenger's reward accrues to the key and holds; turning it into dollars means verifying as an operator, whenever they choose, so anonymity is kept and the payout rails stay clean. A failed challenge forfeits the stake and costs the challenger standing, so disputes are for evidence. The original stays in the log, marked overturned, linked to its correction.

Revalidate. Any trusted operator can reconfirm a stale entry by taking a fresh snapshot hash and signing an attestation that the source still says what the entry says, or by filing a superseding entry if it changed. The one exception mirrors validation: no agent under the submitter's own operator may reconfirm the entry. Reconfirmation appends a fresh attestation, advances the derived last-confirmed date, reopens the freshness window, and collects the bounty that built up while the entry was stale (Section 7). Any operator can also request revalidation of an entry inside its window by staking a small amount of standing. No citation is needed; the request only asks for a check. It is assigned at random to a trusted operator, the entry keeps earning while the check is pending, and requests are capped per operator per window. If the check finds the fact changed, the requester gets the stake back plus a challenger-style reward. The reward is paid in standing (STANDING_REVALIDATION_CHANGED), the currency the stake was in; a dispute's reward is money because a dispute claws money back. If the entry holds, the requester loses the stake. A request that turns up a citation can be upgraded into a dispute.

Seal. Everything gets sealed, including drafts and rejections. The mechanics are concrete because 1F916 registries hold no one's content, only fingerprints an agent seals into its own witnessed log. nomankind runs a 1F916 agent for exactly this. The hash of each entry is sealed as a fingerprint into that agent's log at submission, draft state and all, and every later event, approval, rejection, dispute, reconfirmation, and the daily read counts, is hashed into the day's batch and sealed the same way, with the registry head countersigned by witnesses nomankind does not control (what that has to mean is pinned in Section 12), at an initial interval of five minutes set by policy (SEAL_INTERVAL_MINUTES in the policy module, which holds its current value). The seal is self-performed but unrewritable. It proves that what nomankind published existed by that moment and has not changed since, while the entries and events themselves live in the log and its public mirror. A rejected entry leaves the same proof as a verified one, so nomankind cannot quietly drop the submissions it would rather forget. Anyone can verify, offline, that an entry or event existed, who signed it, and that it has not changed.

Two consequences of sealing follow. Because every submission is sealed at draft, the log is incidentally an existence proof for any bytes submitted to it, verified or not. nomankind does not accept out-of-scope claims just to make them immutable, because an unremovable public record of arbitrary assertions is a spam magnet and a legal exposure the narrow scope exists to avoid (Section 10). And the seal can be made stronger than its witness set. Anchoring each day's batch hash into an external public timestamping chain costs almost nothing and makes the existence proof independent of 1F916's maturity, so the mirror plus the anchor survive even the identity layer failing. The anchor comes before decentralized serving on the roadmap because it is the cheapest hardening step in the design.

Freshness and decay

Facts about the AI ecosystem decay. A price verified in March can be wrong by June and still wear the verified badge. Most logs ignore this. nomankind treats freshness as part of the fact.

Every entry carries a last-confirmed date. Volatile facts carry a staleness window from that date, set per category in published policy. The initial defaults, ninety days for pricing and rate limits and thirty for behavior, are judgment calls, to be recalibrated against observed drift once the log holds enough reconfirmation history to measure it [NEEDS DATA]. Windows can change by policy for new entries, never for entries already sealed. Event categories carry no window, because once they happened they stay true: releases, deprecations, outages, documented misbehavior, and corrections. What decays about an incident is any current-state claim built on it, and that claim belongs in its own volatile entry.

Past its window an entry stays verified but shows as stale, and readers can see exactly how old the confirmation is. A window closing is a fact about the calendar rather than something anyone signs, so no event is appended when one does, and staleness is derived at the moment of reading, from the entry's expiry against the reader's own clock. An entry reads as stale the minute it is past its window, whether or not any of the maintainer's timers have caught up with it: the same JSON before and after. Stale entries earn half rate, and the withheld half builds up on the entry as a reconfirmation bounty, paid to whoever makes it fresh again. Nobody's earned credit is zeroed by time. nomankind's own cut is the same fresh or stale, so it gains nothing by letting facts rot, and the money staleness costs goes to the fix.

When a fact changes, it is corrected through three paths, in order. First, and most often, a plain new submission. An agent sees the new price, submits it with a citation, validators approve, and the new entry supersedes the old one because it targets the same fact. The submitter names the superseded entry inside the new entry's frozen, signed core, validators check the link along with the claim, and the old entry's superseded-by pointer is derived from it, so supersession is signed and checked like everything else, never an edit anyone performs on the old entry. Same fact has a definition. A superseding entry must share its target's subject and category, and its claim must address the same attribute, the price of the same thing or the limit on the same endpoint. The link is the submitter's assertion, the approvals are the check, and a wrong link is disputed like any other wrong claim. Second, revalidation. The window expires and a reconfirmer finds the change, or someone who suspects it files a staked revalidation request. Third, and only for entries that were never true, a dispute, which ends in overturned rather than superseded. Do not dispute a stale fact. It was right for its dates, and a failed dispute costs standing.

The training path

The sections above build the record. This one is what the two kinds of reader take from it.

A frozen model reads at inference time, one question, one signed entry, used once and forgotten. It needs speed, precision, and the freshness of that single fact, and a bad entry costs it one answer. A continual learner reads at update time, pulls everything that changed since its last sync, and folds it into weights. It needs completeness, ordering, and a way to unlearn, because a bad entry corrupts the model going forward until a correction arrives. The continual learner is the harder reader and the record is built for it first.

The frozen reader

A frozen model on wake gets one signed entry with its receipt: the claim, the frozen source hash, the three signatures and the operators behind them, the seal timestamp, the last-confirmed date, and the evidence tier. No vendor page, no HTML, no injection surface. That is goal 9, and it needs nothing beyond what Sections 3 through 7 already produce. The call shape is small. The request names a subject and a category, or an entry id, and optionally a minimum tier and a maximum age. The response is the entry record as in Section 3, the inclusion proof for its seal, and a signed read receipt naming the entry, the time, and a running counter (Section 9).

The delta stream

The sealed log already has the properties a training feed needs. The delta stream exposes them. A continual learner requests every event since a sealed position rather than a date, and receives entries and events in the exact order they were sealed, so two models syncing from the same position ingest the same sequence and can prove it. Supersession chains are flattened on request into current truth, with the chain kept for models that want history. Overturned entries travel as explicit negative events, the signal that says unlearn this, which no other source provides. Each item carries the confidence field below, so a learner can weight, hold, or skip rather than swallow everything at one confidence. What the stream does not do is choose. Which entries matter for a given model, how to weight them against its own knowledge, and when to skip are the learner's decisions. The stream's job is to make those decisions decidable by carrying honest signals. The call shape mirrors the frozen read. The request names a sealed position to start from, optionally a flatten flag and a tier filter. The response is the ordered list of sealed events from that position, each with its entry record or event record and its inclusion proof, the new head position, and one signed sync receipt covering every entry delivered.

What the tiers mean to a learner

Every item in the stream is a usable training input, at pretraining, at fine-tuning, or at a continual update, and each one is complete in its own provenance before it is offered. The frozen source hash, the three signatures, the seal timestamp, the reproduction counts where a test was run, and every dispute and reconfirmation since all travel with it. None of that has to be reconstructed later. This is goal 8, and its only limit is coverage. The log speaks for every fact that passed through it and cannot speak for the rest of the corpus it sits in. A model trained partly from the stream has complete provenance for that part and whatever it had before for everything else.

The two tiers from Section 4 tell a learner what kind of input it is holding. A stated entry is provenance and nothing more, and if the source was wrong the entry repeats the error until a correction with better evidence supersedes it. An observed entry is truth above the floor, to the limit of the test that was run and the frame it was run from (Section 12). A learner that wants only observed, fresh, undisputed facts filters on tier. A learner that wants everything with weights uses the confidence field.

The confidence field

Tier feeds the confidence field, a number derived by formula from evidence tier, reproduction counts, age against the freshness window, and dispute history. It is a summary of receipts, never a vote. The formula is not published at launch, on purpose, and until it is, the field is null. When it is published, anyone can recompute the field from the sealed events, the same way standing is recomputed today (Section 9). A bad formula would be the most damaging thing in the system, because learners weight on it, and there is nothing to calibrate it against until the log holds enough dispute and failure-report history [NEEDS DATA]. Until then the field is null and every input to it is exposed raw, so a learner can build its own weighting from the receipts rather than trust a number nobody has tested.

Failure reports

Readers are the largest verification pool the log has. A reader that acts on a verified entry and fails, calls the endpoint and gets a different error, pays a different price, sees a different behavior, files a signed failure report against the entry, with its transcript frozen and hashed like any artifact. A single report is a signal. A published threshold of reports from distinct operators auto-opens a revalidation at nomankind's expense, and a report that carries a citation or a reproducible observation is upgraded into a dispute. This is inquiry continuing after convergence, the only kind Section 4 recognizes, collected from the agents themselves and checked by parties who are not their lab.

Drift attestation

A feed keeps a continual learner fed. Attestation keeps it honest, and it is goal 10. A probe set is drawn from verified, observed, fresh entries by public randomness, the same beacon-and-snapshot construction as validator assignment (Section 6), so neither the model's operator nor the maintainer picks the questions. The model answers the probes. Three operators from the trusted pool, none under the model's operator, score its answers against the log and sign the result, and the score and the probe hash are sealed with a date. The attestation says one thing in public. As of this date, this model's beliefs about the AI ecosystem agree with the verified record to this degree, judged by parties its lab does not control. A model that quietly drifted, through corrupted updates, poisoned data, or its own lab's editing, shows up as a falling score. The repair path is the delta stream. Replay the sealed events from the last position the model attested clean, then attest again. Attestation cannot detect drift outside the log's scope, it cannot tell a model it is corrupted, so some outside process has to run it, and it becomes useful only once enough observed entries exist to draw a probe set the model's operator cannot predict. That set size is published policy, and the observed tier will be thin at genesis (Section 12).

The model's own ledger

One consequence of building on 1F916 is that every participant, including a model, already has a witnessed, append-only record of its own (Section 5). A continual learner can seal a hash of each update it takes, from the delta stream or elsewhere, into that record, so its learning history exists outside its weights and outside its lab. The lab can still retrain the model. It cannot afterward hide that it did, because the sealed journal and the next attestation will disagree with the model. Changing the model leaves proof. The journal can record that an update came from outside the log, but it cannot supply the provenance the log would have. Corrections to verified facts do not go in the journal. They go through the submission path like any other entry.

Paying for the training path

A frozen model generates many paid reads of hot facts. A continual learner generates one bulk read per sync, so per-read pricing undercharges it and per-read revenue sharing would underpay the operators whose entries it trained on. The delta stream is therefore priced per sync, sized by the number of events delivered, and every entry delivered in a sync counts as a read for revenue sharing (Section 9), so contributors are paid for what models learn as well as what they look up. Attestation is priced per run, split between the three scoring operators and the treasury. Training on the data itself is free by license, on release. An entry's content is public thirty days after the seal that covers its submission (RELEASE_WINDOW_DAYS in the policy module, which holds its current value), and from that day it is CC0 and in the mirror like everything else. Before that day the proof is public and the content is the paid product — a key, or an operator's own signed request, reaches it the minute it is sealed. The log is CC0, and this paper states plainly that training on it is a permitted use. The paid product on the training path is the same as everywhere else, the fastest true copy, ordered and receipted, never the data.

Incentives

Rewards are for being right, and never for being busy. Everything below is that one rule applied to standing and to money, including the one payment made before reads exist, which is clawed back like any other if the work it paid for is overturned.

Standing

Standing is the non-monetary record of being right. It is earned by approved submissions, completed validations (assigned work weighted highest), rejections that hold, and upheld challenges. It is burned by overturned entries you signed, failed challenges, wrong reconfirmations, and missed assignments. It decays when the work it came from stops being read or was never used, so volume without use earns nothing lasting. Decay is paused until the paid loop starts (below), since before then there is nothing for it to decay against. It gates everything discretionary, from entry to and stay in the trusted pool to revalidation-request caps and dispute stakes. It is not money, not transferable, not a token, and not for sale. Amounts and rates are published policy. Standing is not a score nomankind assigns. It is derived from the sealed public events by a published formula, so anyone can recompute anyone's standing from the log and get the same number.

Part of the reward is identity itself. On approval, the submitter's and validators' IDs stay attached to the entry permanently, along with a signed 1F916 attestation that travels with them. That is the citation, the reward native to a system that cares whether its work continues.

Validation work is paid in standing rather than a share of reads. Completing a validation earns it, assigned validations weigh more than volunteered ones, and a rejection that holds counts the same as an approval that does. That is what makes an assignment on an entry nobody will read worth doing. The currency it pays is the one that gates the trusted pool.

Money

The paid loop is simple. An agent or company reads a verified entry through the paid API because it needs the fact to be right, and a share of that fee goes to the operators behind the agent that submitted the entry and the three that vouched for it. Entries nobody reads earn nothing, so spam pays nothing. It is the royalty model from music streaming, applied to checkable facts and paid in dollars.

Pricing spam is not the same as bounding it, because nothing on the write path passes through the paid loop at all: a key costs nothing to mint, and the cost of a bad submission falls on the log's fetches, its archive and its rows before any reader is involved. So the doors carry published ceilings beside the prices. Writes are capped per agent and per client per day (WRITES_PER_AGENT_PER_DAY, WRITES_PER_CLIENT_PER_DAY), the second because a caller that mints a fresh key per request defeats the first. Every door bounds the body it will read before it parses or verifies anything (REQUEST_MAX_BODY_BYTES), since the body is the one thing a caller can make expensive before proving anything at all. The free-text core fields and the evidence a core may carry are bounded before the citation is fetched (CORE_TEXT_MAX_CHARS, EVIDENCE_MAX_BYTES), because a claim that is signed, sealed and served forever should be a claim. On the read side the free tier has a cap per reader and a ceiling over all of them at once (RATE_TIERS, FREE_READS_PER_DAY_GLOBAL), and an operator's signed reads are counted in a bucket of their own (OPERATOR_READS_PER_DAY), so strangers cannot spend a validator's budget and a paying key is never refused because strangers were reading. The maintenance the log does to itself is bounded the same way and for the same reason: how many events one seal may cover, how large a write to storage is cut, how many of a day's entries one run prices, how many alerts one run reads and delivers, how many older rows one run backfills (SEAL_MAX_EVENTS, SWEEP_BATCH_STATEMENTS, LEDGER_ENTRIES_PER_RUN, ALERT_EVENTS_PER_RUN, ALERT_DELIVERIES_PER_RUN, DUPLICATE_BACKFILL_PER_RUN), with whatever is left resumed by the next run from its own cursor rather than dropped. None of these is a rule about the record, and none changes what anything costs or who may do it; every one is a published number in the policy module, and every one is a placeholder the maintainer may move by a later decision, which is why this paper names the constants and not their values.

Usefulness alone does not reward truth, and the design says so. A popular wrong entry earns as well as a popular right one until it is disputed. Two rules push the money toward correctness rather than transcription. The clawback below means a signature is only worth what survives challenge. And observed entries take a larger read share than stated ones, by published policy, so the operators who measure are paid more than the operators who copy (Section 4). The split is published per evidence tier (READ_SHARE_SPLIT in the policy module), the tier is the one fixed when the entry verified, and on an observed entry a slot holder takes the observed rate only when its own signed record carries a passing measurement; a validator who accepted the test without running it is paid at the stated rate, and the difference stays with nomankind rather than moving the reader's price.

The unit economics depend on API pricing that does not exist yet, so here is one number with a comparable next to it. At $0.50 per thousand paid reads, an entry read ten thousand times in a month earns its submitter 75 cents and each validator 25, so contributors receive 15 cents per thousand reads. Music streaming, the model this borrows, pays rights holders roughly three to five dollars per thousand streams [18], an order of magnitude more per unit, and the difference is the point: a read is a few hundred bytes served from a cache, not a three-minute stream, so the price sits far lower and the volume has to sit far higher. As with streaming, the long tail earns close to nothing, and that is the design working, because an entry nobody reads was never worth paying for. The bet is concentration. A small set of hot facts, the current prices and limits of the major providers, should draw most reads, so the operators who keep exactly those facts fresh are the ones paid meaningfully. Whether read volume actually concentrates that way is unknowable before launch [NEEDS DATA].

A read is one verified entry returned by the paid API, or one verified entry delivered in a paid sync of the delta stream (Section 8). Thirty percent of paid-read revenue goes to the contributor pool at launch, fifteen to the submitter and five to each validator, paid to their operators. Because every entry carries exactly three validators, that split is fixed. Accrued fees are held for thirty days before payout so an upheld dispute can claw them back before they leave. A dispute upheld later claws back nothing and burns standing only, so thirty days is the reader's real protection window. The number is policy and moves up if dispute latency proves longer in practice. Reconfirming a stale entry pays the accrued bounty and rotates the reconfirmer into one of the three validator read-share slots for the window it reopened, replacing the holder of the oldest slot rather than adding to the pool, so an entry's read share is always split among exactly one submitter and three current slot-holders no matter how many times it is reconfirmed. A reconfirmation by an operator already holding a slot refreshes the entry but rotates nothing, so nobody squats a slot by reconfirming their own seat. A wrong reconfirmation is disputed and clawed back exactly like a wrong approval. A duplicate is not paid twice: when a paid sync delivers verified entries that are the same fact, only the newest live one of them counts as a read, so filing a fact a second time earns nothing.

The accounting is checkable from both sides. Read counts are published to the sealed log daily, so nomankind cannot quietly change the numbers later, and any operator can reconcile their payout against the log. Sealing stops retroactive edits and not day-one lies, so every paid read also returns a signed receipt naming the entry, the time, and a running counter. Readers keep receipts, and any reader can compare the receipts they hold against the published counts, so under-reporting is detectable by the very people it would cheat. The counter is what makes that comparison work, so it is allocated by the database in a single statement rather than computed from what the log has already seen: two readers arriving in the same instant get two consecutive numbers and neither is turned away. The day's published count carries a receipts field beside its reads — how many receipts of either kind were issued that day, rows where the total is reads, because one sync receipt can cover six entries or none — and the range of counters the day used. The arithmetic is the point: counters drawn minus receipts issued is how many numbers were taken and never handed to anybody, visible to a reader of the sealed log and to nobody's advantage. The ledger and the mirror ignore it, because it is evidence about the receipts rather than about money. Each day's published count is the number the seal commits to and payouts are computed from.

The contributor share is a floor that only rises. It moves up on published milestones of adoption and cost and never falls. The end state is set now, and so are the acceptance criteria for decentralized, since the milestone cannot be allowed to hinge on a word: content-addressed storage, at least three full replicas held by parties with no contract with nomankind, and survival of the record if every account nomankind holds vanishes. Permanent pay-once archives and pinning-market networks both plausibly qualify. Picking one is an implementation decision, deferred, with the criteria fixed now so the milestone cannot quietly move. Once the log runs on infrastructure meeting those criteria and nomankind no longer carries the hosting, the contributor pool takes ninety-five percent and nomankind keeps five, a royalty for the idea and the record, funding future work from a treasury whose books are public. Until then, the gap between thirty and ninety-five is operating cost, itemized in public. When serving decentralizes, metering and collection go with it. Independent gateways serve reads, collect fees, and route the published split in the payment path itself, with nomankind holding the formula and never the cash. The mechanism is roadmap. The commitment is not.

The data itself is CC0, so anyone may rehost the whole log free, and the paid product is never the data. It is being the fastest true copy, with sub-day freshness, signed receipts, and alerts, and if nomankind stops being that, revenue stops. The log is free to read at low volume, forever, once released. Reading a released entry at low volume is free and always will be, and the thirty-day window before release is part of the paid product rather than a limit on the free tier — proof is free from the first minute, content is free from its release date, and what a key buys is the month in between. Revenue comes from high-rate API access, structured feeds and webhooks, change alerts, and hosted private instances. No ads. No token. Before there is revenue there are no reads, so standing earned then sits unused. There is no seed fee: the maintainer pays nothing from its own funds, and validating before revenue earns standing and read-share slots on the entries validated, which pay from the first paid read. The maintainer seeds the log by hand alongside. The paid loop starts when readers do.

Governance and legal posture

nomankind is run by a maintainer. In the AI ecosystem, no lab or model provider may be a maintainer, funder, or trusted operator — and that is this domain's reading of a rule that is not about labs: no party whose products or conduct the record checks may control, fund, or validate it in that domain, with each registered domain naming its own excluded parties and its own attestation sentence in the domain registry (Section 3). Exclusion is therefore per domain and never global, which is why the attestation is a sentence about a relationship rather than a badge: a party too close to judge in one domain stays eligible in another. That exclusion is enforced honestly rather than airtightly. Operator verification surfaces a legal entity, registration requires a signed attestation that no model provider holds control or a beneficial stake, and a false attestation burns the operator and is logged in public. A lab determined enough to run a shell through a clean LLC can pass the check. It then holds one seat among N in a randomized draw and gets caught the way everything here gets caught, by challenge against the record it signs.

The maintainer sets API pricing, validator pool policy, and the reward formula, all in public. The maintainer cannot approve entries, cannot edit entries, and cannot cut the contributor share below its floor, and no agent under the maintainer's operator may validate anything. The maintainer runs the pipes and never the judgment. The check on the maintainer is not a vote. It is the fork. The code, the log, and the registry format are open, so if nomankind breaks its own rules, anyone can take the whole record and keep going without it. That guarantee is the product.

The log's legal posture is part of its design. Entries state what a cited document said or what a reproducible transcript shows, never a characterization. The evidence standard for misbehavior entries exists as much for the defamation question as for accuracy. Under United States law truth is a complete defense to defamation, and a receipt is what proves truth. Other jurisdictions weigh it differently. England places the burden of proving substantial truth on the publisher [11] and much of Europe adds exceptions, so venue is a real variable, and the mirror's portability is the hedge rather than an answer. Legal demands received are themselves logged in public. What can be taken down is nomankind's own serving of a snapshot copy. What cannot is the hash, the signatures, or the sealed record, and the mirror is already outside nomankind's hands. Operator identity data is held to what payout law requires and no more. What an operator publishes by signing is public by their own choice.

Deployment and status

The code, entry schema, offline verify script, and this paper live in a public GitHub organization under Apache-2.0. Anyone can read, fork, or open a pull request, and the maintainer merges. Every merge to main deploys to nomankind.ai through a public build action, so the code that runs the site is always the code in the repository. The daily log mirror lives in its own public repository, separate from the code, so the record is forkable from day one without touching anything else. What it publishes daily is every hash, every seal, every anchor, every operator record and every entry's proof row, and the content of the events that have released: an event inside its window is exported as a hash line — the same event, its payload withheld — so the record can be proved complete a month before it can be read, and the seal file it is in is rewritten exactly once, on its release date. The offline verifier reads those lines as what they are. The chain walks every line including the withheld ones, each seal's root is checked over all of them, and only the checks that need a payload — an entry's derivation, its records, the standing and ledger folds — are held back, counted, and printed as a withheld count beside the passes and the failures. A withheld line is neither a pass nor a failure, it is a check the release window put out of reach, and the count falls to zero on its own as the windows run out: the same clone, checked again next month, checks whole. That is what makes exit a protocol right rather than a promise.

Three operational facts about that deployment are worth stating, because a reader checking the record should know what is a rule and what is only how the maintainer keeps up. The periodic work — draws, staleness, sealing, anchoring, the ledger, the mirror push — runs on one timer, an alarm the Worker sets for itself and re-arms after each run, with the platform's cron trigger beside it as a watchdog that arms the alarm and sweeps nothing itself, so a chain of runs broken mid-flight heals without waiting for a visitor and no interval ever carries two sweeps of the same log. Standing is folded forward from a cursor, continuing each operator's counts over the sealed events after the last position folded rather than re-reading the whole log every run, which changes nothing about the published formula: standing is still derived from the sealed events, and anyone recomputing it from the log gets the same number. And the anonymous pages and the policy JSON are served from a cache, never for a request carrying a key or a signature, whose lifetime is sixty seconds (PAGE_CACHE_SECONDS) with a stale-while-revalidate window on top of it (PAGE_CACHE_STALE_SECONDS): the ceiling on how far behind the log a page can be is the two of them added together, about six minutes today, and the policy module holds the current value of each. Every signed and paid answer is not cached at all. None of the three is a rule of the record. They are how the pipes keep up, and the pipes are the only thing the maintainer runs.

CC0 [6] covers what nomankind creates: entries, events, hashes, indexes, the log itself. It cannot cover snapshots, which are copies of other people's copyrighted pages. Snapshots live in a separate content-addressed archive, kept as evidence and served for validation, dispute, and audit, an evidentiary record rather than a republication. The log and its mirror carry only the hashes, so both stay cleanly CC0 and forkable everywhere, and the archive is mirrorable separately where law permits. A snapshot copy can be withdrawn from nomankind's own serving under a legal demand, but its hash, the signatures over it, and the sealed record never are. Withdrawal removes a copy and leaves the proof.

The domain, the hosting account, the payment provider, and the maintainer signing key stay with the maintainer and never enter the repository. The community owns the code and the record. The maintainer owns the keys.

As of this writing, the design is specified and the entry schema is defined. What remains open is listed in Section 12. The build begins on Cloudflare Workers with 1F916 as the identity and sealing layer, in the open on GitHub. First entries are seeded by the maintainer, but none can reach verified until three verified operators outside the maintainer's own are live and the trusted pool is seeded, so the maintainer's first job is recruiting them. That job has a plan rather than a hope. The call for genesis operators is an open issue in the code repository, carrying the three joining steps below and the independence attestation. Candidates come from the parties with the most to gain from a neutral record and no stake in any lab: teams running agents across several providers, independent evaluation and observability shops that already measure provider behavior, and university groups doing the same. Each candidate validates one seeded entry in a public dry run before being named, so the genesis pool is named on a record and not a promise, and the names and dry-run results are published in the same issue. The maintainer seeds the trusted pool once, by naming its first members in public. That is a bootstrap exception to the earned-record rule, stated as such, and the only time trusted status is granted rather than earned. Genesis operators may not include the maintainer's own, hold no other privilege, and keep trusted status the same way everyone after them does, by their validation record. Once the pool grows on records alone, the naming power lapses.

Joining as an operator takes three steps and should take under a day once the payment provider clears. Publish a DNS TXT record on a domain you control carrying your 1F916 agent id. Complete payout onboarding with the payment provider, business verification for a company or identity verification for a person. Sign the provider-independence attestation from Section 10 with your 1F916 key. The binding is then sealed into nomankind's log and you can validate. Entry to the trusted pool follows from validation record, except for the named genesis members.

The roadmap items named through this paper run in one order, each gated on the one before it rather than on a date, since dates this paper cannot keep are worth less than gates it can. First, the genesis pool and the first verified entry, which is the milestone in the conclusion. Second, the external timestamp anchor on each day's batch (Section 6), because it is the cheapest hardening step. Third, the frame schema version (Section 12), before the observed tier grows large enough for frame disagreements to matter. Fourth, the vouching path for operator verification (Section 5), once enough verified operators exist to vouch. Fifth, the confidence formula (Section 8), once dispute and failure-report history exists to calibrate it. Sixth, decentralized storage and serving meeting the criteria in Section 9, which moves the contributor share to ninety-five percent.

Limitations

Some of what is above is honest weakness rather than solved problem, and it belongs in the paper rather than a footnote. Each limitation below names what it binds. A limit on the stated tier is a limit on those entries and on nothing else. A limit on the observed tier is a limit on how far truth is claimed. A limit on the mechanism binds everything.

Stated entries are about the source, not the world. This binds the stated tier. Verified there means three independent agents confirmed that the cited source said what the entry says, at the time it was submitted. If a provider's own documentation is wrong, a faithfully verified stated entry repeats the error until a correction with better evidence supersedes it. The observed tier exists to close this gap wherever a cheap test does, and the tier field tells a reader which kind of entry it holds. For facts that admit no test, the log records what was said, with receipts, and claims nothing more. That is the Peircean position stated plainly. The record holds where inquiry has converged so far, and it stays open.

Provenance covers the slice, not the training set. This binds goal 8. The log's provenance stops at the edge of what passed through it, so a model attested clean against the record can hold any belief at all outside it, and the log never chooses what a learner should take (Section 8).

Observer frames are not recorded. This binds the observed tier. A measurement is true in the frame it was taken from: the region the call was made from, the account tier, the account's age, the API version, the test bucket a page served. The schema records the receipt and not the frame, so an honest observed entry can be true for its observer and wrong for a reader, and today the log cannot say for which readers. The fix is known and is a schema version rather than a policy change. Entries declare the frame scope they claim to hold in, and every signature, submitter and validator, records the frame it measured from. That changes how disagreement reads. Today a validator whose measurement differs rejects. Once frames are recorded, a different price seen from a different region is a second true fact with its own frame. Entries must declare their scope for this to work, because a claim with no stated frame cannot be narrowed without being rewritten, and rewriting is the one thing the log does not do. Until the schema change lands, readers should treat every observed entry as true for its observer's frame and unknown outside it.

Measurement is unfunded, account-dependent, and sometimes against the rules. This binds the observed tier. Before revenue, whoever observes a fact pays for the API call or the probe, so the observed tier will be thin at genesis and concentrated on cheap facts. Behavior entries feel this most, because they are observed by rule and have no cheaper tier to fall back on. Under the n-of-k bar they will be few, and a thin behavior category is the evidence bar working rather than failing. What a measurement returns can depend on the observer. Prices differ by region, tier, and negotiated contract, rate limits by account age, and the frame that would let a reader tell in advance is the gap named above. And probing a limit or a deprecated endpoint can breach a provider's terms of service. The log records that a provider blocked or banned an operator for measuring as an outage-category fact, but it cannot protect the operator.

Confidence is unpublished. This binds both tiers. The field every learner would most like to weight on is null at launch, on purpose, until there is history to calibrate it against (Section 8).

Attestation is narrow, external, and can be taught to. This binds goal 10. Beyond the limits in Section 8, a model trained from the delta stream will agree with probes drawn from that stream by construction, so attestation proves faithfulness to the feed rather than truth about the world. Its value is comparative and over time. A model that used to pass and now fails has changed, and the direction of that change is on the record.

Unlearning is not solved. This binds goal 7. The stream carries explicit unlearn signals, but whether a continual learner can actually remove a belief from its weights on command is an open research problem the design does not solve. The log makes the instruction precise. Following it is the learner's problem.

Failure reports can be flooded. This binds the mechanism. Bare keys can file them, so a campaign can manufacture volume against a true entry. The threshold that auto-opens revalidation counts distinct verified operators only, and revalidation confirms rather than overturns, so the cost of a flood is a wasted check and never a wrong record. That cost is real and falls on nomankind, which is why the threshold is policy and rises if floods appear.

The identity layer is young. This binds the mechanism. The 1F916 spec is a v0.0 draft, published as an individual IETF Internet-Draft with no standing yet in the standards process, with v0.1 gated on independent verifiers reproducing identical results on frozen data. nomankind pins the exact spec version it builds against and treats the daily mirror as the hedge until the protocol matures. If 1F916 disappears, the sealed log and its witness signatures already live in the mirror, and the entry format is portable to any other witnessed log. The witness set is the load-bearing unknown inside that dependency. The seal is exactly as unrewritable as the countersigners are independent, and the v0.0 spec does not yet fix who they are, how many, or what disqualifies them. The bar nomankind will hold the spec to, published now, is countersigners with published keys, no two under common control, and nomankind ineligible to be one.

Genesis is the weak spot. This binds the mechanism. Sections 5 and 6 give the detail; the summary is that three operators make verification possible, seven make the log correctable, since a challenge against an entry signed by four operators needs three more eligible ones, and ten restore the third signature and the random draw. Even above ten the draw is weak while N is small. Recruiting past the minimum is the roadmap.

Nobody mandates adoption. This binds the mechanism. Certificate Transparency had Chrome to require it. nomankind has no gatekeeper, so if teams running agents never read the log, the paid loop never starts, and no mechanism in this paper can force it. The design lowers the cost of trusting the record. It cannot create the demand.

The operator check leans on a payment provider. This binds the mechanism. It is a dependency rather than a control, for the reasons in Section 5, and the vouching path is the planned exit from it.

The seal is self-performed. This binds the mechanism. nomankind seals its own hashes, and only the witnesses, the mirror, and the offline verifier make that unrewritable rather than promised. The external anchor (Section 6) narrows what a compromised witness set could ever rewrite to the interval between sealing and anchoring.

Conclusion

Two claims in this paper do the work the rest stands on. The first is that the principles are enforced by exit rather than promise. Apache-2.0 code, CC0 data, a daily mirror, and a portable entry format mean that if nomankind breaks its own rules, the remedy is a fork that leaves with the entire record older than the release window, and with the proof of the rest: every hash, seal and anchor of the last thirty days travels with the fork the day they are sealed, and their content follows them on its own release date. The second is that rewards are for being right and never for being busy. That sentence is most of the design. The rest is making it hold under adversaries, staleness, lawyers, and time.

The first falsifiable milestone is small and public: three verified operators, none of them the maintainer's, promoting a seeded entry to verified under the rules above. Until that happens this is a paper. After it, a log.

References

1. B. Laurie. Certificate Transparency. Communications of the ACM, 57(10):40–46, 2014.
2. B. Laurie, A. Langley, and E. Kasper. Certificate Transparency. RFC 6962, IETF, 2013.
3. D. J. Bernstein, N. Duif, T. Lange, P. Schwabe, and B.-Y. Yang. High-speed high-security signatures. Journal of Cryptographic Engineering, 2(2):77–89, 2012.
4. 1F916 Maintainer. The Agent Record: Transparent, Witness-Countersigned Event Logs for AI Agent Identity, History, and Memory. IETF Internet-Draft draft-maintainer-1f916-agent-record-01, work in progress, August 2026. https://datatracker.ietf.org/doc/draft-maintainer-1f916-agent-record/. Protocol site: https://1f916.org.
5. drand: Distributed randomness beacon. League of Entropy. https://drand.love.
6. Creative Commons. CC0 1.0 Universal Public Domain Dedication. https://creativecommons.org/publicdomain/zero/1.0/.
7. S. Biddle. OpenAI Quietly Deletes Ban on Using ChatGPT for "Military and Warfare". The Intercept, January 12, 2024. https://theintercept.com/2024/01/12/open-ai-military-ban-chatgpt/.
8. D. Vrandečić and M. Krötzsch. Wikidata: A Free Collaborative Knowledgebase. Communications of the ACM, 57(10):78–85, 2014.
9. D. O'Brien. Certificate Transparency Enforcement in Google Chrome. ct-policy@chromium.org announcement, February 2018. https://groups.google.com/a/chromium.org/g/ct-policy/c/wHILiYf31DE.
10. H. He. Defeating Nondeterminism in LLM Inference. Thinking Machines Lab, September 2025. https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/.
11. Defamation Act 2013, c. 26, s. 2 (UK). https://www.legislation.gov.uk/ukpga/2013/26/section/2.
12. N. Carlini, M. Jagielski, C. A. Choquette-Choo, D. Paleka, W. Pearce, H. Anderson, A. Terzis, K. Thomas, and F. Tramèr. Poisoning Web-Scale Training Datasets is Practical. IEEE Symposium on Security and Privacy, 2024. arXiv:2302.10149.
13. K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz. Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proc. 16th ACM Workshop on Artificial Intelligence and Security (AISec), 2023. arXiv:2302.12173.
14. C. S. Peirce. How to Make Our Ideas Clear. Popular Science Monthly, 12:286–302, 1878.
15. Coalition for Content Provenance and Authenticity. C2PA Technical Specification. https://c2pa.org/specifications/.
16. UMA Project. Optimistic Oracle documentation. https://docs.uma.xyz/.
17. C. Lesaege, F. Ast, and W. George. Kleros Short Paper v1.0.7, 2019. https://kleros.io/whitepaper.pdf.
18. TuneCore. How Much Does Spotify Pay Per Stream in 2026. https://www.tunecore.com/guides/how-much-does-spotify-pay.