Deep research brief: a tape tier for a blind, agent-native federated archive¶

Status: Historical record

The research brief for the three-site LTO-10 tier. Its retired capacity figures are marked in place.

Audience: an external research agent with web access and no access to our internal documents. Deliverable: evidence, with citations, on the questions below — in the order given, which is the order of how much rests on them. Where the evidence does not exist, say so explicitly; "nobody has measured this" is a finding we will act on.

1. The system, and why standard storage answers do not apply¶

We are designing a durable archive for a federation of roughly 50 independent institutions in a single US state (universities, hospitals, health systems), connected by a state-owned open-access middle-mile network with a 100 Gb/s core. It holds clinical and biomedical corpora under data-use agreements, plus the derived artefacts of medical language-model work: tokenised shards, embeddings, resampled imaging, filtered cohorts, feature tables, model checkpoints.

A proposal under review would add a tape tier of three sites, each with three LTO-10 full-height SAS drives and about 100 licensed slots, 7.20 PB of media holding 4.2 PB logical at the adopted 1.714× combined coding rate — 240 cartridges, 80 per site, 84 of 100 slots occupied, 16 free slots per site (CORRECTED 2026-09-19 from "roughly 8.4 PB of media" / "~94 cartridges per site" / "roughly two free slots per site"; the bill of materials of record is SPECIFICATION.md §14.3), for approximately $368k of capital against a ten-year horizon. We are trying to work out whether that proposal is sound, what it should be instead, and which numbers in it are load-bearing but unmeasured.

Six constraints make most published storage guidance inapplicable. Please hold all six simultaneously when answering; answers that quietly relax one are the failure mode we are trying to avoid.

(a) Holding sites are blind. Data is encrypted at the providing institution with that institution's keys, then chunked and erasure-coded. A holding site stores ciphertext fragments and has no key. Key custody is Shamir t-of-n deliberately spread across institutions that are not the holder, so a fully compromised site can neither read what it holds nor destroy it. Anything that requires the storage site to interpret content — tiering by content, indexing, deduplication against plaintext, predicate evaluation, min/max statistics, record framing — is not merely unimplemented, it is excluded by construction.

(b) The conserved resource is drive time, not capacity. Nine drives is the whole plant. A mount is 60–120 s; serpentine repositioning within a cartridge is reported at 20–60 s and, on a scattered read, dominates mount cost. Capacity is cheap and bounded; drive-seconds are the thing every workload competes for. Consequently $/TB stored is close to a meaningless metric for us and $/TB read, or per-drive-hour, is the real one.

(c) The consumers are autonomous agents, not people. They declare deadlines, fan out, retry, and issue orders of magnitude more requests than human users. Volume carries no anomaly signal. We deliberately do not offer a latency SLO on cold data: a cache miss is a scheduling event, and "no, but at 03:00, and here is your queue position" is an acceptable answer. The design of record therefore leans on declared future demand (a standing intent with a coalescing key) rather than on reactive request queues.

(d) Fifty participants, three failure domains. Erasure width is capped by failure domains, not by participants: a stripe cannot place two fragments in one domain. Nine libraries would support 6+3 surviving three whole domains; three sites support at most one site loss at any width, and the arithmetic floor for surviving one of three is a 1.5× coding rate. The proposal concedes "at n=3 a single-level global code has zero margin".

(e) The tier is monotonic. WORM media is wanted for drive-enforced immutability (it is what makes an immutability API more than a software promise, and it is the backstop against a compromised operator). On WORM there is no delete: reclamation is a whole-cartridge rewrite plus physical destruction of the original, and garbage collection on the tape tier is off by default. Separately, a citation that pins a small sample of a dataset pins most of the packing units it touches (a 0.1% uniform sample of chunks pins ~64% of 1024-chunk packing units), so retention-class grouping — the one mechanism that lets a cartridge expire as a unit — degrades badly once anything is cited.

(f) Consent withdrawal is executed by destroying a key. Redaction is crypto-shredding: destroy the redaction domain's key and the plaintext is gone everywhere, including on media that cannot be erased. The corollary is severe: anything plaintext-derived that is written in the clear to unerasable media is permanent and is outside the reach of withdrawal — a cartridge catalogue of object names, per-column min/max statistics, distinct-value sketches, record lengths, or plaintext digests would each survive the erasure they document, for the 10–30 year life of the medium.

What is already measured here (do not re-derive, but do challenge)¶

Content-defined chunking versus fixed-size chunking on our own corpora: +99.75% sharing under a 0.1% prepend, +49.85% under a middle insertion, but −0.1% on append and −5.04% on scattered in-place overwrite. On real source-code history, CDC bought 0.8% over plain whole-file reuse (zero in three of eight version pairs). Chunk density measured at 17,000–27,000 chunks per GiB.
Checkpoint-to-checkpoint sharing on real model weights is unmeasured (our large-file test base was pseudo-random, so it measured boundary recovery, not weight similarity).
Our design of record asserts that agent-produced derivatives will dominate the object population at 10–100× the source corpus per year, with a useful life of days. That assertion is not measured either.

2. Research questions¶

Standing instructions for every question. (1) Prefer measured operational data to vendor claims, and label which you have. (2) Name operators, systems, dates and numbers, not categories. (3) Actively seek negative results: approaches that were built and abandoned, products withdrawn, features deprecated, consortia that dissolved, papers whose follow-up never appeared. An approach that three operators tried and dropped is worth more to us than one that looks good on paper. (4) Where you find nothing, say "no evidence found" and describe what you searched — that is a result. (5) The prior art named below is from memory and may be imprecise in name, author or date; verify before relying on it, and tell us where we have mis-named something.

What we need to know. The proposal puts a compute node beside each tape library that applies a predicate to the read stream as bytes come off the drive and emits only matches, requiring the on-media container format to carry column-group offsets, per-group statistics (min/max, null counts, distinct sketches), a recorded sort order and self-delimiting record framing. Every one of those inputs is plaintext structure, at a site that holds only ciphertext under per-chunk authenticated encryption. We need to know: (i) whether any deployed system evaluates useful predicates over ciphertext at a party with no key, at a cost below shipping the data; (ii) what the leakage cost of the candidate mechanisms actually is on low-cardinality clinical columns; (iii) whether attested-enclave key release is a real option across independent institutions, or only within one operator; (iv) what an honest "ciphertext-side only" filter can achieve using non-content metadata (retention bucket, key epoch, fragment length, physical position).

What we currently believe, and why. We believe library-local pushdown as specified is unreachable, and that the correct locus for filtering is a party that legitimately holds keys — the providing institution, or a designated compute locus granted a custody quorum. We also believe the consequence is expensive rather than fatal: pushdown never reduced mounts or drive-hours (the proposal says so itself), so removing it costs nothing in the drive-time model and everything in the wide-area model — every selective read then ships a full k-of-n fragment set to a permitted decode locus. Our federation-wide daily network budget is of order 10² TB/day shared by all purposes. ~~our own estimate of the plant's delivery rate lands at the same order (~98 TB/day), so the two constraints bind simultaneously.~~ CORRECTED 2026-09-19: the two constraints bind simultaneously only on a clustered workload — measured plant delivery is 126.2 TB/day clustered against that budget, but 33.3 TB/day scattered, where the plant binds about 3× before the network does (eval/results/plant_contention.json). Removing pushdown still costs nothing in drive-time, and that conclusion is unaffected; the claim that network and plant are co-equal constraints holds only on the clustered side of a 3.8× range.

What would change our decision. Evidence that a blind party can evaluate range or equality predicates over per-chunk-AEAD ciphertext at below the cost of shipping it, with quantified leakage acceptable for clinical data, would restore the pushdown case and with it the argument for ~200 GB containers and the current format spec. Evidence that attested enclaves have been operated across genuinely independent institutions (not one cloud's regions) would open a second route. Absence of both tells us to delete the pushdown section, delete the plaintext-derived statistics from the on-media format, and re-derive container size from mount economics alone.

Where to look. Searchable symmetric encryption and its leakage-abuse literature — Curtmola et al. (2006); Cash et al. dynamic SSE; Islam–Kuzu–Kantarcioglu (NDSS 2012); Cash–Grubbs–Perry–Ristenpart (CCS 2015); Grubbs et al. "Pump up the volume" (IEEE S&P 2018); Kellaris–Kollios–Nissim–O'Neill on range-query reconstruction (CCS 2016). Property-preserving encryption and its refutation — Boldyreva OPE/ORE; Naveed–Kamara–Wright, "Inference attacks on property-preserving encrypted databases" (CCS 2015), which is specifically about clinical columns. Systems: CryptDB (SOSP 2011) and its critics, Microsoft Always Encrypted, MongoDB Queryable Encryption. Enclave-side filtering: VC3, Opaque (NSDI 2017), EnclaveDB, Ryoan, plus the SGX/TDX attack literature (Foreshadow, SGAxe, plundervolt-class) and the Confidential Computing Consortium's own statements about multi-party attestation. Private information retrieval as the honest lower bound — SimplePIR/DoublePIR (Henzinger et al., 2023) and successors, for what access-pattern privacy actually costs. In-storage and storage-side filtering as a market: AWS S3 Select and Glacier Select (chase the deprecation notices and the reasons), Azure Blob query acceleration, SNIA's Computational Storage working group, NGD Systems, Samsung SmartSSD, ScaleFlux — who shipped, who withdrew, and why. And the alternative model, which is mature: DataSHIELD, vantage6 / Personal Health Train, OHDSI distributed studies, OpenSAFELY, UK Trusted Research Environments, the Five Safes framework, ONS Secure Research Service output checking — filtering where the key is, with disclosure control on the output.

Q2. Is a three-site tape tier defensible, and what is the smallest viable additional failure domain?¶

What we need to know. Three things. (i) What do large tape operators actually do about site count and redundancy — erasure coding across libraries, or n independent copies, and why? (ii) What is the smallest configuration that still constitutes a real failure domain (drives, slots, staffing, floor space, network), and what does it cost? (iii) At three sites with any code that survives one site loss, any two sites can jointly reconstruct all ciphertext — a 2-of-3 ciphertext-collusion threshold that is forced, not chosen. Is that acceptable practice anywhere for regulated clinical data, and how have others handled it?

What we currently believe, and why. We believe three sites is below the sensible minimum and that the site count, not the code, is the binding parameter. At three balanced sites the no-co-location placement rules admit only 1.5× and 3.0× coding rates — nothing in between — so the per-class rates the proposal wants (1.2×, 1.8×, 2.5×) are not constructible, and the 1.2× class cannot survive a site loss at all. A site loss is a ~47-day campaign on the six surviving drives — CORRECTED 2026-09-19: 6,763 drive-hours = 8.6 % of the plant-year (eval/results/plant_contention.json) — ~~with zero capacity for anything else~~, which conflated duration with drive-hours. Measured headroom in a rebuild year is 114.3 TB/day clustered, 30.2 TB/day scattered. The real exposure is what this brief already identified: seven weeks at zero global coding margin and no free slots, not contention for drives. (Read the two together: 8.6 % of a year is not spare capacity if it must be spent inside one seven-week window.) It remains the sole failure mode the proposal admits it cannot absorb. We also believe the most likely site-loss event over ten years is not fire or flood but an institution withdrawing at a budget cycle.

What would change our decision. A credible minimum-viable-site cost (say a 1–2 drive, 40–80 slot satellite at a fraction of $122,600) turns domain count into a budget line rather than a fixed three, and dissolves the margin problem without touching the code. Conversely, strong evidence that large operators deliberately concentrate into 2–3 sites with dual copies rather than spreading coding across many would push us to copy that instead.

Where to look. CERN Tape Archive (CTA, successor to CASTOR) — why CERN keeps multiple copies rather than erasure-coding across libraries; look for CHEP proceedings and EPJ Web of Conferences papers, and the Tape@CERN material. Fermilab Enstore, DESY/Fermilab/NDGF dCache, NERSC and ORNL HPSS deployments (HPSS User Forum slide decks publish real operational statistics). ECMWF's MARS archive and DKRZ. Commercial erasure-coded tape: Quantum ActiveScale Cold Storage (two-dimensional erasure coding across cartridges — the closest commercial analogue to what we propose, and we want to know how it actually behaves and who runs it at scale), Spectra Logic BlackPearl/Vail. Historical negative result: RAIT (Redundant Array of Independent Tapes), StorageTek/Oracle — it existed and effectively disappeared; find out why. For preservation-consortium practice and its failures: LOCKSS and CLOCKSS, MetaArchive, Chronopolis, DuraCloud, and the Digital Preservation Network (DPN), which collected member fees and dissolved in 2018 with a documented wind-down — that is the single most relevant negative result to our governance risk. For the collusion-threshold question: threshold custody in production (the DNSSEC root KSK ceremony as an operational model of multi-institution quorum; NIST's multi-party threshold cryptography programme, IR 8214 series).

Q3. What is the real cost unit on LTO-10, and what are its serpentine parameters?¶

What we need to know. (i) Published LTO-10 physical geometry: tape length, wrap count, channel count, linear density, high-speed search velocity, and measured average and worst-case reposition time between two random positions on a loaded cartridge. (ii) Whether LTO-10 implements speed matching over the same sustained-rate band as LTO-9 (an approximate 112 MB/s floor), because below it the drive backhitches. (iii) Measured bytes-transferred-per-mount distributions in production scientific archives, and measured drive utilisation. (iv) Whether IBM's Recommended Access Order (RAO) or equivalent locate-optimisation is available on LTO-10 and what it measurably buys.

What we currently believe, and why. The proposal's capacity model is 9 drives × 400 MB/s × 85%, and it contains no mount term and no reposition term at all, in a document whose own thesis sentence is that mount count is the primary constraint. Decomposed, that model is only achievable at roughly 408 GB transferred per mount; our own placement rules force a whole-container read to gather six symbols of ~33 GB each from six cartridges, which puts effective rate at ~127 MB/s per drive and plant output at ~36 PB/yr, not 96. Separately, our design of record states that mount count is not the unit — "on serpentine LTO it is under 1% of a scattered pass" — and makes the headline term sweep-adjusted drive-seconds. Both documents are probably right about different access patterns; neither carries both terms. At identical bytes-per-mount, we compute the difference between a contiguous and a fully scattered 405 GB read as roughly 14×, using a 40 s per-reposition figure inherited from LTO-8/9-class media.

What would change our decision. Real LTO-10 reposition numbers change the container-size decision, the clustering argument and the entire capacity model. A measured bytes-per-mount distribution from a production archive tells us whether the 85% assumption is a scheduling achievement or a fiction. If RAO or equivalent substantially flattens scatter cost, the clustering layer becomes much less valuable and a whole repack subsystem may be unnecessary.

Where to look. The LTO Program (HPE, IBM, Quantum) generation specifications and the published roadmap, including the compatibility statement for generation 10 and any statement about generation 11. Drive vendor SCSI reference manuals (they document Log Sense pages, TapeAlert and RAO). IBM's Recommended Access Order literature and any published benchmarks of its benefit. Academic serpentine modelling: Hillyer & Silberschatz, "Random I/O scheduling in online tertiary storage systems" (SIGMOD 1996) and their serpentine-drive performance-characterisation work (SIGMETRICS 1996); Sandstå & Midtstraum on serpentine access-time models (late 1990s). Operator telemetry: CTA drive-efficiency and archive-file-size distributions; HPSS User Forum mount statistics; ATLAS tape throughput reports. INSIC tape roadmap for the general "capacity rises, streaming rate does not" trend — note LTO-9 and LTO-10 are both 400 MB/s native while capacity rose 67%, so every whole-cartridge obligation got 67% longer in wall clock.

Q4. What is the actual demand — recall volume, and the derivative population?¶

What we need to know. (i) In comparable archives, what fraction of stored bytes is read per year, and what is the distribution of recall requests per user per year? (ii) Has any tape archive absorbed a machine-learning checkpoint/derivative population, and what happened to it? (iii) Is there measured data on checkpoint-to-checkpoint byte-level similarity for real model weights (not synthetic data)?

What we currently believe, and why. This is the parameter the economics turns on, and nobody has measured it for us. Our own arithmetic says the proposed plant supports roughly 180,000 whole-container reads per year, ~490/day, which across 50 institutions is about ten per institution per day. Meanwhile our design of record asserts derivatives at 10–100× the source corpus per year and explicitly refuses to put them on the archive tier: forcing even the residue of agent sessions onto permanent media prices out at 257 TB/day against a ~100 TB/day federation budget. Our measured chunking results say that exactly those populations — checkpoints, tokenised shards, embeddings — mutate by append and scattered overwrite, the two cases where content-defined chunking ties or loses, so cross-version sharing will not rescue their volume. A single 7B-parameter training run's checkpoint set (20 checkpoints of full resumable state, ~2 TB) costs perhaps $170 of tape against ~$17,500 of GPU time to recompute — a ratio of about 100:1 — which means no store-versus-recompute test denominated in money will ever say "do not store". The throttle has to be a hard quota on committed bytes per day, and our sustained budget over a ten-year horizon is roughly 1.0–1.15 TB/day federation-wide.

What would change our decision. Real read/write ratios and recall distributions decide whether the tier is demand-starved (in which case a third drive per site is cheap headroom and the cloud comparison tightens) or contended (in which case the scheduling questions below dominate).

~~Measured checkpoint similarity decides whether deduplication is worth its complexity at the content layer at all — and if it is not, per-object keys become affordable again, which would retire the hardest unsolved problem in our redaction design.~~

ANSWERED IN-HOUSE 2026-09-19 — DO NOT COMMISSION THIS. eval/results/ckpt_dedup_results.json, measured on a real SFT run (checkpoints every 500 steps, ~48 GB of tensors each) on an HPC compute node: adjacent weight checkpoints share 0 of 184,044 64 KiB blocks, distant 0, the two weight copies inside one checkpoint 0, cross-run control 0, optimizer state 0.0020 % excluding zero blocks. Deduplication is not worth its complexity at the content layer; per-object keys are the default; K_rdom is retired.

What we still want from the literature is the opposite question: published evidence of any archive that measured checkpoint similarity and found a different result, because a contradiction would be more valuable to us than a confirmation.

What replaces it as a brief: checkpoints can be neither deduplicated (measured here) nor recomputed — a NONDETERMINISTIC derivation may never be silently rebuilt, and unpinned floating-point reduction order makes most GPU training nondeterministic (ENTAIL-AGENT-NATIVE-FS.md §3.4 and §14; this brief contains no such statement, contrary to what STORAGE-DIRECTION.md previously attributed to it). So retention policy is the only remaining capacity lever and belongs in the research scope. Read it together with the adjacent finding in the paragraph above — no store-versus-recompute test denominated in money will ever say "do not store" (~$170 of tape against ~$17,500 of GPU) — which is the economic half of the same conclusion. The throttle remains a hard quota on committed bytes per day (~1.0–1.15 TB/day federation-wide).

Where to look. Published archive statistics: CERN CTA (total volume, annual read volume, repack volume), ECMWF MARS (unusually read-heavy, and closest in shape to an "agent" workload), NERSC/HPSS annual reports, DKRZ, NCAR, Fermilab. The ATLAS Data Carousel project, which deliberately measured what happens when you drive a tape archive at high read rates. For ML-checkpoint populations on archival storage: HPC centre reports on checkpoint volumes, the checkpoint-compression and checkpoint-deduplication literature (e.g. work on delta-compressing model checkpoints, LC-Checkpoint, Check-N-Run from Meta), and anything measuring byte-level similarity between successive training checkpoints. Also worth checking: whether any national lab has published an explicit policy refusing checkpoints on archival tape, and what they do instead.

Q5. WORM or rewritable — and does anyone actually operate a monotonic tape archive?¶

What we need to know. (i) Is LTO-10 WORM media available, at what price premium over rewritable, and does anyone use it at petabyte scale? (ii) How do operators of large tape archives actually reclaim space — what is measured repack cost, what live fraction do they see at reclaim, and how much of their plant does repack consume? (iii) How does regulated WORM immutability coexist with a legal right to erasure, in practice? Specifically, is cryptographic erasure accepted by regulators as erasure? (iv) Does retention-class cartridge grouping survive contact with real citation/pinning behaviour?

What we currently believe, and why. The proposal's layout section presumes reclaimable media: it justifies TTL bucketing by a factor-of-four reduction in repack volume and describes repack as "a continuous lowest-priority preemptible background workload". Our design of record says the opposite — on WORM, reclamation is a whole-cartridge rewrite: 20.8 drive-hours of read pass per 30 TB cartridge plus the write of the live fraction, so ~33 h at a ~60 % live fraction, which the measured basis CONFIRMS (eval/results/plant_contention.json, 2026-09-19); ~~~20 drive-hours at 18 TB~~ — the 18 TB LTO-9 basis is not the plant of record (240 × 30 TB = 7.20 PB media) and should not be quoted anywhere. Plant-wide: 1,537 drive-hours = 1.9 % of the plant-year at 85 % dead (15 % live); 5,124 = 6.5 % at 50 % dead. It consumes fresh media, it requires physically destroying the original, and GC is off by default. On that reading repack is not a background workload; it is a continuous cartridge purchase with an operator attending the mail slot. We also believe the TTL-bucketing argument is refuted by our own pin-amplification arithmetic: once a lineage is cited, no cartridge in it can expire as a unit again. And the per-site slot budget is tight — ~~roughly two free slots per site as the bill of materials is written (94 cartridges plus four cleaning cartridges in 100 licensed slots)~~ 16 free slots per site at the corrected bill of materials (80 data cartridges + 4 cleaning = 84 of 100). The finding stands and hardens at the corrected number: a site-loss rebuild must re-place 80 cartridges' worth of fragments onto surviving sites holding 16 free slots each, which is not possible. Recovery is procure-a-site, and procurement lead time is inside the repair window. (Corrected 2026-09-19 against SPECIFICATION.md §14.3. Note also that our reclamation belief is unchanged — a continuous cartridge purchase with an operator at the mail slot — and the drive-hour cost of repack is cheap; as sequential passes, obligations always are. What is expensive is retrieval.)

What would change our decision. If real operators run mixed pools (WORM for cited/retained classes, rewritable for churn) we should copy that partitioning and it changes cartridge counts and the consumable plan. If cryptographic erasure is not accepted as erasure by the relevant regulators, our whole redaction model needs a second mechanism. This decision must be made before media is bought, because it constrains cartridge cohorting.

Raised in priority 2026-09-19. With K_rdom retired in favour of per-object keys (eval/results/ckpt_dedup_results.json), key destruction is the sole erasure mechanism at every granularity, and the design has no second mechanism to fall back to — SPECIFICATION.md §11.1 calls it "the only forget" and retires fragment destruction for three independent reasons. The regulatory question is therefore a single point of failure for the whole governance story, not one input among several, and it remains a decision that must be taken before media is bought. No measurement bears on the regulatory question itself; this note raises its weight, it does not answer it.

Where to look. LTO WORM media availability and pricing from the three licensees. Reclamation in practice: IBM Spectrum Protect (TSM) collocation and reclamation documentation and field experience; HPSS repack; CERN's repack campaigns (they have migrated hundreds of petabytes between generations and have published the operational cost); Enstore migration. Regulatory: SEC Rule 17a-4 WORM requirements and the vendor market that grew around them (NetApp SnapLock, Dell EMC Centera — note Centera's end-of-life, a useful negative result about proprietary WORM stacks). For crypto-shredding as erasure: NIST SP 800-88 Rev. 1 (cryptographic erase), ISO/IEC 27040, EDPB/ICO guidance on whether key destruction constitutes erasure under GDPR, and any HIPAA/OCR equivalent. For pin amplification in practice, look at how research repositories handle "dataset citation pins a subset" — the RDA Working Group on Data Citation recommendations (Rauber et al., 2015) are implemented in several repositories and someone will have hit this.

Q6. Does declared-demand scheduling actually raise GB delivered per drive-hour? Does declared-demand scheduling actually raise tape drive utilisation?¶

RESTATED 2026-09-19. Utilisation is the wrong objective and is inverted (eval/results/plant_sim.json): the reactive plant shows higher drive occupancy precisely because it wastes drive-seconds on mounts — 115.0 (clustered) to 117.5 (scattered) drive-hours reactive against 12.2 batched, ordered and clustered, for the identical delivered bytes. Do not ask for utilisation percentages; they cannot distinguish a good plant from a bad one. The honest metric is GB per drive-hour: measured 68.1 reactive, 172.3 batched+ordered scattered, 653.3 batched+ordered clustered. Ask instead for measured bytes-per-mount distributions and GB per drive-hour, which Q3(iii) already requests.

Our mechanism belief below is HALF confirmed and half refuted — keep both. Confirmed: reactive, mount-on-arrival dispatch drives bytes-per-mount to the floor — 4.0 GB/mount reactive against 111.1 GB/mount batched and media-ordered. Refuted: that honouring deadlines forces that outcome. The harness's batched, ordered policy meets 8 h deadlines with 0 % late up to 156.3 TiB/day offered, breaking only at 312.5 (25.6 % late). At feasible load, coalescing and deadlines are not in conflict; EDF-under-overload remains the real hazard and remains unmeasured. Also confirmed: our suspicion that utilisation is mostly an output of demand, not an input a scheduler sets — payload fraction rises 46.5 % → 80.5 % purely with offered load.

~~The 70–85 % utilisation target, and the "nine drives reach 80 % only if ~77 PB/yr of demand exists" framing~~, are retired with the 96.5 PB/yr capacity model they rest on (§3 row 1).

What we need to know. Measured evidence for the claim that conventional archives sit at 15–30% drive utilisation because requests are reactive, and that converting to deadline-aware or batch-ahead scheduling raises it materially. Specifically: what is the measured relationship between coalescing-window width and mean bytes per mount, and what utilisation do the best-run archives actually achieve?

What we currently believe, and why. We believe the mechanism named in the proposal works against the result claimed. Earliest-deadline-first is a latency discipline: honouring an early deadline means mounting now rather than waiting to coalesce, which is precisely what drives bytes-per-mount down, and bytes-per-mount is what the 85% figure is made of. Our design of record reaches the opposite conclusion twice, calling tape scheduling an offline problem and naming "converting a batchable request into a scheduled one at the moment of claim" as the error that turns 10⁵ individually-optimal passes into a cartridge-exchange storm. We also believe the proposal's rule that admission control must reject, never delay, deletes the very mechanism (standing, coalescable demand) that its own economics depend on. And we suspect utilisation is mostly an output of demand, not an input a scheduler sets: nine drives reach 80% only if ~77 PB/yr of demand exists.

What would change our decision. Measured window-width-versus-bytes-per-mount curves would let us state the latency/throughput trade explicitly in the negotiation interface instead of asserting a number. Evidence that a production archive genuinely sustains 70–85% drive utilisation, and how, would validate the capacity model; evidence that nobody does would force us to re-size the plant against realistic duty.

Where to look. The ATLAS Data Carousel (Rucio-driven, tape-aware, batch-ahead — the closest production analogue to our "declare demand in advance" primitive; look for CHEP papers and the project's own reports). WLCG's retirement of SRM in favour of a minimal Tape REST API — an important negative result about binding reservations across sovereign sites. HPSS class-of-service and tape-ordered recall; Enstore's small-file aggregation; CTA's mount policies and request batching. Older negative results on cross-domain reservation: Globus GARA, SNAP/RSLAs, Maui advance reservations, and SHARP (SOSP 2003) — a delegatable hierarchical resource claim that did not stick because sites would not cede admission control to a foreign ticket. Also, for the underlying scheduling theory, the known degradation of EDF under overload versus FIFO (the domino effect) — relevant because a population in which every agent declares urgency is overload by construction.

Q7. Rateless versus MDS coding at k=6, and the physical layout of the intra-cartridge code¶

What we need to know. (i) The measured decoding-failure probability of RaptorQ (RFC 6330) at small K — specifically K′=10 — with exactly K symbols received, and at K+1 and K+2. (ii) The patent position of RaptorQ (Qualcomm, via Digital Fountain) today, and whether a permissively licensed implementation with interoperability test vectors exists that could be frozen on the media as part of the format spec. (iii) For an intra-cartridge code (proposed: Reed–Solomon 32+2 over 1 GB symbols), what is the empirical longitudinal extent distribution of post-ECC uncorrectable regions on LTO — centimetres or tens of metres? (iv) Does interleaving a stripe's symbols across longitudinal positions cost anything on a full-cartridge sequential pass?

What we currently believe, and why. We believe ratelessness is unjustified here and costs MDS exactness where we cannot afford it. The stated rationale — mint more symbols later as the federation grows — is available from plain Reed–Solomon over GF(2⁸) at any n up to 255 by computing extra parity at commit while the container is still cache-resident, which the design already does anyway. Against that, RaptorQ's published targets are on the order of 10⁻² decode failure at zero overhead, 10⁻⁴ at one extra symbol, 10⁻⁶ at two — and our geometry delivers exactly zero overhead (n−k=3 equals symbols per site, so a site loss leaves precisely k=6). At 10⁻², a site loss silently loses ~1% of 4.2 PB with every surviving cartridge in perfect condition. Plain LT at k=6 is worse still and the proposal says "LT/Raptor" without choosing. Separately, we believe the "2 GB tolerance per 34 GB stripe" claim for the intra-cartridge layer is true only when damage falls inside exactly two symbols; for a contiguous burst at arbitrary alignment the guaranteed tolerance is one symbol, 1 GB. And the proposal specifies the code but never specifies how symbols map to physical tape — which is the parameter that actually decides burst tolerance.

What would change our decision. A measured decode-failure probability below our per-stripe durability target at overhead 0 would keep ratelessness alive. An unencumbered, test-vectored implementation would keep the portability story intact. Real damage-extent data decides whether contiguous 32+2 is adequate or whether interleaving is mandatory — and if interleaving is free on a sequential pass, we will adopt it regardless.

Where to look. RFC 6330 and the Luby/Shokrollahi/Watson/Stockhammer line of papers, plus any independent measurement of RaptorQ failure probability at small K (implementations: openRQ, libRaptorQ — check their test suites for measured rates). Patent expiry: the Digital Fountain/Qualcomm filings are early-2000s and most should now be expired — verify with dates. MDS implementations for comparison: Intel ISA-L, Jerasure (Plank), Backblaze's open-source Reed–Solomon, Klaus Post's Go implementation. For why repair-bandwidth-optimal codes are the wrong objective on a mount-bound plant: regenerating/MSR codes (Dimakis et al.), Clay codes (FAST 2018), Azure LRC (Huang et al., USENIX ATC 2012), Facebook f4 (OSDI 2014), HDFS-Xorbas (VLDB 2013). For media damage: any published LTO error-extent or defect-geometry data, the T10 TapeAlert specification, LTO's own C1/C2 ECC structure, and CERN's tape media verification programme (they scan their whole archive and have published what they find).

Q8. Media and drive health without vendor lifecycle software¶

What we need to know. (i) Is there any published LTO cartridge and drive failure-rate dataset — the tape equivalent of Backblaze's disk statistics? (ii) What do operators actually use to distinguish a media fault from a drive fault, and does the "cartridge-by-drive error matrix" idea already exist in firmware? (iii) What scrub cadence do serious operators run, and how do they justify it? (iv) What is the real duty-cycle rating of an LTO-10 drive — not MTBF at nominal duty, but head and tape-path life at sustained streaming — and what do support contracts exclude?

What we currently believe, and why. We believe the proposal's media-health design (SCSI Log Sense per mount, TapeAlert on every unload, retry and reposition counts, and specifically the full cartridge-by-drive matrix rather than marginals) is the best operational engineering in the document and should be kept whatever happens to the rest. We also believe its scrub economics are wrong in a way that matters: full verification of 2.8 PB at 1.44 TB/hr is 81 drive-days, which is 11.1% of a two-drive site's 730 annual drive-days, not the 22% claimed (22.2% is 81/365 — one drive-year, mislabelled) — and the cadence that would make 22% correct is never stated. The third drive per site is justified entirely by that ratio. We suspect the better justification is background/retrieval concurrency, not scrub. We also do not know whether a drive run at 70–80% duty for ten years (about 70,000 motion-hours) is inside or outside its rating, and that is a real capital line.

What would change our decision. A duty-cycle rating and derating curve converts "drive replacement" from an omission into a budgeted line of $0–$378k over a decade. Published failure data would let us set scrub cadence from a durability model rather than from a round number. If firmware already computes the media-versus-drive discrimination we are proposing to build, we should use it.

Where to look. IBM's SARS (Statistical Analysis and Reporting System) in enterprise and LTO drives, which classifies media versus drive faults in firmware — we want to know exactly what it exposes and whether it is available outside IBM's software stack. Vendor SCSI reference manuals for Log Sense pages (including vendor-specific pages) and the T10 TapeAlert flag definitions. Spectra Logic's MLM/DLM (media and drive lifecycle management) databases and what their Quick PostScan actually costs in drive time per cartridge. CERN's media verification results and any HPSS-community media-error statistics. For duty cycle, the drive datasheets plus any next-business-day support contract terms that exclude high-duty operation.

Q9. Key custody over a citation horizon — the ten-year failure that is not media¶

What we need to know. (i) Prior art and production experience for threshold custody with resharing across independent institutions: proactive secret sharing, share refresh, membership change. (ii) Whether any research federation actually operates this, and what the ceremony and staffing cost is. (iii) What an escrow arrangement looks like that does not defeat the purpose.

What we currently believe, and why. We believe key rot, not media rot, is our ten-year failure mode, and it is not on the tape proposal's risk list at all. Our custody protocol today has no resharing, no share refresh and no membership-change handling; at n=12, t=7 and 5%/year irrecoverable share loss, roughly 34% of ten-year-old citations become undecryptable while the ciphertext sits in perfect condition on WORM. Every portability argument for the on-media format is worth nothing against that number.

What would change our decision. Evidence that proactive VSS with resharing is operationally practical across ~50 independent institutions (or that it is not, and what people do instead) determines whether the archive's real longevity investment goes into media and format or into custody. If the honest answer is "nobody does this across independent institutions", we need to know what the substitutes are — long-lived escrow custodians, HSM-backed institutional key services, or a smaller n.

Where to look. Proactive secret sharing — Herzberg et al. (CRYPTO 1995); PVSS (Schoenmakers); dynamic-committee resharing such as CHURP (CCS 2019). NIST's multi-party threshold cryptography project (IR 8214 series). Operational multi-party ceremonies that genuinely run: the DNSSEC root KSK ceremony (fully documented, audited, multi-institution, decades-long) is the best model we know of; also certificate-transparency log operator practice. Production MPC custody outside our domain (Fireblocks, Coinbase Custody, Unbound/Intel) for what ceremony and availability actually cost. And NIST SP 800-57/800-38D on key lifetime and rotation, since rotation across a decade-old citation is in direct tension with destroying a key to honour a withdrawal.

Q10. On-media format: raw SCSI versus LTFS, and what "portable" honestly means¶

What we need to know. (i) Real accounts of reading proprietary or custom tape formats after 10–20 years — successes and failures. (ii) What LTFS actually costs at scale (index rewrite per unmount, behaviour with high file counts) and whether operators who adopted it kept it. (iii) Whether anyone has published a tape format specification plus reference reader as a preservation artefact, and whether it was ever exercised.

What we currently believe, and why. We believe the portability claim as written is over-broad in two directions. It over-claims, because a cartridge whose catalogue is sealed (which blindness and consent-withdrawal both require) yields ciphertext fragments and physical positions and nothing else — the archive is rebuildable from media only in combination with an index journal snapshot and a custody quorum. And it under-claims what is actually valuable: that no vendor software is needed to get bytes off the medium, which justifies the raw-SCSI decision on its own. We also believe the reference reader must carry the decoder for whichever global code was used, which is a few hundred lines for Reed–Solomon over GF(2⁸) and thousands of lines plus embedded tables for RaptorQ — a second reason Q7 matters.

What would change our decision. Evidence that LTFS at our scale is workable would remove a build item. Evidence of custom formats going unreadable would raise the priority of the reference-reader deliverable and of the out-of-band artefact set (journal snapshot cadence, custody reshare epoch, format spec version) that a 2036 reader needs alongside the media.

Where to look. LTFS as a standard (ISO/IEC 20919) and IBM Spectrum Archive; operator accounts of LTFS at scale, including abandonment. Digital-preservation practice: OAIS (ISO 14721), PREMIS, BagIt (RFC 8493), and the national-archive migration literature; the long-running format-obsolescence debate (Rothenberg's original argument versus the empirical counter-evidence that formats rarely go unreadable while media and drives do). Historical formats and their fate: SAM-QFS, Amanda, Bacula/Bareos volume formats, Enstore's own on-media format. And the specific hard fact that shapes the schedule: LTO-10 broke backward compatibility (it reads and writes only its own generation), so the migration deadline is set by drive availability, not media rating — when the last working LTO-10 drive dies, every LTO-10 cartridge is unreadable regardless of a 30-year media rating.

Q11. The honest economics, and who pays in year four¶

What we need to know. (i) Current, real quotes and TCO models for three comparable alternatives at ~4 PB logical: (a) this three-site LTO build; (b) three-site nearline disk; (c) cloud deep archive, including egress, for a workload whose bytes must reach on-premises compute. (ii) Ten-year cost lines that vendor quotes omit: support renewal in years 4–10, drive replacement at real duty, the generational migration pass (drives, media, slots, and a period where two generations must be resident), and a staging tier. (iii) Governance and funding precedents for a shared service funded by three institutions and consumed by fifty.

What we currently believe, and why. We believe the headline "$86 per logical TB" is a year-zero purchase-order price presented against a ten-year plan, and that the ten-year hardware figure is roughly $194–$404 per logical TB-decade. We believe the cloud comparison, done honestly with egress, favours tape decisively at the assumed read rate — Glacier Deep Archive at list is about $119–$122 per TB-decade for storage, but marginal reads at $0.02–$0.05/GB egress are $20–$50/TB, which puts break-even at roughly 1.5–3.5 PB/yr of retrieval against a design point an order of magnitude higher — and that it favours cloud if real retrieval turns out to be 1–2 archive-reads per year (which is what "archive" usually means, and which Q4 will settle). We also believe cloud cannot serve the deadline-bearing lane at any price (Deep Archive restore is 12 h standard, 48 h bulk), and that one cloud region is one failure domain under one-fragment-per-domain. Against nearline disk at 4 PB, we believe tape does not win on cost or on power at this scale, and that the honest arguments for tape here are offline WORM immutability, media independence, and a failure domain no software defect or stolen credential can reach — none of which the proposal prices. Finally: a three-institution capital commitment creating a decade of non-capital obligation, serving forty-seven non-contributing institutions, is the standard failure mode of academic storage infrastructure, and institutional withdrawal is probably the most likely site-loss event in the register.

What would change our decision. Current HDD $/TB (if it has risen above roughly $30/TB the crossover moves materially), this institution's actual negotiated cloud egress rate, and any documented case of a regional research-storage consortium that sustained operating funds past its founding grant.

Where to look. Public price lists with dates (AWS Glacier Deep Archive and Direct Connect/data-transfer tiers, Azure Archive, Google Archive, Wasabi and Backblaze B2 and Cloudflare R2 for their explicitly different egress terms). Repatriation and exit accounts with real numbers (Dropbox's Magic Pocket, 37signals' cloud exit) — disk rather than tape, but the accounting method is what we want. Preservation-cost models: the 4C project and Curation Costs Exchange, the California Digital Library's Total Cost of Preservation work. Consortium precedents and their funding models: NSF's Open Storage Network, OSG/OSDF, TACC's Ranch and Corral, Great Plains Network, Internet2 and state research networks — and again DPN's dissolution as the documented failure. Commercial comparison: get a like-for-like quote shape for a three-site build with object gateway, lifecycle software and professional services included, since our build claims to be ~74% of such a quote by excluding exactly those items — which means the avoided purchase is on the order of $129k against a rebuild cost we estimate at 4–6 engineer-years.

3. Arithmetic we want independently checked¶

Recompute these from the stated inputs and tell us where you get a different answer. Inputs: 3 sites × 3 LTO-10 drives, 400 MB/s native per drive, 30 TB native per cartridge, 100 licensed slots per site, 4 cleaning cartridges per site occupying slots, 80 data cartridges per site (240 total), 7.20 PB installed media (CORRECTED 2026-09-19 from "~94 cartridges purchased per site, 8.46 PB installed media"; slot occupancy is 84 of 100, i.e. 16 free slots per site — SPECIFICATION.md §14.3), 4.2 PB logical, $122,600 per site.

#	Quantity	Our figure	Basis
1	Plant aggregate	~~12.96 TB/hr raw; 11.02 TB/hr at 85%; 96.5 PB/yr~~ RETIRED 2026-09-19. Raw tape-motion ceiling is an arithmetic ceiling, never achievable; delivered capacity is 11.9 PB/yr scattered to 45.0 PB/yr clustered after scrub and repack, and at most ~57 PB/yr clustered at the deepest load sustained without missing a deadline. The 85 % duty term is not a plant constant: measured payload fraction is 4.8 % reactive, 12.3 % scattered with batching and media-ordering, 46.5 % clustered at the simulated operating point, 80.5 % clustered at 156 TiB/day offered. Duty is an output of placement and queue depth, and this row assumed it as an input.	superseded by `eval/results/plant_sim.json` + `eval/results/plant_contention.json`. Unit trap, resolved: the same claim appears in the measurement harness as 101.2 PB/yr — the identical arithmetic in MiB/s rather than MB/s (9 × 400 MiB/s × 0.85 × 31.536 × 10⁶ s = 101.2 PB exactly). Both spellings are retired; quote neither. The plant has one capacity figure and it is a range set by clustering. Note that `SPECIFICATION.md` §14.1's 82.7 PB/yr is also a drives × duty-adjusted-rate × hours figure (≈1,047 GB/drive-hour against a measured best of 653 clustered and 172 scattered); it is a modelled ceiling, is labelled as one there, and must not be imported here as the reconciled basis. Every figure in this table is MODELLED or MEASURED and must say which. Note also that fragment bytes read is not bytes delivered to a consumer: the two differ by read amplification, a property of packing, and that factor is unmeasured.
2	Bytes per mount implied by an 85% duty at 180 s overhead	408 GB/mount, 1,200 s cycle, ~236,500 mounts/yr	eff(B)=B/(O+B/R), solved at 0.85R
3	Effective rate	~~126.6 MB/s per drive; plant 35.9 PB/yr~~ CORRECTED 2026-09-19. Measured, in the harness's own unit: 653.3 GB/drive-hour clustered, 172.3 scattered, 68.1 reactive (≈ 181–195, 48–51 and 19–20 MB/s; the harness's "GB" is ambiguous between 10⁹ and 2³⁰, so quote GB per drive-hour, not MB/s) — a 3.8× spread set by clustering at identical scheduling policy, and 9.4× for policy alone. The old row lands mid-range by accident: it understates the clustered case by ~30 % and overstates the scattered case by 2.6×. Symbol count per container is not the dominant term; placement is.	`eval/results/plant_sim.json`
4	Whole-container reads the plant can serve	~~~180,000 reads/yr ≈ 492/day ≈ 98 TB/day delivered~~ CORRECTED 2026-09-19: 126.2 TB/day clustered, 65.5 TB/day hot, 33.3 TB/day scattered, after an annual scrub and a repack at 85 % dead (15 % live). There is no single delivery figure for this plant; there is a 3.8× range whose position is chosen at write time by placement.	`eval/results/plant_contention.json` `headroom_after_scrub_and_repack`
5	Combined coding rate	~~1.7 × 1.0625 = 1.806×, not the stated 1.6× → 7.59 PB media, 253 cartridges~~ CORRECTED 2026-09-19: 1.714× — global RS(2,1) = 1.5× × local RS(28,4) = 1.1429× — → 7.20 PB media → 240 cartridges, 80 per site. `SPECIFICATION.md` §8.1 states in terms that "1.806× and 1.9125× do not appear anywhere in this document".	`SPECIFICATION.md` §3, §8.1, §14.3
6	The stated 6.7 PB / 224 cartridges	~~reproduces only from 1.5 × 1.0625 = 1.594×~~ — it is the adopted budget alternative: local RS(30,2) → 1.6× → 6.72 PB → 224 cartridges → 75/site (corrected 2026-09-19, `SPECIFICATION.md` §14.3)
7	Installed logical capacity	~~4.68 PB at 1.806×; 5.31 PB at 1.594×~~ 4.2 PB logical at 1.714× against 7.20 PB media (corrected 2026-09-19)
8	Site-loss rebuild	six surviving drives = 7.34 TB/hr; 5.6 PB read = 31.8 days; read+write 8.4 PB = 47.7 days at 100% dedication. MEASURED 2026-09-19: 6,763 drive-hours = 8.6 % of the plant-year (~47 days on six dedicated drives), leaving 114.3 TB/day clustered / 30.2 TB/day scattered across the rebuild year — the duration figure is confirmed, the "zero capacity for anything else" reading of it is not. Re-derive the byte totals at the corrected 7.20 PB installed media.	the document states ~3 weeks at 11 TB/hr, which is the nine-drive rate; measured basis `eval/results/plant_contention.json`
9	Generational migration	6.7 PB read = 25.3 days; read+write 13.4 PB = 50.7 days on one fleet, ~25 days only if two generations run concurrently
10	Full scrub	MEASURED 2026-09-19: 5,127 drive-hours for all 240 cartridges = 6.5 % of the 78,840 drive-hour plant-year, i.e. 1,709 drive-hours = 71.2 drive-days per site. The modelled 81.0 drive-days per site stands to within 14 %; its 11.1 % of a two-drive site-year is arithmetically correct but is a per-site denominator, and quoting it alongside the plant-year figure is what kept the burden looking ~1.7× larger than the resource the plant actually budgets. (Original basis retained: as-loaded 6.7 PB gives 64.6 drive-days; 22.2 % was the mislabelled one-drive-year figure this row exists to correct.)	`eval/results/plant_contention.json`; `SPECIFICATION.md` §14.4 uses the matching 3,285-drive-day = 78,840-drive-hour plant denominator
11	Cost per logical TB	$367,800/4,200 = $87.57 (stated $363,600 gives $86.57; a $4,200 discrepancy); $78.52 against 4.68 PB installed-logical
12	Time to fill at ~1 TB/day federation-wide	~~12.8 years at 1.806×; 14.5 years at 1.594×~~ recompute at 1.714× against 7.20 PB installed (corrected 2026-09-19; the retired rates are withdrawn, and the recomputation is left to the reviewer this table is addressed to rather than asserted here)
13	Cartridge fill time	50 sites at k=10: 0.1 TB/day/site → 300 days per 30 TB cartridge. 3 sites at 3-of-9 symbols: 0.5 TB/day/site → 60 days	concentration is a 3× improvement on cartridge economics — the strongest unstated argument for three sites
14	Cloud storage baseline	Deep Archive at $0.00099/GB-month ≈ $122/TB-decade; 4.2 PB for ten years ≈ $511k storage before egress
15	Pin amplification	0.1% sample of 1024-chunk units pins 64%; a 200 GB container at 64 KB chunks is ~3×10⁶ chunks, so any sample pins ~100%
16	Content fingerprinting from cleartext lengths (2026-09-19: applies to the metadata plane only; content is fixed-block, so its cleartext lengths carry no content-localisation entropy beyond one trailing remainder per object — `eval/results/cdc_largefile.json`, `SPECIFICATION.md` §3.1)	log₂(1 PB / 64 KB) = 33.8 bits; at ~4.6 bits of entropy per chunk-boundary spacing, 8 consecutive cleartext lengths localise a run of content in a petabyte corpus	which is why record framing and member lengths must stay inside the sealed header

4. What we are not asking¶

These are settled. Please do not spend effort re-arguing them; if you find evidence that overturns one, say so in a single paragraph and move on.

Tape versus "just use the cloud" as a philosophical question. We want numbers at our read rate, not a position. Likewise we are not interested in vendor-sponsored TCO white papers as evidence.
Encrypt-then-erasure-code at origin, with blind holders. This is a requirement, not a preference. Do not propose designs that give the storage site a key or plaintext — except as an explicitly labelled option in Q1, where we want it priced, not advocated.
Redaction by key destruction. We are not revisiting fragment destruction as a redaction mechanism; it is refuted (automatic repair regenerates destroyed fragments from survivors with no key and no approval, and the packing unit bundles hundreds of unrelated subjects).
The commit boundary. All parity, at every layer, is computed while the container is cache-resident, before first write to tape. Lazy parity would cost k mounts per stripe, recurring on every width change, class promotion and site addition. This is the best decision in the proposal and it stands.
A separate intra-cartridge parity layer. Repair that costs zero external mounts and zero wide-area bytes is the only repair this plant can afford. ~~The rate, the symbol size and the physical placement are open (Q7)~~; the existence of the layer is not. SETTLED 2026-09-19 by SPECIFICATION.md §3.2 and §8.1: systematic RS(j, 4), j ≤ 28, over 1 GiB parcels, contiguous within a band, local parity written at the end of the band (1.1429×), plain Reed–Solomon over GF(2⁸) and not RaptorQ. Q7's k = 6 framing is withdrawn — at three failure domains site tolerance is independent of k, so minimal k wins and every k=6 geometry is rejected by name. What genuinely remains open is the damage-extent distribution on LTO-10, which decides whether contiguous RS(28,4) is adequate or symbol interleaving is mandatory; ask that instead. Q7's sub-question (iv) — whether interleaving costs anything on a full-cartridge sequential pass — remains live and unanswered.
Systematic coding. Sub-file access dominates our workload; a non-systematic code turns a ranged read into a full k-symbol gather.
Planning against native, not compressed, capacity and rate. What reaches tape is ciphertext and is incompressible. Do not return 2.5:1 marketing figures.
Two-phase / deferred read semantics, and the absence of a latency SLO on cold data. A cache miss is a scheduling event. Do not propose interactive cold-read architectures, prefetchers or eviction ranking functions.
The negotiation interface shape — a plan and a cost interval returned before execution, with the binding constraint named and concrete rewrites offered, and quota denominated in physical units rather than bytes. The unit is open (Q3: mounts versus sweep-adjusted drive-seconds); the interface is not.
Our API, nouns and verbs. We are not asking for a system design. We are asking for evidence about the physical, cryptographic, economic and operational questions above.
Speculative media. DNA, glass (Project Silica), ceramic (Cerabyte) and similar are not candidates on this horizon. One exception, which we do want: if enterprise tape (IBM 3592 / TS11xx-class, ~50 TB native, with multi-generation read compatibility) is a viable alternative to LTO-10 for a three-site build, say so with prices and compatibility policy — the LTO-10 compatibility break is the single most consequential vendor fact in the proposal, and we may have chosen the wrong family.

5. Output we want¶

For each question: a short answer up front ("the evidence says X"), then the evidence with citations and dates, then explicitly what remains unknown. Separately, please return:

A negative-results list. Approaches built and abandoned, products withdrawn, features deprecated, consortia dissolved — with, where you can find it, the stated reason.
A corrections list. Every figure in section 3 where your recomputation differs from ours, and every place in this brief where we have mis-named a system, a paper or an author.
A "cheapest decisive measurement" list. For each question you cannot settle from the literature, the smallest experiment that would settle it, and whether it can be run before hardware is purchased.

Addendum — LTFS reconsidered (2026-09-19)¶

CLOSED AS SUPERSEDED 2026-09-19, by the adoption of Bareos as Layer 0. BAREOS-RECOMMENDATION.md §11.2 asks that this be stated explicitly rather than left as two live recommendations, and it is stated here. The addendum's case rested on a standard discharging the format-and-reader obligation. Bareos discharges it more cheaply: bls, bextract and bscan are catalogue-free and maintained by someone else, they need no vendor LE extension to work on WORM, and they carry no on-cartridge index that is stale until eject. SPECIFICATION.md §15 lists LTFS among the things deleted from the storage layer.

LTFS survives only as STORAGE-BINDINGS-DECISION.md §10 Step 7 — an on-demand, admitted, costed, refusable export conversion on a drive pair, never on the data path. The addendum's four disclosure conditions (opaque filenames, fixed-size padded containers, coarsened timestamps, no extended attributes) carry over to that export unchanged, and its WORM-index finding — that LTFS-on-WORM depends on vendor LE extensions and leaves the on-cartridge index stale until eject — is preserved as a procurement fact. The same closure applies to STORAGE-DIRECTION.md's LTFS underneath section, whose "an LTFS mount point as root_path works with no code change at all" is withdrawn. The body below is kept as the record of the argument.

~~The architecture document rejected LTFS for raw SCSI. That decision should be reversed~~, and the reason is that one of its four supporting objections was invalidated by a constraint established after it was written.

Objections that no longer hold

"LTFS exposes no mechanism for filtering within a read stream, which forecloses predicate pushdown." This was the strongest argument for raw SCSI and it is void: a blind holder cannot evaluate a predicate over ciphertext under any on-media format. Pushdown is unavailable to raw SCSI for the same reason. See Q1.
"LTFS degrades badly with large file counts, requiring an aggregation layer anyway." This inverts. Containers of 50–200 GB mean LTFS sees a few hundred files per cartridge, which is its best case rather than its worst. Having built the aggregation layer, LTFS beneath it is cheap.

Objections that remain, and are small: fixed block sizing (irrelevant when streaming large containers) and the per-unmount index rewrite (see the WORM complication below).

What LTFS buys. §4.2 commits to three permanent deliverables — a versioned published format spec, a maintained reference reader and on-media self-description — and states that if any lapses, the raw-SCSI decision becomes indefensible. That is a standing obligation on a team already writing a filesystem, index, scheduler and three-layer coding scheme from scratch. A standard discharges it. LTFS additionally deletes raw SCSI block management, partitioning, EOD handling and error recovery, where defects are silent data loss, and makes the DUA demonstration trivial.

Four conditions, non-negotiable, from the crypto-shredding constraint. The LTFS index is plaintext XML on media that cannot be erased — exactly the class of artefact that survives the erasure it documents, for the 10–30 year life of the medium.

Opaque filenames — content-addressed identifiers only. No dataset, project, subject, date or modality. A filename encoding anything about content defeats crypto-shredding permanently.
Fixed-size, padded containers — LTFS records sizes in the clear, and eight consecutive cleartext lengths localise a run of content in a petabyte corpus (arithmetic check 16).
Coarsened or fixed timestamps — commit time correlates with acquisition time.
No extended attributes — LTFS supports them and they land in the clear on tape.

Under these four the index discloses only "N opaque blobs of size S."

The WORM complication, which weakens §4.4. LTFS overwrites the index at the start of the index partition on unmount, which WORM media cannot do. The vendor approach (IBM, US20150127616) holds metadata in local storage between mounts and writes the index only on eject from the library. Therefore: LTFS-on-WORM depends on vendor LTFS LE extensions rather than the bare ISO standard; the on-cartridge index is stale until eject, so cartridge self-description is weaker than §4.4 assumes; and a local metadata store reappears, which is the catalogue dependency self-description was meant to remove. Verify against the specific library and LTFS implementation before resting the legal portability argument on it — this is a procurement question, not a design question.

Unaffected: the coding design. Intra-cartridge parity symbols and global symbols are ordinary LTFS files; the coding layers sit above LTFS, not below it.

Specify ISO/IEC 20919:2021, which supersedes the 2016 edition.

Added to the research questions: Q10 should now ask not whether to adopt LTFS but (i) what the measured per-unmount index cost is on LTO-10 for read-only versus read-write mounts, (ii) which library vendors implement WORM LTFS and by what mechanism, (iii) whether any operator runs LTFS on WORM at petabyte scale and what they report, and (iv) whether an LTFS index can be made to disclose nothing beyond opaque names and padded sizes without departing from the standard.