Navigation Hologram Route Plane

Readers trust whatever browse surface is nearest, so this validator checks that a navigation surface starts from one control entry and keeps every row a projection. Anyone who lands in a large codebase starts from whatever browse surface is nearest, treats that surface as the truth, and acts on a stale or partial view. The route plane is a validator that pushes back on this. It checks that a navigation surface starts from one control entry, that browse rows stay projections, and that no row is allowed to pose as the thing it describes.

It runs offline over fixtures and one exact copy of navigation source modules, emitting plain metadata-only result records that each state only what they checked. The component runs offline over fixture files and over one exact copy of navigation source modules. It never touches a live system. What it emits is a set of plain result records: a cluster summary, a selected card, a source-coupling result, a route lease, an entry-admission record, an affordance-selection record, and a code-architecture packet. Each record states what it checked and carries no source body text.

It is a rules check on a navigation surface, not a live router, a search index, or a source of navigation truth. It is not a live router, a search index, or a source of navigation truth. It is a check that a navigation surface obeys its own rules before a reader or agent trusts it.

Purpose

Why a browse row needs a coupling record

A browse row that speaks with its source's authority lets a stale view steer the next move, so the plane demands a coupling record before granting any authority. A loose navigation surface fails in a specific way. A browse row is a compressed view of some source, and if the row is allowed to speak with the source's authority, then a stale or mislabeled row silently steers the next move. The route plane treats every browse row as a projection and demands a coupling record before that projection gets any authority.

Source coupling is a SHA-256 fingerprint

Source coupling hashes the route rows with SHA-256 and denies authority when the fingerprint or row count disagrees with disk, recording a stale-but-current summary as an overclaim. Source coupling is a plain SHA-256 over the route rows. The manifest declares an expected fingerprint and an expected row count. If either disagrees with the rows on disk, the projection is denied current authority. A summary that claims to be current while its coupling is stale is recorded as an overclaim.

Refusals the fixture must keep catching

The plane forces first contact to the control entry, forbids dropping a required control field on compaction, and demotes anti-trigger affordances, each a named negative case. The other half is what the plane refuses. First contact must begin at the control entry, so a request that starts 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 select it. Each of these is a named negative case the fixture must keep catching.

How it works

Two entry points, one discipline

Two entry points share the same discipline: run drives the fixture mode and run_route_plane_bundle drives the exported-bundle mode. The component has two entry points against the same discipline. run drives the fixture mode. run_route_plane_bundle drives the exported-bundle mode.

The run fixture-mode pipeline

run loads thirteen fixture inputs, scans for leakage, builds a toy option surface, and passes only when the scan is clean and every expected negative case fired. run loads thirteen fixture inputs, scans them for non-public-state leakage, builds a toy option surface with build_toy_option_surface (a cluster summary plus one selected card), then evaluates nine negative-case validators. It merges the negative cases each validator observed and computes the set of expected cases that went unobserved. The status is pass only when no expected case is missing and the non-public-state scan is clean. The fixture proves each guard still fires by requiring every expected negative case to actually appear.

The run_route_plane_bundle bundle-mode gate

run_route_plane_bundle loads nine bundle files, digests and secret-scans them, and passes only when a card was selected and every bundle validator finds nothing. run_route_plane_bundle loads nine bundle files, records a freshness basis and digest over them, scans them with the secret-exclusion scan, then runs the group of exported-bundle validators. Its status is pass only when the secret scan is clean, a card row was selected, no validator produced a finding, and the source-module, lease, entry, affordance, and code-architecture checks all pass.

Digest and anchor checks on copied modules

_stable_hash fingerprints the route rows, while validate_source_module_manifest matches each copied file's digest and anchors, rejects unsafe paths, and keeps bodies out of records. The coupling gate uses _stable_hash, a SHA-256 over the route rows serialized as canonical JSON. validate_source_module_manifest reads each copied file, requires its digest to match both the declared source and target digests, requires every declared navigation anchor to be present in the body, and requires the boundary flags body_copied=true and body_in_receipt=false. A target reference that is absolute or contains .. is rejected before any read. The body text is never written into a result record.

flowchart TD Entry["Control entry first a browse row that claims first contact is replaced with the entry route"] Couple["Source coupling SHA-256 over route rows vs manifest fingerprint and row count"] Rows["Route rows allowed role, actionable command, no source-authority claim, omission record when compressed"] Modules["Source-module manifest five copied bodies digest and required anchors, body never in the record"] Floor["Entry-packet floor required control fields survive compaction"] Pass["Affordance passports anti-trigger rows demoted before selection"] Verdict["Coupling current, all checks pass, card row selected?"] Result records["metadata-only result records cluster flag, card, coupling, route lease, entry admission, affordance, code-architecture packet"] Blocked["Blocked stable error codes and findings, bodies redacted"] Entry --> Couple Couple --> Rows Rows --> Modules Modules --> Floor Floor --> Pass Pass --> Verdict Verdict --> Result records Verdict --> Blocked

Negative cases

Eight cases carrying nine error codes

Eight negative cases carry nine stable error codes, one case carrying two, and the fixture passes only when every code is observed. The fixture mode is defined by eight negative cases that carry nine stable error codes. One case carries two codes, which is why the counts differ. Every code below must be observed for the fixture to pass.

Prior Art Grounding

Progressive disclosure, CLI, and graph tooling

The design borrows progressive disclosure, CLI discoverability, and directed-graph tooling, but keeps cards, leases, and browse rows below authority until coupling and entry records agree. The route plane sits on information-architecture and graph-navigation practice. The first-contact rule follows the usability pressure behind progressive disclosure: show the control entry and immediate affordances before deeper browse rows. The command-facing surface follows the Command Line Interface Guidelines emphasis on discoverable commands and clear next actions. The graph side is ordinary directed-graph tooling: NetworkX documents topological sorting over dependency edges, and PageRank shows the older pattern of computing route salience from graph structure. This component keeps those ideas below authority: cards, leases, and browse rows stay projections unless the coupling and entry-admission records agree.

Source-Backed Doctrine Packet

The authoritative sources for this module are:

• core/organ_registry.json::implemented_organs[navigation_hologram_route_plane] records the accepted component authority: evidence class semantic_validator, 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] carries the cold-reader gloss. It restates the scope limit: 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.
• standards/std_microcosm_navigation_hologram_route_plane.json governs the authority boundary public_navigation_route_plane_runtime_and_copied_source_body_validator_not_live_source_authority and declares the runtime bundle command python -m microcosm_core.organs.navigation_hologram_route_plane validate-route-plane-bundle --input examples/navigation_hologram_route_plane/exported_route_plane_bundle.
• src/microcosm_core/organs/navigation_hologram_route_plane.py is the runtime source for fixture validation, bundle validation, the coupling gate, the negative-case guards, and the source-module digest and anchor checks.
• 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 the nine stable error codes above.
• examples/navigation_hologram_route_plane/exported_route_plane_bundle/source_module_manifest.json names the five exact copied route and control bodies validated by digest and anchors.
• tests/test_navigation_hologram_route_plane.py is the regression floor for fixture records, copied-source digests, source-module anchors, record redaction, bundle validation, digest-mismatch rejection, and this packet.

The five copied source modules:

The fixture command writes these result records:

• 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

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

What a pass certifies here

A pass means the fixture caught every negative case, the bundle validated its rows, coupling, and copied modules, and no record leaked a body or non-public paths. A pass means the fixture observed every expected negative case, the exported bundle validated its route rows, source coupling, and copied source modules, and no result record carried a source body or a non-public paths. The validation result records for this module are the result records those commands write.