Set 9 Source Engines Bundle

Ten copied engines run against public fixtures

This component copies ten backend and governance engine bodies into a public bundle and runs each against fixtures, emitting metadata-only records of what ran and whether the paired rejection fired. This component copies ten backend and governance engine bodies out of the larger system into a public bundle, then runs each one against small fixtures to confirm the copied code still computes what it did before. It emits metadata-only records: which engine ran, what it produced, and whether the paired rejection fired.

Execution tests behavior beyond matching digests

A digest proves the bytes match but not that the logic still behaves, so the bundle loads each copied module and calls its real functions rather than trusting baked-in output. Copying a file into a public bundle proves that the bytes match. It does not establish that the logic still behaves. This component closes that gap by loading each copied module and calling its real functions, rather than comparing against output files baked once and trusted forever.

One bundle spans ten bounded engine domains

The result is one reproducible evidence bundle spanning ten domains, from provenance lineage and approval adjudication to host-pressure admission and milestone-relative quality accounting. The result is a reproducible evidence bundle for provenance lineage, approval adjudication, Python symbol indexing, mission-graph wave ordering, dependency pin drift, config-authority audit, host-pressure admission, doctrine enrichment, worker pre-dispatch gating, and milestone-relative quality accounting.

Purpose

A digest check cannot prove behavior

An exported copy can pass a digest check and still be dead, because a digest confirms identical bytes but says nothing about whether the function still runs. An exported copy can pass a digest check and still be dead. A digest says the bytes are identical to what was copied. It says nothing about whether the function still runs, or whether a later edit quietly changed a branch. A result file that is written once and checked forever has the same weakness: it stops tracking the code it claims to describe.

Live execution guards the loose-copy failure

The component ties proof to live execution, loading each engine from its copied file so the check moves when the body moves and a digest-faithful but behavior-lost bundle fails. This component ties the proof to live execution. Each of the ten engines is loaded from its copied file and driven with a fixture, so the check moves when the copied body moves. That is the point of the "loose copy" failure it guards against: a bundle that looks faithful because the digest matches, while the behaviour it was supposed to preserve is gone.

How it works

The pipeline runs in four stages, in this order.

Stage one resolves the source manifest

First _source_rows reads source_module_manifest.json, one row per copied engine carrying a module id, target path, expected digest, and required anchors, while helpers locate each copied file. First it resolves the source manifest. _source_rows reads source_module_manifest.json, one row per copied engine, each with a module id, a copied target path, an expected digest, and required anchor strings. _source_module_path and _source_module_text locate the copied file for a given module id.

Stage two checks digests and anchors

Second, a copied body failing its manifest digest raises CROWN_JEWEL_SOURCE_DIGEST_MISMATCH, and one missing a required anchor raises CROWN_JEWEL_SOURCE_ANCHOR_MISSING even after the digest is refreshed. Second it checks digests and anchors. A copied body whose bytes no longer match its manifest digest fails CROWN_JEWEL_SOURCE_DIGEST_MISMATCH. A body that has lost one of its required anchors fails CROWN_JEWEL_SOURCE_ANCHOR_MISSING, even when the digest was refreshed to match the edit.

Stage three runs the ten exercises

Third, _run_all_exercises drives all ten: nine import the copied module and call its functions, while the text-backed mission graph gates a local reimplementation on anchors in the copied text. Third it runs the exercises. _run_all_exercises drives all ten. Nine are path-backed: the copied module is imported with _load_python_source_module and its own functions are called against a fixture in a temporary directory. One, the mission graph, is text-backed: _source_backed_mission_graph_contract scans the copied text for branch anchors and gates a local reimplementation on whether they are present.

Stage four evaluates and emits records

Fourth, evaluate collects exercise statuses, counts mechanisms and modules, and returns a body_in_receipt-false record, with run and run_batch9_bundle wrapping the two paths and result_card projecting a compact card. Fourth it evaluates and emits. evaluate collects the exercise statuses, counts the declared mechanisms against EXPECTED_MECHANISMS, counts copied modules, and returns a record with body_in_receipt set to false. run wraps this for the fixture path and run_batch9_bundle for the exported bundle path. result_card projects a compact card carrying an authority floor and a body floor.

Each engine is exercised through its real imported function:

Local reference implementations define expected shape

The component also carries local reference implementations that define the expected shape, but for nine engines the imported copy runs, with the mission graph the sole case where the local body runs. The component also carries local reference implementations, such as resolve_lineage, build_ast_doc_tree, and compile_mission_graph. These define the expected shape. For nine engines the imported copy is what actually runs; the mission graph is the one case where the local body runs, gated by anchors found in the copied text.

flowchart TD manifest["source_module_manifest.json 10 copied engine bodies"] fixtures["fixture input positive fixture + 10 negative cases"] digest["digest + anchor check bytes match, anchors present"] exercises["_run_all_exercises load each copy, call its functions"] neg["negative cases apply fixture_patch, rerun"] emit["evaluate metadata-only record + card"] manifest --> digest fixtures --> exercises digest --> exercises exercises --> neg exercises --> emit neg --> emit

Negative cases

Each engine ships one paired rejection, and evaluate_negative_case patches the positive fixture, reruns the exercises, and blocks with a stable error code only when the rejection actually fired. Each engine ships one paired rejection. evaluate_negative_case takes a case id, loads <case_id>.json, applies its fixture_patch onto the positive fixture with _deep_update, reruns the exercises, and calls _negative_case_observed to inspect one field. If the rejection fired the case returns status blocked with its stable error code; if it did not, the case fails. The ten cases and their codes:

• lineage_self_loop_pruned -> BATCH9_LINEAGE_SELF_LOOP_PRUNED
• approval_preacquired_claim_refused -> BATCH9_APPROVAL_PREACQUIRED_CLAIM_REFUSED
• ast_syntax_error_gap -> BATCH9_AST_SYNTAX_ERROR_GAP
• mission_graph_missing_target -> BATCH9_MISSION_GRAPH_MISSING_TARGET
• dependency_pin_drift_detected -> BATCH9_DEPENDENCY_PIN_DRIFT_DETECTED
• config_authority_mutation_allowed_rejected -> BATCH9_CONFIG_AUTHORITY_MUTATION_ALLOWED_REJECTED
• host_pressure_auto_policy_blocks -> BATCH9_HOST_PRESSURE_AUTO_POLICY_BLOCKS
• doctrine_enrichment_unindexed_empty -> BATCH9_DOCTRINE_UNINDEXED_EMPTY
• worker_forbidden_surface_blocked -> BATCH9_WORKER_FORBIDDEN_SURFACE_BLOCKED
• milestone_missing_committed_at_bucketed -> BATCH9_MILESTONE_MISSING_COMMITTED_AT_BUCKETED

Two tamper modes on the copied bodies

Two tamper modes sit alongside these: an unrefreshed digest fails CROWN_JEWEL_SOURCE_DIGEST_MISMATCH, and a removed anchor still fails CROWN_JEWEL_SOURCE_ANCHOR_MISSING, keeping fixture-only replacements outside the proof shape. Two tamper modes sit alongside these. An edit to a copied body with no manifest digest refresh fails CROWN_JEWEL_SOURCE_DIGEST_MISMATCH. Removing a required anchor while refreshing the digest still fails CROWN_JEWEL_SOURCE_ANCHOR_MISSING. Together these keep a fixture-only or static-record replacement outside the accepted proof shape.

Prior Art Grounding

Golden-master testing that runs the copy

The component follows the characterization or golden-master tradition, pinning behavior with deterministic fixtures, but its variation runs the copied code rather than comparing against a frozen output file. This component follows the characterization, or golden-master, testing tradition (Feathers, Working Effectively with Legacy Code), which pins existing behaviour with deterministic fixtures before trusting it. The variation here is that the pin runs the copied code rather than comparing against a frozen output file. The result is fixture-bound import evidence, not lineage truth, human approval authority, or market-level conclusions.

Validation Result record Path

Run these from the microcosm-substrate/ public root:

What the four commands together prove

The four commands prove the fixture and bundle paths, the focused test covers imports and rejections, and the corpus check confirms the projections stay consistent, nothing wider. The first command proves the public fixture path. The second proves the exported bundle path. The focused test covers exact-copy imports, source-sensitive behaviour shifts, digest-mismatch blocking, required-anchor removal, and the semantic rejections above. The corpus check confirms the generated instance, Mermaid, Atlas card, and this Markdown stay mutually consistent. A pass means the copied bodies and fixtures ran and matched here, nothing wider.