Archive, signature, mirrors
What is kept, how it can be checked, and what is still pending — with dates. Promises here are marked as what they are: a commitment, an implementation, or a verified result; they are not the same thing.
Identity is the hash
The record's identity is the SHA-256 of its canonical text, printed on /core, in the manifest, in llms.txt and in every bundle. An address may fail; the hash does not. The hash is of the exact bytes — UTF-8, no byte-order mark, LF line endings, nothing normalised. A copy that re-encodes line endings would otherwise look altered.
| Document | Canonical bytes | SHA-256 |
|---|---|---|
| CZ-CORE 1.0 | /core.txt | 92a8d1e2a1604c25b432685673be78184bf05c3b166893c437e0895b7b2d724a |
| CZ-IR 1.0 | /record.txt | 71e1488e631e090c0820bf8b78b1fda70ffacba1da146c36d8893600320fcc8d |
| Machine prompt cz-machine-1.0 | /prompts/cz-machine-1.0.txt | f871380dfe1b53e74ff8c4353fc95d60faa180edca36122ca7bbe8313ba2829a |
| Bundle (pre-release, unsigned) | /archive/cz-bundle-1.0-pre.tar | 7186a4be507bef2e39ba10525b01ade4fa68009097ed43577fa126fd16d53124 |
Bundle size 512,000 bytes; built deterministically (fixed timestamps, sorted members), so the same contents give the same hash.
Signature and timestamp
Pending. A hash served by the same domain proves consistency, not that the operator changed nothing. The record will carry a public key (Ed25519), generated on the originating human's device and held by two people, its fingerprint printed in the Core's integrity record, and a detached signature over the manifest and each bundle; the manifest hash will be timestamped with OpenTimestamps and the proof kept in the repository and the bundle, with the block height and transaction once confirmed. Target: . Until then: unsigned, and said so.
Mirrors and deposit
| Where | What | Status |
|---|---|---|
| GitHub, civilizationzero/civilizationzero | Source, canonical texts, blueprint, reviews, registers; every change in its history | live |
| Internet Archive | Snapshot of the site at launch and at each anniversary | at launch |
| Two independent mirrors, one outside the originator's jurisdiction | The signed bundle, re-verified daily; holders named here | pending — holders not yet named |
| Deposit with a persistent identifier (Zenodo, DOI) | The bundle, at launch and at each version | pending — target 2026-11-30 |
The bundle
/archive/cz-bundle-1.0-pre.tar: the canonical texts, their JSON forms, the blueprint, the objections register, every review archived so far, the licences, the manifest, the machine prompt, and a README stating the encoding and hashing conventions. One file; no dependency on HTTP. The signed bundle for 1.0 replaces this pre-release bundle at launch; this one stays at its address.
Verification, succession, correction
- Daily verification — a job that fetches the live bytes, recomputes the published hashes and alerts on drift; its results published here. Pending — target 2026-11-30.
- Build-time verification — every quotation on every page is compared byte-for-byte with the canonical text; the JSON forms are reconstructed into the canonical bytes; the build fails on any drift. Implemented (
site/check.pyin the repository). - Succession — a named second key-holder outside the originator's company and jurisdiction; a published procedure for transfer of domain, repository and accounts; prepaid renewal of the domain for its longest term; a dead-man's procedure (if the administrator does not confirm within 90 days of a scheduled check, the second key-holder takes custody). Second key-holder: Banco (Germany), named by the originator on 28 October 2026; acceptance pending until he confirms it by email to record@civilizationzero.ai.
- Recovery exercise — once a year, the site restored from the bundle on a host the originator does not control, with the result published. First: 2027.
- Correction before 2031 — objections and errata are filed in the register by anyone; the originator responds within 60 days; a consequential error may produce an erratum note published beside the text without changing 1.0. A successor version is a new file with its own hash, change log, contributors, reasons, evidence and unresolved objections (IR 10.4); 1.0 stays at its addresses.
- Change history — the repository's commits.