Owns: studbook/ Must not touch: TRVM/forge/ (substrate — consume it, never reimplement it), RRABBIT/m2/, root *.md.
## ❌ BLOCKED. Do not write schema until two things are ruled 1. studbook §10.5 — does the identity ladder admit a new prefix? A studbook record is not a
sem-,scen-orreplay-. If the answer is no, studbook is keyed by something else and the schema changes shape. 2. The index question (CONFIDENTIALITY.md§4) — accept, minimise, or encrypt the operator-visible graph. This decides what columns exist. Both are [TRAVIS]. Reading, and the prolly-tree finding below, can proceed meanwhile.
studbook/docs/spec/README.md — the whole spec. Its header says *"draft spec. No
implementation. Nothing in §7 or §10 has been ruled. Do not build from this yet."* That still holds for §7 and §10.
PUBLISH_PATH.md — studbook's first named consumer.
CONFIDENTIALITY.md — §4 is the tension that decides the schema.
STACK_HUB.md §0.8 — why Postgres is right for the index and catastrophic for the bytes.
"A record in studbook carries where it came from, and a record that cannot show its provenance is refused rather than stored."
Supabase is abandoned (2026-07-30). studbook replaces it. Nothing migrates until studbook
holds the same data with the same guarantees — fleet.* serves KILN and FleetPrompt today.
Postgres is the index, R2 holds the bytes. Measured: bytes in Postgres is 18.7× R2 and
puts every tier underwater — a 10 TB customer would cost $2,867/month. The same customer's index is ~250 MB, or seven cents.
This does not reverse §2. §2 rejected Postgres as the data model — a row does not say why it
is that row. As an index over content-addressed blobs, the refusal still comes from content addressing and Postgres only makes it queryable. Never describe this as "studbook moved back to Postgres."
Postgres lives on the Hetzner VM (lane C), managed by Pigsty, shared with nothing that has a
user's bytes in it.
Enterprise clients get their own VM and their own database. Single-tenant, which sidesteps
§10.2 for them entirely.
studbook §4: "If studbook reimplements something substrate already proves, that is a finding, not a shortcut." TRVM/forge/ already ships, with batteries:
| Capability | Where | Guarantee |
|---|---|---|
| Content-addressed store | wrl_store.py _ContentStore | key is sha(bytes); WRL_STORE_ID_MISMATCH |
| Verified read | _get_bytes | re-hashes every read; WRL_STORE_CORRUPT |
| Durable atomic write | _atomic_write | temp → fsync → os.replace → dir fsync |
| Optimistic concurrency | wrl_project.py | per-document exact-CAS, WRL_PROJECT_STALE, no auto-merge |
| Verified export/import | wrl_bundle.py | closure, identity re-derivation, corruption |
| Crash recovery | RecoveryJournalV1 | atomic, non-authoritative, never auto-applied |
The index schema. Records, ancestry edges, chunk manifests. Per CONFIDENTIALITY.md §4
option 2 (recommended): opaque ids, sizes and edges — no names, no paths. A manifest does not need to know a file is called taxes-2026.pdf to say which chunks compose it, and the human-readable fields are exactly the leaky ones.
The three queries that justify the whole thing (studbook §4): given a record, its ancestry;
given two states, what changed; given a claim, the evidence chain, every link re-derivable.
The R2 adapter. RRABBIT/m2/trackstore.js is the shape to follow — *the store is never
trusted, every read re-derives the hash.* Do not weaken that.
The parity gate before anything migrates: same reads, same refusals, side by side with
Supabase still up.
§7.3 proposes a prolly tree for §6.1's index gap and calls itself "a reading task before it is a build task." But STACK_HUB.md §0.8 argues Postgres may simply be the answer — ordered access and range scans today, at the cost of history-independence and cheap subtree diff.
Produce a written finding on which trade is right. That is a real deliverable and it needs no ruling. Do not start building a prolly tree.
**A track records a live OS world, not a sealed sem- world.** Conflating them is the plan's
R9 and it fails quietly — WRLM's passing test counts would appear to back OS-world claims they do not touch.
Convergent encryption is refused by name. Deriving the key from the plaintext restores
cross-user dedup and looks like free money; it also restores the confirmation-of-a-file attack §6.2 identified. Per-user dedup has none of this and is where the saving is.
studbook §9's non-goals are load-bearing. Not a general database, not a SQLite competitor, not
a new identity rung without §10.5. A hub asking for joins is not a reason to relax them.
`studbook/` is a local-only git repo with no remote. Commits survive; pushes have nowhere to
go. Do not assume it is backed up.
Travis said on 2026-08-15 that studbook runs on Fly with a site at studbook.computedriven.com.
Five checks found neither — no DNS record, no HTTP response, no Fly app, no source in tree. Recorded in PUBLISH_PATH.md §6 and still unresolved. Do not assume a deployment exists.