Standards Meta Diagnostics

It confirms every accepted component still ties to a standard, a documented way to run it, and a saved result record, emitting a coded finding when a tie is missing. standards_meta_diagnostics is a coverage checker. It reads the project's public catalogs and confirms that every accepted component is still tied to a written standard, a documented way to run it, and a saved result record. When one of those ties is missing, it emits a structured finding with a named error code instead of a paragraph of prose.

Silent drift is the failure: attachments fall out of step one component at a time with nothing breaking, so a gap sits unnoticed until a reader hits the hole. The problem it solves is silent drift. A spine of accepted components stays coherent only while each one keeps its four attachments: a standard that describes it, a runtime contract that runs it, a result record that holds its last verdict, and a stated limit on what it is allowed to claim. As the spine grows, those attachments fall out of step one component at a time, and nothing breaks when they do. A new component can be accepted while its standard file, registry row, or result-record ref is never added. The gap just sits there until a reader trusts the spine and finds a hole.

Its output is a metadata-only record of refs, counts, hashes, and verdicts, readable in the open without exporting private source. The check emits a metadata-only result record: refs, counts, hashes, and verdicts, never the source bodies they describe. So a coverage report can be read in the open without exporting private source.

Purpose

Coverage projected from the live registry

Positive coverage is projected from the live public registry rather than stored, so four public surfaces must agree on one component set or a mismatch is a finding. A loose check fails here in a specific way. If the diagnostic held its own checked-in list of what the spine should contain, that list would itself go stale, and a stale example would quietly become the thing the spine is measured against. So the positive coverage is projected from the live public registry rather than stored. The accepted-component list, the standard rows, the runtime-contract rows, and the result-record refs then have to agree on exactly the same set of components. Any component that appears in one surface but not another is a finding.

Five negative fixtures keep it falsifiable

Five negative fixtures must each surface their expected failure, and the run blocks if one that should fail passes. The check is also falsifiable. It carries five negative fixtures that each must surface their expected failure. If a fixture that should fail passes, the run is blocked, so the checker cannot silently stop catching a class of gap.

How it works

Two entry points drive the same validator over different inputs.

run drives the fixture path

run calls _build_result with live positive projection and all five negatives evaluated, then attaches a freshness basis and writes result records. run is the fixture path. It calls _build_result with include_negative=True and project_positive_from_live=True, so the positive rows come from live registry state and all five negative fixtures are evaluated. It then attaches a freshness basis and calls _write_receipts.

run_diagnostics_bundle reads the exported bundle

run_diagnostics_bundle reads the three exported JSON inputs directly and can return a cached result when the input digests are unchanged. run_diagnostics_bundle is the exported-bundle path. It calls _build_result with include_negative=False and project_positive_from_live=False, reading the three exported JSON inputs directly. With reuse_fresh_receipt it can return a cached result when _fresh_bundle_receipt confirms the input digests have not changed.

_build_result is the core. In order, it:

1. loads the payloads through _load_payloads, which either reads standards_inventory.json, organ_runtime_contracts.json, and diagnostic_policy.json, or projects those rows from the live registry via build_diagnostics_input_payloads;
2. validates any exported source-module manifest with _source_module_manifest_result, which digest-checks each copied body;
3. runs scan_paths over every input with the forbidden-class policy loaded by load_forbidden_classes;
4. computes _positive_findings over the accepted-component set and _negative_findings over the five negative fixtures;
5. assembles the status.

When status is pass versus blocked

Status is pass only with no positive findings, no missing negatives, no blocking secret hits, and a passing or absent manifest; anything else is blocked. The status is pass only when there are no positive findings, no missing negative cases, no blocking secret hits, and the source-module manifest is pass or absent. Anything else is blocked.

_positive_findings checks each accepted component

_positive_findings records a gap when any accepted component's inventory row, refs, standard identity, result records, or runtime step is missing, and it rejects overclaim flags. _positive_findings does the coverage work. For each component id in the policy's accepted_organ_ids, it looks up the inventory row and the runtime row, and it derives the expected standard identity std_microcosm_<id> and the expected file standards/std_microcosm_<id>.json. It records a finding when the inventory row is absent, when standard_id, standard_ref, or registry_row_ref is empty, when the standard identity does not match the live file, when receipt_refs is empty, or when the runtime row lacks a cli_command or a runtime_step. It also rejects a policy that sets any overclaim flag such as release_authorized.

Negative findings, result records, and the compact card

_negative_findings records each fixture's triggered code, _write_receipts writes the result, board, and validation records, and result_card projects a card that omits the detailed lists. _negative_findings walks the five negative fixtures and records the error code each one is built to trigger. _write_receipts writes the result, board, and validation records with write_json_atomic, plus an sign-off record when asked. result_card projects a compact card that omits the covered-component list, findings, and source refs from its payload while keeping them in the full result.

flowchart TD inventory["standards_inventory"] contracts["runtime contract inventory"] policy["diagnostic_policy"] negatives["five negative fixtures"] build["_build_result"] positive["_positive_findings: coverage per component"] negative["_negative_findings: expected failures"] scan["scan_paths: secret exclusion"] status["status: pass or blocked"] result records["_write_receipts: metadata-only records"] inventory --> build contracts --> build policy --> build negatives --> build build --> positive build --> negative build --> scan positive --> status negative --> status scan --> status status --> result records

Negative cases

Five negative fixtures each map to one expected error code, and a run that fails to surface any of them is blocked: Five negative fixtures each map to one expected error code, and a run that fails to surface any of them is blocked:

• missing_standard_ref yields STANDARDS_META_MISSING_STANDARD_REF
• unmapped_accepted_organ yields STANDARDS_META_UNMAPPED_ACCEPTED_ORGAN
• missing_receipt_ref yields STANDARDS_META_MISSING_RECEIPT_REF
• release_overclaim yields STANDARDS_META_AUTHORITY_OVERCLAIM
• private_source_leakage yields STANDARDS_META_PRIVATE_SOURCE_FORBIDDEN

What the current fixture reports

On the current fixture the sign-off record reports status: pass with 88 accepted components fully mapped, all five error codes present, and zero blocking secret hits. On the current fixture the sign-off record reports status: pass with accepted_organ_count: 88, standard_mapping_count: 88, runtime_contract_count: 88, all five expected error codes present, and secret_exclusion_scan.blocking_hit_count: 0.

Prior Art Grounding

Grounded in schema and contract validation

The design follows JSON Schema and OpenAPI validation practice, applying it to the launch boundary as bounded evidence about consistency rather than a claim of authority. This component is grounded in schema and contract validation practice rather than in a claim that a diagnostic creates authority. JSON Schema treats a schema as a machine-readable vocabulary for validating structured JSON data, and OpenAPI uses interface descriptions so a consumer can understand an API without reading its source. The check applies that pattern to the launch boundary: standards, adapter contracts, result records, and scope limits are validated as public projections, and the check stays bounded evidence about consistency.

• JSON Schema validation and structured-data constraints: https://json-schema.org/
• OpenAPI interface descriptions and conformance expectations: https://spec.openapis.org/oas/latest.html

Validation Result record Path

Reader validation without durable writes

./repo-pytest tests/test_standards_meta_diagnostics.py -q \
  --basetemp=/tmp/microcosm_standards_meta_diagnostics_pytest
./repo-python scripts/build_doctrine_projection.py \
  --check-paper-module-corpus

What a pass certifies

A pass means positive inputs cover the accepted set, the five negatives surface their named codes, and the paper-module corpus is in parity, as validator evidence about consistency. A pass means the positive inputs cover the accepted-component set, the five negative cases surface their named error codes, and the paper-module corpus is in parity. It is validator evidence about consistency.