Set 8 Validator Checker Bundle

Six copied checker groups are executed

This component runs a selection of a copied validator's checker functions instead of asserting from a distance that a body imported but never exercised is correct. This component takes one copied validator source file and actually runs a selection of its checker functions, instead of asserting from a distance that the file is correct. An earlier import copied the whole validator body into Microcosm but only ever called its status-judge entry point. Most of the functions sat there as text that nothing exercised.

Observed behavior closes the import-only gap

It closes that gap for six named checker groups by importing the copied validator, driving selected functions with small public inputs, and writing a metadata-only result record. The bundle closes that gap for six named checker groups. It imports the copied self-indexing-cognitive-system/src/idea_microcosm/validators.py, drives selected functions with small public inputs, and writes a metadata-only result record. A pass means those six groups behaved the way their names claim. It does not mean the whole validator suite is fresh or correct.

Purpose

Copying a file is not running it

Copying a file and running it are different claims, so this component calls six checker groups to make a green run rest on observed behavior rather than file presence. Copying a file and running it are different claims. A copied body can contain a function called private_boundary_hits and still be wrong, because nobody ever fed it a string with a home path in it. Asserting "the file is present" is cheap and says almost nothing. This component picks six groups of checkers and calls them, so a green run rests on observed behavior rather than on the file existing.

Six groups span the validator's judgements

The six groups are chosen to span the validator's kinds of judgement, from source-shape anchoring to the no-write entry point, each reaching a different part of the imported body. The six groups are chosen to span the kinds of judgement the validator makes: source-shape anchoring, status-policy judging, private-boundary scanning, specimen checker groups, launch-gate checker groups, and the no-write validate(root, write_receipt=False) entry point. Each group reaches into a different part of the imported body.

Two choices keep a green run honest

Two design choices keep a green run honest: absent private state falls back to source anchors marked public_runtime_source_only, and negative cases are judged from engine outputs, not matched text. Two design choices keep a green run honest. When the private system state is not present on disk, the component does not pretend the runtime checkers passed. It falls back to reading the copied source for the named anchors and marks the rest of the engines public_runtime_source_only, recording that as a stated limit. And the negative cases are judged from the engine outputs, not from whether a fixture file happens to contain the right error string, so a check cannot pass by matching text.

How it works

Two entry points feed one runner

The run and run_batch8_validator_checker_bundle entry points feed one shared runner that validates the source manifest, calls _evaluate, and writes result, board, validation, and sign-off artifacts. The entry points are run and run_batch8_validator_checker_bundle. Both hand the input directory to a shared crown-jewel runner, which validates the source manifest and then calls _evaluate. The runner writes four artifacts: a result, a board, a validation record, and an sign-off record.

_evaluate picks live or source-only mode

_evaluate picks the mode first: six live engines when private state is present, or the source-anchor engine plus source-only witnesses otherwise, turning any non-passing engine into a finding. _evaluate picks the mode first. If the private system state is present and the input is a normal fixture, it runs six live engines. If the input is an exported bundle, or the private state is absent, it runs the source-anchor engine plus source-only witnesses for the other five. It then turns any non-passing engine into a finding, and adds a finding if the copied source manifest does not report exactly one module.

The six engines, in the order _evaluate lists them:

Shared checker helper and the bundle-mode stub

_zero_failure_matrix imports the validator and records a failure count per named checker, while _public_runtime_source_only_engine is the bundle-mode stub reporting a pass backed only by copied-source anchors. _zero_failure_matrix is the shared helper the two checker-group engines use. It imports the validator, calls each named checker against the private root, and records the failure count per checker. _public_runtime_source_only_engine is the stub the bundle mode substitutes for a live engine: it reports a pass backed by copied-source anchors, with macro_state_available: false stated on the row.

result_card carries authority and body floors

result_card compresses the run into two floors: an authority_floor of fixed all-false ceiling fields, and a body_floor recording body_in_receipt: false so no copied body text ships. result_card compresses the run into a card with two floors. The authority_floor copies the fixed ceiling fields, all false: release_authorized, publication_authorized, provider_dispatch, model_dispatch, source_mutation_authorized, full_validator_suite_freshness_claim, public_clone_or_hosting_authority, and test_completeness_proof. The body_floor records body_in_receipt: false so the card never carries copied body text.

flowchart TD A["Fixture input or exported bundle"] --> B["Validate source manifest"] B --> C{"Private state present?"} C -- "yes, fixture input" --> D["Six live checker engines"] C -- "no, or bundle input" --> E["Source-anchor engine plus source-only witnesses"] D --> F["Semantic negative-case checks"] E --> F F --> G["Result, board, validation, sign-off records"] G --> H["Result card: authority_floor and body_floor"]

Negative cases

Six negative cases judged from engine output

The fixture declares six negative cases with stable error codes, and _observed_negative_case reads live engine output or the source-only witness to decide whether each guard actually held. The fixture declares six negative cases in EXPECTED_NEGATIVE_CASES, each paired with a stable error code. _observed_negative_case reads the live engine output (or the source-only witness) to decide whether the guard actually held, and evaluate_negative_case emits the error code when it did.

The six cases and their error codes

The six cases run from missing_validator_source to validate_entrypoint_bypassed, and because judgement reads runtime evidence, each moves only when the matching engine observed the protective behavior. The cases are missing_validator_source (BATCH8_VALIDATOR_SOURCE_REQUIRED), policy_allows_poisoning (BATCH8_VALIDATOR_POLICY_POISONING_BLOCK_REQUIRED), private_boundary_blind (BATCH8_VALIDATOR_PRIVATE_BOUNDARY_REQUIRED), specimen_checker_missing (BATCH8_VALIDATOR_SPECIMEN_CHECKERS_REQUIRED), release_gate_missing (BATCH8_VALIDATOR_RELEASE_GATES_REQUIRED), and validate_entrypoint_bypassed (BATCH8_VALIDATOR_ENTRYPOINT_REQUIRED). Because the judgement reads runtime evidence, a case moves only when the matching engine actually observed the protective behavior.

Prior Art Grounding

Three ordinary patterns, no new invention

The component borrows three ordinary patterns, fixture-driven testing, schema validation, and policy/checker separation, adding nothing beyond bounded checker exercises over copied public source. The component borrows three ordinary engineering patterns: fixture-driven testing, where public inputs and expected negative cases are declared and replayed; schema validation, where a data shape is checked against a declared expectation; and policy/checker separation, where the code that decides is kept apart from the code that invokes it. Useful public references are JSON Schema, pytest fixtures, and Open Policy Agent. Microcosm keeps this component to bounded checker exercises over copied public source and adds nothing beyond that shape.

Validation Result record Path

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

What passing all three commands proves

A pass on all three commands means the six named groups behaved as claimed and the negative cases moved with runtime evidence, not a claim about the rest of the suite. The first command writes the bounded checker result and sign-off record. The second runs the exported bundle path, which checks copied source, manifest digests, and the source-only witnesses without importing the private validator. A pass on all three means the six named groups behaved as claimed and the negative cases moved with runtime evidence. It is not a claim about the rest of the suite.