Set 8 Compliance Pipeline Bundle

batch8_compliance_pipeline_capsule takes two internal subsystems, copies their source bodies into the public clone, and runs them on synthetic inputs. batch8_compliance_pipeline_capsule takes two internal subsystems, copies their source bodies into the public clone, and runs them on synthetic inputs. The first subsystem is a compliance scanner registry and its bounded ledger builder. The second is a six-stage pipeline that turns a long block of raw text into a short observe plan. The component runs six checks over the copied bodies and writes result records that carry no source text.

Most bundle components in this group are shape linters. They read the copied source for expected tokens and pass when the tokens are present. Most bundle components in this group are shape linters. They read the copied source for expected tokens and pass when the tokens are present. This one goes further for the parts it can. Several of its checks import the copied bodies and call the real functions on made-up inputs, so a pass records observed behaviour, not just presence.

The question it answers is narrow. When these two subsystems are copied into the public clone and driven on a sample, do they still behave the way their internal contracts say, without touching a live ledger or dispatching any work? The question it answers is narrow. When these two subsystems are copied into the public clone and driven on a sample, do they still behave the way their internal contracts say, without touching a live ledger or dispatching any work?

Purpose

A loose check would grep the copied files for a function name and stop there. That proves the text was copied, not that it runs. A loose check would grep the copied files for a function name and stop there. That proves the text was copied, not that it runs. The one behaviour worth showing directly is digest preservation. The pipeline compresses a long input down to a short digest before it decides what to inspect next. If that compression silently drops an instruction, the downstream agent never sees it. So the component feeds the real digest_raw_seed an eighty-line block of low-signal text with one directive line buried inside, then checks the directive survives. The paired negative case removes the marker that recognises directive lines and confirms the directive is then lost. That pairing is the point: a compression step asserted to keep the one line that matters, with a test that fails when it does not.

The standing limit is deliberate. The bounded compliance check runs the ledger builder in check-and-report mode, which reads and reports but never writes. The standing limit is deliberate. The bounded compliance check runs the ledger builder in check-and-report mode, which reads and reports but never writes. The pipeline checks stop before any dispatch. The result is evidence that the copied mechanics work on a sample, not a claim that the live compliance ledger is fresh or that every branch is covered.

How it works

run and run_batch8_compliance_pipeline_bundle both call run_crown_jewel_organ with _evaluate as the evaluator and evaluate_negative_case as the negative-case evaluator. run and run_batch8_compliance_pipeline_bundle both call run_crown_jewel_organ with _evaluate as the evaluator and evaluate_negative_case as the negative-case evaluator. _evaluate first decides its mode. If the input directory holds a source_module_manifest.json and a source_modules directory, it is an exported bundle and every check runs in standalone mode against the copied token contracts only. A plain fixture input lets the checks import live modules from the parent tree where present. _evaluate then runs six checks in order and passes only if all six pass and the manifest records at least eleven copied source modules, which is the count in SOURCE_REQUIRED_ANCHORS.

The six checks:

Two of these are worth reading closely. _compliance_coverage_bounded_check builds the command build_compliance_ledger.py --check --report --standard-id std_compliance_coverage --standard-id std_microcosm, runs it through _run_public_witness, and parses the summary. Two of these are worth reading closely. _compliance_coverage_bounded_check builds the command build_compliance_ledger.py --check --report --standard-id std_compliance_coverage --standard-id std_microcosm, runs it through _run_public_witness, and parses the summary. The pass condition is strict. The run must report wrote_ledger false, both standard ids refreshed, a partial projection, a ratchet status of ready_next_row or closed_batch, and a truthful check result, where truthful means one of ok with no error findings, failed caused by error findings, or failed caused by a missing projection artifact. When the parent repo is not present the check falls back to _standalone_compliance_coverage_contract, which reads the copied builder for its bounded-check tokens instead of running it.

_pipeline_digest_and_shard_normalization builds a source note of a heading, one narrative line, one directive line, and eighty low-signal lines, then digests it to 240 characters. _pipeline_digest_and_shard_normalization builds a source note of a heading, one narrative line, one directive line, and eighty low-signal lines, then digests it to 240 characters. It checks directive_preserved. It also feeds _normalize_shards_payload a shard with status weird and checks the status is rewritten to pending while the original value is kept as status_variant. It calls _pick_diverse_shards and checks one concept group contributes at most two shards.

The six negative cases each copy the bundle to a scratch directory, remove one load-bearing token from one copied body, and re-run the matching check. The six negative cases each copy the bundle to a scratch directory, remove one load-bearing token from one copied body, and re-run the matching check. _mutated_source_negative carries this out and reports blocked only when the check both blocks and reports the expected condition, so a green run means each contract was exercised rather than skipped.

flowchart TD bundle["Copied source bundle 11 bodies body_in_receipt: false"] compliance["Compliance checks registry witness, bounded check, baseline scanner"] pipeline["Pipeline checks digest and shards, compile helpers, dispatch boundary"] negatives["6 negative cases remove one token per body; matching check must block"] records["Result records result, board, validation"] bundle --> compliance bundle --> pipeline bundle --> negatives compliance --> records pipeline --> records negatives --> records

Negative cases

EXPECTED_NEGATIVE_CASES names six. missing_compliance_registry removes _LazyComplianceAdapters from the copied registry and expects code BATCH8_COMPLIANCE_REGISTRY_REQUIRED. EXPECTED_NEGATIVE_CASES names six. missing_compliance_registry removes _LazyComplianceAdapters from the copied registry and expects code BATCH8_COMPLIANCE_REGISTRY_REQUIRED. bounded_check_failed removes _bounded_check_command from the builder. baseline_missing_standard flips baseline_inventory_only in the baseline adapter. digest_loses_directive removes the directive marker from the extract stage so the buried line drops. compile_helper_empty_mentions removes a compile helper name. pipeline_boundary_missing removes observe_dispatch_skipped from the execute stage. Each case passes only when the matching check turns from pass to blocked.

Prior Art Grounding

This component borrows from control-assessment, policy-as-code, provenance, and observability practice without adopting any one framework. This component borrows from control-assessment, policy-as-code, provenance, and observability practice without adopting any one framework. Useful anchors are NIST SP 800-53 Rev. 5 as a control-catalog pattern for naming and reporting control posture, Open Policy Agent as a pattern for evaluating structured inputs without embedding every rule in the caller, SLSA provenance for treating artifact origin as an explicit attestation, and OpenTelemetry for staged-pipeline instrumentation. The component borrows the scanner, policy, and pipeline-stage shapes and validates bounded no-write behaviour and pure helper mechanics only.

Validation Result record Path

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

The fixture command writes the exercise result and sign-off JSON. The bundle command validates the copied source modules, manifest digests, observed negative cases, and body scans. The fixture command writes the exercise result and sign-off JSON. The bundle command validates the copied source modules, manifest digests, observed negative cases, and body scans. A pass means all six checks passed, the eleven source modules were present, and the six negative cases each blocked. These validation result records are the evidence a reader recomputes; they do not refresh the live ledger or dispatch any work.