Set 11 Saturation Engines Bundle

Four saturation engines run from copied source

Thirteen unrelated pieces of internal logic are copied into a public bundle and re-run on synthetic inputs so a reader can watch each behave. This component takes thirteen unrelated pieces of internal logic, copies their source bodies into a public bundle, and re-runs each one against small synthetic inputs so a reader can watch the logic behave instead of taking a claim on trust. The targets share nothing except that treatment: a run ranker, a cluster-insight deriver, a delta gate, a navigation grader, a supersession rollup, a browse sectioner, an evidence selector, a secret scanner, two market-board engines, a graph wayfinder, a session-diagnostic lens, and a demo-coverage auditor.

Each engine answers a distinct bounded question

One narrow question: does each imported mechanism actually compute the guard it claims, on inputs designed to make it fail? The single question it answers is narrow. For each mechanism, does the imported source actually compute the guard it claims to, on inputs designed to make it fail? It is a saturation pass because the targets are swept up together so one reviewer can audit a broad slice of the codebase from one place.

The result reports saturation without acting on it

The records are metadata-only: digests, computed outputs, probe values, and verdicts, while copied source bodies stay in the bundle tree. It emits metadata-only result records: source-module digests, per-mechanism computed outputs, computed negative-case probe values, and pass or blocked verdicts. Copied source bodies stay in the bundle's source_modules tree and are never inlined into a record.

Purpose

Why a fixture filename proves nothing

A fixture filename is only a label, and a runner that counts it without exercising the real function is green and blind at once. A test that trusts its own fixture filenames proves nothing. A file named run_affinity_stale_terminal_rejected is a label. If the runner counts that label as a rejection without exercising the real function, the suite is green and blind at the same time. That is the failure this component is built to avoid.

Two agreeing computations per negative case

A case is verified only when the mechanism's own exercise and a separate probe over its probe_input agree, so an undemonstrated failure is flagged. So it never lets a label stand in for a result. For each negative case it recomputes the guard from the fixture's own probe_input and refuses to mark the case verified unless two independent computations agree: the mechanism's own exercise and a separate probe over the fixture input. A fixture that asserts a failure it cannot demonstrate is flagged, not counted.

How it works

Two entry points, one fixed pipeline

Both entry points forward to _run_batch11_crown_jewel_organ, which drives the whole pipeline in one fixed order. run and run_batch11_saturation_engines_bundle are the two entry points. Both forward to _run_batch11_crown_jewel_organ, which drives the pipeline in a fixed order.

Manifest and digest checks before any logic

validate_source_manifest checks each copied module's digest, line count, and anchors first, so thirteen mechanisms rest on twelve modules before any logic runs. First it loads the required input batch11_saturation_engines_capsule_probe_manifest.json. Then validate_source_manifest checks each copied module against its recorded digest, line count, and required source anchors, so a drifted or partial copy is caught before any logic runs. EXPECTED_MODULE_IDS names the twelve copied modules; the market-board engines share one copied quant_presentation_mart source, which is why thirteen mechanisms rest on twelve modules.

Thirteen exercises in fixed order in _evaluate

_evaluate runs each copied function in the fixed EXPECTED_MECHANISMS order, and any reorder, block, or wrong module count becomes a finding. _evaluate then exercises all thirteen mechanisms in the order fixed by EXPECTED_MECHANISMS. Each exercise runs the copied function and returns a small computed output. _run_affinity_matrix, for example, calls the copied recommend_run_by_affinity over two candidate runs and records whether a stale terminal run was refused. Any reordering, blocked exercise, or wrong module count becomes a finding: BATCH11_MECHANISM_ORDER_INVALID, BATCH11_MECHANISM_BLOCKED, or BATCH11_SOURCE_MODULE_COUNT_INVALID.

Echo-risk pairing in _build_integrity_matrix

Each row pairs the mechanism's output with an independent probe over probe_input, and any disagreement sets echo risk that blocks the whole run. _build_integrity_matrix is where the negative cases are kept honest. For each mechanism it reads two values. One is the mechanism's own computed output. The other comes from _compute_negative_case_probe, which recomputes the case from the fixture's probe_input using the same copied function, then digests that input into fixture_probe_input_digest. A row's negative result counts as computed only when both values are true. When they disagree, the row's fixture_verdict_echo_risk is set. A non-zero fixture_verdict_echo_risk_count raises BATCH11_FIXTURE_VERDICT_ECHO_RISK and blocks the whole run. _source_evidence attaches the per-mechanism digest and anchor rows so each verdict is traceable to a specific copied module.

Forbidden-class scan and result record body scan

After validation the runner scans fixtures against forbidden classes and passes the payload through a body scan that blocks any leaked copied body. After evaluation the runner calls validate_negative_cases, then scans the fixture files with scan_paths against the forbidden classes loaded from core/private_state_forbidden_classes.json. Finally it writes the result, board, and validation records, and passes the assembled payload through scan_receipt_payload_for_bodies. If a copied body leaked into a record, that scan flips the status to blocked with CROWN_JEWEL_RECEIPT_BODY_SCAN_BLOCKED. result_card projects the passing payload into a compact card; main is the command-line dispatch for the run and validate-bundle actions.

Tier and binding disposition per row

Each row is tagged by verification tier and by a binding disposition recording how the mechanism relates to the rest of the system. Each row is tagged by tier and binding disposition. The six mechanisms in TIER_B_MECHANISMS are marked B_verified_by_controller; the rest are A_adversarially_verified_in_cap. MECHANISM_BINDING_DISPOSITIONS records how each mechanism relates to the rest of the system: a new import, an already-bound gate the bundle only re-checks, an under-bound path it extends, or a mechanism absent from the public component plane at import time.

flowchart TD input["probe manifest + copied source modules"] manifest["validate_source_manifest digest and anchor checks"] evaluate["_evaluate 13 exercises in fixed order"] matrix["_build_integrity_matrix mechanism value AND fixture probe"] probe["_compute_negative_case_probe recompute from probe_input"] scan["scan_paths + result record body scan"] record["metadata-only result record"] input --> manifest manifest --> evaluate evaluate --> matrix probe --> matrix matrix --> scan scan --> record

Negative cases

Thirteen named cases as claims to satisfy

EXPECTED_NEGATIVE_CASES declares one named case per mechanism, each an error-coded claim the copied code must actually satisfy on breaking inputs. EXPECTED_NEGATIVE_CASES declares thirteen named cases, one per mechanism, each with an error code. They read as claims the code must actually satisfy. A stale terminal run is refused even when made sticky and feed-rich (run_affinity_stale_terminal_rejected). A zero-energy calculator bucket produces no fake dominance share (calculator_zero_bucket_no_fake_dominance). A new gap blocks the delta gate (std_python_new_gap_blocks). A wrong route is graded down (exogenous_nav_wrong_route_graded_down). An unresolved hard failure blocks the portability rollup (portability_unresolved_hard_fail_blocks). A synthetic key shape blocks the projection scan (projection_secret_token_blocks). An unreachable navigation target returns a blocker rather than a fabricated path (frontend_nav_unreachable_target). A demo take missing its anchors scores below a complete one (demo_take_missing_anchor_penalized).

Synthetic secret-scan fixture, never live material

The probe recomputes each outcome from the fixture input, and the secret-scan case uses synthetic test strings, never live material, that must be blocked. For each case the probe recomputes the outcome from the fixture input. The secret-scan example is deliberate: the fixture carries a synthetic key shape and a private ledger path, both test strings, never live material, and the probe confirms both are blocked.

Prior Art Grounding

Characterization testing and the test-oracle problem

The lineage is characterization testing plus the test-oracle problem: a stored expectation is no oracle unless an independent probe from the fixture input agrees. The method is characterization testing: pin a piece of existing code by exercising it against fixtures and recording what it actually does, rather than asserting a value someone typed by hand. The negative-case discipline is a version of the test-oracle problem. A stored expectation is not an oracle if it can pass without the code running, so the probe computes an independent expectation from the fixture's own input and requires the two to agree. There is no external specification these engines implement, so the honest lineage is that engineering practice, not a standard. The links in earlier drafts to overload and backpressure literature described a different kind of saturation and are dropped here.

Validation Result record Path

Fixture files are inputs, not verdicts

Each fixture is a public probe_input the component recomputes into recorded probe, fixture, and mechanism values before counting a case verified. Negative-case fixture files are inputs, not verdicts. Each file carries a public probe_input; the component computes the corresponding probe and records fixture_probe_input_digest, fixture_computed_value, and mechanism_computed_value in the integrity matrix before counting a case as verified.

Run these from the microcosm-substrate/ public root:

What a pass certifies

A pass means digests and anchors matched, all thirteen exercises ran in order, every case reproduced with zero echo risk, and no body leaked. A pass means every copied module matched its digest and anchors, all thirteen exercises ran in order, every negative case was reproduced from its own input with zero echo risk, and no copied body reached a record. It is fixture evidence about this standalone component, nothing wider.