Set 5 Authority and Systems Bundle

Authority-system checks run from copied bodies

A reader can inspect eight unrelated authority and systems mechanisms at once and confirm each refuses its wrong answer, without running any of the real machinery. This component lets a reader inspect eight unrelated authority and systems mechanisms at once, and confirm that each one refuses the wrong answer, without running any of the real machinery. The eight are: post-execution result record validation, reasoning replay scope, verifier-gated proof repair, process orphan classification, generated-state fixpoint settlement, trace-tape compaction, code blast radius, and doctrine-graph compilation.

Fixture cases exercise delegation and refusal

It ships an exact copy of each source body, checks the copies against digests and anchors, then runs a synthetic re-derivation per mechanism that recomputes its own verdict instead of echoing a stored answer. It carries an exact copy of each original source body in examples/batch5_authority_systems_capsule/exported_batch5_authority_systems_capsule_bundle/source_modules/ and checks those copies against recorded digests and required text anchors. Alongside that, it runs a small synthetic re-derivation for each mechanism. Every re-derivation recomputes its own verdict from the fixture input. It does not echo a stored answer.

The result carries evidence without inherited authority

The run emits a metadata-only result record for each mechanism, each naming a pass or a refusal and the scope limit it stayed inside. The output is a set of metadata-only result records under receipts/first_wave/batch5_authority_systems_capsule, each stating a pass or a refusal and the scope limit the run stayed inside.

Purpose

One shared discipline across eight subjects

The eight mechanisms share no subject, only the discipline of declining to claim more than they earned, where a loose version accepts a drifted result record, hands Lean a placeholder, or invents coverage. The eight mechanisms share nothing in subject. One checks post-execution result records. Another decides when a reasoning step needs re-running. Another gates a Lean proof attempt. Another classifies a stray process. What they share is a single discipline: each must decline to claim more than it earned. A loose version fails in the obvious ways. The result record check would accept a drifted result record. The proof gate would hand a placeholder to Lean. The orphan check would signal a live process. The blast-radius pass would invent coverage for a leaf that has no dependents.

Synthetic exercises beside verifiable source

Rather than replay the real tools, it verifies copied source against digests and anchors and runs one synthetic exercise per mechanism, passing a negative case only when the exercise itself reaches the refusal. The unusual choice here is that the component does not replay the real tools. It reads the copied source bodies, verifies them against digests and anchors, then runs one synthetic exercise per mechanism. A negative case passes only when the exercise itself reaches the refusal, not when a fixture asserts the refusal for it. That is the point of the design: you can read eight refusal behaviours in one place while the genuine source bodies stay verifiable next to them.

How it works

Two entrypoints share one evaluator

run and run_batch5_bundle both drive run_crown_jewel_organ with _evaluate and evaluate_negative_case, differing only by BUNDLE_INPUT_MODE, and both write metadata-only records with body_in_receipt always False. run and run_batch5_bundle are the two entrypoints. Both call the shared run_crown_jewel_organ driver with SPEC, passing _evaluate as the evaluator and evaluate_negative_case as the negative-case evaluator. run_batch5_bundle sets BUNDLE_INPUT_MODE so the same evaluator runs against the exported source bundle instead of the plain fixture. Both write metadata-only result records and, when asked, an sign-off record whose body_in_receipt field is always False.

The _evaluate pipeline order

_evaluate loads the manifest, checks the ten source paths against SOURCE_REQUIRED_ANCHORS, runs the eight exercises, then recomputes the eight negative-case probes, passing only when no findings were raised. _evaluate runs the pipeline in this order. It loads batch5_exercise_manifest.json. It compares the source manifest against SOURCE_REQUIRED_ANCHORS, the map of the ten required source paths to the text anchors each must contain, and emits BATCH5_SOURCE_MODULE_SET_INCOMPLETE if any are missing. It then runs the eight exercises, one per manifest block, and emits BATCH5_MECHANISM_EXERCISE_FAILED for any exercise that does not pass. Last, it recomputes the eight negative-case probes over sorted(EXPECTED_NEGATIVE_CASES). The run status is pass only when no findings were raised.

Exercises recompute and never act

Every mechanism exercise derives its verdict purely from a manifest block, touching no provider, no Lean run, no process signal, and no generated-state mutation. Each exercise reads a small block from the manifest and recomputes a verdict. None call a provider, run Lean, signal a process, or mutate generated state.

Probes rerun exercises, echo risk tracked

_compute_negative_case_probe reruns each exercise on the case's probe_input and rejects only on a recomputed refusal, while fixture_verdict_echo_risk_count flags any verdict not recomputed from its own input. The negative-case probes reuse those same functions. _compute_negative_case_probe runs the relevant exercise on the case's probe_input, then evaluate_negative_case marks the case rejected only when the recomputed verdict is the refusal. The run tracks a fixture_verdict_echo_risk_count: a case whose verdict was not recomputed from its own probe input counts as risk, so a fixture cannot pass a negative case by simply asserting the answer.

flowchart TD Manifest["Copied source bundle + exercise manifest digests and anchors checked first"] --> Evaluate["_evaluate source-set check, then eight exercises"] Evaluate --> Exercises["Eight mechanism exercises each recomputes its own verdict"] Exercises --> Probes["Negative-case probes rerun exercises on probe_input"] Probes --> Records["metadata-only result records status pass only when no findings"] Records --> Ceiling["Scope limit no external model access, no mutation, no proof success, no launch"]

Negative cases

Eight cases with stable error codes

EXPECTED_NEGATIVE_CASES declares eight cases, each carrying the stable error code the run must raise when its perturbation is caught. EXPECTED_NEGATIVE_CASES declares eight cases, each with a stable error code the run must raise when the perturbation is caught.

• receipt_provider_context_drift gives BATCH5_RECEIPT_DRIFT_REJECTED.
• irrelevant_context_no_replay gives BATCH5_REPLAY_IRRELEVANT_CONTEXT_NO_REPLAY.
• proof_contract_sorry gives BATCH5_PROOF_CONTRACT_BAD_PROOF_REJECTED.
• live_descendant_never_signal gives BATCH5_ORPHAN_REAPER_LIVE_DESCENDANT_NEVER_SIGNAL.
• nonconverging_residual_classified gives BATCH5_DRAINER_NONCONVERGING_RESIDUAL_CLASSIFIED.
• trace_omission_receipt_required gives BATCH5_TRACE_OMISSION_RECEIPT_REQUIRED.
• blast_radius_leaf_empty gives BATCH5_BLAST_RADIUS_EMPTY_LEAF_DOES_NOT_INVENT_COVERAGE.
• doctrine_deleted_path_drift gives BATCH5_DOCTRINE_DELETED_PATH_DRIFT_REPORTED.

Prior Art Grounding

Provenance, tracing, and supply-chain attestation

The design borrows the lineage, trace, and attestation shape of W3C PROV, OpenTelemetry, and SLSA provenance, while staying bounded to copied public source, synthetic inputs, and refusal checks. This bundle borrows from provenance interchange, trace instrumentation, and software supply-chain attestation practice. W3C PROV models the entities, activities, and agents that produce data so a reader can judge its reliability. OpenTelemetry is a vendor-neutral pattern for traces, metrics, and logs across composed systems. SLSA provenance treats artifact origin, builder identity, and build parameters as explicit attestable metadata. The lineage, trace, and attestation shape is borrowed; the exercise stays bounded to copied public source bodies, synthetic inputs, and refusal checks.

Validation Result record Path

Reader-verifiable commands, run from the microcosm-substrate/ public root:

PYTHONPATH=src ../repo-python -m microcosm_core.organs.batch5_authority_systems_capsule run \
  --input fixtures/first_wave/batch5_authority_systems_capsule/input \
  --out /tmp/microcosm-batch5-authority-systems-vrp \
  --card
PYTHONPATH=src ../repo-python -m microcosm_core.organs.batch5_authority_systems_capsule run-batch5-bundle \
  --input examples/batch5_authority_systems_capsule/exported_batch5_authority_systems_capsule_bundle \
  --out /tmp/microcosm-batch5-authority-systems-bundle-vrp \
  --card
PYTHONPATH=src ../repo-pytest tests/test_batch5_authority_systems_capsule.py -q --basetemp /tmp/microcosm-batch5-authority-systems-tests

What each command verifies

The first command writes the synthetic result, the second validates copied modules, digests, anchors, and secret-exclusion, and the test file checks exercises, bundle, omission record, and the eight refusal cases. The first command writes the synthetic exercise result. The second validates the copied source modules, their manifest digests, anchor rows, and secret-exclusion posture while keeping source bodies out of the record. The test file checks the exercises, the exported bundle, the omission record, the body-scan boundary, and the eight refusal cases. A pass here means the bounded exercise ran and its refusals held, nothing more.