Measure at the ceiling a deployment would run

`store-bench` opened its measured store with `ENGINE_MAX_INDEX_RUNS =
1_000_000` against a store default of 64, carrying the comment "raised because
index-delta sealing is unimplemented". Sealing landed in fef8520, so the reason
had lapsed and two things followed that did not follow before: the emitted
`index_run_ceiling` named a reason that was no longer true, and at an
effectively infinite fan-out ceiling no seal in a measured run was ever
triggered by fan-out pressure, so `index_maintenance: runs_sealed` was earned by
entry pressure alone.

The raise is dropped rather than the enum renamed, so `bench/result-schema.json`
is untouched and no contract review was needed. The store opens at its own
default and the derivation reports `store_default` from the comparison it
already made.

Demonstrated rather than assumed, because the whole question was whether a run
survives the ceiling the raise existed to escape. A 45-second submit-path run at
`max_index_runs = 64` published 5,192 groups - 81x the ceiling - with no
`NotImplemented` refusal, and its rate was flat against a 5-second run at the
same ceiling (113.2/s vs 117.7/s). Both figures are debug-build and diagnostic
hardware and are evidence of survival, not of throughput. The emitted bundle
declares `index_run_ceiling: store_default` against a configured ceiling of 64,
with `index_maintenance: runs_sealed` alongside.

The raised branch of the derivation does not become dead code. The existing
fixture keeps covering it and `a_run_at_the_store_default_declares_store_default`
covers the branch a real run now takes, because a comparison needs both sides
exercised. The constant survives as a test-only value under a name that says so,
rather than being deleted and leaving the branch reachable only from a
configuration nothing produces.

The rationale block above the run is corrected too: it counted two of B1's
deliverables as bounding the bundle when only checkpointing still does, and it
still described the ceiling it no longer raises.

check-phase1.sh reports GATE_EXIT=0; verify-store-recovery.sh --cycles 2 reports
matrix=pass, bundle=schema-valid, acknowledged_loss=0, torn_transactions=0,
VERIFY_EXIT=0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

crates/levcs-store/src/bin/store-bench.rs

@@ -3056,20 +3056,30 @@ fn skeleton_ack_record(sequence: u64) -> AckRecord {
 //
 // # What this run can and cannot claim, stated before the code
 //
-// Two of B1's unimplemented deliverables bound it, and both are a bound on the
-// *bundle*, not merely on this file:
+// One condition still bounds it, and it is a bound on the *bundle*, not merely
+// on this file:
 //
-//   * `submit` refuses `NotImplemented` after `max_index_runs` group
-//     publications, because sealing the in-memory index delta into an
-//     `IndexRun` is unimplemented. The ceiling is raised here so the run can
-//     reach its measured seconds at all, which means the run holds every delta
-//     layer it ever published in memory and its lookup fan-out grows for the
-//     whole run. A P2 measurement is of a steady state; this is not one, and
-//     the bundle says so through `outcome` and its verdicts.
-//   * `StoreEngine::checkpoint` is unimplemented, so no checkpoint is taken.
-//     Section 7 requires that a P2 run not have been achieved with
-//     checkpointing disabled. This one was. That alone makes the
-//     `storage_primitive` gate unearnable today, whatever the rate says.
+//   * `StoreEngine::checkpoint` exists but this run never accumulates enough
+//     work to trip it, so the bundle declares `enabled_not_reached`. Section 7
+//     requires that a P2 run not have been achieved with checkpointing
+//     disabled, and `exercised` is the value it wants. Until a run reaches
+//     that, the `storage_primitive` gate stays unearnable whatever the rate
+//     says.
+//
+// One bound that stood here is gone, and the ceiling below is the evidence.
+// `submit` used to refuse `NotImplemented` after `max_index_runs` group
+// publications because sealing the in-memory delta into an `IndexRun` was
+// unimplemented, so this file raised the ceiling to a million to reach its
+// measured seconds at all — which meant the run held every delta layer it ever
+// published and its lookup fan-out grew for the whole run. Sealing landed, so
+// the raise outlived its reason and was dropped: the store opens at its own
+// default and the bundle declares `index_run_ceiling: store_default`.
+//
+// Dropping it is what makes `index_maintenance: runs_sealed` mean what it
+// reads. At a ceiling of a million the fan-out trigger never fired and every
+// seal in a measured run came from entry pressure; at the default the run seals
+// on fan-out as well, which is the steady state the ceiling exists to impose
+// and the one a P2 number has to be of.
 //
 // A third bound stood here until B1 landed startup state 1: `StoreEngine::open`
 // refused to build an absent root, so this run seeded one with
@@ -3087,8 +3097,18 @@ fn skeleton_ack_record(sequence: u64) -> AckRecord {
 // `transaction_status` on a reopened engine rather than comparing sequence
 // sets.
 
-/// Raised because index-delta sealing is unimplemented; see the note above.
-const ENGINE_MAX_INDEX_RUNS: u32 = 1_000_000;
+/// A ceiling above the store default, used **only** by the derivation's unit
+/// tests so the `raised_*` branch stays covered after the measured run stopped
+/// producing it.
+///
+/// No measured run configures this. It is not the value the old
+/// `ENGINE_MAX_INDEX_RUNS` had a right to: that one was applied to the store,
+/// and this one exists so a test can hand `RunConditions::derive` a raised
+/// observation and check it says so. Deleting it would leave the branch
+/// reachable only from a configuration nothing here produces, which is how a
+/// derivation quietly stops being a derivation.
+#[cfg(test)]
+const RAISED_MAX_INDEX_RUNS_FOR_DERIVATION_TESTS: u32 = 1_000_000;
 
 /// One commit's objects, matching the frozen workload: one 1 KiB blob, one
 /// tree, one commit.
@@ -3358,7 +3378,7 @@ fn run_engine(
         options.max_group_bytes = 8 * 1024 * 1024;
         options.max_group_idle = Duration::from_millis(1);
         options.journal_preallocate_bytes = 64 * 1024 * 1024;
-        options.max_index_runs = ENGINE_MAX_INDEX_RUNS;
+        // Deliberately left at the store default. See the note above.
         options.signer = Some(signer.clone());
         options
     };
@@ -5128,8 +5148,11 @@ sys.exit(1 if errors else 0)
         assert_eq!(submit.mutation_path, "store_engine_submit");
         assert_eq!(
             submit.index_run_ceiling, "raised_because_index_sealing_unimplemented",
-            "the submit run raises max_index_runs above the store default, and the \
-             declaration must follow from that comparison rather than from the path"
+            "this fixture configures max_index_runs above the store default, and the \
+             declaration must follow from that comparison rather than from the path. \
+             The measured submit run no longer raises it -- see \
+             `a_run_at_the_store_default_declares_store_default` -- so this is the \
+             only remaining cover for the raised branch"
         );
         assert_eq!(submit.index_maintenance, "deltas_retained_in_memory");
         assert_eq!(
@@ -5181,6 +5204,31 @@ sys.exit(1 if errors else 0)
         );
     }
 
+    /// The measured submit run stopped raising `max_index_runs` once index
+    /// sealing landed, so the value it now declares is `store_default`. This
+    /// asserts the derivation follows the observation to that value rather
+    /// than to the path it came from.
+    ///
+    /// It is the other half of the pair: the fixture in
+    /// `the_ten_run_conditions_are_derived_from_what_the_run_observed` keeps
+    /// the raised branch covered, and this covers the branch a real run now
+    /// takes. Neither is redundant, because the derivation is a comparison and
+    /// a comparison needs both sides exercised.
+    #[test]
+    fn a_run_at_the_store_default_declares_store_default() {
+        let mut at_default = submit_observations();
+        at_default.configured_max_index_runs = at_default.default_max_index_runs;
+
+        let conditions = RunConditions::derive(&at_default, true, "diagnostic")
+            .expect("a store-default ceiling declares");
+
+        assert_eq!(
+            conditions.index_run_ceiling, "store_default",
+            "a run that configured exactly the store default must declare it, \
+             whatever path it ran"
+        );
+    }
+
     #[test]
     fn an_observation_with_no_named_value_is_refused_rather_than_guessed() {
         // Charter item 6 at the emitter: the schema's enumerations are closed
@@ -6235,7 +6283,7 @@ sys.exit(1 if errors else 0)
                     groups: 1,
                     unsealed_delta_backlog: None,
                 },
-                configured_max_index_runs: ENGINE_MAX_INDEX_RUNS,
+                configured_max_index_runs: RAISED_MAX_INDEX_RUNS_FOR_DERIVATION_TESTS,
                 default_max_index_runs: default_max_index_runs(),
                 receipts: ReceiptComparison::AnyCommittedStatusAccepted,
                 objects_new_counted: true,

doc/phase1-storage-spine-scope.md

@@ -2109,20 +2109,40 @@ before:
    `index_maintenance = runs_sealed` is therefore true and narrower than it reads, and a P2 run
    at this ceiling is not measuring the fan-out steady state the ceiling exists to impose.
 
-**This is a decision, not an edit, and it is not B4's to make alone.** Two ways close it and
-they are not equivalent:
+**This was a decision, not an edit, and it is not B4's to make alone.** Two ways could close it
+and they were not equivalent:
 
 - **Drop the raise** — set the bench to the store default, and `index_run_ceiling` emits
-  `store_default` with no schema change at all. This is the outcome to prefer if the measured
-  run survives the real ceiling, because it is the configuration the exit criterion is about.
-  It is a change to what the benchmark measures and must be demonstrated, not assumed: the run
-  may now seal on fan-out, and that is the point of making it.
-- **Amend the enum** — if some raise is still genuinely required, the value needs a name that
-  states the surviving reason. `bench/result-schema.json` is lead-owned; per item 4 above,
-  **request it, do not emit it**, which makes this a contract review rather than a commit.
+  `store_default` with no schema change at all. The outcome to prefer *if the measured run
+  survives the real ceiling*, because it is the configuration the exit criterion is about. A
+  change to what the benchmark measures, to be demonstrated rather than assumed.
+- **Amend the enum** — if some raise were still genuinely required, the value would need a name
+  stating the surviving reason. `bench/result-schema.json` is lead-owned; per item 4 above,
+  **request it, do not emit it**, which would make it a contract review rather than a commit.
 
-Until one of them lands, §7's run-conditions count stands at three of four with this recorded
-against it.
+**Closed 2026-08-07 by dropping the raise, ruled by the lead and demonstrated rather than
+assumed.** The store is opened at its own default and `ENGINE_MAX_INDEX_RUNS` is retired; the
+schema enum is untouched, so no contract review was needed.
+
+The demonstration is the part that mattered, because the whole question was whether a run
+survives the ceiling it had been raised to escape. A 45-second submit-path run at
+`max_index_runs = 64` published **5,192 groups** — 81× the ceiling — with no `NotImplemented`
+refusal, and its rate was flat against a 5-second run at the same ceiling (113.2/s vs 117.7/s,
+debug build, diagnostic hardware; the figures are for survival, not for throughput). The
+emitted bundle declares `index_run_ceiling: store_default` against
+`resources.configured_ceilings.max_index_runs = 64`, with `index_maintenance: runs_sealed`
+alongside. `check-phase1.sh` reports `GATE_EXIT=0` and `verify-store-recovery.sh --cycles 2`
+reports `matrix=pass`, `bundle=schema-valid`, `VERIFY_EXIT=0`.
+
+`runs_sealed` now means what it reads: seals come from fan-out pressure as well as entry
+pressure, which is the steady state the ceiling exists to impose. §7's count is unchanged at
+three of four — this was never one of the four — but the third of them is now earned under the
+ceiling a deployment would actually run.
+
+The raised branch of the derivation has not become dead: `bench`'s
+`a_run_at_the_store_default_declares_store_default` covers the branch a real run now takes, and
+the existing fixture keeps the raised branch covered, because a comparison needs both sides
+exercised.
 
 #### Carry-forward: the SIGKILL cycles still drive the journal seam
 
@@ -2300,15 +2320,15 @@ decides whether a P2 figure describes a steady state or a burst — a run with a
 that grows for its whole duration and no checkpoint ever taken is measuring a system that has
 not yet reached the condition the number is supposed to characterize.
 
-**A fourth condition is not on the exit list and bears on the same question.** The submit path
-still declares `index_run_ceiling = raised_because_index_sealing_unimplemented`, because
-`store-bench.rs` opens its store with `ENGINE_MAX_INDEX_RUNS = 1_000_000` against a store
-default of 64. The derivation is honest — it compares the configured ceiling to the default and
-reports the raise — but the *reason* the enum names is no longer true, and the raise itself now
-has a consequence it did not have when sealing was unimplemented: at an effectively infinite
-fan-out ceiling, no seal in the measured run is ever triggered by fan-out pressure, so
-`runs_sealed` above is earned by entry pressure alone. Resolving it is a decision, not an
-edit — see the carry-forward under §6.6 item 5.
+**A fourth condition is not on the exit list and bore on the same question, and it is now
+closed.** The submit path used to declare `index_run_ceiling =
+raised_because_index_sealing_unimplemented`, because `store-bench.rs` opened its store with
+`ENGINE_MAX_INDEX_RUNS = 1_000_000` against a store default of 64 — so no seal in a measured
+run was ever triggered by fan-out pressure and `index_maintenance = runs_sealed` was earned by
+entry pressure alone. The raise was dropped on 2026-08-07 after a run demonstrated survival at
+the real ceiling; the path now declares `store_default`, and `runs_sealed` above is earned
+under the ceiling a deployment would run. The carry-forward under §6.6 item 5 records the
+evidence.
 
 Three of four is the accurate reading of how much of the P2 exit criterion is currently earned,
 and the remainder is the expensive one — the same disclosure the SIGKILL carry-forward above