Architecture & navigation

Teleology

pattern_binding_contract is the public root component that binds pattern rows to source-available source bundles, public runtime refs, authority-chain handles, scope boundaries, and secret-exclusion result records. Synthetic rows are allowed only as regression controls or negative cases; they are not product evidence.

Purpose

A mined engineering pattern is a tempting thing to publish on its own. It reads like a self-contained insight, so it is easy to lift a single row out of a private ledger and present it as a finished public claim. This component exists to stop that. It answers one question: can a given pattern row be admitted to the public surface, and if so, under exactly what evidence and what ceiling?

The check is binding rather than display. Every pattern row must name a source bundle that points at a real public runtime ref or regression-harness ref, a governing standard, and an scope boundary. A row that lacks any of these, duplicates another row's id, or claims to be a standalone public leaf is rejected. The same validator runs deliberate negative cases alongside the positive control, so the result record proves not only that good rows pass but that each known failure mode is still caught.

The less obvious idea is truth accounting. When an exported bundle is validated, the component separates rows that merely describe runtime metadata from rows that represent a real pattern-ledger import, and records that a high accepted-row count is not the same as system progress. This guards against the quiet inflation where counting accepted rows starts to read like a measure of how much real work has landed. The route-readiness layer closes the matching gap on the selector side: a row can look selectable in isolation, but it is only admitted through the component that owns it, its fixture contract, and a gate that refuses to let hard no-standalone rows appear as selectable targets.

Public Contract

The validator checks required binding fields, duplicate pattern conflicts, unsupported authority-chain handles, unresolved reference bundles, secret/provider/operator body sentinels, and public-leaf overclaim failures. It emits command-owned result records under receipts/first_wave/pattern_binding_contract/.

The exported system bundle also carries the source route-readiness selector overlays as public source-open bodies: examples/pattern_binding_contract/exported_route_readiness_bundle/. The validator recomputes the selector contract against the imported pattern ledger, route-readiness audit, row-to-component router, route cards, fixture specs, decision matrix, dependency DAG, internal routing graph, and copied source validation report. This closes the old gap where a mined pattern row could look selectable without opening the component bundle that owns it.

Cold readers should use microcosm pattern-route-readiness validate-bundle against examples/pattern_binding_contract/exported_route_readiness_bundle/ when the question is selector admission rather than generic pattern binding. The older pattern-binding validate-route-readiness-bundle action remains a compatibility route to the same validator.

Shape

flowchart LR subgraph Inputs["Pattern-binding inputs"] Patterns["Pattern rows id, governing standard, scope boundary, source refs, projection posture"] Bundles["Source bundles metadata-only refs to public runtime or regression harness"] Handles["Authority-chain handles resolver result records"] end Validator["pattern_binding_contract required fields, duplicate ids, bundle resolution, secret-exclusion scan"] subgraph Negative["Refusal floor"] Dup["Duplicate id rejected"] Leak["Private body leak rejected"] Overclaim["Public-leaf overclaim rejected"] Unsupported["Unsupported authority handle not upgraded"] end subgraph Bundle["Exported-bundle path"] Truth["Truth accounting runtime-metadata rows vs real pattern-ledger import"] RouteReadiness["Route-readiness selector component-first admission, fixture contract, hard no-standalone gate"] end Result records["Result records refs, digests, counts, verdicts; body text omitted"] Patterns --> Validator Bundles --> Validator Handles --> Validator Validator --> Negative Validator --> Bundle Truth --> RouteReadiness Negative --> Result records Bundle --> Result records

Evidence Binding

Accepted component row: core/organ_registry.json::implemented_organs[pattern_binding_contract]. Evidence class: core/organ_evidence_classes.json::organ_evidence_classes[pattern_binding_contract] with rank 5 semantic-validator authority. The runtime locus is src/microcosm_core/organs/pattern_binding_contract.py, with focused coverage in tests/test_pattern_binding_contract.py.

Paper bundle authority: core/paper_module_capsules.json#paper_module.pattern_binding_contract. Mechanism source: core/mechanism_sources.json#mechanism.pattern_binding_contract.validates_public_pattern_bindings.

Reader Evidence Routing

Read this module as a public binding membrane for pattern rows, not as a private pattern-ledger certificate or a standalone public-leaf selector. Start with paper_modules/pattern_binding_contract.json for the bundle payload, then open standards/std_microcosm_pattern_binding_contract.json to check the required fields, public/private boundary, source-open body import floor, route-readiness rules, and result record expectations.

Use core/fixture_manifests/pattern_binding_contract.fixture_manifest.json before inspecting fixtures or exported bundles. The manifest and the source_module_manifest.json files name the copied source body floor; result record payloads should carry source refs, digests, anchors, counts, verdicts, and omission result records rather than inlining body text.

Treat route-readiness selection as component-first evidence. A mined pattern row can be selectable only through the route-readiness bundle, selector contract, and result records that keep duplicates, unknown refs, private leakage, missing fixture contracts, dependency cycles, hard no-standalone rows, and companion-overlay gaps rejected.

Prior Art Grounding

This component follows the software pattern-language tradition of making reusable engineering structures explicit, named, and reviewable. The Hillside patterns library is the direct prior-art family for treating patterns as shared vocabulary rather than loose implementation notes.

The binding layer also borrows from provenance and supply-chain attestation patterns. W3C PROV motivates the source/ref/evidence relation shape, while SLSA and in-toto motivate digest-bound artifact claims and step-level metadata. Microcosm applies those ideas to pattern rows and route-readiness selectors, not to launch certification.

Re-entry condition: if copied source bodies, route-readiness overlays, or negative-case rules change, rerun the three first commands above and update this paper module plus standards/std_microcosm_pattern_binding_contract.json from the new result record fields. Do not raise the scope limit from selector and binding validation to launch, public sharing, private-data equivalence, or standalone public-leaf authority.

Validation Result record Path

From microcosm-substrate/, reproduce this page's proof boundary with temporary result records:

These checks validate public pattern-binding fixtures, system-bundle result records, route-readiness selector result records, and metadata-only authority handles only; they do not certify the private pattern ledger, hosted readiness, launch, external model access, private-data equivalence, or whole-system correctness.

The current authority is the runtime result record set under receipts/first_wave/pattern_binding_contract/; do not cite a separate pattern-specific sign-off result record unless an sign-off-lane artifact is actually present. Cold readers should inspect result record fields rather than markdown constants: status, secret_exclusion_scan, source_open_body_imports, truth_accounting, route_readiness_summary, selection_contract, and source_manifest.

pattern_assimilation_step is the public completion-learning contract for landed components. It validates that every component recorded as landed in a fixture set carries exactly one same-lane completion decision, and that the decision resolves to a result record that can be inspected rather than to a phrase.

Purpose

When a development pass claims that local work taught the system something, that claim is usually prose: a note that the run "improved the fixture" or "found nothing to refine". Prose is easy to assert and impossible to check. This component answers a single question: did each landed component actually deposit an inspectable completion decision, or is the learning claim unbacked?

The decision is forced into one of two typed shapes. Either a concrete refinement result record that names the owner surface it changed and the artifact it touched, or a typed nothing_to_refine result record that proves stewardship was checked, the next-best lane was considered, and a re-entry condition was recorded. A landed component with no completion, or with a completion that points at a result record that does not exist or does not match, is rejected. So is a duplicate result record id that would let one lesson be counted twice.

The interesting constraint is the one the component refuses to relax. A local lesson may route to the owner surface that owns the affected artifact, but it may not promote itself into global doctrine. A refinement row that sets claims_global_doctrine_authority is blocked outright. The point is that learning has to land on a specific board with a named steward, not become a free-floating rule, which is the failure mode that turns a useful local note into unsupported general advice.

Route Card

• Component id: pattern_assimilation_step
• JSON bundle authority: core/paper_module_capsules.json::paper_module.pattern_assimilation
• Accepted-component evidence class: semantic_validator
• Standard: standards/std_microcosm_pattern_assimilation_step.json
• Validator authority: src/microcosm_core/validators/sign-off.py
• Fixture manifest: core/fixture_manifests/pattern_assimilation_step.fixture_manifest.json
• Fixture input: fixtures/first_wave/pattern_assimilation_step/input
• Runtime bundle: examples/pattern_assimilation_step/exported_assimilation_bundle
• Primary result records: receipts/first_wave/pattern_assimilation_acceptance.json, receipts/first_wave/pattern_assimilation_receipt.json, and receipts/first_wave/pattern_assimilation_step/exported_assimilation_bundle_validation_result.json
• Projection posture: the JSON bundle is the paper-module source authority. This Markdown is the cold-reader explanation.

Shape

flowchart TD landings["Landed component rows organ_landing_summaries.jsonl each names a completion result and result record ref"] refinement["Refinement result records owner_surface, changed artifact"] nothing["Nothing-to-refine result records stewardship, next-best lane, re-entry"] validator["sign-off.py validate_pattern_assimilation"] filter["Pre-filter valid result records refinement: named owner, no doctrine upgrade nothing: all three fields present"] match{"Per landed component: exactly one completion, ref resolves to a matching row?"} pass["Accepted typed, owner-routed completion learning"] negatives["Negative cases recorded MISSING_PATTERN_ASSIMILATION_Completion MISSING_REFINEMENT_OWNER_SURFACE DUPLICATE_REFINEMENT_RECEIPT_ID LOCAL_LESSON_AUTHORITY_UPGRADE RAW_SEED_BODY_IN_ASSIMILATION_FIXTURE"] result records["metadata-only result records result records/first_wave/pattern_assimilation_*"] ceiling["Scope limit public fixture metadata, no doctrine changes"] landings --> match refinement --> filter nothing --> filter filter --> match validator --> filter match -->|resolved| pass match -->|missing, dangling, duplicate, upgraded| negatives pass --> result records negatives --> result records result records --> ceiling

The bundle is present, so the cold-reader path starts from core/paper_module_capsules.json::paper_module.pattern_assimilation, not from a legacy-only boundary. That bundle binds this Markdown to the accepted pattern_assimilation_step component, the sign-off.py validator locus, the standard, first-wave fixture manifest, exported assimilation bundle, focused tests, metadata-only result records, and generated Mermaid/Atlas navigation status.

Read the diagram as the validation flow, not an authority upgrade. The validator pre-filters the refinement and nothing-to-refine result records, then walks each landed component row and checks that its declared completion resolves to a matching valid result record; unresolved, missing, duplicate, or doctrine-upgraded rows become recorded negative cases. The ceiling remains public fixture and exported-bundle metadata plus metadata-only result records, with no live ledger mutation, source-file changes, source note ingestion, private-system equivalence, global doctrine changes, launch or publishing-scope decision, behavior-change proof, or whole-system correctness.

First Command

From microcosm-substrate:

Use the exported bundle validator when the question is whether the public source-open body imports still match their declared source bodies:

What It Proves

Pattern assimilation is the public completion-learning contract for landed components. It validates that each landed component in the fixture set has exactly one same-lane completion decision: either a concrete refinement result record naming the owner surface and changed artifact, or a typed nothing_to_refine result record with stewardship checked, next-best-lane checked, and a re-entry condition.

A cold agent should use this component when a pass claims that local work taught the system something. The validator makes that claim inspectable: it checks owner-surface evidence, duplicate result record ids, off-lane completions, missing completion decisions, residual lifecycle posture, and attempts to promote a local lesson into global doctrine authority without the governing lane.

Bundle-Bound Reader Shape

The paper-module bundle binds this Markdown to two explained subjects: pattern_assimilation_step and mechanism.pattern_assimilation_step.validates_public_pattern_assimilation_step. It also carries the route-contract concept concept.architecture_and_navigation_route_contract_bundle.

The executable locus is src/microcosm_core/validators/sign-off.py, specifically validate_pattern_assimilation, run_assimilation_bundle, validate_source_module_manifest, _write_jsonl_upsert, EXPECTED_NEGATIVE_CASES, PATTERN_ASSIMILATION_AUTHORITY_CEILING, and main.

Its law edges are bounded to the local completion-learning scope limit: P-1, P-2, P-3, P-5, P-6, P-7, P-8, P-9, P-12, P-13, P-15, AX-1, AX-4, AX-5, AX-6, AX-7, AX-8, AX-11, and AX-12. Its paper-module neighbors are cold_reader_route_map, pattern_binding_contract, and voice_to_doctrine_self_improvement_loop.

If the generated JSON instance disagrees with the bundle or validator source, the bundle and validator win; refresh the projection rather than editing it.

Source-Backed System

This component is more than a prose rule. The exported assimilation bundle imports four bodies by manifest:

• macro_pattern_autonomy_process_contract_body_import from state/microcosm_portfolio/reconstruction/macro_pattern_autonomy_process_contract_v1.json
• macro_pattern_assimilation_fixture_manifest_body_import from state/microcosm_portfolio/reconstruction/fixture_manifests/pattern_assimilation_step.fixture_manifest.json
• pattern_assimilation_retracted_adapter_receipt_body_import from state/microcosm_portfolio/reconstruction/pattern_assimilation_step_real_substrate_adapter_receipt_v1.json
• pattern_assimilation_acceptance_validator_source_body_import from src/microcosm_core/validators/sign-off.py

The manifest is examples/pattern_assimilation_step/exported_assimilation_bundle/source_module_manifest.json. It must keep body_in_receipt: false, exact source and target digests, required anchors, and validation refs. The copied validator body anchors validate_pattern_assimilation, run_assimilation_bundle, and PATTERN_ASSIMILATION_AUTHORITY_CEILING.

Result record Floor

A passing fixture run emits:

• receipts/first_wave/pattern_assimilation_acceptance.json
• receipts/first_wave/pattern_assimilation_receipt.json
• state/microcosm_portfolio/reconstruction/macro_pattern_autonomy_process_runs_v1.jsonl

A passing exported-bundle run emits:

• receipts/first_wave/pattern_assimilation_step/exported_assimilation_bundle_validation_result.json

The first-wave result records must include public-relative paths, no private root paths, no copied body text, a redacted non-public-state scan with zero blocking hits, observed negative cases, error codes, scope limit, scope boundary, and the exact result record paths. The bundle result record must show source_module_manifest_status: pass, body_copied_material_count: 4, the four body-material ids above, body_in_receipt: false, body_text_in_receipt: false, and only public replacement refs.

Reader Evidence Routing

A cold reader should inspect the evidence in this order:

1. Open the JSON source record to confirm subject ids, dependency ids, principle and axiom refs, and code locus.
2. Run the focused sign-off test or fixture command to prove the completion learning shape still accepts valid fixture rows and rejects the required negative cases.
3. Run the exported bundle validator when source-module digest, anchor, copied body, or replacement posture is the question.
4. Treat generated JSON, Mermaid, Atlas, and coverage as projection evidence only; if they drift, refresh them through the doctrine-lattice builder.
5. Use the result record floor to check public-relative paths, metadata-only source verification, source note exclusion, and local-lesson scope limits.

Negative Cases

The current negative-case floor is:

• MISSING_PATTERN_ASSIMILATION_CLOSEOUT for a landed component without a refinement or typed no-op completion.
• MISSING_REFINEMENT_OWNER_SURFACE, MISSING_STEWARDSHIP_CHECK, and MISSING_REENTRY_CONDITION for refinement result records that cannot route the lesson to an owner surface and re-entry condition.
• DUPLICATE_REFINEMENT_RECEIPT_ID for duplicate refinement result records.
• LOCAL_LESSON_AUTHORITY_UPGRADE for local lessons that claim global doctrine authority.
• RAW_SEED_BODY_IN_ASSIMILATION_FIXTURE for source notes or private source note bodies in the public fixture.
• ASSIMILATION_BUNDLE_SOURCE_MODULE_INVALID for exported source-module digest or anchor mismatch.

These are not ornamental checks. If a run stops observing them, the module can no longer support the claim that Microcosm learns from landed work without turning local notes into unsupported global doctrine.

Prior Art Grounding

Pattern assimilation is grounded in software pattern-language practice: recurring engineering lessons should be named, bounded, reviewed, and connected to the context where they apply. The Hillside patterns library is the direct prior-art family for treating patterns as a shared engineering vocabulary rather than one-off notes.

The result record and trace shape also borrows from provenance and observability practice. W3C PROV informs the requirement that each refinement cite its owner surface and evidence relation, while OpenTelemetry traces are a useful analogue for linking spans of work into an inspectable causal chain. Microcosm uses those inspirations for completion learning only; a local lesson still needs the owning lane before it can become broader doctrine.

Validation Result record Path

From microcosm-substrate, keep validation result records outside tracked first-wave paths unless the owning result record lane intends to refresh them:

The fixture and bundle result records prove same-lane completion-learning shape over the public fixtures and copied body imports only; they do not promote a local lesson to global doctrine authority. Source-copy or result record drift is an owning validator/manifest lane issue, not Markdown source authority.

Focused pytest re-entry is:

PYTHONPATH=src ../repo-python -m pytest -p no:cacheprovider tests/test_pattern_assimilation_step.py -q --basetemp=/tmp/microcosm_pattern_assimilation_pytest

Use an isolated /tmp basetemp for focused pytest runs so result record scratch paths do not rewrite source-run rows inside the checkout.

Validation Anchors

Focused coverage lives in tests/test_pattern_assimilation_step.py and checks:

• streamed JSONL loading and upsert behavior;
• required negative-case observation;
• public-relative redacted result records;
• source result record field floors from the fixture manifest;
• exported assimilation bundle runtime shape;
• source-module digest mismatch rejection;
• exported bundle result records;
• exact copied source body imports.

Purpose

Doctrine in most systems is prose convention. A standard says a rule should hold, a paper module says a section should be present, and nothing checks whether the claim is actually true. This component exists to make doctrine shape a thing a program can pass or fail. It answers one question: does a standard row or a paper-module fixture carry the structure that doctrine here requires, or is it just text that looks the part?

What it checks is deliberately structural rather than semantic. A standard row must declare a teleology, a governing standard, result record expectations, and an scope boundary. A paper module must carry the matching sections by heading. The validator does not judge whether the prose is good. It judges whether the load-bearing fields are present, so a row cannot quietly drop its result record expectations or its scope boundary and still pass.

The less obvious part is that the failures are first-class. Five negative cases are part of the contract: a row missing its required fields, a prose-only standard that tries to claim executable authority, a source doctrine body copied into a public fixture, a duplicate standard slug, and a grammar pass that overclaims doctrine completeness. A run that does not observe each of these classes is blocked, so the checker is held to demonstrating that it can reject, not only that it can accept.

The component also imports copied source bodies, but only through a source-module manifest with declared SHA-256 digests, and never inlines a body into a result record. The result record reports refs, hashes, counts, and verdicts; the bodies live in the bundle. The point is to make the doctrine shape checkable without turning the public surface into an export of the private standards engine.

Teleology

executable_doctrine_grammar turns toy public standards and paper-module fixtures into deterministic grammar result records. It makes doctrine-shape claims checkable while importing copied, source bodies only through source-module manifests, digests, and result record boundaries.

Shape

flowchart TD A["Public doctrine fixtures fixtures/first_wave/executable_doctrine_grammar/input"] --> B["Executable grammar validator src/microcosm_core/components/executable_doctrine_grammar.py"] C["Exported standards bundle examples/executable_doctrine_grammar/exported_standards_bundle"] --> B D["Source-module manifest examples/executable_doctrine_grammar/exported_executable_grammar_metabolism_bundle/source_module_manifest.json"] --> B B --> E["metadata-only deterministic result records result records/first_wave/executable_doctrine_grammar/"] E --> F["Bundle and atlas evidence core/paper_module_capsules.json::paper_modules[18]"] F --> G["Bounded reader claim doctrine-shape validation, not launch-scope decision"]

Reader Evidence Routing

Reader evidence routes through the executable-grammar runtime, fixture inputs, exported standards bundle, executable-grammar metabolism bundle, source-module manifests, public result records, and focused tests. The Mermaid diagram and Atlas card are generated navigation projections; this page is the cold-reader explanation of the proof boundary.

Public Contract

The validator checks standard slugs, teleology, governing standard refs, result record expectations, scope boundaries, paper-module sections, source-body sentinels, duplicate slug conflicts, prose-only authority claims, and doctrine-completeness overclaims. It also validates the imported public executable-grammar specimen, standards registry, standards type-plane, lattice registry, kind-atlas runtime, and standards option-surface runtime as exact copied source modules.

Prior Art Grounding

This component is grounded in schema validation, parser generators, and executable semantics traditions. JSON Schema anchors the idea that document shape can be validated by a shared machine contract, Tree-sitter shows the practical value of generated grammars for inspectable source structure, and the K framework is a close reference point for turning semantic rules into executable artifacts.

Microcosm borrows the executable-contract pattern: doctrine shape, result record expectations, duplicate slugs, imported source bodies, and scope boundaries are checked by a validator instead of left as prose convention. It does not claim source doctrine completeness or launch-scope decision.

First Commands

From microcosm-substrate/, a cold agent can prove the fixture path:

PYTHONPATH=src python3 -m microcosm_core.organs.executable_doctrine_grammar validate --input fixtures/first_wave/executable_doctrine_grammar/input --out receipts/first_wave/executable_doctrine_grammar --card

The exported public standards bundle uses the same component with a narrower input:

PYTHONPATH=src python3 -m microcosm_core.organs.executable_doctrine_grammar validate-standards-bundle --input examples/executable_doctrine_grammar/exported_standards_bundle --out receipts/first_wave/executable_doctrine_grammar --card

The source-open source-body floor is the executable-grammar metabolism bundle:

PYTHONPATH=src python3 -m microcosm_core.organs.executable_doctrine_grammar validate-executable-grammar-metabolism-bundle --input examples/executable_doctrine_grammar/exported_executable_grammar_metabolism_bundle --out receipts/first_wave/executable_doctrine_grammar --card

Source-Backed Mechanism

The mechanism row mechanism.executable_doctrine_grammar.validates_public_doctrine_grammar_bundle points at validate, validate_standards_bundle, validate_executable_grammar_metabolism_bundle, validate_source_module_imports, validate_standard_registry, validate_paper_module_shape, result_card, EXPECTED_NEGATIVE_CASES, and GRAMMAR_AUTHORITY_CEILING.

Those symbols are the runnable floor:

• validate writes the fixture standards, paper-module, group-index, and sign-off result records.
• validate_standards_bundle validates the exported public standards bundle and keeps result record paths public-relative.
• validate_executable_grammar_metabolism_bundle validates the copied executable-grammar metabolism specimen, standards registry/type-plane, lattice registry, kind-atlas, and standards option-surface bodies.
• validate_source_module_imports requires source_module_manifest.json, copied_non_secret_macro_body, exact_copy, allowlisted source refs, body-in-result record exclusion, and SHA-256 digest matches.
• result_card compresses result record evidence without duplicating body text.

Negative Cases

The fixture must keep these failures executable rather than prose-only:

• invalid_standard_and_module: missing teleology, result record expectations, governing standard, and scope boundary.
• prose_standard_claims_runtime_authority: prose cannot claim executable runtime authority.
• macro_doctrine_body_copied_into_fixture: source doctrine body sentinels are rejected from public fixtures.
• duplicate_standard_slug_conflict: duplicate slugs are rejected deterministically.
• grammar_index_pass_overclaims_doctrine_complete: grammar pass is not doctrine-completeness authority.

Atlas Binding

• paper_module_ref: core/paper_module_capsules.json#paper_module.executable_doctrine_grammar
• mechanism_refs[].ref: mechanism.executable_doctrine_grammar.validates_public_doctrine_grammar_bundle
• code_loci[]: src/microcosm_core/organs/executable_doctrine_grammar.py with the mechanism symbols named above.

Validation Result record Path

./repo-pytest tests/test_executable_doctrine_grammar.py -q --basetemp=/tmp/microcosm_executable_doctrine_grammar_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

Purpose

A large codebase has a recurring failure: the agent or reader that lands in it starts from whatever browse surface is nearest to hand, treats that surface as the authority, and acts on a stale or partial view. The route plane exists to make the first move legible and to stop a browse row from being mistaken for the thing it describes. It answers one question: given a control entry, what is the safe ordered path into the browsable route projections, and what proof says that path is wired rather than asserted?

The unusual part is that the component never asserts a route is correct from prose. It treats every browse row as a projection and demands a coupling result record before that projection is allowed any authority. Source coupling is a plain SHA-256 over the route rows: the manifest carries an expected fingerprint and an expected row count, and if either disagrees with the rows on disk the projection is denied current authority. A route summary that claims to be current while its coupling is stale is rejected outright.

The other half of the design is what it refuses to do. First contact must begin at the control entry, not at a drilldown projection, so a request that tries to start from a browse row is replaced with the entry route. Compaction of the entry packet may not drop a required control field. An affordance row whose passport carries an anti-trigger is demoted before similarity search can ever select it. None of these are stylistic preferences; each is a named negative case the fixture must keep catching, so the route plane is defined as much by the eight things it blocks as by the path it permits.

Teleology

The navigation route plane gives a public clone a typed way to move from a control entry to browseable route projections without treating browse rows as authority.

Public Contract

The component runs in two modes against the same checks. The fixture mode loads a set of synthetic inputs, builds a toy option-surface from the rows (a cluster-flag summary plus one selected card), and then runs the negative-case validators that prove each guard still fires. The exported-bundle mode runs the same kind of checks against a real copied bundle: it validates the route rows, the source-coupling fingerprint, the source-module manifest, the route-lease policy, the entry-packet floor, the affordance passports, and the code-architecture projection packet, and only reports a pass when the secret scan is clean, a card row is selected, and every component validator passes.

The source-coupling gate is the spine. It hashes the route rows with SHA-256 and compares that against the fingerprint and row count declared in the manifest; a mismatch denies the projection any current authority, and a summary that claims current authority while coupling is stale is recorded as an overclaim. The source-module manifest names five exact copies of source route and control bodies. Each is checked by digest and by required navigation anchors, and each must declare that its body is copied but never written into the result record, so the evidence is reproducible without exposing the source text.

Shape

flowchart TD Entry["Control entry first browse row that claims first contact is replaced with the entry route"] subgraph Gates["Route-plane gates"] Couple["Source coupling SHA-256 over route rows vs manifest fingerprint + row count"] Rows["Route rows surface role, actionable command, no source-authority claim, omission result record when required"] Modules["Source-module manifest 5 copied source bodies digest + required anchors, body never in result record"] Lease["Route-lease policy selected lane, permitted actions, source authority rejected"] Floor["Entry-packet floor required control fields survive compaction"] Pass["Affordance passports anti-trigger rows demoted before similarity can select them"] end Verdict{"Coupling current, all gates pass, card row selected?"} Entry --> Couple Couple --> Rows --> Modules --> Lease --> Floor --> Pass --> Verdict Verdict -->|yes| Result records["metadata-only result records cluster flag, card, coupling, route lease, entry admission, affordance, code-architecture packet"] Verdict -->|no| Blocked["Blocked stable error codes, findings, bodies redacted"] Negative["Negative-case floor BANNED_FIRST_CONTACT_ROUTE, SOURCE_COUPLING_STALE, and 7 more"] -.-> Gates Result records --> Ceiling["Scope limit projection evidence only; no live route freshness, source authority, or launch"] Blocked --> Ceiling

Source-Backed Doctrine Packet

• core/organ_registry.json::implemented_organs[navigation_hologram_route_plane] is the accepted component authority. It records status accepted_current_authority, evidence class semantic_validator, evidence strength rank 5, scope limit validates declared public contract only, and validator command python -m microcosm_core.organs.navigation_hologram_route_plane run --input fixtures/first_wave/navigation_hologram_route_plane/input --out receipts/first_wave/navigation_hologram_route_plane.

• core/organ_atlas.json::organs[navigation_hologram_route_plane] gives the cold-reader gloss: control entry comes first, browse rows stay projections, eight route-plane negative cases are detected, exact copied navigation source modules validate, and result records omit body text.

• standards/std_microcosm_navigation_hologram_route_plane.json governs the standard authority boundary public_navigation_route_plane_runtime_and_copied_source_body_validator_not_live_source_authority. It requires route rows, option-surface contracts, source coupling, source-module manifests, route leases, entry-packet floors, affordance passports, code-architecture packets, body-import verification, scope limit, and scope boundary.

• src/microcosm_core/organs/navigation_hologram_route_plane.py is the runtime source for fixture validation, route-plane bundle validation, secret-exclusion scan, route-lease checks, entry-admission floor checks, affordance-passport demotion, code-architecture packet result records, and source-module digest/anchor validation.

• core/fixture_manifests/navigation_hologram_route_plane.fixture_manifest.json binds fixture expectations: body_copied_material_count=5, body_material_status=copied_non_secret_macro_route_substrate_with_provenance, body_in_receipt=false, and negative cases tied to stable error codes.

• examples/navigation_hologram_route_plane/exported_route_plane_bundle/source_module_manifest.json names five exact copied source route-control bodies: navigation_route_plane_intervention_source_body_import, navigation_route_plane_context_pack_source_body_import, navigation_route_plane_entry_packet_source_body_import, navigation_route_plane_option_surface_source_body_import, and navigation_route_plane_navigation_contract_source_body_import.

• tests/test_navigation_hologram_route_plane.py is the regression floor for fixture result records, exact source-source digest matches, source-module anchors, result record redaction, exported bundle validation, digest-mismatch rejection, and this source-backed paper-module packet.

• receipts/first_wave/navigation_hologram_route_plane/*.json carries public result records for cluster/card output, source coupling, route lease, entry-payload admission, affordance-passport selection, code-architecture packet, and exported bundle validation.

Source-module body floor:

Registry result record refs:

• receipts/first_wave/navigation_hologram_route_plane/affordance_passport_selection_receipt.json
• receipts/first_wave/navigation_hologram_route_plane/code_architecture_projection_packet_receipt.json
• receipts/first_wave/navigation_hologram_route_plane/entry_payload_admission_receipt.json
• receipts/first_wave/navigation_hologram_route_plane/route_lease.json
• receipts/first_wave/navigation_hologram_route_plane/source_coupling_result.json
• receipts/first_wave/navigation_hologram_route_plane/toy_kind_card.json
• receipts/first_wave/navigation_hologram_route_plane/toy_kind_cluster_flag.json

First command from microcosm-substrate/:

PYTHONPATH=src python3 -m microcosm_core.organs.navigation_hologram_route_plane run --input fixtures/first_wave/navigation_hologram_route_plane/input --out receipts/first_wave/navigation_hologram_route_plane

Runtime bundle command from microcosm-substrate/:

PYTHONPATH=src python3 -m microcosm_core.organs.navigation_hologram_route_plane validate-route-plane-bundle --input examples/navigation_hologram_route_plane/exported_route_plane_bundle --out receipts/runtime_shell/demo_project/organs/navigation_hologram_route_plane

Standard-declared runtime bundle validator: python -m microcosm_core.organs.navigation_hologram_route_plane validate-route-plane-bundle --input examples/navigation_hologram_route_plane/exported_route_plane_bundle --out receipts/runtime_shell/demo_project/organs/navigation_hologram_route_plane.

Atlas scope limit restated: It validates only the declared public toy route-plane contract and its regression fixtures (plus exact copied navigation source modules in the bundle path); it does not establish live route freshness, grant source authority, authorize any later component, run any provider/live-kernel call, or certify the whole wave.

The negative-case floor is part of the doctrine, not incidental test trivia. Across the eight negative cases, the fixture must keep detecting these stable error codes (one case carries two codes, so the list runs to nine):

• BANNED_FIRST_CONTACT_ROUTE
• SOURCE_COUPLING_STALE
• MISSING_OMISSION_RECEIPT
• ATLAS_PROJECTION_NOT_CONTROL_ENTRY
• ROUTE_CARD_PRIVATE_BODY_LEAK
• ROUTE_SUMMARY_OVERCLAIMS_FRESHNESS
• DUPLICATE_ROUTE_ID_CONFLICT
• ENTRY_ADMISSION_CONTROL_FLOOR_DROPPED
• AFFORDANCE_PASSPORT_ANTITRIGGER_IGNORED

Reader Evidence Routing

Reader evidence starts at the generated JSON instance, then routes through the route-plane runtime, fixture manifest, source-module manifest, public result records, and focused regression. The browse rows, Mermaid diagram, and Atlas card are derived projections; they are not control-entry or source authority.

Prior Art Grounding

The route plane is grounded in information-architecture and graph-navigation patterns. The first-contact rule follows the same usability pressure as progressive disclosure: show the control entry and immediate affordances before deeper browse rows. The CLI-facing surface is also informed by the Command Line Interface Guidelines, especially the emphasis on discoverable commands, examples, and clear next actions.

The graph side maps to established directed-graph tooling. NetworkX documents topological sorting as an ordering over dependency edges, and graph-ranking algorithms such as PageRank show the older pattern of computing route salience from graph structure. Microcosm keeps those ideas below authority: route cards, leases, and browse rows are projections unless source-coupling and entry-admission result records agree.

Validation Result record Path

From microcosm-substrate/, reproduce this page's proof boundary with temporary result records:

PYTHONPATH=src ../repo-python -m microcosm_core.organs.navigation_hologram_route_plane run --input fixtures/first_wave/navigation_hologram_route_plane/input --out /tmp/microcosm-navigation-hologram-route-plane
PYTHONPATH=src ../repo-python -m microcosm_core.organs.navigation_hologram_route_plane validate-route-plane-bundle --input examples/navigation_hologram_route_plane/exported_route_plane_bundle --out /tmp/microcosm-navigation-hologram-route-plane-bundle
../repo-pytest tests/test_navigation_hologram_route_plane.py
PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

These checks validate the public fixture and exported route-plane bundle only; they do not grant live route freshness, source authority, provider/live-kernel execution, later-component authorization, launch-scope decision, or whole-wave certification.

standards_meta_diagnostics is the terminal public coverage diagnostic for the Microcosm runtime spine. It checks that accepted adapter-backed components remain mapped to standards, runtime contracts, result records, and explicit scope limits before a cold reader trusts the spine as coherent.

It consumes public standards_inventory.json, organ_runtime_contracts.json, and diagnostic_policy.json inputs backed by registry refs, runtime commands, sign-off result records, and the exported diagnostics bundle. Its result record contract is source-open by default: secret_exclusion_scan proves that secrets, account or browser material, model-output data bodies, raw operator bodies, and account secret-equivalent live-access material are excluded, while public_runtime_refs point at the real standards, component, sign-off, fixture, bundle, and paper-module system. Bodies are not inlined into JSON result records, so the positive evidence uses body_in_receipt: false, real_runtime_receipt: true, and synthetic_receipt_standin_allowed: false.

The component rejects five boundary failures:

• accepted component rows without standard_id or standard_ref
• accepted components missing from the standards inventory
• accepted component rows without result record refs
• launch, provider, public sharing, secret export, trading/advice, or whole-system correctness overclaims
• private source bodies or model-output data bodies in public diagnostics

Purpose

A spine of accepted components is only coherent if each component is still attached to the things that make it accountable: a standard that describes it, a runtime contract that runs it, a result record that records its last verdict, and an explicit statement of what it is not allowed to claim. As the spine grows, those four attachments drift out of step one component at a time, and the drift is silent. A new component can be accepted into the runtime while its standard file, registry row, or result record ref is never added. Nothing breaks; the gap just sits there until a reader trusts the spine and finds a hole.

This component answers a single question: does every accepted component still resolve to a standard, a runtime contract, a result record, and an scope limit, with no extra and no missing entries? It treats the answer as a graph-closure check rather than a written audit. The accepted-component list, the standard rows, the runtime-contract rows, and the result record refs must agree on exactly the same set of components. Any component that appears in one surface but not another becomes a structured finding with a named error code, not a paragraph of prose.

The unusual choice is that the diagnostic refuses to grow its own authority. It projects its positive coverage from the live registry rather than a checked-in list, so a stale example cannot quietly become the thing the spine is measured against. It carries five negative fixtures that must each surface their expected failure, so the checker is itself falsifiable. And its result records deliberately hold refs, counts, hashes, and verdicts rather than the bodies they describe, so a coverage report can be read in the open without exporting private source.

Technical Mechanism

standards_meta_diagnostics is a public consistency validator over three finite surfaces: a standards inventory, component runtime contracts, and diagnostic policy. The positive path either reads those exported JSON inputs or projects them from the live public registry, then requires the accepted-component list, the standard rows, the runtime-contract rows, and the result record refs to agree on the same component set. This is a graph-closure check, not a narrative audit: an accepted component without a standard ref, registry-backed standard row, runtime step, validator command, or result record ref becomes a structured finding.

The mechanism has four guarded stages:

1. run loads standards_inventory.json, organ_runtime_contracts.json, and diagnostic_policy.json, or projects the positive rows from live public registry state when the caller asks for live positives.
2. The validator checks every accepted component row against a resolving std_microcosm_<organ_id> standard, the standards registry entry, the runtime shell step, a non-empty validator command, and non-empty result record refs with body_in_receipt: false.
3. Five negative fixtures exercise the expected boundary failures: missing_standard_ref, unmapped_accepted_organ, missing_receipt_ref, release_overclaim, and private_source_leakage.
4. The exported-bundle path revalidates the same shape through source_module_manifest.json, exact source-module digest checks, source-open body-import accounting, secret_exclusion_scan, and the projection-only AUTHORITY_CEILING.

The output card deliberately omits the covered-component list, findings, secret-exclusion detail, source refs, public runtime refs, scope boundary, scope limit, and source-module summary from the compact payload. Those keys remain in the full result record, which keeps the reader-facing card inspectable without turning it into a private-body export.

Shape

flowchart TD bundle["paper_module bundle: subjects + code_loci + scope limit"] inventory["standards_inventory.json"] contracts["organ_runtime_contracts.json"] policy["diagnostic_policy.json"] negatives["negative fixtures: missing standard, unmapped component, missing result record, overclaim, private source"] runtime["standards_meta_diagnostics.run / run_diagnostics_bundle"] scan["secret_exclusion_scan + public_runtime_refs"] result record["sign-off result record: counts, error codes, scope boundary"] projections["generated navigation projections: mermaid + atlas card"] bundle --> projections inventory --> runtime contracts --> runtime policy --> runtime negatives --> runtime runtime --> scan scan --> result record runtime --> result record

Evidence/accounting:

• core/paper_module_capsules.json::paper_modules[29:paper_module.standards_meta_diagnostics] is the JSON authority row. It names the component and mechanism subjects, the resolved code locus src/microcosm_core/organs/standards_meta_diagnostics.py, and the projection-only scope limit.
• paper_modules/standards_meta_diagnostics.json::paper_module_payload.source_authority is json_capsule; generated_projections.mermaid.status is available_from_capsule_edges; generated_projections.atlas_card.status is linked_from_capsule_edges; relationships.edges currently has 11 edges.
• organs/standards_meta_diagnostics.json::organ_payload.source_registry_row records status: accepted_current_authority, the validator command, and the generated result record refs; its claim_ceiling keeps the diagnostic scoped to the declared public contract.
• src/microcosm_core/organs/standards_meta_diagnostics.py names INPUT_NAMES, NEGATIVE_INPUT_NAMES, EXPECTED_NEGATIVE_CASES, PUBLIC_RUNTIME_REFS, and AUTHORITY_CEILING, which are the runtime contract this reader section summarizes.
• tests/test_standards_meta_diagnostics.py asserts the fixture and exported bundle paths, the five expected negative cases, source-module digest checks, body_in_receipt: false, real_runtime_receipt: true, and synthetic_receipt_standin_allowed: false.
• result records/sign-off/first_wave/standards_meta_diagnostics_fixture_acceptance.json records status: pass, accepted_organ_count: 77, standard_mapping_count: 77, runtime_contract_count: 77, five expected error codes, secret_exclusion_scan.blocking_hit_count: 0, and the scope boundary that the diagnostic excludes launch, providers, registry mutation, formal-result correctness, or whole-system correctness.

Reader Evidence Routing

• Start with the JSON Bundle Binding to identify the source record and the projection-only scope limit before treating the diagnostic as evidence.
• Use Structured Lattice Bindings to understand which wiring is resolved and which dependencies remain pending. Pending dependencies are honest residuals, not hidden failures.
• Use Validation Result record Path for reproducibility: focused pytest exercises the diagnostic policy and negative cases; the corpus check verifies paper-module parity.
• Treat secret-exclusion and public-runtime refs as result record evidence about public projection consistency. They do not mutate standards, include launch operations, expose private source material, or prove whole-system correctness.

Named Proof Consumers

• tests/test_standards_meta_diagnostics.py::test_standards_meta_diagnostics_observes_negative_cases is the fixture consumer. It proves that the positive public inputs cover the accepted component set and that the five expected negative cases surface their named error codes.
• tests/test_standards_meta_diagnostics.py::test_standards_meta_diagnostics_bundle_validates_runtime_shape is the exported-bundle consumer. It checks the bundle id, covered component set, source-module manifest status, source-open body-import counts, body_in_receipt: false, and the false scope limit flags.
• tests/test_standards_meta_diagnostics.py::test_standards_meta_diagnostics_rejects_source_module_digest_mismatch, ::test_standards_meta_diagnostics_rejects_partial_source_module_digest_mismatch, and ::test_standards_meta_diagnostics_rejects_partial_target_module_digest_mismatch are the digest-drift consumers. They make copied source-module bodies falsifiable instead of relying on manifest prose.
• tests/test_standards_meta_diagnostics.py::test_standards_meta_diagnostics_source_modules_are_exact_macro_body_imports is the exact-copy consumer for the three public source-body imports named in the exported bundle.
• tests/test_standards_meta_diagnostics.py::test_standards_meta_diagnostics_receipts_use_secret_exclusion is the public/private boundary consumer. It checks that result record evidence uses the secret-exclusion lane and keeps private bodies out of public diagnostics.
• tests/test_standards_meta_diagnostics.py::test_standards_meta_diagnostics_input_builder_tracks_live_registry and the live-positive projection tests are the registry-freshness consumers. They keep fixture inputs tied to public registry state instead of allowing a stale checked-in example to become silent authority.

Prior Art Grounding

This component is grounded in schema- and contract-validation practice rather than in a claim that diagnostics create authority. JSON Schema treats a schema as a machine-readable vocabulary for validating structured JSON data, and OpenAPI uses interface descriptions so consumers can understand an API without reading source code or observing traffic. The component imports that pattern into Microcosm's launch boundary: standards, adapter contracts, result records, and scope limits are checked as public projections, while the diagnostic remains bounded evidence about consistency rather than a new source of truth.

Prior-art anchors:

• 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

./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

This module is the public Microcosm projection of the source system's recursive self-improvement metabolism. It is not a synthetic result record layer. It imports the real source shape from recursive_self_improvement_operating_loop, doctrine_population_loop, and local_to_general_propagation: local pressure is sensed, classified, assigned to an owner surface, mutated or captured there, validated, closed out, and given a concrete re-entry condition.

The exported bundle also carries exact copies of the source bodies that make this loop real: recursive self-improvement, doctrine population, local-to-general propagation, the plane-home decision table, work log metacontrol, work log skill doctrine, and the work log standard. Result records report only source refs, hashes, counts, and scan status; the body text lives under examples/.../source_modules/ai_workflow/.

Purpose

The component answers one question: did a declared lesson actually change a named owner surface and pass that surface's own validation, or did it only produce a result record that says so? "The system learned from its work" is an easy claim to assert and a hard one to back. Without a check, a log entry, a closed ticket, or a confident summary all read as progress. This validator refuses that shortcut.

Each lesson row must name the surface it changed (a skill, a paper module, a standard, or a captured Work item), the action it took there, and the validation and completion refs that show the change held. Every ref must resolve to a real file in the exported bundle, the copied source modules, or the public Microcosm tree. A lesson then lands in exactly one of four outcomes: refined_existing_surface (a surface changed and was validated), workitem_captured (deferred work, but only with a concrete re-entry condition), nothing_to_refine (a typed null result that still required stewardship and a next-best-lane check), or already_propagated_verified. Anything that does not fit one of these is a finding, not an outcome.

The unusual part is the defence against self-grading. A lesson row may carry an expected_label or expected_status field, but the validator ignores it and recomputes the verdict from the evidence. If the row is not genuinely backed, its own asserted label cannot rescue it, and the case is recorded as VOICE_DOCTRINE_BAKED_EXPECTED_LABEL_IGNORED. A fixture cannot pass by declaring its own success. The same instinct runs through the negative floor: source notes, private thread bodies, model-output data, direct edits to doctrine nodes, and global promotion without owner validation are each rejected, keeping "the system improves itself" separate from "this public artifact may rewrite doctrine or export private voice."

Shape

flowchart LR Signal["Local pressure mistake, route gap, validation finding, residual"] Classify["Classify owner surface + action"] Owner["Owner surface skill, paper module, standard, Work item"] Refused["Refused raw voice, private body, direct node edit, result record-only, unvalidated promotion"] subgraph Outcome["One of four typed outcomes"] Refined["refined_existing_surface changed ref + validation"] Captured["workitem_captured with re-entry condition"] Null["nothing_to_refine stewardship + next-lane checked"] Already["already_propagated_verified"] end Recompute["Recompute verdict from evidence expected_label ignored"] Validate["Validation owner evidence + completion ref; every ref must resolve"] Source["Exact source bodies 8 manifest rows: hashes, anchors"] Result records["metadata-only result records result, board, validation, fixture sign-off"] Signal --> Classify Classify --> Owner Owner --> Refused Owner --> Outcome Outcome --> Recompute Recompute --> Validate Source --> Result records Validate --> Result records Refused --> Result records

Public Mechanics

• Local lessons carry source pattern refs, evidence refs, owner-surface ids, owner actions, validation refs, completion refs, and outcomes.
• Owner surfaces are explicit: skills, paper modules, standards, and residual captures each retain their own mutation authority.
• refined_existing_surface requires a changed owner surface and validation.
• workitem_captured requires a concrete re-entry condition.
• nothing_to_refine requires stewardship and next-best-lane checks.
• source notes, private thread bodies, model-output data, live work log bodies, direct doctrine-node edits, and global promotion claims are rejected by negative cases.
• Exported bundle validation requires source_module_manifest.json, verifies each copied body hash/line/byte/anchor contract, and scans copied bodies for forbidden public material.

Reader Evidence Routing

Read this module as a lesson-propagation validator, not as a general doctrine mutation license. The fixture proves that local pressure must choose a named owner surface, perform an owner-authorized action, carry validation and completion refs, and either refine an existing surface, capture a Work item with a re-entry condition, record a typed nothing_to_refine, or verify an already-propagated result.

Read source-open evidence through the exported bundle manifest. It carries eight copied source bodies: three paper modules, four skills or skill companions, and the work log standard. Each manifest row records byte and line counts, exact source and target hashes, required anchors, and body_in_receipt: false. The source bodies make the source loop inspectable, while result records remain refs, hashes, counts, scan status, and scope limits.

Read the negative floor as equally load-bearing. source notes bodies, private thread bodies, model-output data bodies, direct doctrine-node edits, result record-only progress, live work log mutation, and unvalidated global promotion are rejected. Those rejections keep "the system learns from work" separate from "this public artifact can mutate doctrine or export private state."

Prior Art Grounding

This component is grounded in after-action review, lessons-learned, and pattern language practices. NASA's Lessons Learned Information System is a public example of preserving operational lessons so future work can reuse them, while pattern-language practice gives a vocabulary for turning repeated local solutions into named, reusable forms. Microcosm adopts that direction without collapsing operator voice into doctrine: a local lesson only becomes durable when it has evidence, an owner surface, a validation result record, and a bounded re-entry path.

Prior-art anchors:

• NASA Lessons Learned Information System: https://llis.nasa.gov/
• Pattern language background: https://hillside.net/patterns/

Runtime

PYTHONPATH=src python -m microcosm_core.organs.voice_to_doctrine_self_improvement_loop run \
  --input fixtures/first_wave/voice_to_doctrine_self_improvement_loop/input \
  --out receipts/first_wave/voice_to_doctrine_self_improvement_loop

The exported bundle uses the same validator without negative-case inputs:

PYTHONPATH=src python -m microcosm_core.organs.voice_to_doctrine_self_improvement_loop run-bundle \
  --input examples/voice_to_doctrine_self_improvement_loop/exported_voice_to_doctrine_bundle \
  --out receipts/runtime_shell/demo_project/organs/voice_to_doctrine_self_improvement_loop

Validation Result record Path

Run from microcosm-substrate:

A green fixture or bundle result record proves only the public lesson-propagation boundary above; it does not grant source-file changes, live work log mutation, global doctrine-promotion, launch, or whole-system authority.

cognitive_operator_registry is the public contract diagnostic for the source system's typed cognitive-operator system. It checks that each public operator row carries the required operator-shape fields, that every active operator is backed by a dogfood result record proving it changed a live decision, and that the registry policy declares explicit scope limits before a cold reader trusts the operators as real reusable cognition rather than inspirational prose.

Purpose

A team that writes down its reusable thinking moves as a registry tends to accumulate entries faster than it can prove any of them help. The single question this component answers is: which of these listed operators has actually changed a live decision, and which is just a tidy description of one? An entry may only call itself active if it points to a dogfood result record, and that result record must carry cognition_delta_evidence recording a concrete decision that came out differently because the operator was applied.

The unusual part is that the check refuses to take a row at its word. Where a result record cites evidence surfaces, command paths, or task-ledger handles, the validator resolves each one against the public system (see _dogfood_receipt_ref_resolves and _record_dogfood_evidence_resolution_findings in the source). A row whose prose says it was dogfooded but whose evidence does not resolve is recorded as a failure, not a pass. A second check, the anti-sprawl case, flags two operators that share a slug or a near-identical claim unless an accretion decision was recorded, so the registry cannot quietly grow two near copies of the same idea.

The evidence contract is source-open by default. The validator emits refs, hashes, counts, and verdicts; secret_exclusion_scan proves that secrets, account or session material, model-output data bodies, source notes, and account secret-equivalent access material are excluded. Operator bodies are never inlined into the JSON result record, so the positive evidence carries body_in_receipt: false, real_runtime_receipt: true, and synthetic_receipt_standin_allowed: false.

Prior Art Grounding

This component borrows from cognitive work analysis, provenance, schema validation, and policy-gated registries. Useful anchors include:

• Cognitive Work Analysis, summarized in this information-systems design overview, as prior art for analyzing cognitive work in complex sociotechnical systems.
• W3C PROV, for connecting operator claims to activities, agents, and evidence used to evaluate trustworthiness.
• JSON Schema, for the required-shape validation pattern behind public operator rows.
• Open Policy Agent, as a precedent for policy evaluation that remains distinct from the registry data being evaluated.

Microcosm borrows the cognitive-work, provenance, shape-checking, and policy registry patterns, but keeps this component to a public contract diagnostic. It does not mutate operators, prove operator correctness, expose private operator bodies or source notes, authorize providers, or include launch operations.

It consumes public operator_registry.json, operator_standard.json, and dogfood_index.json inputs that project real source operator rows and dogfood result records. Its result record contract is source-open by default: secret_exclusion_scan proves that secrets, account or browser material, model-output data bodies, source notes, and account secret-equivalent live-access material are excluded, while public_runtime_refs point at the real standard, component, sign-off, fixture, bundle, and paper-module system. Bodies are not inlined into JSON result records, so the positive evidence uses body_in_receipt: false, real_runtime_receipt: true, and synthetic_receipt_standin_allowed: false.

The component rejects seven boundary failures:

• operator rows missing required operator-shape fields
• active operators with no backing dogfood result record
• dogfood result records missing cognition_delta_evidence
• near-duplicate operators (identical slug or near-identical claim) with no recorded accretion decision (the anti-sprawl governor case)
• launch, provider, source-file changes, registry-mutation, or operator-correctness overclaims
• operator rows that claim operator-voice or source note authority
• private operator source bodies or model-output data bodies in public inputs

The exported bundle also imports three verbatim source bodies behind an import membrane: the cognitive-operator registry (codex/doctrine/cognitive_operators.json), the cognitive-operator standard (codex/standards/std_cognitive_operator.json), and the registry projection/validation tool (system/lib/cognitive_operator_registry.py). Each is copied byte-for-byte with a sha256 digest and required anchors; result records carry refs, hashes, counts, and verdicts only.

Shape

flowchart LR Registry["Public operator registry operator ids, roles, runtime refs"] Standard["Operator standard required fields, scope limit"] Dogfood["Dogfood result records cognition-delta evidence"] Validator["cognitive_operator_registry validator"] Source["Copied source bodies registry, standard, validator tool"] Negative["Negative floor missing fields, no dogfood, sprawl, overclaim, private leakage"] Result record["Result records refs, hashes, counts, verdicts; body text omitted"] Registry --> Validator Standard --> Validator Dogfood --> Validator Source --> Validator Validator --> Negative Validator --> Result record

Reader Evidence Routing

Read this module as a public contract diagnostic, not as a glossary of operators or a live execution surface. This page explains the shape a reader should verify; the structured data lives in the JSON files below.

Start with paper_modules/cognitive_operator_registry.json for the full module record, then use standards/std_microcosm_cognitive_operator_registry.json to check required fields, forbidden authority, public/private boundary rules, and result record expectations. Open core/fixture_manifests/cognitive_operator_registry.fixture_manifest.json before inspecting fixtures or copied source modules, because the manifest names the source-open body floor and the body-omission contract.

Read dogfood result records as evidence that an active operator changed a live decision; do not read them as proof that the operator is generally correct. Read negative cases as part of the positive claim: missing roles, missing dogfood, missing cognition-delta evidence, duplicate/sprawl pressure, operator-voice claims, authority overclaims, and private-source leakage must remain rejected.

Technical Mechanism

The runtime mechanism lives in src/microcosm_core/organs/cognitive_operator_registry.py. run() loads the first-wave public fixture inputs: operator_registry.json, operator_standard.json, and dogfood_index.json. _positive_findings() checks that operator rows have required ids, slugs, roles, claims, runtime refs, evidence refs, and scope limits, then requires each active operator to resolve to a dogfood result record with cognition-delta evidence. The dogfood evidence resolver follows public fixture refs and copied bundle handles rather than accepting a row because its prose says it was dogfooded.

Negative pressure is source-declared in EXPECTED_NEGATIVE_CASES. _negative_findings() exercises missing required fields, active operators without dogfood result records, dogfood rows without cognition-delta evidence, operator sprawl without accretion decisions, operator-voice authority claims, provider/source/launch/correctness overclaims, and private source or model-output data leakage. A pass is therefore not only "the positive rows parsed"; it also means the expected refusal classes were observed and recorded.

run_registry_bundle() is the body-floor consumer. It executes the same registry contract against examples/cognitive_operator_registry/exported_cognitive_operator_registry_bundle and makes _source_module_manifest_result() mandatory. The manifest must prove exact copied source bodies for codex/doctrine/cognitive_operators.json, codex/standards/std_cognitive_operator.json, and system/lib/cognitive_operator_registry.py; _source_open_body_import_summary() then records body ids, classes, line counts, hashes, and body_in_receipt: false. AUTHORITY_CEILING keeps those result records below registry mutation, operator correctness, provider authority, source-file changes, launch, and whole-system correctness.

Named Proof Consumers

• microcosm_core.organs.cognitive_operator_registry.run is the first-wave fixture consumer. It reads the public registry, standard, and dogfood index, writes the result, board, validation, and sign-off result records, and checks the expected negative floor.
• microcosm_core.organs.cognitive_operator_registry.run_registry_bundle is the exported-bundle consumer. It proves the copied source registry, standard, and validator bodies through source-module manifest equality while keeping copied body text out of result records.
• tests/test_cognitive_operator_registry.py::test_cognitive_operator_registry_observes_negative_cases is the public-contract regression. It asserts that all expected negative cases are observed and that all fixture operators have dogfood result records.
• tests/test_cognitive_operator_registry.py::test_cognitive_operator_registry_bundle_validates_runtime_shape is the bundle-shape regression. It checks operator counts, source-module manifest status, body-material ids, and the metadata-only result record boundary.
• tests/test_cognitive_operator_registry.py::test_cognitive_operator_registry_source_modules_are_exact_macro_body_imports is the exact-copy proof consumer. It byte-compares every manifest source ref with the copied target and verifies the recorded sha256 digests.

Validation Result record Path

Run the first-wave fixture into disposable result records from the Microcosm root:

Run the exported bundle through the same component:

cd microcosm-substrate
PYTHONPATH=src ../repo-python -m microcosm_core.organs.cognitive_operator_registry run-registry-bundle --input examples/cognitive_operator_registry/exported_cognitive_operator_registry_bundle --out /tmp/microcosm_cognitive_operator_registry_bundle

cd microcosm-substrate
../repo-pytest tests/test_cognitive_operator_registry.py -q
cd ..
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

The source atlas row carries the matching paper_module_ref, mechanism_refs, and code_loci entries.

routing_anti_patterns_registry is the public contract diagnostic for the source system's typed navigation failure rows. It validates the copied codex/doctrine/routing_anti_patterns.json registry as runnable Microcosm system: the input must declare kind: routing_anti_patterns, carry a positive version, and expose stable anti_patterns rows with unique ids and plain explanatory text.

The positive fixture imports the real source registry body. The exported bundle also carries a source module manifest and a byte-for-byte copy under source_modules/codex/doctrine/routing_anti_patterns.json, with sha256 hashes and anchors for kernel_before_grep, bridge_before_scope, and mode_in_chat_only. Result records carry refs, hashes, counts, and verdicts only; they do not inline the copied body.

The component rejects five boundary failures:

• missing kind
• duplicate anti-pattern ids
• anti-pattern rows missing explanatory text
• launch, provider, source-file changes, route-policy mutation, maturity, or whole-system-correctness overclaims
• private routing bodies, source note bodies, model-output data bodies, or secret values in public inputs

Purpose

A navigation system can fail quietly. An agent reaches for grep when a kernel route would have narrowed the space first, or changes execution mode in chat without updating the disk contract, and nothing complains until the work is already off the rails. This component answers one question: does the public registry of known routing failures hold its declared shape, and does the copied source body that backs it stay byte-honest? It names recurring navigation mistakes as typed rows so they can be recognised, not rediscovered.

The registry is treated as a checked artifact, not as authority. A page describing routing failures is easy to read as a router or as policy. The component refuses both: a row may project a public anti-pattern, but it may not declare source_authority, route_authority, or any internal control role, and the validator rejects rows that try. So the document can describe how navigation goes wrong without itself becoming the thing that decides how navigation should go.

One design choice sits in how each row's route-repair state is decided. Rather than trust a label baked into the row, the checker derives the repair state from the row's own id and explanatory text: kernel_before_grep only earns kernel_first_navigation if its text actually mentions grep, kernel, and route. A row carrying a pre-written expected_route_repair_state is flagged, and baked_expected_labels_sufficient is fixed to false. The point is to stop a registry from grading itself by self-asserted labels, and to keep the meaning grounded in the text a reader can see.

Shape

This module is a projection over a bundle-backed public routing diagnostic, not route source authority. Cold readers should read it as a bounded chain: the JSON bundle and standard name the contract; the runtime component validates fixtures and an exported source bundle; result records preserve hashes, counts, verdicts, and negative cases; generated Mermaid and Atlas rows expose the bundle edges; the scope limit remains projection-only.

flowchart TD Bundle["core/paper_module_capsules.json paper_module.routing_anti_patterns_registry"] Standard["standards/std_microcosm_routing_anti_patterns_registry.json"] Markdown["paper_modules/routing_anti_patterns_registry.md reader projection; not route authority"] Runtime["src/microcosm_core/components/routing_anti_patterns_registry.py run / run-bundle / result record writer"] Fixture["fixtures/first_wave/routing_anti_patterns_registry/input registry + negative cases"] Bundle["examples/routing_anti_patterns_registry/exported_routing_anti_patterns_bundle source_module_manifest + exact copied body"] Tests["tests/test_routing_anti_patterns_registry.py"] Result records["result records/.../routing_anti_patterns_registry*.json refs, hashes, counts, verdicts"] structured source record["paper_modules/routing_anti_patterns_registry.json 22 edges; Mermaid available; Atlas linked"] Ceiling["Scope limit no route authority, mutation, external model access, launch, or whole-system proof"] Bundle --> Markdown Bundle --> structured source record Standard --> Runtime Fixture --> Runtime Bundle --> Runtime Runtime --> Tests Runtime --> Result records Tests --> Result records structured source record --> Ceiling Result records --> Ceiling Markdown --> Ceiling

Technical Mechanism

The component is a contract checker around a public routing-registry copy, not a router. run loads the first-wave fixture and asks _build_result to validate the positive routing_anti_patterns.json payload, all declared negative cases, the secret-exclusion scan, and the metadata-only result record bundle. The positive path requires kind: routing_anti_patterns, a positive integer version, stable anti-pattern ids, explanatory text, and the named source anchors kernel_before_grep, bridge_before_scope, and mode_in_chat_only.

The failure lattice is explicit. _payload_findings records typed evidence for missing kind, non-positive version, missing rows, missing ids, duplicate ids, missing text, forbidden authority-role masquerade, private-source fields, and overclaims about launch, external model access, source-file changes, route-policy mutation, maturity, readiness, or whole-system correctness. A pass is admitted only when every expected negative case appears with its expected error code and missing_negative_cases is empty. That makes the negative cases proof obligations rather than illustrative examples.

The exported-bundle path adds source-copy accountability. run-bundle calls run_routing_anti_patterns_bundle, which requires bundle_manifest.json, source_module_manifest.json, and the copied body under source_modules/codex/doctrine/routing_anti_patterns.json. The manifest checker streams sha256 over the copied target, verifies sha256, source_sha256, and target_sha256, checks required anchors, classifies the material as copied_non_secret_macro_body, and rejects any body-in-result record claim. The source body is available in the exported source-module tree; result records keep only refs, hashes, counts, verdicts, and omission fields.

The governing lattice is deliberately narrow. The bundle binds this mechanism to concept.architecture_and_navigation_route_contract_bundle, P-1, P-2, P-3, P-5, P-6, P-8, P-9, P-12, P-15, and AX-1, AX-4, AX-5, AX-7, AX-8, AX-11, but the checker consumes those refs as a scope limit: evidence must be replayable, typed, public-safe, and below projection authority. It also depends on navigation_hologram_route_plane, agent_route_observability_runtime, and cold_reader_route_map, so the registry can describe navigation failure shapes without becoming the internal control route source.

Reader Evidence Routing

Read this module through the following source-to-proof route:

1. Start at the source record core/paper_module_capsules.json::paper_modules[58:paper_module.routing_anti_patterns_registry]. It is the source authority for source_authority: json_capsule, the component subject, mechanism subject, runtime source locus, concept, principles, axioms, dependency modules, and the projection statuses.
2. Read the generated structured source record paper_modules/routing_anti_patterns_registry.json only as a projection from that source record.
3. Follow the runtime proof path through src/microcosm_core/organs/routing_anti_patterns_registry.py, fixtures/first_wave/routing_anti_patterns_registry/input/, and examples/routing_anti_patterns_registry/exported_routing_anti_patterns_bundle/. Those surfaces carry the public registry fixture, negative cases, source_module_manifest.json, copied body target, required anchors, and digest checks.
4. Confirm the public result record floor with the named fixture command, bundle command, focused regression, and corpus check below. Result records may carry ids, refs, hashes, counts, verdicts, and omission fields, but not private routing bodies or model-output data.
5. Treat generated diagram, Atlas, search, object-map, and site cards as reachability projections from the same source row. They help a public reader find the module; they do not outrank the bundle, runtime, manifest, tests, or metadata-only result records.

Named Proof Consumers

• First-wave fixture consumer: PYTHONPATH=src ../repo-python -m microcosm_core.components.routing_anti_patterns_registry run --input fixtures/first_wave/routing_anti_patterns_registry/input --out /tmp/microcosm-routing-anti-patterns-registry/fixture --sign-off-out /tmp/microcosm-routing-anti-patterns-registry/sign-off.json --card consumes the public registry fixture, six expected negative-case families, private-source rejection, secret-exclusion scan, metadata-only result record writer, and command-card omission boundary.
• Exported-bundle consumer: PYTHONPATH=src ../repo-python -m microcosm_core.organs.routing_anti_patterns_registry run-bundle --input examples/routing_anti_patterns_registry/exported_routing_anti_patterns_bundle --out /tmp/microcosm-routing-anti-patterns-registry/bundle --card consumes the source-module manifest, exact copied source registry body, sha256 digest floor, required anchors, material class, and source-open summary while keeping body text out of result records.
• Focused regression consumer: PYTHONPATH=src ../repo-python -m pytest -p no:cacheprovider tests/test_routing_anti_patterns_registry.py -q pins negative-case coverage, source-authority masquerade rejection, digest mismatch blockers, exact copied-body imports, secret-exclusion result record policy, and fresh-card reuse behavior.
• It is a read-only result record for this Markdown slice, not permission to hand-edit generated projections.

Prior Art Grounding

This registry follows the same family as pattern and anti-pattern catalogs: name recurring failure shapes so future operators can recognize and avoid them. The Hillside patterns library is the positive pattern-language ancestor, and the software anti-pattern literature supplies the inverse move: documenting repeated practices that look useful but produce bad outcomes.

The routing-specific presentation also borrows from CLI usability practice. The Command Line Interface Guidelines emphasize discoverability, clear errors, and suggested next actions; this component applies that pressure to navigation failures by requiring stable ids and explanatory text while keeping the registry projection below route-source authority.

Validation Result record Path

From microcosm-substrate, validate the public routing-registry diagnostic without writing tracked result records:

Passing validation proves the public anti-pattern registry fixture and copied-body digest floor only. It does not make this registry route source authority, and it excludes route-policy mutation, external model access, launch, or whole-system correctness.

doctrine_fact_claim_audit is a Crown Jewel import component with real runnable system and a strict public scope limit. It consumes synthetic public fixtures, copied source source bodies, and source manifests that verify sha256 digests, line counts, required anchors, secret-exclusion status, and result record body omission.

What it proves: fact assertion, code-loci, DAG, and numeric claim binding fixture truth gate only.

Purpose

Documentation about a living system rots. A page states that there are forty-seven of something, or cites a function in a file, and both claims quietly go stale as the code moves underneath them. A reader cannot tell a current count from a number that was true once and never rechecked. This component exists to answer one question: which of a page's factual assertions can be re-derived from source right now, and which have become untracked drift?

The approach treats a documentation claim like a cached value that needs an invalidation strategy. A bare number is not enough; the claim is admissible only when it is bound to a fact assertion that records how to recompute or revalidate the value. The same pass resolves every cited code locus on disk and checks that the quoted anchor text is actually present, so a plausible-but-dead file reference becomes a typed finding rather than inert prose. The interesting move is that nothing here asks a model whether the prose reads as true. The component recomputes a bounded relation over public fixtures and reports only what that relation supports.

The second design choice worth naming is how the checks are proved. The negative floor is semantic, not label-trusting: the test harness overwrites the declared failure fixtures with bogus pass rows and confirms the evaluator still derives the expected stable error codes itself. That keeps the proof attached to the mechanism rather than to the fixture filenames. The honesty of the page rests on that: the component is a narrow claim-audit gate over copied public fixtures, not a comprehension engine, a minimum-read-graph proof, a source-file changes lane, or any launch-scope decision.

Prior Art Grounding

This component borrows from provenance modeling, structured fact-check metadata, schema validation, and supply-chain attestation. Useful anchors include:

• W3C PROV, which models entities, activities, and agents so readers can assess the quality, reliability, and trustworthiness of derived information.
• Schema.org ClaimReview, as a web metadata pattern for recording a reviewed claim and its fact-checking context.
• JSON Schema, for declaring expected structure and rejecting malformed or incomplete claim records.
• SLSA provenance, for the software-supply-chain pattern of tracing artifacts back to source and build metadata.

Microcosm borrows the provenance, claim-review, schema, and attestation shapes, but keeps this component to public fixture fact counts, code-loci existence, anchor presence, DAG references, and synthetic volatile numeric binding cases. It is not a comprehension engine, private-doctrine export, launch-scope decision, or a minimum-read-graph proof.

Technical Mechanism

The runtime mechanism is a public fixture evaluator in src/microcosm_core/organs/doctrine_fact_claim_audit.py. The component declares a CrownJewelSpec with four required inputs: fact_assertions.json, fact_dag.json, numeric_claims.json, and projection_protocol.json. The shared crown-jewel runner handles source-manifest validation, result record writing, negative-case execution, and scope limit attachment; this module supplies the domain evaluator and the semantic negative-case mutator.

evaluate first loads the fact assertion table and compares expected_fact_count to the number of fact rows. Each fact must carry at least one code locus. The evaluator resolves every relative code-locus path against the copied source-module bundle, then checks that the declared anchor text is present in the copied body. The DAG pass builds the set of audited fact ids and rejects any edge whose from or to endpoint is not in that set. These checks convert plausible documentation references into result record-backed paths, anchors, and graph edges.

Numeric claims are checked by importing the copied source_modules/system/lib/derived_fact_hologram.py body from the exported bundle and calling its find_unbound_numeric_claims function. For each row in numeric_claims.json, the evaluator synthesizes FactAssertion instances for the declared sections, records unbound numeric detections, and blocks a case when a non-detector row leaves current-state numeric prose without a matching fact assertion. Detector rows are positive evidence only because they must surface the expected section and number.

The negative floor is semantic rather than label-trusting. evaluate_negative_case mutates the positive fixture in memory for wrong_fact_count, missing_code_locus, dead_code_locus, dead_dag_ref, and unbound_numeric_claim, then reruns the same evaluator in a temporary input directory. The tests deliberately overwrite the declared negative-case files with bogus pass rows and confirm that the component still derives the expected stable error codes from the evaluator itself. That keeps the proof tied to the mechanism, not to fixture labels.

The source-open body floor is separate from the result record floor. The exported bundle manifest names two copied bodies, derived_fact_hologram.py and paper_modules.py, with digests and line counts. Runtime result records carry refs, counts, verdicts, scope boundaries, and body_in_receipt: false; they do not embed copied source bodies or private operator material.

How to run it:

Runtime bundle route:

PYTHONPATH=src python3 -m microcosm_core.organs.doctrine_fact_claim_audit run-doctrine-fact-bundle --input examples/doctrine_fact_claim_audit/exported_doctrine_fact_claim_audit_bundle --out receipts/runtime_shell/demo_project/organs/doctrine_fact_claim_audit

Shape

• Subject: doctrine_fact_claim_audit, with mechanism mechanism.doctrine_fact_claim_audit.validates_public_doctrine_fact_claim_audit.
• Runtime locus: src/microcosm_core/organs/doctrine_fact_claim_audit.py, especially run, run_doctrine_fact_bundle, evaluate, _evaluate_numeric_claims, _load_derived_fact_module, EXPECTED_NEGATIVE_CASES, and AUTHORITY_CEILING.
• The fixture checks an expected fact count, resolves declared code-locus paths, verifies required source anchors, rejects dead DAG references, and requires volatile numeric claim cases to be bound to fact assertions.
• The accepted positive result record reports three facts, three verified code loci, two DAG edges, two numeric claim cases, and one detected unbound numeric detector case, while preserving body_in_receipt: false.
• The negative floor is stable: dead_code_locus, dead_dag_ref, missing_code_locus, unbound_numeric_claim, and wrong_fact_count.
• The public standard is standards/std_microcosm_doctrine_fact_claim_audit.json; the fixture manifest is core/fixture_manifests/doctrine_fact_claim_audit.fixture_manifest.json.

flowchart LR Facts["fact_assertions.json facts + expected_fact_count"] --> Eval["evaluate"] Dag["fact_dag.json edges"] --> Eval Numerics["numeric_claims.json cases"] --> Eval Manifest["source module manifest copied bodies"] --> Eval Eval --> Count{"declared fact count = table length?"} Eval --> Loci{"each code locus path on disk + anchor in body?"} Eval --> DagRef{"DAG endpoints are known fact ids?"} Eval --> Bound{"current-state numerics bound to a fact assertion section?"} Count -->|mismatch| Block["typed blocking finding"] Loci -->|missing path or anchor| Block DagRef -->|dead ref| Block Bound -->|unbound| Block Count -->|ok| Result record["metadata-only result record body_in_receipt: false"] Loci -->|ok| Result record DagRef -->|ok| Result record Bound -->|ok| Result record Neg["evaluate_negative_case mutate fixture, rerun evaluator"] --> Codes["expected stable error codes"]

Named Proof Consumers

• Fixture CLI consumer: PYTHONPATH=src ../repo-python -m microcosm_core.components.doctrine_fact_claim_audit run --input fixtures/first_wave/doctrine_fact_claim_audit/input --out /tmp/microcosm-doctrine-fact-claim-audit/fixture --sign-off-out /tmp/microcosm-doctrine-fact-claim-audit/sign-off.json --card. Expected proof shape: status: pass, three fact rows, three verified code loci, two DAG edges, two numeric-claim cases, one detector case, zero blocking unbound numerics, five semantic negative cases, and body_in_receipt: false.
• Exported bundle consumer: PYTHONPATH=src ../repo-python -m microcosm_core.organs.doctrine_fact_claim_audit run-doctrine-fact-bundle --input examples/doctrine_fact_claim_audit/exported_doctrine_fact_claim_audit_bundle --out /tmp/microcosm-doctrine-fact-claim-audit/bundle --card. Expected proof shape: the same evaluator runs through the exported bundle input mode, validates the source-module manifest, and writes metadata-only bundle result records.
• Focused regression consumer: PYTHONPATH=src ../repo-python -m pytest -p no:cacheprovider --basetemp=/tmp/microcosm_doctrine_fact_claim_audit_pytest tests/test_doctrine_fact_claim_audit.py -q. Expected proof shape: the seven tests cover the positive fixture, dead code locus, missing code locus, dead DAG ref, unbound numeric claim, semantic negative-case derivation, and exported-bundle route.
• Corpus parity consumer: PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus. Expected proof shape: the structured source record remains reproducible from the bundle and Markdown projection without hand-editing generated state.
• structured source record readback consumer: jq '{source_authority:.paper_module_payload.source_authority, mermaid:.paper_module_payload.generated_projections.mermaid.status, atlas:.paper_module_payload.generated_projections.atlas_card.status, edge_count:(.relationships.edges|length), unresolved:(.relationships.unpopulated_selective_relations|length)}' paper_modules/doctrine_fact_claim_audit.json. Expected proof shape: json_capsule, available_from_capsule_edges, linked_from_capsule_edges, resolved bundle edges, and zero unpopulated selective relations.

Reader Evidence Routing

• Start with paper_modules/doctrine_fact_claim_audit.json as the primary reference, then open this Markdown page as a reader guide to that record.
• Open standards/std_microcosm_doctrine_fact_claim_audit.json for the standard, required witnesses, negative floor, denied authority, and result record contract.
• Open core/fixture_manifests/doctrine_fact_claim_audit.fixture_manifest.json for fixture inputs, copied-body counts, durable result record refs, and source-open body omission rules.
• Open examples/doctrine_fact_claim_audit/exported_doctrine_fact_claim_audit_bundle/source_module_manifest.json before inspecting copied source modules; result records carry refs and digests, not copied source body text.
• Run the fixture or bundle route from the microcosm-substrate directory and inspect the written JSON files. The component CLI exposes --card, but it does not expose a --json stdout mode.
• Use scripts/build_doctrine_projection.py --check-paper-module-corpus to verify this paper-module projection stays inside the shared corpus contract.

Claim-Rot Detection

This component treats documentation claims like cached values that need an invalidation strategy. The failure mode is not only a wrong number; it is a volatile number embedded in current-state prose with no attached route for re-deriving it.

The detector flags volatile numerics: a number near a countable noun inside a current-state section. Such a claim is admissible only when it is bound to a fact assertion that records how to recompute or revalidate the value. The same audit resolves every cited code locus on disk and checks that the quoted anchor is actually present, so stale file references and plausible-but-dead anchors are negative evidence rather than inert prose.

The public fixture does not claim natural-language comprehension. It proves the more useful contract: current-state numerics, fact assertions, DAG refs, code loci, and anchor text can be audited as result record-backed claims instead of untracked documentation drift.

Scope limit: Doctrine fact claim audit checks only public fixture fact counts, code-loci existence, anchor presence, DAG references, and synthetic volatile numeric claim binding cases. It is not a comprehension engine, does not establish a minimum read graph, does not export private doctrine, and excludes launch.

Validation Result record Path

From microcosm-substrate, validate with external result record outputs so the reader check does not churn tracked result records:

A diagram view is generated for this module, and an atlas card links to it. Passing result records validate fact-count, code-locus, DAG-ref, numeric-claim, digest, and negative-case boundaries only. If copied source bodies drift, refresh the exact copy bundle through the owning lane before treating bundle red as a reader-page defect.

Negative cases covered by the fixture manifest: dead_code_locus, dead_dag_ref, missing_code_locus, unbound_numeric_claim, wrong_fact_count.

Source provenance is anchored by examples/doctrine_fact_claim_audit/exported_doctrine_fact_claim_audit_bundle/source_module_manifest.json and result records carry refs, digests, counts, verdicts, and scope boundaries only.

Purpose

A navigation system that lists what it knows is easy to build. A system that can state, precisely, what it has not yet covered is harder, and it is the more honest signal to a cold reader. This component answers one question: for a declared set of Kind Atlas families, how many rows does the option surface expose that the generated System Atlas has not yet materialised?

The answer is a small debt vector, computed rather than asserted. For each selected kind the component recomputes the live Kind Atlas row count through system.lib.kind_atlas.build_kind_atlas, counts the entities the build_system_atlas.py graph has actually materialised for that kind, and reports the difference as known coverage debt. Concepts, mechanisms and standards are checked back to real source source files so the materialised set cannot be inflated with names that have no file behind them.

The unusual part is what the validator refuses. It will not accept a fixture that claims its unknown-unknowns are exhaustive: declaring claims_unknown_unknowns_exhaustive raises a finding rather than passing. The ledger reports a bounded count of gaps it can see and explicitly declines to claim there are no others. Known debt is treated as typed residual pressure, not as a completeness proof, and absence of a row is never read as proof that nothing is missing.

Abstract

self_ignorance_coverage_ledger is a public Microcosm Crown Jewel component that measures a narrow, source-grounded form of self-ignorance: known row-level coverage debt between live Kind Atlas option-surface counts and generated System Atlas materialization evidence. It recomputes the selected Kind Atlas families, derives materialized entity IDs from a build_system_atlas.py graph snapshot, source-validates graph-derived entity IDs, replays semantic negative cases, and emits metadata-only result records with scope boundaries.

The current exported bundle is a realness-rung R4 check when the source repo is available: live Kind Atlas counts are bound, the System Atlas graph slice is builder-bound, the live System Atlas graph is cross-checked, expected entity IDs are source-backed, and copied source source bodies are digest-bound through a manifest. The claim is only known_kind_atlas_coverage_debt_projection_only: it is not absence proof, unknown-unknown omniscience, total repository search proof, source-file changes, launch-scope decision, publishing-scope decision, private-system equivalence, provider affiliation, or whole-system correctness.

Problem

Navigation systems can overstate themselves in two opposite ways. A vague "coverage is incomplete" tells a cold reader nothing operational. A confident "nothing else is missing" is worse: it converts absence of evidence into evidence of absence. This component exists to occupy the narrow technical middle: for a declared finite domain of Kind Atlas families, compute the gap between what the option surface exposes and what the System Atlas graph has materialized.

The result is a self-ignorance ledger, not a universal discovery engine. Its positive output is a bounded debt vector. Its negative output is equally important: the validator must refuse fixtures that claim exhaustive unknown-unknown coverage, hand-author materialization counts, substitute entity IDs, use stale/baked expected IDs as authority, tamper with the System Atlas builder result record, or repair a copied-source manifest into a self-reference.

Mechanism

The runtime locus is src/microcosm_core/organs/self_ignorance_coverage_ledger.py. The exported-bundle entrypoint is run_self_ignorance_bundle; the core evaluator is evaluate; the semantic negative-case replayer is evaluate_negative_case; the local scope limit is AUTHORITY_CEILING.

The evaluator consumes four public bundle files:

Algorithmically, the component performs this loop:

1. Load bundle inputs and the source-module manifest through the Crown Jewel common runner.
2. Recompute selected Kind Atlas rows from the source repo when system/lib/kind_atlas.py is available.
3. Load system_atlas_graph.json, require the System Atlas builder marker, and derive materialized IDs by kind.
4. Cross-check the bundled graph slice against state/system_atlas/system_atlas.graph.json when the source repo is available.
5. For concepts, mechanisms, and standards, verify that graph-derived expected IDs resolve to real source source files.
6. Compute known_coverage_debt_count = live_kind_atlas_row_count - graph_derived_materialized_count by kind.
7. Replay semantic negative cases from clean input copies instead of trusting declared error labels.
8. Write result records with refs, counts, hashes, findings, realness evidence, and scope boundaries; copied body text stays out of result records.

For the current exported bundle, the public count vector is:

Those numbers come from examples/self_ignorance_coverage_ledger/exported_self_ignorance_coverage_ledger_bundle/kind_atlas_rows.json, materialized_entities.json, and system_atlas_graph.json, and are proof-consuming snapshot facts. They are not stable doctrine constants; rerun the validator after Kind Atlas, System Atlas, or source manifests move.

Projection Protocol Result record

projection_protocol.json is the result record that prevents a static graph slice from masquerading as live authority. The accepted bundle must carry:

The focused tests test_self_ignorance_coverage_ledger_rejects_projection_scope_tamper and test_self_ignorance_coverage_ledger_rejects_system_atlas_receipt_tamper are the proof consumers for this protocol.

Mermaid Flow

flowchart LR KA["Live Kind Atlas rows 503 selected rows"] Graph["System Atlas graph slice 307 materialized entities"] Proto["projection_protocol.json scope + build_system_atlas.py result record"] Source["Source source files concept/mechanism/standard ids"] Manifest["source_module_manifest.json copied_non_secret_macro_body"] Eval["evaluate()"] Neg["semantic negative-case replay"] Debt["known debt vector 196 units"] Result record["metadata-only result records counts, refs, hashes, scope boundaries"] Ceiling["scope limit known debt projection only"] KA --> Eval Graph --> Eval Proto --> Eval Source --> Eval Manifest --> Eval Eval --> Debt Eval --> Neg Debt --> Result record Neg --> Result record Result record --> Ceiling

This diagram is the human proof path and must stay subordinate to the bundle and generated projection.

Real-Good / Real-Bad / Perturbation Evidence

The positive case is test_self_ignorance_coverage_ledger_projects_real_bundle_known_debt plus the bundle route:

PYTHONPATH=src ../repo-python -m microcosm_core.organs.self_ignorance_coverage_ledger run-self-ignorance-bundle --input examples/self_ignorance_coverage_ledger/exported_self_ignorance_coverage_ledger_bundle --out /tmp/microcosm-self-ignorance-coverage-ledger/bundle --card

The accepted result must report status pass, known debt 196, observed negative cases forbidden_absence_inference and coverage_debt_mismatch, realness_rung: R4, live_kind_atlas_recompute_used: true, live_system_atlas_graph_crosscheck_used: true, and source-module digest success.

The real-bad cases are not marketing examples; they are the contract. Treat a guard as validated only when the focused pytest route passes in the current checkout:

Perturbation evidence is test_self_ignorance_coverage_debt_moves_with_materialized_entity_graph: adding a real, source-backed standard entity moves the known-debt count from 196 to 195 and keeps the result passing. That proves the ledger is coupled to the graph-derived materialization set, not to a fixed prose number.

The unsourced-materialization guard target is test_self_ignorance_coverage_ledger_rejects_coherent_fake_standard_entity. Its intended refusal is SELF_IGNORANCE_EXPECTED_ENTITY_ID_SOURCE_MISSING, but the paper must not count that guard as validated unless the focused pytest route currently blocks the fake standard entity. If it regresses, lower the source-validation claim to the passing guards above and route the source/test issue through the work log before completion.

Source-Backed Concept / Mechanism / Law Links

P-19 appears in the component atlas row as an adjacent governing principle for residual classification, but it is not part of the paper-module bundle's principle_refs. Treat it as component-level context unless the bundle is later updated through the JSON authority lane.

Evidence Contract

The fixture contract lives at core/fixture_manifests/self_ignorance_coverage_ledger.fixture_manifest.json. The active standard lives at standards/std_microcosm_self_ignorance_coverage_ledger.json. Together they admit public synthetic fixtures, copied source source bodies, hashes, anchors, validator refs, and generated result records. They forbid private repo bodies outside copied public fixtures, model-output data bodies, account secret or account-bound material, operator private notes, raw thread bodies, and result record body text for copied material.

The exported bundle manifest at examples/self_ignorance_coverage_ledger/exported_self_ignorance_coverage_ledger_bundle/source_module_manifest.json currently carries one source module: tools/meta/factory/build_system_atlas.py, copied into the bundle under source_modules/tools/meta/factory/build_system_atlas.py. The manifest records the source/target relation, digests, line count, required anchors System Atlas and kind, replacements, and the boundary that transform result records record hashes and replacement classes rather than source bodies.

The standard's result record contract requires a real runtime result record, a source-module manifest for the exported bundle, a secret-exclusion scan, at least the forbidden_absence_inference negative case, and body_in_receipt: false. Synthetic result records are not accepted as stand-ins for this component's authority.

Reader Evidence Routing

Read this module in this order:

1. paper_modules/self_ignorance_coverage_ledger.json for the generated paper-module projection and relationship edges.
2. core/paper_module_capsules.json::paper_modules[49:paper_module.self_ignorance_coverage_ledger] for source authority.
3. standards/std_microcosm_self_ignorance_coverage_ledger.json for the public/private boundary, validator contract, result record expectations, and scope limit.
4. src/microcosm_core/organs/self_ignorance_coverage_ledger.py for evaluate, evaluate_negative_case, run, and run_self_ignorance_bundle.
5. examples/self_ignorance_coverage_ledger/exported_self_ignorance_coverage_ledger_bundle/ for the current public evidence bundle.
6. tests/test_self_ignorance_coverage_ledger.py for proof consumers, bad cases, and perturbation cases.

Treat negative cases as part of the positive claim. The paper should cite only guards that the focused validation route blocks in the current checkout. The validated guard set must include forbidden absence inference, coverage mismatch, baked expected IDs without source, declared entity substitution, materialized count tamper, graph materialization tamper, graph builder tamper, projection protocol tamper, stale source self-reference, and digest mismatch. Fake-but-coherent standard entities remain a required unsourced-materialization guard target, but not an observed passing guard unless the focused test route blocks that perturbation.

Prior Art Grounding

The nearest ordinary analogue is software coverage measurement: coverage tools report what was exercised or missed over a declared surface, not all possible missing behaviors. coverage.py is useful as a reference pattern for bounded observed coverage over a source set.

The health-signal side is adjacent to automated repository checks such as OpenSSF Scorecard: bounded checks can produce useful risk signals without becoming complete security or quality proof. Microcosm applies that pattern to navigation coverage debt and keeps the scope boundary in the same result record frame as the count.

Validation Result record Path

From microcosm-substrate, run:

PYTHONPATH=src ../repo-python -m pytest -p no:cacheprovider tests/test_self_ignorance_coverage_ledger.py -q
PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus
PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check

Use a throwaway result record directory for manual bundle checks:

PYTHONPATH=src ../repo-python -m microcosm_core.organs.self_ignorance_coverage_ledger run-self-ignorance-bundle --input examples/self_ignorance_coverage_ledger/exported_self_ignorance_coverage_ledger_bundle --out /tmp/microcosm-self-ignorance-coverage-ledger/bundle --card

Passing validation proves that the declared public bundle, source-module manifest, negative cases, and paper-module corpus remain coherent. It does not establish freshness beyond the checked snapshot or authorize generated projection edits by hand.