Research cross system performance program

Historical report imported 2026-10-10 from docs/research/cross-system-performance-program.md. Original SHA-256: def4e77450fba9c2177280ffc6ea871e5d20402dd62638192343f22c23d1948b. Measurements and outcomes retain their stated revisions. Links and local environment labels are normalized; $FABRIC_DATA is the mounted experiment drive. See evidence policy.

Cross-system performance research for Fabric

Status: exploratory synthesis with the first registered execution slices, 2026-10-08. The readiness protocol (local checkout reference docs/experiments/benchmarks/catalog-cross-system-readiness-protocol.md; not present at origin/main) and prefix-progress protocol (local checkout reference docs/experiments/benchmarks/catalog-prefix-progress-protocol.md; not present at origin/main) register their finite workloads separately. No format migration is adopted. Tier 6 of the source hierarchy. The queue (local checkout reference docs/research/cross-system-lab-queue.json; not present at origin/main) coordinates research items rather than dispatching workloads; its revision map supplies immutable downloader pins. The active goal covers source review, experiments and consolidation; source review alone does not complete it.

The subsequent candidate source screen revises D2, details D1's commit-thread dependency, and verifies concrete Vortex compressed kernels for a fifth candidate. Execution resumed after the owner restored permissions and the data mount became writable; historical unavailable runs remain unavailable. The first slice reran six sealer controls successfully and retrieved the pinned Turso source; candidate progress is recorded separately.

The downloaded-source synthesis now covers 21 additional complete archive inventories and three repositories with bounded implementation-file retrieval, with explicit historical failures. Its linked storage, query and operations dissections supersede the narrower initial review coverage in the table below. The continuation protocol (local checkout reference docs/experiments/benchmarks/cross-system-continuation-protocol.md; not present at origin/main) registers the executed offline memory census, full-chain query census and native prefix-load comparison, including observer/checker counterexamples and scoped follow-ups. The earlier unavailable-environment section at the end is a historical preparation record, not the present execution state.

Objective and present evidence

Revised engineering goal

Owner revision, 2026-10-09: address Fabric's unknowns and gaps and continue multidimensional engineering, informed by research into other research and coding agents. This section is the revised repository objective; the session's goal API exposes status changes but cannot edit the existing objective text. The earlier goal remains unfinished. Its historical blocked status does not establish the current environment: a fresh read-only inspection found the data drive mounted read-write and no loaded fabric-work-* units. Executable work still requires fresh containment and budget admission.

Goal. Bring Fabric toward reliable end-to-end use in development and small deployments by closing the recorded correctness, sustained-memory, capacity, recovery and installation evidence gaps. Trace each gap to source, a contract and an executable deciding check; repair reproduced defects and verify the correction independently. Continue bounded algorithm research across ownership, representation, indexing, scheduling and admission, using contemporary source research and effective agent methods to generate competing hypotheses. Test nulls, adverse workloads and held-out cases before integrating a candidate. Preserve fidelity, durable custody, completeness, freshness, snapshot semantics and bounded operation. Keep the current resource limits and historical budgets; record measured gains, rejected ideas, remaining uncertainty and cleanup.

The finish line for readiness is the applicable registered checks passing on their stated profiles, with an operator-usable configuration and recovery path. An unavailable host or an unmet gate remains open; a report alone does not close it. Research rounds have finite candidate lists and can conclude with no winner. Further interesting ideas do not indefinitely extend a completed round, and a successful microbenchmark does not substitute for a readiness gate.

Gap order and lab responsibilities

These are work priorities, not a new benchmark protocol or a change to any registered threshold. Reuse existing protocols where applicable; separately register new workloads and checks before measurement.

Priority	Lab and deciding work	Evidence required to close the gap
G0	Coordinator: reconcile historical failures, latest receipts, source identity, host and remaining budgets	A current gap ledger tied to revisions; the older catalog availability failure is already addressed by coupled completion, and subsequent fast checks passed. Do not reopen it solely because an old paragraph says failed.
G1	Capacity and storage: finish bounded-sealer acceptance, attribute simultaneous owners, then the unchanged soak	Exact rows/files and fault cleanup; registered heap/scale gates; requested live heap, process RSS and cgroup memory measured separately; all unchanged soak gates. A shorter diagnostic cannot stand in for the registered soak.
G2	Query and representation with capacity: concurrent dev/small consumers and mixed signals	Exact complete pagination across pending and sealed data; source-to-visible and ACK-to-visible delay, query tails, accepted/offered Spool rates, backlog/drain, CPU, memory and disk observations under explicit application limits. Resolve the C5 prerequisites (local checkout reference docs/experiments/benchmarks/coupled-c5-preservation-review.md; not present at origin/main) before dispatching its deferred matrix.
G3	Reliability and operations: cancellation, overload, restart, retention and bounded disk exhaustion	Deterministic reproductions, producer-backed custody and independent query controls, completed worker ownership, truthful gaps/incompleteness and cleanup under isolated fixtures. Physical power loss remains a distinct untested assumption until suitable hardware evidence exists.
G4	Reliability and operations: installation and target-profile runs	Verify the actual host and cgroup enforcement, then run applicable installation/history/stress/outage checks; update the qualification ledger. A different host yields measured evidence, not target qualification.
G5	Coordinator: consolidate product use and bounded research	Reproducible dev/small settings, operational/recovery instructions, current check receipts and before/after costs; each admitted research card has a supported, rejected or inconclusive disposition with its evidence. Release tagging is a separate action.

The three standing labs retain their PIs and scoped assistants. Parallelize independent source questions and preparation; serialize resource-heavy work. Use Luna for bounded extraction/inspection and the requested GPT-6.1-SOL medium for PI work when needed. Keep at most four active agents including the coordinator in this environment. Dispatch is governed by useful independent work and remaining cost, not a requirement to keep every slot occupied.

Agent methods to test locally

Primary sources consulted on 2026-10-09 provide methods, not evidence of Fabric performance or a ranking of agents:

• OpenAI's long-horizon Codex account describes persistent specifications, milestone plans, execution feedback and verification. Apply this through the existing queue, run records and receipts: every handoff names the source revision, invariant, current result and next discriminating action. Its demonstration does not establish unattended reliability for Fabric.
• AlphaEvolve's technical report combines generated program changes, automated evaluation, retained candidate diversity and evaluation cascades. Adapt the mechanism to a small set of structurally different candidates: cheap semantic rejection first, component measurements next, held-out confirmation and service interaction last. Evaluator adequacy remains a limit; preserve independent oracles and adverse workloads instead of optimizing only one convenient score.
• Anthropic's research system describes explicit delegation, effort scaling and checkpoints, with higher token costs and limits for tightly coupled coding work. Its long-running harness account adds incremental work and end-to-end checks across sessions. Keep one integration owner and ask assistants for source/tool evidence. Agent agreement is never an acceptance gate.

Our local hypothesis is that these methods improve useful uncertainty reduction per unit of research cost. Compare concrete outputs: reproduced defects, falsified models, held-out prediction errors and confirmed end-to-end gains, alongside wall time, compute, evidence bytes and token usage when available. Do not invent missing token measurements or treat more agents as more evidence.

The first candidate families remain those motivated by the native round: bounded buffer reuse versus early release, incremental conversion versus overlapping representations, state-sensitive query admission versus unconditional checks, and shared staging budgets versus independent per-run caps. Limit a round to the existing six-card/two-prototype exploration envelope. Assess allocation history, workload selectivity and CPU/I/O contention as rival explanations. Readiness work has priority; promising research proceeds only through its own cost and correctness gates.

All builds, checks and experiments still use the resource launcher, data-drive scratch, 16/20 GiB high/max and zero swap. The 20 GiB laboratory envelope is not a deployment claim. The default 30-minute invocation deadline remains; a longer registered soak requires its existing explicit owner scope and finite extension, not an uncapped fallback. No budget is reset by this goal revision. Remote work requires host-specific containment and preserves existing services. Cleanup follows authenticated retention of failure evidence.

Evidence inherited from the earlier scope

The first service/recovery execution under the revised goal is complete: both current native cases passed finite custody/query/residency gates and all eighteen selected storage recovery cases passed. Artifact finalization defects and launcher attribution were recorded; seventeen fast checks, manual documentation checks and cleanup were completed. The unchanged long soak and broader readiness gates remain separate unfinished work. The measured lower Walk residency motivates balanced confirmation with query-off controls, not a new default or a multiplied optimization claim.

Find changes that make Fabric affordable and reliable for development and small deployments while preserving exact custody, fidelity, query completeness, freshness and bounded operation. Study mechanisms from other engines against Fabric's actual costs. Treat an attractive mechanism as a hypothesis until a matched comparison and independent correctness checks support it.

The owner's subsequent direction makes generative synthesis an explicit part of this goal: use contemporary engineering evidence to generate alternative development trajectories, then test them. Sources provide mechanisms, costs and counterexamples; the candidate space also includes combinations, inversions and new mechanisms that no inspected source supplies. Originality is an open research question. Correctness and usefulness determine whether a candidate progresses.

The user's proposed research agenda is incorporated below. Three bounded Luna source-review assignments covered compressed representation, Feldera storage, and admission/reliability. The coordinator reviewed their evidence, including the qualifications below. Those assignments were source inspections, not lab performance runs; model agreement is not a verification gate.

Several starting assumptions need updating against this working tree:

• The bounded sealer (local checkout reference crates/fabric-server/src/segment/bounded.rs; not present at origin/main) already exists. The next question is total memory and progress under concurrent ingestion, sealing and queries. A per-run bound does not bound the whole process.
• Its normal sort-run limit is 16 MiB with a row cap and bounded merge fan-in. Separate log, metric and span builders, input decoding, writer buffers and output can coexist. A row larger than the target run can be admitted into an empty run; the target is not an unconditional allocation ceiling.
• Current durable custody is exact encoded Batches, with typed Parquet tables and raw custody preserved through publication. FOB1-derived hot blocks are not a universal replacement storage format. An alternative-format experiment must compare with today's bounded builder and include conversion costs.
• Borrowed log reads and the storage-owned ReadCatalog (local checkout reference crates/fabric-server/src/read_catalog.rs; not present at origin/main) already exist. ReadCatalog owns Walk discovery; Scan still has separate source acquisition. Extending a common boundary is useful only with exact snapshot semantics and measured savings.
• Recent allocation work reduced requested allocation while leaving peak unchanged. That historical result is not evidence of a new service RSS or throughput gain.
• Lifecycle fixes already retain query permits with actual blocking work after cancellation. More scheduling tests should target uncovered cuts, not repeat that discovery.

These statements concern the dirty working tree, not HEAD alone. The Turso manifest (local checkout reference docs/research/turso-source-manifest.json; not present at origin/main) hashes its inspected Fabric files; every future executable comparison must freeze all affected sources afresh. Current contracts take precedence over older research entries and predictions.

Initial source map and transfer limits

The references below identify what was inspected, not a claim that every named engine has been audited. Pinned source is distinguished from design documents and documentation-only surveys. No upstream benchmark is a Fabric measurement.

Reference and evidence	Mechanism to investigate	Fabric limit or counterexample
Turso review, pinned Rust source	Snapshot-aware page location, borrowed records, explicit I/O ownership, cost attribution and failure scheduling	Its cache can exceed its nominal capacity and its buffer pool can allocate fallback buffers. Borrow the ownership lessons, not a claimed hard memory bound.
Comet 1.1.0 analysis, plus allocation observer and fair pool	Reconcile reservations with allocation and process/container observations; account consumer identity and already-incurred debt	The allocation observer measures; it does not refuse allocation. A reservation ledger alone cannot enforce a process ceiling.
Feldera storage proposal, Spine and ListMerger	Immutable batches, incremental merging and bounded scheduling quanta	The 2024 proposal is not current performance evidence. Merger fuel is not a byte or wall-time bound; details below.
Vortex execution internals and scanning, documentation review	Preserve supported compressed encodings through filters and execute lazily	Fallback paths canonicalize. Inspect the selected kernels before claiming a particular predicate avoids decoding. Conversion, raw custody and coexisting buffers count.
Lance filtered read and scalar index, selected source review	Selection masks and logical identity independent of physical row addresses	Stable-ID lookup itself can materialize sequences. Identity stability does not imply bounded memory or permission to retain expired files.
redb design, documentation review	Publish committed roots while managing readers of earlier roots	Fabric page tokens expire with retention and return Gone. Copying reader-pinned reclamation would change that contract.
Fjall README, documentation review	Contrast persistent hot indexes and value separation with COW metadata	Another engine introduces its own maintenance, buffering and durability choices. No integration is nominated.
Tantivy and Quickwit architecture, documentation review	Postings, stored fields and columnar fast fields for selective search	Tokenized text search is not Fabric substring semantics. Candidates require exact predicate verification.
ClickHouse skipping indexes and DuckDB indexing, documentation review	Sparse/min-max elimination and locality before payload materialization	Dense, randomly mixed matches can make index lookup pure overhead; build cost and query memory also count.
GreptimeDB indexes and Tempo block format, documentation review	Different indexes for different predicates; trace-oriented retrieval	A portfolio needs a measured break-even decision. No filter may suppress a possible match. Trace lookup also needs complete cross-segment coverage.
Roaring Rust implementation, repository overview	Candidate-set intersection and compact row identifiers	Compare with sorted sparse IDs and ranges at matched density and clustering; an extra representation can cost more than it saves.
Vector controller, guarantees and buffering	Latency/error feedback and isolation through buffering	ACK meaning depends on destination/configuration. Fabric's durable ACK and per-Strand ordering remain unchanged; low RTT is not proof of sealing capacity.
OTLP Arrow receiver, documentation review	Transport representation and conversion costs	Receiver maturity is not Fabric compatibility. FAB1 changes, dictionary recovery and replay semantics need their own scoped protocol work.
FoundationDB testing, Shuttle, Loom, fail-rs and existing Fabric property tests	Reproducible schedules and explicit failure cuts	A modeled schedule does not establish native filesystem durability or cover all OS interleavings. Reuse current fixtures before adding test dependencies. fail-rs integration has not been inspected.
Feldera incremental updates and differential-dataflow as a queued deeper review	Derived results updated by changes instead of rescans	Duplicate transport is already idempotent. It must not become a second insertion followed by a compensating deletion. New aggregate semantics are not adopted here.
Prometheus chunk format, documentation review	Timestamp/value encodings specialized for numeric series	Compare exact supported Fabric values, units, attributes and order. A favorable scalar series says little about mixed telemetry.
SlateDB design, documentation survey	Object-storage persistence and cache/manifest boundaries	Deferred until a remote cold-storage need is established; another storage lifecycle is not an immediate memory fix.

A useful adversarial finding in Feldera

In the inspected ListMerger, work checks fuel between merge steps, while copy_times may traverse and consolidate multiple input time/weight entries before decrementing fuel for an emitted value. An empty/zero-weight result can return before that decrement. This is a source observation about the unit of accounting, not a demonstrated bug or timing result. A related PushMerger has a comment limiting its use to development tweaks; it is not evidence of the default production path.

The transferable hypothesis is to charge consumed work, including input bytes and decode effort, rather than only emitted rows. Still bound the largest indivisible decode/write operation: checking a deadline afterward cannot bound that operation. Fabric must preserve all distinct observations and stable ties; it must not copy Feldera's weighted consolidation into raw custody.

Coupled models to test

Memory is an ownership problem and a measurement problem

Record simultaneous time series:

• R(t): declared reservations, with owner and resource scope;
• A(t): live requested allocation bytes observed by the instrumented allocator;
• P(t): process RSS, including mappings and resident allocator effects;
• C(t): cgroup memory, with anonymous/file/kernel breakdown, pressure and events.

They are not interchangeable. Reservations may be unused; allocations may be outside the allocator observer; RSS differs from requested allocation; cgroup memory includes file cache and other charged descendants. Consequently A-R is a diagnostic residual, not an exact measure of untracked memory. Do not add these four counters or treat the sum of independent peaks as a simultaneous peak.

For disjoint live allocation owners, a useful accounting model is

A(t) = input(t) + runs(t) + merge(t) + encode(t) + cache(t) + query(t) + other(t).

Charge shared backing allocations once, record spare capacity, and follow ownership through cancellation and handoff. Record the byte-time integral of each representation as well as its peak: a smaller allocation held much longer can obstruct admission. A bounded progress reserve must cover completion/spill; otherwise every worker can hold a partial allocation while waiting for more. The cgroup remains the external containment boundary, not evidence that graceful admission or sustained capacity has been established.

Less copying can retain more memory

Consider results borrowing from K distinct decoded frames of size F. Keeping those borrows alive can retain roughly K*F bytes. Copying only k selected payloads of mean size b costs roughly k*b, plus keys and allocation overhead. This is a simplified lifetime model, not a claim that current Fabric retains such borrows. It predicts a useful negative case for a blanket zero-copy design: sparse results spread over many wide frames.

Candidate: borrow during inspection, materialize only retained winners, then release frame ownership promptly. Compare both timing and backing allocations retained per returned row. Rust lifetimes and RAII can enforce the ownership boundary; Rust alone does not bound the amount of memory that a valid borrow pins.

Smaller working sets can increase backlog cost

For journal bytes arriving at rate x and drained by sealing at mu, dJ/dt = x - mu. Use the same byte domain for both rates. If each additional unsealed byte induces a bytes of derived in-memory state locally, then dM_tail/dt ≈ a*(x-mu) while that regime applies.

Thus saving deltaM in a worker but lowering sustained drain below arrival can erase the saving after approximately deltaM / (a*(x-mu)). Estimate a and the rates rather than assuming linearity globally. Measure acceptance, backlog age, drain and query cost together. ACK-to-queryable is measured independently: pending journals are queryable, so sealing delay is not visibility delay.

The earlier fitted worker/run-size curves are historical hypotheses. Three measurements fitting a quadratic do not identify a reliable extrapolation or justify a new optimum on this builder. Worker counts are discrete, CPU contention changes tails, and isolated throughput gains cannot simply be multiplied.

Query and index decisions need avoided work and amortization

Decompose a complete query into discovery, integrity validation, key/predicate work, payload decoding/materialization and output. Count source/group visits, raw bytes hashed, rows decoded and rows retained. A candidate that skips required integrity validation is invalid even if the answer happens to match.

An index is worthwhile over its useful lifetime only when measured query savings exceed build, maintenance and retention costs in a declared common cost model. One CPU-only diagnostic is Q_lifetime * (CPU_scan - CPU_indexed) > CPU_build + CPU_maintenance; disk, memory and latency remain separate constraints. A broad scan is a deliberate negative case, not an embarrassing result to omit.

The independent-row model P(empty group) = (1-p)^R is a null model. Clustering, conditional selectivity and field cardinality change it. Block read cost also changes with R; a fixed-cost derivation cannot choose the block size for all layouts. Measure clustered and shuffled versions of the same records. Select index candidates from those measurements before implementing an online solver.

Identity, completeness and incremental results stay separate

Logical evidence identity survives a move from journal to Segment; a physical locator is valid only within its generation/snapshot. Exact retry, a new Batch with equal content, and a changed payload under the same identity are three different cases. A remap must preserve that distinction and the existing query order. A metadata handle must not silently extend physical retention.

A derived count can support signed updates; an arbitrary aggregate such as a maximum cannot be updated by merely subtracting a deleted maximum. Start any incremental experiment with a precisely defined count and finite window/late policy. Compare after every update with a full recomputation. Coverage and unknown intervals remain part of the answer: zero is not evidence of absence outside known coverage. Fabric already exposes evidence metadata; new result types or progressive APIs need a separate contract, not another wrapper by fiat.

Generative exploration and selection

Use the multidimensional-reasoning and fabric-experiment workflows as one loop:

source evidence -> mechanism cards -> candidate generation -> adversarial screen -> discriminating experiment -> held-out confirmation -> revised model/trajectory.

Compile mechanisms into their invariants, ownership lifetimes, cost drivers, workload assumptions and failure cases. Generate candidates across representation, ownership, scheduling, physical locality and feedback. Vary causal mechanisms, not just names and parameters. Operators include combining compatible mechanisms, inverting an assumption, removing a synchronization barrier, moving a decision across a responsibility boundary, and perturbing the workload until the preferred design loses. Preserve competing explanations until a test distinguishes them.

Stochastic exploration should broaden the search without making evidence unrepeatable. For a sampled round, freeze admissible dimensions/operators, record the sampler and seed, and retain every selected combination, including infeasible ones and rejection reasons. Preserve exact generated candidate text and available model/configuration metadata: a workload seed does not make language-model generation deterministic. Record unavailable controls as unavailable. The initial cards below were constructed from source inspection; no seeded sampling execution or stochastic coverage claim is recorded here.

Prepare at most six distinct cards in the first batch and nominate at most two for prototypes within the existing allowance. Use one slot for the strongest evidence-supported candidate and one for a feasible different mechanism family that tests an uncertain assumption. Leave the second slot unused if its candidate is dominated or infeasible. Judge potential gain, uncertainty resolved, test cost and reversibility; do not invent probabilities or reward novelty alone. This stage fits the existing queue and does not create an unlimited new campaign.

Every card records source ingredients, proposed departure, affected contract, causal prediction, null, adverse workload, distinguishing test, cost ceiling and decision to reject, revise or confirm. Separate generator, adversary and verifier roles even when the coordinator performs them. Reserve fresh workloads for confirmation: repeatedly tuning on one fixture does not make its best result independent evidence. Preserve negative results. Combine mechanisms only after separate ablations and an interaction comparison; model confidence and multiplied isolated speedups are not evidence.

Initial candidate cards

These are unmeasured hypotheses, not novel-algorithm claims or selected production changes. The lab rows below provide existing execution homes.

Candidate / lab home	Synthesis and proposed departure	Distinguishing test and rejection case
D1 / O2, Capacity consulted	Combine explicit completion ownership with ordered reclamation: process each worker completion and reclaim only the durable contiguous prefix while sibling builds continue	Hold a later worker at a barrier after an earlier label publishes. Compare checkpoint/reclaim timing with today's group barrier. Reverse which worker stalls and inject build/panic/reclaim failures. Reject reclaim across a hole, detached work, unbounded completion state or unacceptable checkpoint/ACK contention.
D2 / Q2	Revised after source screening: log winners already become owned and decoded borrows stay local; measure residual attribute and rejected metric/span construction instead of adding a generic ownership policy	Preserve rejected-row validation and compare requested allocation, full-query CPU/latency and backing residency. The original escaped-log-borrow premise is not supported in the inspected paths.
D3 / M1 and Q3	Treat hot-tail acceleration and sealing as competing uses of derived memory: allocate optional hot-block effort according to expected reuse before publication, preserving exact journal fallback	Compare static allocation with a bounded policy under quiet/repeated queries, growing backlog and a stalled sealer. Measure build, query and fallback costs. Reject oscillation, stale estimates, starvation or suppressed validation. Start with existing optional structures; new indexes remain separate research.
D4 / M2 and O3	Combine input-work-charged merge quanta with latency feedback: adjust background yields using measured ACK pressure, while keeping memory admission and durable ACK semantics independent	Separate network delay from durable-sync contention; compare fixed and feedback scheduling. Add an interaction cell only after isolated component results. Reject confusion between RTT and storage pressure, unstable backlog, or an unbounded indivisible operation.
D5 / M3	Use a supported compressed string predicate before output materialization, informed by concrete FSST kernels	Compare matcher/representation construction, compressed execution and full output costs; preserve literal substring semantics and exact fallback for unsupported predicates. See the source screen for byte-length, copy and lifetime limits.

D1 has a concrete source basis in build_and_reclaim: it collects all worker results for a chunk before invoking reclaim_prefix. Existing tests cover reclamation before a later group finishes; that does not demonstrate reclamation before a sibling in the same group finishes. Current publication may already remove covered data from the query tail, so earlier physical journal deletion does not automatically reduce RSS or query cost.

An analytical example clarifies the prediction. Assume three labels finish at 10, 100 and 20 ms, negligible checkpoint cost and an available commit thread. The current group barrier makes the first reclaim wait until 100 ms. Processing completions separately could release label 1 at 10 ms; labels 2 and 3 still wait until 100 ms. The modeled journal byte-time saving is bytes(label 1) * 90 ms. If the oldest label finishes last, this benefit vanishes. These are constructed times, not measurements. Real checkpoint cost, commit-thread contention and full worker cleanup belong in the experiment.

Evidence selects the next trajectory: finish a promising candidate, revise a failed causal model, or explore another family. A null result is useful when it removes a false assumption. Source review feeds ongoing invention and falsification, with a finite budget for each round.

Finite lab queue

The coordinator is accountable PI during preparation. Active execution PIs and bounded assistants follow standing orchestration (local checkout reference docs/experiments/lab-orchestration.md; not present at origin/main). Three responsibilities persist without three continuously running agents. Source assistants have completed their assignments; no native jobs are active.

ID / lab	Experiment and hypothesis	Null or rejection case	Primary evidence / dependency
G0 / coordinator with Operations	Freeze the current baseline and a feasible resource/evidence envelope before dispatch	Required storage, containment, full failure preservation or remaining budget cannot be established	Readiness receipt, source hashes, real commands and limits. Prerequisite for every executable cell.
M1 / Capacity and lifecycle	Measure simultaneous memory owners as payload width, backlog and worker/query overlap vary; H: the model explains the dominant peaks and identifies an enforceable admission boundary	Reservations look bounded while decoded, writer, output or historical-generation state grows outside them	R/A/RSS/cgroup time series, allocation lifetimes, offer/accept/ACK rates, backlog/drain. G0; diagnostic, no speed threshold.
Q1 / Query and availability	Census full paginated queries over tail, sealed and crossing snapshots; H: measured discovery/validation/materialization terms predict a held-out workload sufficiently to rank the next change	Observer overhead or unexplained interaction defeats the ranking	Plain/count/stage builds, source/group/row/byte counts, first-page and full-chain cost, unchanged exact oracles. G0.
O1 / Recovery and operations	Exercise actual accepted-work, lost-ACK, cancellation, publication and reclaim cuts; H: custody, identity, snapshot evidence and owned-work cleanup survive every declared cut	Lost/duplicate evidence, future metadata in old snapshots, expired coverage revived, detached work	Reproducible cut transcript, retry/reopen and Gone controls, minimized failures. G0; builds on current native/simulator fixtures.
M2 / Capacity and lifecycle	Prototype a resumable merge quantum charged by input work, with a bounded indivisible step; H: mixed-load tail latency improves without unstable backlog	Yield overhead slows drain, wide steps violate the quantum, or tie/order/cleanup changes	Input bytes per yield, longest step, CPU/MiB, temporary I/O, ACK/query tails, byte-exact output. M1 and O1.
Q2 / Query and availability	Compare selective materialization and borrowed/reused metric/span paths only where Q1 identifies remaining cost; H: unnecessary payload ownership falls without retaining large backing frames	More pinned bytes, allocation savings without useful service gain, altered validation/error order	Materialized rows, retained backing bytes, requested allocation/peak and full-query CPU/latency. Q1 and O1.
M3 / Capacity and lifecycle, Query consulted	Compare bounded Parquet with a scratch Vortex representation on identical inputs; H: compressed execution lowers whole-path cost enough to justify further work	Conversion/unsupported kernels/raw custody erase the benefit or memory overlaps increase peak	End-to-end encode/read/query CPU, RSS/cgroup, retained and temporary bytes, exact outputs. M1/Q1; inspect actual selected kernels first.
Q3 / Query and availability	Compare existing pruning with one measured bitmap/postings candidate and sparse/range/Roaring RowSets; H: selected workload amortizes build cost	Dense/random matches favor scan, or a filter creates false negatives	Build/query CPU, bytes, candidate false positives, exact full answers; clustered/shuffled and absent-index/corrupt-index controls. Q1, before adding a portfolio controller.
O2 / Recovery and operations, Query consulted	Stress logical-to-physical mapping across publication and retention using Lance/redb/Turso lessons; H: storage resolution preserves identity without extending file lifetime	Stale offset, duplicate/new-identity confusion, leaked generation or invalid Gone behavior	Exact retry and changed-payload controls, old/new snapshots, reclaim/reopen transcripts. O1; use current metadata boundary first.
O3 / Recovery and operations, Capacity consulted	Compare fixed admission with a bounded feedback policy across independent Strands; H: overload recovery improves without changing durable ACK or per-Strand custody	RTT confuses slow disk with spare capacity, oscillation/backlog grows, cancellation releases capacity too soon	Offered/Spool-accepted/server-ACKed/refused/retried rates, disk/sync delay vs network-delay cells, spool bytes/age, drain and latency. M1/O1; no wider per-Strand window.
Q4 / Query and availability	Isolated finite-window derived count with late updates; H: each incremental answer equals independent historical recomputation at lower repeated-query cost	Replay double counts, late policy loses evidence, deletion/expiry semantics differ, state becomes unbounded	Update-by-update independent table of expected results, state bytes and CPU; O2 and a separate toy semantic specification. No production aggregate API.
M4 / Capacity and lifecycle	Compare one exact numeric-series encoding against current columns; H: smaller representations survive mixed-workload costs	High entropy, high cardinality, irregular time or preserved metadata erase gains	Bitwise value round trips where required, timestamps/units/attributes, encode/decode CPU and total retained bytes. M3; no protocol change.

Dispatch order is G0, then M1/Q1/O1 as separately admitted workloads; source and fixture preparation and the generative stage may overlap. Screen candidate cards against M1/Q1/O1 evidence before nominating prototypes. This can revise candidate priority without altering a registered experiment. M2/Q2 are the current first candidate changes. M3 and Q3 follow measured attribution. O2/O3 use the verified ownership baseline. Q4/M4 are later bounded research, not prerequisites for a usable first deployment. Do not dispatch every Cartesian combination of rows, formats, workers and indexes. One failing correctness cell stops that candidate; a null result can complete an experiment and close an unproductive direction.

Each row is a scoped question, not yet an executable protocol. Before registration, freeze exact fixture bytes, seeds, arrival/query schedules, commands, candidate switches, sample requirements, absolute latency/backlog guards and failure-state preservation. Start with one alternating screening pair; nominate at most one configuration for three fresh alternating confirmation pairs. The inherited candidate rule proposes at least 10% primary-cost improvement in every pair and at most 5% regression in declared secondary guards, plus exact semantics. It is not an executed result or a significance test. Diagnostic and correctness rows have their own criteria. Freeze criteria before measurements; insufficient tail samples mean inconclusive.

Development and small-deployment cells should differ in offered load, source count and explicitly enforced application resources, while sharing a reproducible data distribution. Reuse the dev/small fixtures (local checkout reference docs/experiments/benchmarks/dev-small-local-protocol.md; not present at origin/main) as a starting point, not as proof of deployment capacity. Add traces and wide attributes in separately frozen cells where the historical fixtures omit them. The harness's 20 GiB cap is not a claimed application memory requirement.

Ideas retained outside the immediate queue

Evidence semantics, physical representation, computation and verification should remain separate responsibilities. This fits the current pure core and explicit storage boundary; it does not justify a new generic framework or another embedded database. Borrowed views, consuming moves, checked byte arithmetic and RAII-owned permits are Rust dimensions to investigate before unsafe/SIMD or allocator changes. No new dependency belongs in the pure core as an incidental optimization.

Adaptive instrumentation, progressive investigations, OTLP Arrow transport, remote cold storage and general incremental operators remain research candidates. They need concrete consumers plus authorization/expiry/fidelity, coverage, replay/dictionary, retention or aggregate semantics respectively. Keep Parquet interoperability while alternatives are experimental. The existing research ledger contains related prior art; this review makes no novelty or frontier-advancement claim for rediscovering it.

Resource admission, observations and remaining work

Read-only findmnt -T $FABRIC_DATA -o TARGET,FSTYPE,OPTIONS exited 0 and reported the data volume mounted ext4 with ro,nosuid,nodev,relatime,seclabel,errors=remount-ro. The cause is unestablished. The requested local Turso download and every executable row remain not run: environment unavailable. Upstream source was retrieved through GitHub/web tools; it was not cloned to system-disk or RAM scratch. No experiment scratch, process, transient unit or remote workload was created in this source-review turn.

After the required volume is writable, G0 must still establish real admission:

1. Freeze current source and inventory historical time/evidence allowances. Updating the goal does not reset any allowance. Preserve all previous failed and interrupted outcomes; measure available headroom instead of forecasting it.
2. Bound successful and failed artifacts before dispatch. The C5 preservation review (local checkout reference docs/experiments/benchmarks/coupled-c5-preservation-review.md; not present at origin/main) remains unresolved; M1 is not a renamed completion of the full C5 matrix. Its deadline, readiness and replay-preservation defects need their recorded fixes before that original matrix can run.
3. Register executable protocols separately from implementation. This session's .git access is read-only; no registration commit was made. Do not work around that boundary or alter protected oracle/contract expectations.
4. Serialize builds, tests, experiments and validators through python3 -B tools/resource_group.py -- COMMAND, retaining the 16 GiB high / 20 GiB maximum, no-swap and 30-minute outer limit. Verify aggregate containment and data-drive build/temp paths. Smaller deployment claims require attested child limits, not merely affinity or names. Reconcile scratch, free reserve, time and evidence caps before each job.
5. Preserve and verify failure evidence, then remove only owned scratch and processes. Record actual command/exit, source/binary identity, storage paths, resource observations and cleanup. No remote host work is admitted here.

Research documentation was written to the repository as a durable record. Manual documentation validators, Rust checks, alternate-engine builds and all comparative experiments were not run because their required scratch/build volume is unavailable. No new measurement, performance win, alpha readiness or engine adoption is claimed. The active goal remains unfinished with this finite queue prepared for registration and resource admission.