Set 8 Policy Engines Bundle

Set 8 Policy Engines Bundle validates three deterministic public policy-engine exercises without running campaigns, providers, markets, or repository mutations.

Contains 21 sections · 1 diagram · 5 references

The write-up

This component takes three copied public policy-engine bodies and runs each one against a small fixed fixture to confirm it still makes the same deterministic decision. This component takes three copied public policy-engine bodies and runs each one against a small fixed fixture to confirm it still makes the same deterministic decision. The three engines are a lab contract audit red/green gate, a market-fusion readiness gate that fails closed, and a campaign dispatch transition adjudicator.

It is a checker, not an engine host. It does not run live campaigns, use external model services or models, mutate any repository, validate a market, or approve public sharing or launch. It is a checker, not an engine host. It does not run live campaigns, use external model services or models, mutate any repository, validate a market, or approve public sharing or launch. What it emits is a metadata-only result record: which engines were found, what each exercise decided, and the three stable negative-case codes that fired.

Purpose

Each of the three copied bodies shares one shape: a machine-checkable gate that runs before any judgement or downstream action and refuses by default when evidence is absent. Each of the three copied bodies shares one shape: a machine-checkable gate that runs before any judgement or downstream action and refuses by default when evidence is absent. Copying a gate into a public bundle is cheap. Confirming the copy still behaves like the original is the part that needs a test. This component answers one question for a cold reader: do these copied gate bodies make the same red, refuse, and reject decisions when driven by public fixture inputs?

A loose check would import the modules and assert they load. That passes even if a gate silently started accepting what it used to reject. A loose check would import the modules and assert they load. That passes even if a gate silently started accepting what it used to reject. So each exercise drives a concrete decision with a known answer and marks itself blocked the moment the decision changes.

How it works

run and run_batch8_policy_engines_bundle both forward to run_crown_jewel_organ with the shared SPEC, one for fixture input and one for the exported bundle. run and run_batch8_policy_engines_bundle both forward to run_crown_jewel_organ with the shared SPEC, one for fixture input and one for the exported bundle. The work happens in _capsule_evaluator. It loads the probe manifest, reads the declared engine ids, and checks that set equals the three ids in EXPECTED_ENGINES. A mismatch records BATCH8_POLICY_ENGINE_SET_MISMATCH. It then reads the source-module manifest through _source_rows and checks the three required module ids are present; a gap records BATCH8_POLICY_ENGINE_SOURCE_MODULE_MISSING. Only when all three modules are present does it run the exercises. Any exercise that returns a status other than pass records BATCH8_POLICY_ENGINE_RUNTIME_BLOCKED. The bundle is pass only when the findings list is empty.

The copied bodies are loaded by _load_copied_module, which resolves each module's target path from the manifest and executes it under a temporary sys.path, so a body import failure surfaces as a blocked exercise rather than a crash. The copied bodies are loaded by _load_copied_module, which resolves each module's target path from the manifest and executes it under a temporary sys.path, so a body import failure surfaces as a blocked exercise rather than a crash.

_exercise_lab_contract_audit writes a green set of lab node artifacts, runs the copied compute_lab_contract_audit, and expects status green. _exercise_lab_contract_audit writes a green set of lab node artifacts, runs the copied compute_lab_contract_audit, and expects status green. It then rewrites one compute-node output to carry a banned ? and runs the audit again, expecting status red with QUESTION_MARK_OUTPUT in the hard-fail list. Both halves must hold or the exercise is blocked.

_exercise_market_fusion calls the copied preflight_candidate_situation three ways. A registered situation must refuse with named reasons that do not include candidate_situation_gate_missing. _exercise_market_fusion calls the copied preflight_candidate_situation three ways. A registered situation must refuse with named reasons that do not include candidate_situation_gate_missing. An unregistered situation must refuse with candidate_situation_gate_missing. A malformed payload sent through preflight_consumer_claims must also refuse with that same missing-gate reason. The distinction is the point: a refusal the gate reasoned about stays legible as different from a fail-closed default on something it never saw.

_exercise_campaign_transition calls the copied validate_dispatch_transition. A candidate to blocked move must return legal_transition. _exercise_campaign_transition calls the copied validate_dispatch_transition. A candidate to blocked move must return legal_transition. A completed to completed move must return already_target. A completed to running move must raise CampaignTransitionError with the word terminal in its message, because completed is a terminal state.

evaluate_negative_case re-runs the matching exercise for each of the three declared cases and reports the stable error code when the refusal holds. evaluate_negative_case re-runs the matching exercise for each of the three declared cases and reports the stable error code when the refusal holds. result_card projects a run into a compact public card carrying engine ids, the authority floor from AUTHORITY_CEILING, and a metadata-only flag set, with no source bodies or scan scope in the card.

Diagram of the mechanism (6 steps).

Diagram source & refs

flowchart TD manifest["Probe manifest + source manifest"] evaluator["_capsule_evaluator engine set == EXPECTED_ENGINES three source modules present"] lab["_exercise_lab_contract_audit green then red on banned ?"] market["_exercise_market_fusion refuse; fail-closed on missing gate"] campaign["_exercise_campaign_transition legal / already_target / terminal"] result["metadata-only result record pass only when findings empty"] manifest --> evaluator evaluator --> lab evaluator --> market evaluator --> campaign lab --> result market --> result campaign --> result

Negative cases

The fixture declares three negative cases, one per engine, and EXPECTED_NEGATIVE_CASES maps each to its stable code. The fixture declares three negative cases, one per engine, and EXPECTED_NEGATIVE_CASES maps each to its stable code. lab_contract_question_mark_red_gate fires BATCH8_LAB_CONTRACT_QUESTION_MARK_RED_GATE when the injected ? output forces a red audit. market_fusion_missing_gate_refused fires BATCH8_MARKET_FUSION_MISSING_GATE_REFUSED when an unregistered situation refuses with the missing-gate reason. campaign_completed_to_running_refused fires BATCH8_CAMPAIGN_COMPLETED_TO_RUNNING_REFUSED when the terminal-state move is rejected. A green run with none of these firing would mean a gate stopped refusing, which the bundle reports as blocked.

Prior Art Grounding

Policy-as-code evaluation without policy authority

The design borrows the policy-as-code idea of evaluating policy as a separate engine over structured input, as in Open Policy Agent. The design borrows the policy-as-code idea of evaluating policy as a separate engine over structured input, as in Open Policy Agent. The explicit risk-gate and red/green decision posture echoes NIST's AI Risk Management Framework. The market-claim language stays inside the boundary described by the CFTC's prediction markets explainer. This component keeps the deterministic-gate and fail-closed-preflight shape and holds it to fixture inputs and copied public source.