Preservation Architecture
§R1 Objective
The lock decides when the vault may be opened. Preservation decides whether there is anything left to open. For a future reader to read anything, four things must survive, in order: the bytes; the means of finding them; the means of interpreting them; and the ability to open them. Success at one stage promises nothing about the next. This document covers the first three. It follows the vocabulary of the OAIS reference model (ISO 14721) where that helps and ignores it where it does not.
The objective is eventual recovery, whole or in part — not continuous availability. A vault that is offline for a century and then found is a success. No numerical survival probability to 2400 is offered, because nobody has the data to compute one. What is offered instead is a design in which every ordinary failure is survivable and the arithmetic of each is shown. It is a design: no capsule has yet been sealed and no copy placed, and Status will say when that changes.
§R2 Capsules
The archive is packed into 101 capsules. A capsule is a meaningful group of records — a decade of journals, a body of correspondence, a project — assembled as a BagIt bag (RFC 8493): a directory of payload files with a manifest of per-file SHA-256 digests, a human-readable description, and the context needed to interpret what is inside. The bag is serialised as a POSIX pax archive and encrypted under profile AB-E1 (Sealing §S6).
Three rules keep a capsule legible to a stranger:
- Every capsule stands alone. There is no central catalogue whose loss would orphan the rest. Each capsule’s header names its ring, its lock, and its own parameters.
- No compression layer. Files are stored in durable formats chosen from the Library of Congress Recommended Formats Statement — plain UTF-8 text, PDF/A, PNG and TIFF, FLAC, CSV — most of which are already compressed. A solid compressed stream would turn one damaged byte into a lost capsule.
- Damage stays local. Encryption is in independent 1 MiB chunks. A capsule with a hole in it yields every chunk around the hole, and the bag manifest says which files those chunks belong to.
§R3 101 × 88
Each encrypted capsule is split by a Reed–Solomon erasure code — profile AB-S1 — into 88 shards, any 60 of which rebuild it. 101 × 88 = 8,888: one shard for every photograph in the founding collection.
The code is applied to ciphertext, so shards can be checked, repaired and re-generated by custodians who hold no key. It supplies redundancy only. It is not secret sharing, and it is not meant to be: because the code is systematic, each of the first sixty shards is a run of whole encrypted chunks. A reader who finds only eleven shards of a capsule cannot rebuild the capsule, but can still decrypt — once the lock has yielded — every chunk in whichever of those eleven are data shards. Fragments are worth having, and the format is arranged so that they are usable.
Each shard file is a 136-byte header followed by its slice, so that any single shard identifies the vault, the capsule and the lock it belongs to, and carries the sealed key:
| Bytes | Field |
|---|---|
| 0–3 | “AB8S” |
| 4, 5 | profile version (1); reserved, zero |
| 6–7 | capsule number |
| 8 | shard number, 1–88 |
| 9, 10, 11 | k (60); n (88); reserved, zero |
| 12–19 | length of this shard’s slice |
| 20–27 | length of the capsule ciphertext |
| 28–91 | the capsule’s header core |
| 92–131 | the sealed key Wc, or zero for the Remainder |
| 132–135 | CRC-32 of bytes 0–131 |
A shard’s digest is the SHA-256 of the whole file, header included. Digests live outside the shards — in the capsule inventory and in the photographs — which avoids a header that must contain its own hash. The capsule inventory is a plain text file, signed at the ceremony: capsule number, ring, header core, sealed key, ciphertext length, lock digest, and for each of the 88 shards its length and its SHA-256 and SHA3-256.
Shard s of capsule c is paired with photograph i = (s − 1) · 101 + c. The stride of 101 spreads every capsule evenly across the chronological sequence, so any 101 consecutive photographs carry one record for every capsule, and with it the sealed key of every capsule that has one (Photographs §E2).
If shards within one copy fail independently with probability q, a capsule is lost from that copy when more than 28 of its 88 fail:
| Shard loss q | P(a given capsule is lost) | P(any of the 101 is lost) |
|---|---|---|
| 10% | 4 × 10−9 | 4 × 10−7 |
| 20% | 0.3% | 26% |
| 25% | 5.8% | 99.8% |
| 30%, one copy | 31% | ≈ 100% |
| 30%, two copies pooled | 3 × 10−10 | 3 × 10−8 |
The table says two things. Within a copy, the code shrugs off scattered decay and then fails abruptly — a cliff, not a slope, somewhere past one shard in five. And a second independent copy moves the cliff out of sight, because a shard is only gone when it is gone everywhere. Real losses are not independent: a custodian fails and takes a whole copy with it. Coding is the defence against rot; replication across unlike custodians is the defence against history.
§R4 Copies and custody
A replica is all 8,888 shard files plus the bootstrap kit (§R5). The design target is eight replicas across at least four of these five custody classes, chosen for unlike ways of failing:
- Commercial object storage, under at least three legal jurisdictions. Cheap, convenient, and gone the month the invoices stop.
- Research and memory institutions — repositories whose mission is measured in decades and whose failure mode is reorganisation rather than bankruptcy.
- Content-addressed public networks, where a copy persists as long as anyone at all finds it worth pinning.
- Cold physical deposits on media that need no power and no vendor (§R5).
- The artwork itself. The carriers and the bootstrap kit travel with exhibited and collected copies of The 8 Museum. Art is kept for reasons that have nothing to do with data, which is exactly the point.
A custodian is counted when it has returned a fixity report, not when it has been paid. The deposit register records each copy with its evidence; exact locations of physical deposits are held in the sealed locations manifest (Locations).
§R5 Cold media and the bootstrap kit
Bulk shards go to whatever archival media are current — at the time of writing, inorganic write-once optical discs and photosensitive archival film of the kind deposited in the Arctic World Archive on Svalbard. Makers’ lifetimes for these run from a century to a millennium. They are makers’ claims. The design relies on the media being different, not on any of them being right.
The bootstrap kit is what lets a stranger begin. It is small, and wherever possible it is readable with a lens and no electricity — printed on archival film and on fired ceramic of the kind held by Memory of Mankind at Hallstatt. It contains:
- this manual, as plain text;
- the lock file: n, the waypoint exponents, the arrival checks, the lock digest — and the milestones, or where space is short, their digest;
- the capsule inventories and the carrier catalogue, or their digests where space is short;
- the reference implementation, as source text short enough to retype;
- the public texts of every standard the vault depends on (§R9);
- a description, in pictures, of how bytes are written as marks.
§R6 Fixity, repair, migration
Once a year each custodian hashes every shard it holds under SHA-256 and SHA3-256, compares against the inventory, and reports. A failed shard is regenerated from any 60 healthy ones of the same capsule, or copied from another replica. The report is filed whether or not anything failed; a custodian that stops reporting is treated as lost and replaced.
Migration means copying bytes to new media. It never means re-encrypting — nobody can — and it never means transcoding a carrier. Wrapping old ciphertext in a newer cipher would add nothing: the old ciphertext is already public and cannot be recalled. The vault’s cryptography is fixed on the day it is sealed, and its custodians are asked only to keep bytes, count them, and pass them on.
§R7 Authenticity
A future reader must be able to tell the vault from an imitation of it. Three anchors are provided. They are not wholly independent — the signature’s public key is itself vouched for by the other two — but each fails differently.
The maker’s signature. The lock file, the 101 capsule inventories and the carrier catalogue are signed at the ceremony under SLH-DSA-SHA2-256s (FIPS 205) — a stateless hash-based scheme whose security rests on nothing but the hash function — and, for present-day convenience, under Ed25519. The keys are generated on the ceremony machine, the public halves leave with the outputs, and the private halves are destroyed with everything else. A signing key that existed for one afternoon, on one machine, cannot be stolen, coerced or inherited; what vouches for the public key is what vouches for the ceremony — the witnesses’ attestations, the timestamps, and every bootstrap kit. One signature is 29,792 bytes, which nobody will mind.
Independent time. The digests of everything signed are committed to OpenTimestamps, which anchors them in the Bitcoin chain by hashing alone, deposited with web archives, and printed wherever print will have them. Hash-chained and widely witnessed records keep their force whatever becomes of signature schemes. RFC 3161 timestamps are taken too, for present-day convenience, in the knowledge that they are themselves signatures and will be forgeable on the day the capability door opens.
The photographs. Every carrier holds the SHA-256 of its shard. Once the carriers circulate, eight thousand widely copied artworks amount to a distributed integrity catalogue that no single party can quietly rewrite. A record in a single photograph proves nothing by itself — it is protected against damage, not forgery — but thousands of independent copies that agree are hard to argue with.
After the ceremony nothing new can be signed in the maker’s name. Custodians sign their own reports with their own keys, and the custody log records who vouched for what, and when.
§R8 Stewardship
The maker is the first steward and will not be the last. The design assumes that every institution fails eventually, including any set up for this purpose, and so it asks little of any one of them: keep bytes, hash them yearly, hand them on, and — for those who wish — run a leg of the relay. None of these tasks requires a secret, and none can damage the vault if done badly by one custodian among several.
A stewardship fund is intended, to pay for storage, audits and relay hardware. The architecture is arranged so that the fund’s failure slows the relay and thins the copies rather than ending anything. Succession and funding arrangements will be recorded in Status as they are made, with their evidence.
§R9 What the vault depends on
Every algorithm and format named in this manual is an open, published standard that can be reimplemented from its text:
The kit carries the public texts. A reader who has lost all of them and the kit besides has larger problems than this vault, but the mathematics will still be true when they get to it.
§R10 Residual risk
What remains is loss without witnesses: every copy failing quietly within one generation’s inattention, with nobody left who knew there was anything to keep. No architecture defends against being forgotten. The defence is the work itself — the photographs, the museum, this manual, the oddity of the thing — which has to be interesting enough that someone, in each century, would rather keep it than not.