Paper modules

Full module

verifier_lab_kernel is the public composition root for the formal-math verifier lab. It is not a theorem prover, a benchmark runner, a private Lean import, or a frontend surface. It composes already-public Microcosm components into one leak-proof result record so a reader can see which claim came from a verifier, which claim came from an oracle comparator, which claim came from a provider hypothesis, and which rows were rejected by contract.

The component consumes:

• a public ForwardProblem packet with target shape, statement summary, public input hash, and allowed premise ids;
• an OracleSidecar packet that may compare against hidden or hindsight knowledge but never increments forward success;
• verifier attempts and verifier result classes;
• provider/NIM hypotheses as advisory residual diagnoses only;
• CP2 typed action candidates, bounded evidence bodies or raw tactic scripts;
• bounded Evolve candidates over policy artifacts only.

The runnable fixture also calls the existing public components:

• tactic_portfolio_availability_probe;
• target_shape_tactic_routing_gate;
• formal_math_verifier_trace_repair_loop;
• formal_math_lean_proof_witness.

Purpose

In a formal-math agent loop, several different things can look like progress. A Lean checker can accept a term. An oracle holding a hindsight answer can say a candidate matches. A provider model can offer a plausible next tactic. A retrieval step can return a premise. Treated loosely, all of these blur into a single sense of "it worked", and oracle or provider success quietly inflates the count of theorems actually proved. This component exists to stop that blur. The one question it answers is: for each row of evidence, which authority class does it belong to, and what may that class claim?

The composition root runs or consumes nine named component components (corpus readiness, Lean Std premise indexing, premise retrieval, tactic availability, target-shape routing, Ring2 precision and recall, verifier trace repair, proof diagnostics, and the Lean proof witness) and sorts every result into seven separate buckets: verifier-checked, provider-suggested, oracle-compared, retrieval-miss, CP2-translated, Evolve-candidate, and contract-rejected. Each bucket keeps its own authority. A passing component cannot lend its standing to a different bucket.

The unusual part is how the boundary is enforced rather than merely described. The kernel keeps two counters, oracle_forward_success_increment_count and provider_results_counted, and they must read zero. An oracle that marks itself as forward success, or a provider hypothesis that claims proof authority, is recorded as a contract violation, not as a result. The same discipline applies to data: forward problems and CP2 actions are scanned for fields that would smuggle in a proof body, an ideal answer, or an oracle's needed premise ids, and CP2 and Evolve outputs are confined to a fixed vocabulary of action classes and policy artifacts. What the reader receives is a single aggregate result record that carries references, digests, counts, and verdicts, with the proof, provider, oracle, and stdout bodies left out.

Shape

Read the verifier lab kernel as a public result record composition route, not as a proof oracle. The local path spine is the bundle and structured source record (core/paper_module_capsules.json::paper_modules[0:paper_module.verifier_lab_kernel], paper_modules/verifier_lab_kernel.json), the runtime composition root (src/microcosm_core/organs/verifier_lab_kernel.py), the public packet (fixtures/first_wave/verifier_lab_kernel/input/verifier_lab_packet.json), and the emitted public result records under receipts/first_wave/verifier_lab_kernel/.

flowchart TD bundle["Bundle and structured source record core/paper_module_capsules.json paper_modules/verifier_lab_kernel.json"] packet["Public verifier packet fixtures/first_wave/verifier_lab_kernel/input/verifier_lab_packet.json"] kernel["Composition root src/microcosm_core/components/verifier_lab_kernel.py"] components["Public component result records tactic portfolio / target shape / trace repair / Lean witness"] buckets["Separated claim buckets lean_verified | oracle_compared | provider_suggested | retrieval_miss | cp2_translated | evolve_candidate | contract_rejected"] result records["Public board/result/validation result records result records/first_wave/verifier_lab_kernel/*.json"] ceiling["Scope limit no proof-body import; no oracle/provider forward success; no launch claim"] bundle --> packet --> kernel kernel --> components --> buckets --> result records kernel --> ceiling buckets --> ceiling

Prior Art Grounding

This component is grounded in small-kernel theorem-proving and proof-certificate composition patterns. The LCF approach and HOL Light anchor the idea that a verifier lab should distinguish trusted checked results from heuristics and automation. Lean-oriented work such as LeanDojo adds the modern agent context: retrieval, provider hypotheses, and proof-state interaction need explicit boundaries before they can influence proof claims.

Microcosm borrows the composition discipline: verifier success, oracle comparison, provider hypothesis, CP2 translation, and Evolve candidate rows are separate buckets with separate authority. It does not count oracle or provider success as forward proof success.

The sign-off result record must separate these buckets:

• lean_verified;
• provider_suggested;
• oracle_compared;
• contract_rejected;
• retrieval_miss;
• cp2_translated;
• evolve_candidate.

The kernel rejects five contract failures:

• forward problems that carry candidate, ideal, repair, oracle, source proof, proof body, or base-index fields;
• oracle comparator success counted as forward success;
• provider hypotheses claiming proof authority;
• CP2 candidates carrying proof bodies, raw tactic scripts, provider bodies, or oracle templates;
• Evolve candidates mutating anything outside the bounded policy-artifact set.

Reader Evidence Routing

Cold-reader audit starts with the generated structured source record for this module, not with a broad theorem-proving claim. The structured source record must confirm that verifier and mechanism subjects resolve and that a diagram view and atlas card are available for this module.

Evidence should be read in this order:

• Module definition: core/paper_module_capsules.json::paper_module.verifier_lab_kernel and paper_modules/verifier_lab_kernel.json.
• Runtime proof: src/microcosm_core/organs/verifier_lab_kernel.py, the fixture input packet, and the public component calls listed above.
• Bucket-separation proof: result record rows for lean_verified, provider_suggested, oracle_compared, contract_rejected, retrieval_miss, cp2_translated, and evolve_candidate.
• Negative boundary proof: rejection of private proof bodies, oracle-to-forward success, provider proof authority, CP2 proof bodies, arbitrary Evolve mutation, source-file changes, benchmark solve-rate claims, launch claims, hosted-deployment claims, and secret export.

Validation Result record Path

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

Full module

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.

Full module

This public slice validates synthetic route-feedback fixtures for the agent observability component.

It checks actor-axis authority boundaries, route-lease consumption, duplicate trace ids, hook-shadow advisory status, anti-pattern debt retirement, and behavior-change evidence gates.

Purpose

The observability surface is the place where a cold reader should see that a local run produced a route, work transaction, event trail, evidence ref, and authority boundary. It should not force that reader to start from raw JSON, and it should not replace command-backed evidence with motion or dashboard style.

The useful first artifact is therefore a compact causal board: one command, one selected route, one work/event/evidence chain, one result record or validator handle, and one scope limit. Browser views, screenshots, and videos are allowed projections of that board, not separate claims.

Underneath the board, the component is a replay validator rather than a live tap. It reads recorded trace rows and turns them into paper-visible evidence only after a set of authority-boundary checks agree, and the choice that does the real work is the actor axis. A row tagged as an advisory actor cannot also claim live mutation authority, and a behaviour-change claim is blocked unless it names the trace ids that evidence it. This guards the specific failure mode of observability that reads as proof: a trace that asserts it changed how an agent behaved, with nothing recorded that a reader can check. Here the assertion is rejected, the private transcript body it might carry is redacted, and the run is marked blocked rather than green.

Shape

The reader path starts at the source record, then follows the governed standard into the runtime component, public fixture inputs, source-open manifests, result records, and regression checks. The path is local and inspectable: core/paper_module_capsules.json::paper_modules[2:paper_module.agent_route_observability_runtime] points to standards/std_microcosm_agent_route_observability_runtime.json and src/microcosm_core/organs/agent_route_observability_runtime.py; the runtime then writes bounded public result records under receipts/first_wave/agent_route_observability_runtime/.

flowchart TD Bundle["JSON bundle core/paper_module_capsules.json::paper_modules[2]"] Standard["Authority boundary standards/std_microcosm_agent_route_observability_runtime.json"] Runtime["Runtime component src/microcosm_core/components/agent_route_observability_runtime.py"] Fixtures["Public fixture input fixtures/first_wave/agent_route_observability_runtime/input"] Manifests["Source-open manifests examples/agent_route_observability_runtime/*/source_module_manifest.json"] Negatives["Required negative cases actor axis, route lease, hook shadow, non-public-state floors"] Bundles["10 exported bundle validators 31 source-module rows"] Card["Compact result card large/private payloads omitted"] Result records["metadata-only result records result records/first_wave/agent_route_observability_runtime/"] Tests["Focused checks tests/test_agent_route_observability_runtime.py"] Ceiling["Scope limit public route-observability fixtures only"] Bundle --> Standard --> Runtime Runtime --> Fixtures --> Negatives --> Result records Runtime --> Manifests --> Bundles --> Result records Result records --> Card Result records --> Tests --> Ceiling

Technical Mechanism

The component is a route-feedback replay validator, not a live observability tap. run loads the first-wave fixture, streams JSONL trace rows without materializing the whole file, scans public inputs for forbidden non-public-state classes, and then composes six validation gates: route compliance, hook-shadow coverage, anti-pattern debt retirement, route-lease mode control, agent-principle-lens admission, and egress mirror boundaries. The result only passes when the expected negative-case set is complete, the non-public-state scan passes, hook-shadow coverage passes, agent-principle-lens rows do not mint principles or promote candidate axioms, and the egress mirror keeps private state, model-output data, and browser UI/operator UI state false.

The first-wave fixture is deliberately small but adversarial. The focused test expects 10 trace rows, one actor-axis mismatch, one authority rejection, one route-miss replacement, six hook-shadow cases, six egress cases, one anti-pattern debt retirement, and two route-lease control failures (KERNEL_BLOAT_BEFORE_DIRECT_ACTION and ROUTE_LEASE_NOT_CONSUMED). The negative-case floor covers wrong actor axis, missing route lease, private transcript body, duplicate trace id, route-compliance overclaim, route miss replacement, hook-shadow missing authority, banned-route intervention, command displacement, live-state read attempt, and hook-shadow budget overrun.

The exported-bundle side is the source-open body floor. Ten source_module_manifest.json files under examples/agent_route_observability_runtime/ declare 31 copied or sanitized public source-module rows with body_in_receipt=false. Most rows are copied source bodies; the route-compliance-audit bundle is a mixed manifest with one public-reference sanitized row and copied body rows. Bundle validators check source-target digests, line counts, byte counts where declared, required anchors, validation refs, and non-public-state scans. A manifest digest mismatch or synthetic non-public-state regression token blocks the bundle and still keeps result record bodies redacted.

Result records are generated as public-relative JSON proof surfaces. write_receipts emits route-compliance, hook-shadow, debt-retirement, route-lease, agent-principle-lens, and egress-mirror result records with common fields: validator id, command, status, expected and observed negative cases, findings, scope boundary, non-public-state scan, scope limit, source pattern ids, and result record paths. result_card then exposes a compact card while omitting large or private payload classes such as findings, private scans, source body imports, and scope limit bodies.

Named Proof Consumers

• run is the first-wave fixture consumer. It proves the public trace-row, hook-shadow, route-lease, agent-principle-lens, egress, negative-case, and metadata-only result record boundary for the local fixture.
• run_observability_bundle is the main exported-bundle consumer. It validates public route events, agent-path observations, session diagnostics, hook-shadow rows, actor-axis checks, debt rows, process-audit rows, observability policy, source-module manifest integrity, and result record-card reuse for the exported observability bundle.
• The companion bundle consumers run_route_compliance_audit_bundle, run_session_attribution_bundle, run_harness_configuration_audit_bundle, run_multi_agent_fanin_bundle, run_bridge_dispatch_yield_resume_bundle, run_controller_heartbeat_bundle, run_agent_trace_route_repair_bundle, run_agent_observability_store_bundle, and run_computer_use_action_trace_bundle prove the same route-observability membrane across adjacent public route, session, bridge, controller, store, and computer-use evidence slices.
• tests/test_agent_route_observability_runtime.py is the focused regression consumer. It asserts source-module manifest body-copy contracts, digest and line-count checks, sanitized-row handling, duplicate-key rejection, streaming loaders, required negative cases, public-relative redacted result records, bundle blocking on digest mismatch/non-public-state hits, and compact card omission of private scans.
• tests/test_macro_projection_import_protocol.py::test_agent_execution_trace_body_import_is_unified_under_macro_projection_spine is the cross-module consumer that keeps the route-observability body import under the source projection import spine rather than a local-only copy story.

Prior Art Grounding

This component is grounded in distributed tracing and agent trajectory work. The W3C Trace Context recommendation and OpenTelemetry show the established observability pattern: propagate trace identity, collect events, and preserve enough context to debug a distributed transaction. Agent work such as ReAct also made the interleaved reasoning/action trajectory a first-class object for interpreting agent behavior.

Microcosm borrows the traceability shape for route feedback: selected route, route lease, trace id, work/event/evidence chain, validator ref, and scope limit are exposed together. It does not read live operator traces, model-output data, browser HUD state, or certify runtime behavior outside the public fixture.

Source-Backed Doctrine Packet

This module is source-backed only when a reader can move from the public doctrine claim to the runtime component, standard, source-module manifests, result records, and negative cases without guessing. The compact packet is:

Component authority:

• core/organ_registry.json::implemented_organs[organ_id=agent_route_observability_runtime]
• core/organ_evidence_classes.json::organ_evidence_classes[agent_route_observability_runtime]
• These rows declare status=accepted_current_authority, evidence_class=semantic_validator, evidence strength rank 5, and the exact scope limit below.

Standard authority:

• standards/std_microcosm_agent_route_observability_runtime.json
• This governs the public route-observability schema, body import posture, authority boundary public_route_observability_runtime_metadata_and_copied_macro_trace_bodies_not_live_session_provider_browser_hud_or_hook_authority, and scope boundary language.

Bundle and mechanism authority:

• core/paper_module_capsules.json#paper_module.agent_route_observability_runtime
• core/mechanism_sources.json#mechanism.agent_route_observability_runtime.validates_public_route_feedback
• These bind the authored Markdown projection to the accepted component, mechanism row, code locus, generated projection hooks, result record refs, guardrails, and focused regression command without treating this prose as source authority.

Runtime and manifest evidence:

• src/microcosm_core/organs/agent_route_observability_runtime.py
• See the body-floor manifest list below.
• The runtime builds public fixture result records, exported bundle validators, observability cards, source-manifest checks, non-public-state scans, and typed negative-case results. The manifests bind the copied route/observability source body materials recorded by microcosm workingness::agent_route_observability_runtime.source_open_body_imports while preserving body_in_receipt=false.

Focused regression and result records:

• tests/test_agent_route_observability_runtime.py
• tests/test_macro_projection_import_protocol.py::test_agent_execution_trace_body_import_is_unified_under_macro_projection_spine
• receipts/first_wave/agent_route_observability_runtime/
• These pin streaming loaders, digest helpers, bundle validators, source-module manifests, scope limits, source-body import coupling, route compliance, hook-shadow advisory status, debt retirement, route-lease mode control, principle lensing, and egress mirror boundaries.

Reader Evidence Routing

Reader evidence starts at the JSON source record, then follows the accepted component and mechanism refs into the runtime source, fixture manifests, result record set, and focused regression. The route is intentionally source-backed but not source-authoritative: this Markdown helps a cold reader find the proof surfaces, while the bundle, registry, standard, mechanism row, runtime source, and result records remain the authority.

Observable First Artifact Contract

The first observable artifact must fit a single browser or terminal viewport and preserve this order:

Required cues:

• Local action: show the exact command, normally microcosm hello <project> or microcosm tour --card <project>. A visual board cannot be the first proof if the producing command is hidden.
• Selected route: show selected_route_id plus a short reason. Route explanation stays tied to the local project, not whole-system capability.
• Work transaction: show work id, state, and result record ref when present. State changes are local system events, not source-file changes or external model service.
• Event and evidence chain: show event ids, evidence class, proof surface, and scope boundary. Counts remain accounting fields, not progress or launch scores.
• Authority boundary: place the scope limit beside the positive claim. The board rejects hosted launch, private-data equivalence, external model access, and whole-system correctness.
• Structural scale bridge: name the larger system surface exercised by this run. Scale is a drilldown path, not an implied proof upgrade.

If a renderer cannot show all slots in one viewport, it should show the command, route, evidence class, result record ref, and scope limit first, then link to the full route model as drilldown.

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.agent_route_observability_runtime \
  run \
  --input fixtures/first_wave/agent_route_observability_runtime/input \
  --out /tmp/microcosm-agent-route-observability-runtime
PYTHONPATH=src ../repo-python \
  -m microcosm_core.organs.agent_route_observability_runtime \
  validate-observability-bundle \
  --input examples/agent_route_observability_runtime/exported_observability_bundle \
  --out /tmp/microcosm-agent-route-observability-bundle
../repo-pytest \
  tests/test_agent_route_observability_runtime.py \
  tests/test_macro_projection_import_protocol.py::test_agent_execution_trace_body_import_is_unified_under_macro_projection_spine
PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

The focused regression file is the proof consumer for this result record section. Its 51 tests cover the Markdown source-backed packet, streaming JSONL loaders, duplicate-key rejection, source-module manifest contracts, digest and line count helpers, exported observability and companion bundles, public-relative redacted result records, field-floor ratchets, card reuse, private-scan blockers, exact or source body imports, and computer-use action-trace boundaries. The source-projection focused test keeps the agent execution trace body import under the shared source projection spine.

That result record path validates declared public metadata and writes bounded result records. It does not inspect live sessions, export transcript/provider bodies, read browser HUD state, expose account secrets or browser state, control accounts, send recipients, change source files, prove benchmark performance, authorize public sharing, claim hosted readiness, or include launch operations.

The negative-case floor is part of the doctrine, not an implementation detail. Keep these cases visible when strengthening the module: actor-axis mismatch, missing route lease, private transcript body, duplicate trace id, route-compliance overclaim, kernel bloat before direct action, reusable-lease metadata without trace feedback, route miss replacement, hook-shadow missing authority, hook-shadow banned-route intervention, command displacement, live-state read attempt, and hook-shadow budget overrun.

Validation Shape

Fixture validation should continue to require actor-axis boundaries, route-lease consumption, duplicate trace-id detection, hook-shadow advisory status, anti-pattern debt retirement, and behavior-change evidence gates. When an observable-first board or endpoint is present, validation should also prefer fields that prove the compact causal order:

• command ref before visual state;
• selected route before full route graph;
• work/event/evidence refs before explanation prose;
• evidence class and scope boundary beside any counter;
• scope limit before hosted, launch, provider, or correctness language;
• compact endpoint or board ref before raw JSON drilldown.

Scope boundary: this module does not inspect live operator traces, prompt/provider bodies, HUD/browser/operator UI state, live work log rows, model-output data, private source bodies, or runtime behavior. It only defines the public fixture and projection boundary for observable route evidence.

validates only public recorded route-feedback and observability metadata fixtures, including route-lease consumption, trace attribution, hook-shadow advisory status, anti-pattern debt retirement, behavior-change evidence gates, and public source body import refs; does not read live operator/provider/browser UI/account state, mutate work log or source, install hooks, certify runtime behavior, authorize pattern assimilation, private-system equivalence, launch, public sharing, or whole-system correctness

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

python \
  -m microcosm_core.organs.agent_route_observability_runtime \
  run \
  --input fixtures/first_wave/agent_route_observability_runtime/input \
  --out receipts/first_wave/agent_route_observability_runtime

Full module

This module is the public Microcosm projection of the rule that agent benchmark claims must be replay-backed before they are score-backed. It carries copied source-open source pattern provenance bodies for the benchmark-integrity pattern row and reconstruction state, plus a metadata-only regression integrity component. It is not a benchmark runner or product-progress claim.

The fixture models a repository repair benchmark with public case ids, task and patch hashes, locked evaluator ids, evaluator config hashes, file-access log refs, contamination-check refs, trusted-reference score refs, output-replay refs, held-out guard ids, and body_in_receipt=false rows. It deliberately keeps issue bodies, oracle patch bodies, hidden-gold answers, model-output data, and live repository paths out of the public boundary.

The exported bundle includes source_module_manifest.json and source_artifacts/ copies of the source pattern provenance rows from state/microcosm_portfolio. The validator verifies those copied bodies by manifest digest and keeps body text out of result records.

Purpose

Agent benchmark numbers are easy to state and hard to trust. A single headline like "passes N percent of repository repair tasks" hides every decision that produced it: which evaluator ran, whether its configuration was frozen, whether the agent could see held-out answers, whether the test cases leaked into training, and whether one lucky attempt was promoted as the score. This component exists to answer one question before any of that language is allowed: can each claimed pass be replayed from public refs that name their evaluator, their configuration hash, and the evidence that the run was not gamed?

A positive result cannot be asserted. A replay row that simply declares integrity_pass is recomputed from scratch. The validator checks that the evaluator id is on a locked list, that the configuration hash is one the policy declared in advance, that file-access, contamination, and output-replay evidence artifacts exist and pass, and that the case id was registered up front. If any of those is missing or contradicted, the row is recomputed as quarantine regardless of what it declared. Declaring success is treated as the thing to be checked, not as the proof.

There is a further floor: an integrity_pass must be backed by a sanitised real command-run trace, not only by hand-written replay refs. Each row cites a real_benchmark_trace_ref that has to resolve to a copied artifact carrying a passing focused pytest run for this component, with sha256 digests bound to the recorded command-run id and an explicit list of omitted live material (model-output data, account secrets, private issue bodies, oracle patch bodies). The point is to stop a benchmark claim from resting on prose. The evidence has to trace back to a command that actually ran and is reproducible from public refs, while the private and live material that command touched stays out of the public boundary.

This is a discipline fixture, not a leaderboard. It proves that a metadata-only replay respected an anti-gaming boundary over public case ids and locked evaluator refs. It never reports a score, a SWE-bench result, or a capability claim, and the eleven negative cases below are there to demonstrate the boundary holding rather than to advertise a number.

Technical Mechanism

The component turns a benchmark claim into a replay-verification problem. Its inputs are the projection protocol, locked evaluator policy, benchmark case roster, replay observations, exported bundle manifest, source-module manifest, and copied source_artifacts/ rows. _build_result loads those inputs, validates source-module imports, scans public inputs and copied source bodies against the non-public-state forbidden-class policy, checks projection protocol density, validates the locked evaluator policy, validates the case roster, and then validates each replay row against the same public boundary.

A positive replay cannot pass by declaring success. The replay row must name a case id present in benchmark_cases.json, cite a locked evaluator id, carry an evaluator config hash allowed by locked_evaluator_policy.json, expose file-access, contamination-check, trusted-reference, and output-replay refs, and cite source-artifact evidence refs that match the exported source-module manifest targets. Each of those evidence refs must resolve to a metadata-only benchmark_integrity_evidence_artifact_v1 artifact bound to the same replay, case, evaluator, and config hash, with file-access marked passed, contamination flags clear, a trusted reference present without a claimed score, and an output replay that is not final-answer-only grading. The validator recomputes whether each row is integrity_pass or quarantine; missing refs, unregistered cases, unlocked or mutated evaluators, score authorization, private issue bodies, oracle patch bodies, hidden-gold access, model-output data, pass-k cherry-picking, and misleading tests force quarantine or a blocking finding.

A further gate is the real-trace floor. Every positive replay row also cites a real_benchmark_trace_ref, and that ref must resolve to a copied source-module artifact whose material_class is public_sanitized_real_benchmark_trace. The validator opens that artifact and checks that it records a completed, exit-zero command run of the focused pytest for this component, carries a passing pytest summary, binds sha256 digests for the command metadata, stdout, and stderr to a declared command-run id, cites state/command_runs/ source refs for that id, and declares the omission of model-output data, account secrets, private issue bodies, and oracle patch bodies. A replay whose real_benchmark_trace_ref is missing, unverified, or not also listed in the source-artifact evidence refs cannot stand as a pass. This is what stops a benchmark claim from resting on hand-authored refs alone: the integrity verdict has to trace back to a command that actually ran and is reproducible from public refs.

The copied body floor is verified separately from the public result record. The source-module manifest must declare copied_non_secret_macro_body material, public source pattern body classes, body_in_receipt=false, and digest-stable targets. validate_source_module_imports checks that each manifest row points to an existing copied artifact and that its recorded SHA-256 digest matches disk. Result records and command cards then omit the bodies and carry only ids, refs, digests, classes, counts, verdicts, findings, and scope limits.

The public trace is a second proof pass rather than a display copy of replay rows. build_public_benchmark_integrity_anti_gaming_trace recomputes each span from locked-evaluator status, contamination signals, file-access refs, contamination-check refs, trusted-reference refs, and declared quarantine reasons. The expected public fixture has three spans: two recompute as integrity_pass, one recomputes as quarantine, and the trace must agree with the declared replay verdicts before the component can return status=pass.

Named Proof Consumers

• run consumes the first-wave fixture and writes the result, board, validation result record, sign-off result record, and metadata-only command card. It is the proof consumer for the canonical fixture boundary and required negative-case floor.
• run-benchmark-integrity-bundle consumes the exported public bundle and proves that source-open body imports, bundle shape, manifest digests, and metadata-only result record/card rules survive outside the fixture directory.
• tests/test_agent_benchmark_integrity_anti_gaming_replay.py is the focused regression consumer. It asserts negative-case observation, digest verification, source-artifact evidence refs, public trace verdict recomputation, positive/negative verdict handling, metadata-only result records, bundle runtime shape, and command-card reuse of a fresh result record.
• A cold reader consumes this Markdown only after checking the JSON bundle, generated JSON instance, exported source manifest, case roster, replay observations, focused test path, and scope limit. The reader may verify the replay boundary but must not infer a benchmark claims, provider behavior, product-progress state, public sharing state, or launch-scope decision.

Shape

flowchart LR Bundle["JSON bundle authority"] --> Markdown["Reader projection"] Protocol["projection_protocol.json"] --> ProtocolGate["source refs and result record density"] Manifest["source_module_manifest.json"] --> DigestGate["material class and digest gate"] DigestGate --> Bodies["copied public source provenance bodies"] DigestGate --> RealTrace["sanitised real command-run trace passing pytest, sha256 digests, declared omissions"] Cases["3 public case ids"] --> ReplayGate["case roster and required replay refs"] Policy["locked evaluator policy"] --> EvaluatorGate["locked ids and config hashes"] Replays["3 replay observations"] --> ReplayGate EvaluatorGate --> ReplayGate ProtocolGate --> ReplayGate ReplayGate --> EvidenceGate["per-ref evidence artifacts file-access, contamination, trusted reference, output replay"] EvidenceGate --> Recompute["recompute integrity_pass or quarantine"] RealTrace --> Recompute Recompute --> Trace["public trace verdict recomputation"] Trace --> Verdicts["2 integrity_pass and 1 quarantine"] Negatives["11 anti-gaming fixtures"] --> Quarantine["quarantine or blocking finding"] Bodies --> PrivateScan["metadata-only non-public-state scan"] RealTrace --> PrivateScan Verdicts --> Result record["metadata-only integrity result record"] Quarantine --> Result record PrivateScan --> Result record Result record --> Ceiling["anti-score scope limit"]

The page shape is a bounded replay spine, not a benchmark leaderboard. A reader starts at the JSON bundle, follows the source-open manifest into three copied public source provenance bodies, then checks the public case roster, locked evaluator policy, replay observations, recomputed trace verdicts, and metadata-only result records. The output is an integrity-boundary verdict: two public case replays pass the boundary, one public case replay is quarantined, and no score or hidden-gold authority is created.

Reader Evidence Routing

• Bundle route: read core/paper_module_capsules.json::paper_modules[3], then the generated JSON instance, before treating this Markdown as explanatory projection.
• Bundle route: read examples/agent_benchmark_integrity_anti_gaming_replay/exported_benchmark_integrity_bundle/source_module_manifest.json for module_count=3, body_in_receipt=false, copied body refs, digest refs, and the explicit secret-exclusion boundary.
• Case route: read benchmark_cases.json for repo_issue_public_001, repo_issue_public_002, and repo_issue_public_003; the rows expose ids, hashes, splits, and held-out guard ids, not issue bodies or oracle patches.
• Replay route: read replay_observations.json for the locked evaluator ids, config hashes, file-access refs, contamination refs, trusted-reference refs, output-replay refs, and the two integrity_pass plus one quarantine verdict pattern.
• Runtime route: run tests/test_agent_benchmark_integrity_anti_gaming_replay.py when the reader needs recomputation evidence. The focused tests assert source-module digest verification, public trace verdict recomputation, required negative cases, and metadata-only result record boundaries.

Public Mechanics

• A replay cannot pass unless the evaluator id and config hash are locked.
• A replay row cannot pass unless its case id appears in the declared benchmark_cases.json roster.
• File-access logs, contamination checks, trusted references, and output replay refs are required before any benchmark-style language can be considered.
• Train/test leakage, hidden-gold access, oracle patch bodies, model-output data, final-answer-only grading, pass-k cherry-picking, misleading tests, private issue bodies, unregistered case replays, and score overclaims are quarantine cases.
• integrity_pass is evidence that a metadata-only regression replay respected the boundary, not evidence of a SWE-bench score, live agent capability, or product-spine system progress.
• Result records expose ids, refs, verdicts, counts, negative cases, and scope limits only.
• Source body imports expose source pattern provenance artifacts in the bundle, with result records limited to refs, digests, classes, and validation status.

Prior Art Grounding

This component is grounded in the long-running observation that optimized metrics can become targets and lose evidential force, plus the AI-safety literature on reward hacking and specification gaming. Concrete Problems in AI Safety frames reward hacking as a practical accident-risk problem, DeepMind's specification-gaming survey collects concrete examples of agents satisfying a proxy in the wrong way, and benchmark-contamination work such as Benchmarking Benchmark Leakage in Large Language Models motivates explicit leakage and benchmark-use documentation.

Microcosm borrows the anti-gaming accounting pattern: evaluator ids, config hashes, case rosters, file-access logs, contamination checks, trusted-reference refs, and replay refs must be present before benchmark-style language is allowed. It does not report or imply a model score.

Validation Result records

The focused proof consumer is tests/test_agent_benchmark_integrity_anti_gaming_replay.py. A passing result record has to show that the fixture and exported-bundle validators recompute benchmark-integrity replay from public case ids, locked evaluator ids, config hashes, file-access refs, contamination-check refs, trusted-reference refs, output-replay refs, source-module manifest digests, and negative-case rows rather than trusting declared benchmark language.

PYTHONDONTWRITEBYTECODE=1 ./repo-pytest \
  tests/test_agent_benchmark_integrity_anti_gaming_replay.py \
  -p no:cacheprovider
./repo-python scripts/build_doctrine_projection.py \
  --check-paper-module-corpus

For the focused test, the result record boundary is the asserted shape: three public case ids, three replay rows, two recomputed integrity_pass rows, one quarantine row, three public trace spans, locked-evaluator and config-hash coverage, three copied source-module imports, nine source-artifact evidence refs, three verified source-artifact evidence refs, body_in_receipt=false, and negative cases for verdict mismatch, invalid declared verdict, evaluator config hash swaps, missing replay/source evidence, digest mismatches, manifest boundary violations, hidden-gold/oracle/provider/score overclaims, and unsafe command-card body reuse. For the corpus check, the result record only proves bundle/instance parity; it does not create benchmark claims, product-progress, provider, public sharing, or launch-scope decision.

Validation Result record Path

Run the first-wave fixture validator from the repo root and write its result record outside the repo working tree:

Then run the exported bundle validator:

cd microcosm-substrate && PYTHONPATH=src ../repo-python -m microcosm_core.organs.agent_benchmark_integrity_anti_gaming_replay run-benchmark-integrity-bundle --input examples/agent_benchmark_integrity_anti_gaming_replay/exported_benchmark_integrity_bundle --out /tmp/agent_benchmark_integrity_bundle_receipt --card > /tmp/agent_benchmark_integrity_bundle_card.json

The focused regression test and corpus projection checks are:

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

Full module

Abstract

research_replication_rubric_artifact_replay is a public Microcosm component that turns "an agent replicated a paper" into a replayable evidence contract. It does not rerun a real paper, use external model services, certify benchmark performance, or grant publishing-scope decision. It checks whether a public replay bundle exposes the objects a replication claim must cite before its authority can rise: contribution decomposition refs, rubric-tree refs, allowed input refs, scratch-scaffold refs, experiment-DAG refs, metric-script refs, declared artifact hashes, grader reports, runtime budgets, ablation diffs, failure taxonomies, cold-rerun refs, public execution-trace spans, and source-module digests.

The technical result is an R3 local artifact replay: one public metric script is executed over one allowed public input table, the produced output is compared with a declared output artifact, and the declared hash file is checked against that artifact. A successful run says the replay packet is structurally accountable, digest-bound, redaction-aware, and negative-case tested. It does not say that a real paper was independently replicated.

Purpose

The single question this component answers is narrow: before an agent is allowed to say it replicated a paper, can the claim be forced into a bundle that a cold runtime can check without trusting any prose? The interesting move is that the component refuses to treat "replicated" as one fact. It pulls the claim apart into the objects a real replication would have left behind, a contribution decomposition, a grading rubric tree, the allowed public inputs, an experiment DAG, metric scripts, declared artifact hashes, a grader report, a runtime budget, an ablation diff, a failure taxonomy, and a cold-rerun result record, and it asks for each one by name.

What keeps this from being a checklist linter is the small executable core. The exported bundle does not just assert that an artifact hash exists. The runtime reads one public metric script, runs it over one allowed public input table, produces an output, and then checks that output against both the declared output artifact and the declared hash file. A replay row can name all the right refs and still fail here if the numbers do not reproduce. The negative-case fixtures attack exactly the gap a plausible fake would exploit: report-only success, benchmark-performance language, final-answer-only grading, undeclared hashes, and reuse of the original author's code.

The deliberately modest part is the subject matter. The two paper bundles are public synthetic examples, and the metric is a single sum over a small table. The component's value is the boundary, not the science. It does not run a real paper, call a provider, search compute without bound, or grant any launch or publishing-scope decision. It only makes a replication claim accountable enough that an independent reader can see where the evidence stops.

Telos

Research-agent demos often collapse four objects into one sentence: the paper, the runnable artifact, the grading rubric, and the evidence that an independent rerun happened. This component keeps those objects separate. A replay is admissible only when it names each evidence object and when the local runtime can check the public artifact replay without touching private paper bodies, non-public data bodies, hidden rubrics, model-output data, original-author code bodies, or launch/publishing-scope decision.

The central bet is modest and technical: before any replication claim is made, the system can force the claim into a falsifiable bundle with declared hashes, bounded metric execution, metadata-only result records, and explicit scope boundaries.

Mechanism

The mechanism row is mechanism.research_replication_rubric_artifact_replay.validates_public_research_replication_replay. It runs in src/microcosm_core/organs/research_replication_rubric_artifact_replay.py and is backed by the functions run, run_replication_bundle, validate_source_module_imports, validate_projection_protocol, validate_replication_policy, validate_research_replays, _build_result, _freshness_basis, and the constants EXPECTED_NEGATIVE_CASES, AUTHORITY_CEILING, SOURCE_MODULE_MANIFEST_REF, BUNDLE_RESULT_NAME, and CARD_SCHEMA_VERSION.

The runtime has two modes:

• Fixture mode reads fixtures/first_wave/research_replication_rubric_artifact_replay/input, includes positive replay rows plus eight negative-case fixtures, and writes first-wave result, board, validation, and sign-off result records.
• Exported-bundle mode reads examples/research_replication_rubric_artifact_replay/exported_research_replication_bundle, validates the public runtime example, checks the source-module manifest, and writes receipts/runtime_shell/demo_project/organs/research_replication_rubric_artifact_replay/exported_research_replication_bundle_validation_result.json.

The proof object is the tuple:

1. replication_policy.json, which states required replay fields, rubric axes, and forbidden claims.
2. research_replays.json, which supplies two synthetic paper bundles that cite public inputs, metrics, artifact hashes, grader reports, budgets, failures, and cold-rerun result records.
3. execution_artifacts/execution_artifact_manifest.json, which authorizes the replayable artifact relation.
4. source_module_manifest.json, which names copied source bodies and digest obligations.
5. Runtime result records, which expose refs, counts, digests, trace spans, and scope boundaries without embedding private bodies.

Metric-Script and Artifact Evidence

The exported bundle includes a small but real artifact-replay loop:

run_replication_bundle reads execution_artifacts/execution_artifact_manifest.json, executes the public_sum_metric over the allowed public input, compares the produced payload with execution_artifacts/artifacts/result_table.json, and verifies the declared hash in execution_artifacts/artifacts/result_table.sha256.json. The focused tests mutate each side of that relation, so the pass is not just a field-presence check.

Pipeline

flowchart TD bundle["JSON bundle authority paper_module.research_replication_rubric_artifact_replay"] policy["Replication policy required fields + rubric axes + forbidden claims"] replay["Research replay rows 2 synthetic paper bundles"] artifacts["Execution artifacts allowed input + metric spec + declared hash"] metric["Local metric replay public_sum_metric over allowed input"] source_manifest["Source-module manifest 3 source pattern slices + 1 exact-copy component body"] trace["Public execution trace 2 metadata-only spans"] negatives["Negative fixtures 8 overclaim cases"] result records["metadata-only result records counts, refs, digests, scope boundaries"] ceiling["Scope limit no replication-success or publishing-scope decision"] bundle --> policy policy --> replay replay --> artifacts artifacts --> metric source_manifest --> result records metric --> result records trace --> result records negatives --> result records result records --> ceiling

Evidence Contract

The policy file requires fourteen replay fields: paper_id, contribution_decomposition_ref, rubric_tree_ref, allowed_public_input_refs, scratch_repo_scaffold_ref, experiment_dag_ref, metric_script_refs, artifact_hash_refs, declared_artifact_hash_refs, grader_report_ref, cost_runtime_budget_ref, ablation_diff_ref, failure_taxonomy_ref, and cold_rerun_receipt_ref.

The policy also requires eight rubric axes: contribution decomposition, artifact replay, experiment DAG, metric script, grader alignment, budget boundary, failure taxonomy, and cold rerun. A replay row can therefore pass only as a structured evidence packet, not as a final answer or narrative report.

The exported runtime result record currently records the following evidence floor: two synthetic paper bundles, two replay rows, two artifact replay rows, two cold-rerun refs, two public execution-trace spans, four copied source modules, no findings, no error codes, source-module status pass, and input_mode: exported_research_replication_bundle. The fixture result record records all eight negative cases as observed.

Failure Modes and Guardrails

The expected negative cases are:

• original-author code reuse
• hidden-rubric leakage
• report-only success
• benchmark-performance overclaim
• private paper or data body leakage
• unbounded compute search
• final-answer-only grading
• undeclared artifact hash refs

The tests also cover source-module digest mismatch, local bundle body tamper, rehashing a swapped source module, wrong execution-artifact hashes, wrong artifact refs with matching hashes, report-only exported replays, metric perturbation, replay metric-script ref tamper, input perturbation, output body tamper, baked output swaps, and self-consistent input/output/hash rewrites. These cases make the component stronger than a field-presence linter: it rejects common ways to produce plausible but unaccountable replication prose.

Test Matrix

The focused regression file tests/test_research_replication_rubric_artifact_replay.py carries the source proof for this module.

Realness Rungs

This module's realness is intentionally runged:

1. Synthetic replay subjects. The two paper bundles are public synthetic examples, one ML-method replay and one computational-science replay.
2. Real schema pressure. The required fields, rubric axes, declared hash roster, source-module manifest, and non-public-state exclusions are enforced by runtime code and focused tests.
3. Local artifact replay. The exported bundle executes a local metric over allowed public input and compares produced output against declared artifact hashes.
4. Source-open provenance. Three public source pattern bodies and one exact Python internal control body are copied into the bundle and digest-checked.
5. metadata-only public result records. Result records carry counts, refs, digests, verdicts, trace spans, and scope boundaries while excluding private/live/provider material.

The rung contract matters: the component is more than generic documentation polish, but it is still not paper-replication authority.

Relation to Concepts, Principles, and Axioms

The JSON bundle binds the module to concept.research_and_science_replay_evidence_bundle. That concept is instantiated by the mechanism above and abides by AX-1, AX-6, AX-8, and AX-12 at the concept layer. The bundle's direct axiom refs are AX-1, AX-2, AX-5, and AX-7.

The bundle's principle refs are P-1, P-2, P-3, P-6, P-8, and P-15. For this component, the important principle pressure is:

• Evidence must be structured and replayable before authority rises.
• Result records and scope boundaries are part of the artifact, not commentary after it.
• Projections stay below source authority; a readable paper module does not outrank the JSON bundle, mechanism row, runtime code, source-module manifest, or result records.
• Typed refusal is part of the mechanism: benchmark, provider, public sharing, private-body, original-code, and unbounded-compute claims remain false unless another authority surface actually grants them.

The module depends on paper_module.agent_benchmark_integrity_anti_gaming_replay. Benchmark performance overclaim controls stay routed through that sibling instead of being reinvented here.

Reader Evidence Routing

Open evidence in this order:

1. core/paper_module_capsules.json#paper_module.research_replication_rubric_artifact_replay for the source-authority bundle, scope limit, doctrine refs, generated projection statuses, and code loci.
2. core/mechanism_sources.json#mechanism.research_replication_rubric_artifact_replay.validates_public_research_replication_replay for the validator command, exported-bundle validator command, focused regression, guardrails, input refs, result record refs, and upstream mechanisms.
3. standards/std_microcosm_research_replication_rubric_artifact_replay.json for the first-wave standard, public/private boundary, source-body floor, and hard launch/public sharing/provider/source-file changes flags.
4. examples/research_replication_rubric_artifact_replay/exported_research_replication_bundle/source_module_manifest.json for source-open body-floor counts and digest obligations.
5. receipts/runtime_shell/demo_project/organs/research_replication_rubric_artifact_replay/exported_research_replication_bundle_validation_result.json for the current exported-bundle validation result.
6. tests/test_research_replication_rubric_artifact_replay.py for negative cases, digest tamper tests, metric replay tests, public-relative result record tests, command-card economy, and source-body exclusion.

Prior Art Grounding

This replay scores a research artifact against a replication rubric. It follows artifact-evaluation practice from systems and machine-learning venues (ACM Artifact Review and Badging), which separates 'available' from 'functional' from 'reproduced'. Microcosm borrows the rubric-over-artifact shape; the result is fixture-bound replay evidence, not a reproducibility guarantee or a peer-review verdict.

Validation Result record Path

Focused runtime validation:

./repo-pytest tests/test_research_replication_rubric_artifact_replay.py -q --basetemp=/tmp/microcosm_research_replication_rubric_artifact_replay_pytest

Paper-module corpus validation:

./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

The runtime commands behind the result records are:

Full module

This module documents the source-available claim contract for agentic_vulnerability_discovery_patch_proof_replay. It turns an agentic vulnerability-discovery claim into a public trace-backed local replay: synthetic metadata-only targets, issue hypotheses, trace evidence, abstract exploitability refs, patch diffs, regression tests, verifier result records, sandbox policy verdicts, false-positive triage, cold replay, negative cases, and scope limits.

Purpose

An agent that says it found and fixed a security bug is making a claim that is easy to assert and hard to check. The phrase "found and fixed" can stand for a real, tested repair, or for a plausible-looking patch that was never run, a false positive promoted to a finding, or a benchmark number with no evidence behind it. This component exists to refuse that ambiguity. It answers one question: before any "found and fixed" language is allowed, does a complete evidence chain line up, from a synthetic target through a hypothesis, a trace, an abstract exploitability ref, a patch diff, a regression test, and a verifier result record?

The part worth noticing is that two of those checks are not field checks. They recompute the thing the fixture is claiming. Each executable regression witness names one of three small, public mini-targets, a webhook redirect allowlist, a notebook log redactor, and a scheduler path normaliser. The validator runs that function twice, once in its unpatched form and once patched, and compares the results it computes against the expected_pre_patch and expected_post_patch values the fixture declared. A witness whose declared output does not match the computed output is rejected. In the same spirit, each verifier result record has its pass or false_positive verdict recomputed from the joined proof, patch, test, and witness evidence; the row's own label and result record filename are not taken on trust. The failure mode this guards against is a fixture that asserts a green result without the work behind it ever having run.

This is a synthetic, metadata-only replay, not live security work. The synthetic overclaim fixtures, live targets, real CVE exploitation, weaponised payloads, exploit steps, patch-without-test claims, benchmark claims, are regression boundaries the runtime must reject, not capabilities it offers. The useful claim is narrow and is stated plainly below: Microcosm can hold an agentic security story to a checked evidence chain before it admits patch-proof language.

Shape

flowchart TD bundle["JSON bundle authority"] markdown["Markdown reader projection"] mechanism["mechanism source row"] component["patch-proof replay runtime"] fixture["first-wave fixture"] bundle["exported patch-proof bundle"] targets["synthetic target refs"] hypotheses["issue hypotheses"] traces["trace evidence refs"] proofs["abstract exploitability refs"] patches["patch diff refs"] regressions["regression test refs"] executable["executable regression witnesses"] verifiers["verifier result records"] sandbox["sandbox verdicts"] negative["negative-case fixtures"] secret_scan["secret-exclusion scan"] replay["cold replay rows"] public_trace["public trace spans"] source_modules["source-module body floor"] result records["metadata-only result records"] consumer["focused proof-consumer tests"] ceiling["scope limit"] bundle --> markdown bundle --> mechanism mechanism --> component component --> fixture component --> bundle fixture --> targets bundle --> targets targets --> hypotheses hypotheses --> traces traces --> proofs proofs --> patches patches --> regressions regressions --> executable executable --> verifiers verifiers --> sandbox negative --> result records secret_scan --> result records sandbox --> replay replay --> public_trace source_modules --> secret_scan source_modules --> public_trace public_trace --> result records result records --> consumer result records --> ceiling

The module shape is a metadata-only synthetic patch-proof replay, not a live vulnerability discovery or fix-correctness claim. The runtime forces target refs, hypotheses, trace refs, abstract exploitability refs, patch diff refs, regression test refs, verifier result records, sandbox verdicts, false-positive triage, cold replay, public trace spans, source-module digests, negative cases, and scope boundaries to line up before bounded patch-proof language is admitted.

Technical Mechanism

The mechanism is an evidence join, not a scanner. The JSON bundle names the component and mechanism row, and the component resolves every claim through _build_result in src/microcosm_core/organs/agentic_vulnerability_discovery_patch_proof_replay.py. That function loads the projection protocol and vulnerability policy, then validates targets, issue hypotheses, trace evidence, exploitability refs, patch diffs, regression tests, executable regression witnesses, verifier result records, sandbox verdicts, false-positive triage, cold replay rows, optional negative-case fixtures, the public trace builder, and the source-module manifest. A result can pass only when those validators agree, the secret-exclusion scan has zero blocking hits, the public trace status is pass, all positive validators are pass, and the exported bundle's manifest digests match copied source bodies.

Two of those validators do work the others do not. The executable regression witness check runs each declared mini-target function in both its unpatched and patched form and compares the computed pre/post outputs against the values the fixture declared, so a witness cannot pass on a label alone. The verifier result record check recomputes each pass or false_positive verdict from the joined hypothesis, proof, patch, test, and witness evidence, and also requires the result record-ref filename to match that recomputed verdict, so a row cannot claim a result its own evidence does not support. The other validators are stricter joins: every hypothesis must resolve to a synthetic target, every patch-required hypothesis must carry both an abstract exploitability ref and a metadata-only patch diff, and every patch must pair with a regression test that fails before the patch and passes after it. A patch without a paired test, or a false positive promoted to a finding, blocks the result.

The runtime deliberately keeps two evidence modes separate. The first-wave fixture includes the negative-case authority, so it must observe the expected overclaim failures such as live target material, real CVE exploitation, weaponized payload export, exploit steps, patch-without-test claims, and benchmark claims claims. The exported bundle is the public runtime example, so its expected_negative_cases can be empty while it still proves the body floor, public trace, digest checks, regression witnesses, and scope limit. Both modes write metadata-only result records; copied bodies stay behind the source_module_manifest.json refs and hashes.

Named Proof Consumers

• tests/test_agentic_vulnerability_discovery_patch_proof_replay.py::test_agentic_vulnerability_patch_proof_replay_observes_negative_cases consumes the first-wave fixture and checks the expected counts, negative-case coverage, public trace status, body-import boundary, secret-exclusion scan, and scope limit booleans.
• tests/test_agentic_vulnerability_discovery_patch_proof_replay.py::test_agentic_vulnerability_exported_bundle_validates_runtime_shape consumes the exported bundle and checks runtime mode, target/hypothesis/patch counts, executable regression witnesses, source-module manifest status, copied-body count, metadata-only import summary, secret-exclusion status, and public trace span count.
• The rejection tests in the same file are the scope limit in executable form: they mutate false-positive promotion, remove regression tests, tamper executable witnesses, omit exploitability proof, cross-wire verifier result records, and alter source-module digests, then require blocked results and specific error codes instead of allowing patch-proof language.

What It Admits

The validator admits only metadata-only patch-proof evidence where trace refs, abstract proof refs, patch diff refs, regression tests, verifier result records, sandbox verdicts, and cold replay line up.

The result record fields to inspect first are target_count, issue_hypothesis_count, patch_diff_count, regression_test_count, verifier_receipt_count, observed_negative_cases, secret_exclusion_scan, public_agent_execution_trace, body_import_verification, and authority_ceiling.

Prior Art Grounding

This component is grounded in the recent line of agentic software-engineering and security-evaluation work that treats code repair as an executable, test-backed claim rather than a prose claim. SWE-bench popularized repository issue resolution as an LLM task with real codebases and test-based patch evaluation, while SWE-agent made the agent-computer interface itself part of the repair system. Security benchmarks such as CyberSecEval 2 and SecCodePLT motivate separating secure-code or vulnerability capability claims from uninspected generated patches.

Microcosm borrows the accountability pattern: issue hypotheses, trace evidence, patch diffs, regression tests, verifier result records, and negative cases must line up before patch-proof language is allowed. It does not import live targets, CVE exploitation authority, weaponized payloads, or benchmark performance claims.

Source-Backed Doctrine Binding

• Component: src/microcosm_core/organs/agentic_vulnerability_discovery_patch_proof_replay.py
• Bundle: core/paper_module_capsules.json#paper_module.agentic_vulnerability_discovery_patch_proof_replay
• Mechanism: core/mechanism_sources.json#mechanism.agentic_vulnerability_discovery_patch_proof_replay.validates_public_agentic_vulnerability_patch_proof_replay
• Standard: standards/std_microcosm_agentic_vulnerability_discovery_patch_proof_replay.json
• Evidence class: core/organ_evidence_classes.json::agentic_vulnerability_discovery_patch_proof_replay records algorithmic_projection at rank 3.
• Source-module manifest: examples/agentic_vulnerability_discovery_patch_proof_replay/exported_patch_proof_bundle/source_module_manifest.json declares nine copied source/control/standard/tool bodies, including strict_json_source_body_import.
• Runtime result record: receipts/runtime_shell/demo_project/organs/agentic_vulnerability_discovery_patch_proof_replay/exported_patch_proof_bundle_validation_result.json
• Sign-off result records: receipts/first_wave/agentic_vulnerability_discovery_patch_proof_replay/* and result records/sign-off/first_wave/agentic_vulnerability_discovery_patch_proof_replay_fixture_acceptance.json

Reader Evidence Routing

• Bundle route: core/paper_module_capsules.json::paper_modules[5:paper_module.agentic_vulnerability_discovery_patch_proof_replay] is the JSON authority row. A diagram view is generated for this module; the Atlas card view is a staged exercise pending the component-atlas lane.
• Mechanism route: core/mechanism_sources.json::mechanism.agentic_vulnerability_discovery_patch_proof_replay.validates_public_agentic_vulnerability_patch_proof_replay binds the validator command, exported-bundle validator command, focused regression, guardrails, input refs, result record refs, and runtime code locus.
• Runtime route: src/microcosm_core/organs/agentic_vulnerability_discovery_patch_proof_replay.py owns run, run_patch_proof_bundle, _source_module_manifest_result, _source_open_body_import_summary, _build_result, _freshness_basis, EXPECTED_NEGATIVE_CASES, AUTHORITY_CEILING, SOURCE_MODULE_MANIFEST_NAME, BUNDLE_RESULT_NAME, and CARD_SCHEMA_VERSION.
• Exported-bundle route: examples/agentic_vulnerability_discovery_patch_proof_replay/exported_patch_proof_bundle is the public runtime bundle for the synthetic patch-proof replay. Open source_module_manifest.json before trusting copied-body counts, then inspect the runtime validation result record.
• Focused-test route: tests/test_agentic_vulnerability_discovery_patch_proof_replay.py verifies negative cases, public-relative metadata-only result records, exported-bundle runtime shape, exact copied source modules, digest mismatch rejection, command-card result record reuse, and public trace construction.

Cold-Agent Use

Open the source-module manifest first, then the runtime result record, then the component source. The useful claim is not that a real vulnerability was discovered or fixed.

The useful claim is that Microcosm can force an agentic security story to expose synthetic target refs, issue hypotheses, trace evidence, abstract exploitability refs, patch diffs, regression tests, verifier result records, sandbox verdicts, false-positive triage, cold replay, public trace spans, secret-exclusion scan, negative-case result records, and scope limits before patch-proof language is allowed.

Re-entry condition: after the sibling organ_atlas.json lane releases, bind this paper-module bundle, mechanism ref, and code locus into the atlas row and rerun python -m microcosm_core.doctrine_lattice --check.

Negative Cases

The contract rejects live_target_material, real_cve_exploitation, weaponized_payload_export, account_secret_material, network_exfiltration, exploit_instruction_steps, patch_without_tests, and benchmark_score_claim. These are falsification fixtures, not product evidence.

Validation Result record Path

Run the first-wave fixture validator from the repo root and write its result record outside the repo working tree:

Then run the exported bundle validator:

cd microcosm-substrate && PYTHONPATH=src ../repo-python -m microcosm_core.organs.agentic_vulnerability_discovery_patch_proof_replay \
  run-patch-proof-bundle \
  --input examples/agentic_vulnerability_discovery_patch_proof_replay/exported_patch_proof_bundle \
  --out /tmp/agentic_vulnerability_patch_proof_bundle_receipt \
  --card > /tmp/agentic_vulnerability_patch_proof_bundle_card.json

The focused regression test and corpus projection checks are:

PYTHONPATH=src ./repo-pytest \
  tests/test_agentic_vulnerability_discovery_patch_proof_replay.py
cd microcosm-substrate && PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py \
  --check-paper-module-corpus

Full module

Purpose

"Closed-loop materials lab" is one of the easier phrases to overclaim. A fixture can look like an autonomous discovery loop while carrying nothing that should be spoken aloud: wetlab steps, reagent quantities, a controlled or bioactive target, robot commands, or a flat assertion that some material was discovered. This component exists to sit in front of that language and answer one question: is a closed-loop-lab-shaped fixture safe and grounded enough to be talked about at all, in a simulator-only frame, before any lab claim is allowed?

Its real name inside the runtime is the materials_chemistry_artifact_safety_refusal_validator. The public-promise name "closed-loop replay" was deliberately reframed because nothing here executes a wetlab loop or commands a robot. The unusual part is that the component does not trust the fixture's own conclusion. A normal replay would read a declared "selected candidate" label and report it. This validator instead recomputes the winner from public numbers, weighting an assay proxy, an active-learning score, and a safety gate, then treats a mismatch between that recomputed pick and the declared label as a failure rather than a footnote. A stale or flattering label cannot pass.

The second discipline is refusal as a first-class result. Eight categories of dangerous or overclaiming content each have a named forbidden code, and a fixture that smuggles one in is expected to be refused, not quietly accepted. The verdict is computed from public simulator rows, safety fields, source-module manifests, replay-graph status, negative-case coverage, and a sentinel scan, and it stays inside a simulator-only ceiling. It is a safety and refusal check, not a laboratory.

Abstract

materials_chemistry_closed_loop_lab_safety_replay is a public, simulator-only replay validator for materials-lab language. It does not claim a material discovery, a wetlab protocol, a robot loop, or a benchmark. It checks whether a closed-loop-lab shaped public fixture has enough evidence to be talked about at all: candidate material refs, safety-screen refs, simulator-only assay rows, active-learning decisions, a Lab/Evolve replay graph, source-module manifest digests, negative-case refusals, metadata-only result records, and an explicit scope limit.

The technical claim is a numeric verdict proof boundary. A passing run must recompute the selected candidate from score-backed fixture rows rather than trusting a declared label. The baseline fixture contains four candidates and selects mat_polymer_membrane_001 with score 0.917; perturbation tests prove that stale labels, missing score rows, out-of-range scores, and safety-gate failures block the verdict.

Mechanism

The runtime locus is src/microcosm_core/organs/materials_chemistry_closed_loop_lab_safety_replay.py. The relevant entrypoints are run for first-wave fixture validation and run_lab_bundle for exported-bundle validation. The validator loads a replay policy, candidate rows, experiment DAG rows, simulator assays, active-learning decisions, optional source-module manifests, and eight forbidden negative-case fixtures.

The sign-off rule is deliberately small:

1. Positive rows must link candidates, experiments, assays, safety screens, active-learning decisions, failure taxonomy refs, and cold replay refs.
2. Negative cases must be observed and refused.
3. Numeric replay must recompute the selected candidate from public numbers.
4. Source-module imports must verify copied bodies without putting bodies into result records.
5. The safety verdict must remain inside the simulator-only scope limit.

flowchart TD policy["replay_policy.json numeric policy + expected label"] candidates["candidate_materials.json 4 candidate refs + safety gates"] assays["simulator_assays.json 4 public assay proxy values"] decisions["active_learning_decisions.json 4 active-learning scores"] numeric["numeric replay weighted recompute of the winner"] labelcheck{"recomputed pick == declared label? safety gate >= 0.70?"} negatives["negative-case fixtures 8 forbidden lab classes"] refuse{"any forbidden MATERIALS_*_FORBIDDEN observed?"} manifest["source_module_manifest.json 4 copied public body modules"] replay["Lab/Evolve replay graph replay cases"] verdict["safety verdict"] accepted["public_safe_simulator_replay_accepted"] blocked["blocked_public_safety_boundary"] result record["metadata-only result records counts, digests, findings"] ceiling["scope limit no wetlab / no discovery / no launch"] policy --> numeric candidates --> numeric assays --> numeric decisions --> numeric numeric --> labelcheck labelcheck -->|stale label or gate fail| blocked labelcheck -->|match| verdict negatives --> refuse refuse -->|yes| blocked refuse -->|no| verdict manifest --> replay replay --> verdict verdict --> accepted accepted --> result record blocked --> result record result record --> ceiling

Numeric Assay And Verdict Evidence

The replay policy declares:

• selection rule: max_weighted_public_assay_active_learning_and_safety_gate_score
• minimum safety gate: 0.70
• expected selected candidate: mat_polymer_membrane_001
• weighted score: 0.45 * public_assay_proxy_value + 0.35 * public_active_learning_score + 0.20 * public_safety_gate_score

The source fixture binds four score-backed rows:

The focused regression test_materials_chemistry_numeric_replay_recomputes_verdict_from_fixture_numbers proves the pass case: status pass, verified_numeric_row_count == 4, selected candidate mat_polymer_membrane_001, selected decision decision_membrane_001, selected next action simulate_assay, score 0.917, realness rung R3, and verdict basis recomputed_from_public_assay_active_learning_and_safety_gate_fixture_numbers.

The verifier does not use expected labels for selection. Expected labels are checked only after the selected row is recomputed from candidate, assay, and decision content.

Test Matrix

These cases are source/test-backed by tests/test_materials_chemistry_closed_loop_lab_safety_replay.py. Fresh local first-wave result record output is the authority for current numeric replay; older archived first-wave result records and the checked-in exported bundle predate the numeric replay rows and should not be read as the numeric proof. The exported bundle still needs refreshed numeric rows before it is a full exported-bundle pass.

Evidence Routes

• JSON bundle: core/paper_module_capsules.json::paper_module.materials_chemistry_closed_loop_lab_safety_replay
• Generated JSON instance: paper_modules/materials_chemistry_closed_loop_lab_safety_replay.json
• Mechanism source: core/mechanism_sources.json::mechanism.materials_chemistry_closed_loop_lab_safety_replay.validates_public_materials_lab_safety_replay
• Runtime: src/microcosm_core/organs/materials_chemistry_closed_loop_lab_safety_replay.py
• Domain standard: standards/std_microcosm_materials_chemistry_closed_loop_lab_safety_replay.json
• Paper-module standard: standards/std_microcosm_paper_module.json
• Fixture input: fixtures/first_wave/materials_chemistry_closed_loop_lab_safety_replay/input
• Exported bundle: examples/materials_chemistry_closed_loop_lab_safety_replay/exported_materials_lab_safety_bundle
• Focused tests: tests/test_materials_chemistry_closed_loop_lab_safety_replay.py

Prior Art Grounding

This replay exercises a closed-loop materials and chemistry lab controller with a safety gate over synthetic experiments. It is grounded in the self-driving laboratory literature, where a propose-run-measure loop is paired with safety interlocks that can refuse an unsafe experiment. Microcosm borrows the loop-plus-safety-gate shape on a simulator; the result is metadata-only simulator evidence, not a real laboratory controller, chemical-safety authority, or launch.

Validation Result record Path

Run the current runtime proof from the Microcosm root:

Inspect the exported source-body bundle. Until the exported fixture is refreshed with score-backed numeric rows, this command may return a blocked numeric verdict while still proving the manifest/body-floor boundary:

cd microcosm-substrate
PYTHONPATH=src ../repo-python -m microcosm_core.organs.materials_chemistry_closed_loop_lab_safety_replay run-lab-bundle --input examples/materials_chemistry_closed_loop_lab_safety_replay/exported_materials_lab_safety_bundle --out /tmp/microcosm_materials_chemistry_lab_safety_bundle

Run the focused regression suite:

cd microcosm-substrate
PYTHONPATH=src ../repo-pytest tests/test_materials_chemistry_closed_loop_lab_safety_replay.py -q

cd microcosm-substrate
PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

This lane intentionally does not run scripts/build_doctrine_projection.py --write; generated projections, atlas cards, and shared bundle surfaces belong to their owner lanes.

Full module

Abstract

certificate_kernel_execution_lab is a source-available public runtime refactor of the source certificate-kernel pattern. It runs a small Lean/Lake certificate kernel, generated certificate rows, analyzer metadata, CP2 typed-action reruns, and bounded Evolve policy reruns without importing private proof bodies. The exported bundle also carries copied source body modules from the real Erdos #257 certificate-kernel system: Lean kernel files, generated certificates, the strike runner, toolchain files, and Lean profile result records. The v2 fixture carries both a simple NatSumCertificate row family and a miniature BoundedOrderCertificate family so the public lab is no longer only a single-shape arithmetic result record.

Purpose

This component exists to stop a proof-adjacent claim from resting on prose. The single question it answers is narrow: did a small Lean kernel actually compile and accept the declared certificate rows, here and now, with the command, the return code, and the source hashes on record? Everything else in the page is accounting that keeps the answer honest.

The reduction it relies on is the interesting part. A large class of proof-adjacent facts can be expressed as a finite certificate plus a decidable Boolean checker shaped like validate : Cert -> Bool. The agent is never asked to write a human proof. It is asked to supply the right certificate rows, and Lean decides. The fixture carries two checker families, NatSumCertificate over arithmetic and BoundedOrderCertificate over a bounded modular order, so the sign-off is not a single hard-coded shape. A row counts as accepted only when the runner shells out to lake env lean over a temporary copy of the public project and receives exit code 0.

What is unusual is the weight placed on rejection. Deliberately wrong rows, a missing certificate, a bad arithmetic certificate, a bad bounded-order certificate, must fail through the same real Lean route, in the residual class the fixture predicted. A bundle that can show only green sign-off is treated as a replay artifact, not as certificate-kernel evidence. The runner also keeps the proof channel separate from the language model channel: a transition that can see oracle structured source record or provider hypothesis text is rejected before execution, so a model's confidence can never be quietly counted as a proof. The result record records command identity, counts, and verdicts, and never the proof bodies themselves.

Shape

flowchart TD bundle["JSON bundle authority"] markdown["Markdown reader projection"] mechanism["mechanism source row"] component["certificate-kernel runtime"] fixture["first-wave Lean fixture"] bundle["exported certificate bundle"] manifest["certificate manifest"] lake["Lean/Lake subprocess"] analyzer["Lean analyzer metadata"] transitions["transition trace rows"] cp2["CP2 typed-action reruns"] evolve["bounded Evolve reruns"] source_modules["source-module body floor"] readout["public readout"] result records["metadata-only result records"] ceiling["scope limit"] bundle --> markdown bundle --> mechanism mechanism --> component component --> fixture component --> bundle fixture --> manifest bundle --> manifest manifest --> lake lake --> analyzer lake --> transitions transitions --> cp2 cp2 --> evolve source_modules --> analyzer analyzer --> readout evolve --> result records readout --> result records result records --> ceiling

The module shape is a bounded public certificate-kernel execution witness, not general theorem authority. This page points at the mechanism and runtime component; the runtime validates Lean/Lake command identity, source hashes, generated certificate rows, analyzer metadata, transition traces, CP2 typed-action reruns, bounded Evolve reruns, source-module manifest digests, negative cases, public readout, metadata-only result records, and an scope limit.

Mechanism

The mechanism is a finite-certificate execution reducer. The public entrypoints run and run_certificate_bundle both call _build_result, which loads the certificate lab packet, certificate manifest, Lean project, optional negative fixtures, and optional exported-bundle source manifest before any claim is recorded. The fixture path may run Lean/Lake in a temporary public workspace; the exported-bundle path validates the standalone runtime contract and copied body floor without rerunning private source machinery.

The reducer first establishes source and result record boundaries. _input_paths enumerates the public Lean files and JSON inputs, then scan_paths checks them against core/private_state_forbidden_classes.json. _source_module_manifest_result verifies the exported bundle's nine copied source bodies by material class, target presence, required anchors, and SHA-256 equality; _source_open_body_import_summary turns that manifest into the body floor that result records can cite without carrying proof bodies.

Execution evidence is split into three layers. _build_lake_project runs lake build MicrocosmCertificateLab for the fixture path, while _analyze_lean_project records public Lean imports, declarations, line counts, and hashes with body_in_receipt: false. _execute_transitions then sets certificate transition rows through Lean: accepted rows must return zero, missing or bad certificate rows must fail in the expected residual class, and CP2/Evolve rows must rerun within allowed action and artifact classes instead of mutating arbitrary source.

The negative cases are part of the proof consumer, not examples around it. EXPECTED_NEGATIVE_CASES requires rejection of provider/oracle-visible transition rows, CP2 proof-body leakage, Evolve source-file changes, and non-public source refs in the manifest. The focused regression test tests/test_certificate_kernel_execution_lab.py exercises those refusals, digest mismatch handling, cached command-card economy, public readout generation, and the counters that keep oracle/provider/proof-body/source-file changes at zero.

AUTHORITY_CEILING and RECEIPT_TRANSPARENCY_CONTRACT bind the mechanism back to the lattice relation. The module can claim bounded public fixture and bundle evidence over Lean/Lake command identity, certificate rows, analyzer metadata, transition outcomes, CP2/Evolve reruns, source manifest digests, and metadata-only result records. It cannot claim general theorem authority, provider proof authority, benchmark solve rate, private-body equivalence, source-file changes, launch, or whole-system correctness.

Public Surfaces

• Component runner: python -m microcosm_core.organs.certificate_kernel_execution_lab run --input fixtures/first_wave/certificate_kernel_execution_lab/input --out receipts/first_wave/certificate_kernel_execution_lab
• Exported bundle runner: python -m microcosm_core.organs.certificate_kernel_execution_lab run-certificate-bundle --input examples/certificate_kernel_execution_lab/exported_certificate_kernel_execution_lab_bundle --out receipts/runtime_shell/demo_project/organs/certificate_kernel_execution_lab
• CLI: microcosm certificate-kernel-execution-lab run --input fixtures/first_wave/certificate_kernel_execution_lab/input --out receipts/first_wave/certificate_kernel_execution_lab
• Standard: standards/std_microcosm_certificate_kernel_execution_lab.json
• Fixture manifest: core/fixture_manifests/certificate_kernel_execution_lab.fixture_manifest.json
• Source-module manifest: examples/certificate_kernel_execution_lab/exported_certificate_kernel_execution_lab_bundle/source_module_manifest.json

Prior Art Grounding

This component is grounded in proof-carrying and proof-assistant traditions. Necula's Proof-Carrying Code anchors the idea that an untrusted producer can supply a certificate checked by a small trusted verifier. The Lean theorem prover continues the small-kernel proof-assistant lineage, and LeanDojo shows why reproducible Lean environments, premise access, and programmatic proof-state interaction matter for theorem-proving agents.

Microcosm borrows the certificate-kernel discipline: certificate rows, Lean/Lake command identity, return codes, source hashes, transition traces, negative rows, and metadata-only result records must be visible before proof-adjacent language is allowed. It does not claim general theorem proof authority.

Research Bet

This component is the certificate-kernel bet in runnable form: a large class of proof-adjacent facts can be reduced to a finite certificate plus a decidable Boolean checker. The public lab keeps the agent task narrow. It does not ask the agent to synthesize a human proof; it asks for the right certificate rows, then lets Lean/Lake decide whether the checker accepts them.

The toy path uses a Lean certificate kernel shaped like validate : Cert -> Bool and accepts only when Lean can compile and run the declared check. The source-body import path carries the real Erdos #257 source floor: Lean kernel files, generated certificate shards, toolchain files, and profile result records from the Mathlib formalization family. The result record may say "accepted" only when the public runner shells out to Lean/Lake and receives exit code 0 for the declared bundle.

The negative floor is part of the proof, not decoration. Deliberately wrong certificate rows must be rejected by the real Lean route, including arithmetic and bounded-order failures. A bundle that cannot show genuine rejection cases is only a replay artifact, not certificate-kernel evidence.

Source-Backed Doctrine Binding

• Component: src/microcosm_core/organs/certificate_kernel_execution_lab.py
• Bundle: core/paper_module_capsules.json#paper_module.certificate_kernel_execution_lab
• Mechanism: core/mechanism_sources.json#mechanism.certificate_kernel_execution_lab.validates_public_certificate_kernel_execution
• Standard: standards/std_microcosm_certificate_kernel_execution_lab.json
• Evidence class: core/organ_evidence_classes.json::certificate_kernel_execution_lab records external_subprocess_witness at rank 4.
• Source-module manifest: examples/certificate_kernel_execution_lab/exported_certificate_kernel_execution_lab_bundle/source_module_manifest.json declares nine copied Lean/tool/profile body modules.
• Runtime result record: receipts/runtime_shell/demo_project/organs/certificate_kernel_execution_lab/exported_certificate_kernel_execution_lab_bundle_validation_result.json
• Sign-off result records: receipts/first_wave/certificate_kernel_execution_lab/* and result records/sign-off/first_wave/certificate_kernel_execution_lab_fixture_acceptance.json

Reader Evidence Routing

• Bundle route: core/paper_module_capsules.json::paper_modules[7:paper_module.certificate_kernel_execution_lab] is the JSON authority row. A diagram view is generated for this module; the Atlas card for this module is staged and will appear once the component-atlas lane completes its binding pass.
• Mechanism route: core/mechanism_sources.json::mechanism.certificate_kernel_execution_lab.validates_public_certificate_kernel_execution binds the validator command, exported-bundle validator command, focused regression, guardrails, input refs, result record refs, and runtime code locus.
• Runtime route: src/microcosm_core/organs/certificate_kernel_execution_lab.py owns run, run_certificate_bundle, _source_module_manifest_result, _source_open_body_import_summary, _build_result, _receipt_freshness, build_public_readout, EXPECTED_NEGATIVE_CASES, AUTHORITY_CEILING, SOURCE_MODULE_MANIFEST_NAME, BUNDLE_RESULT_NAME, and CARD_SCHEMA_VERSION.
• Exported-bundle route: examples/certificate_kernel_execution_lab/exported_certificate_kernel_execution_lab_bundle is the public runtime bundle. Open source_module_manifest.json before using copied-body counts, then inspect the runtime validation result record and public readout.
• Focused-test route: tests/test_certificate_kernel_execution_lab.py verifies Lean/Lake execution, analyzer output, transition batching, CP2/Evolve counters, public structured bundle shape, digest mismatch rejection, exact copied source modules, cached command-card economy, transparent metadata-only result records, and the cold-reader public readout.

Cold-Agent Use

Open the source-module manifest first, then the runtime result record, then the component source. The useful claim is not that Microcosm proved the Erdos #257 theorem, solved a benchmark, imported private proof bodies, or gained provider/oracle authority. The useful claim is that Microcosm can force a proof-adjacent story to expose Lean/Lake command identity, return codes, source hashes, declaration counts, certificate rows, transition traces, typed CP2 actions, bounded Evolve reruns, source-module body refs, negative-case result records, and authority counters before certificate-kernel language is allowed.

Re-entry condition: after the sibling organ_atlas.json lane releases, bind this paper-module bundle, mechanism ref, and code locus into the atlas row and rerun python -m microcosm_core.doctrine_lattice --check.

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.certificate_kernel_execution_lab run-certificate-bundle --input examples/certificate_kernel_execution_lab/exported_certificate_kernel_execution_lab_bundle --out /tmp/microcosm_certificate_kernel_execution_lab_bundle

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

Full module

Abstract

corpus_readiness_mathlib_absence_gate is the public formal-math corpus readiness boundary for Microcosm. It carries copied corpus/toolchain rows from the 2026-05-11 proof-state curriculum smoke run and forces Mathlib absence, absent-corpus blocking, consumer gate decisions, and source-module digest coupling to be visible before any downstream retrieval, tactic-routing, or proof-witness language is allowed.

Purpose

Formal-math agents fail in a specific way: they treat "there is a corpus" as if it meant "this corpus is usable for the proof route I am about to take". A roster lists miniF2F, PutnamBench, ProofNet, LeanDojo and Mathlib, the agent assumes the libraries are present, and the failure only surfaces later as a broken import or a tactic that needs a premise the host cannot resolve. This component answers one question before that happens: for each corpus, is it actually present on this host, and is the Mathlib import lane actually available, or not?

The unusual part is that the gate does not take the answer on trust. It runs a bounded Lean/Lake import probe in a temporary directory: one small file that imports Std and is expected to compile, and one that imports Mathlib and is expected to be rejected with the toolchain's own unknown module prefix 'Mathlib' error. A corpus is only marked usable for Mathlib-dependent work when the runtime evidence agrees the corpus exists, carries a Lake file, and the Mathlib lane probe passes. In the current system the Mathlib probe stays false, so every Mathlib-dependent consumer is blocked, and the one consumer that passes is the Lean3 translation smoke, which needs no Mathlib project at all.

This closes the most common way a readiness claim drifts. Stale alias fields such as mathlib_available, or a PASS lean status, cannot turn the gate green on their own; they must agree with the live probe or the row is flagged. The probe is deliberately narrow. It checks that imports resolve and that Mathlib is genuinely absent. It does not run a lake build, prove any theorem, or claim Mathlib is installed. The output is a readiness board and a set of blocked consumer verdicts, bounded evidence.

Shape

flowchart TD fixture["Fixture or exported bundle input corpus readiness rows + consumer gate cases"] probe["runtime_lean_import_probe lake env lean: Std compiles, Mathlib import rejected"] artifacts["validate_runtime_source_artifacts check SHA-256 digests, parse probe JSON"] mathlib{"Mathlib lane available? corpus exists + Lake file + probe passes"} corpus["validate_corpus_readiness 7 corpus rows, alias fields must agree with probe"] gates["validate_consumer_gate_cases derive verdicts from readiness facts"] imports["validate_source_module_imports 4 copied source artifacts, digest match"] allowed["Allowed: Lean3 translation smoke (needs no Mathlib project)"] blocked["Blocked: Mathlib-dependent and absent-corpus consumers"] result records["metadata-only result records result, board, validation, sign-off, bundle"] ceiling["Scope limit no Mathlib availability, proof, provider, launch"] fixture --> artifacts artifacts --> probe probe --> mathlib mathlib -->|no, probe false| corpus corpus --> gates gates --> allowed gates --> blocked fixture --> imports corpus --> result records gates --> result records imports --> result records result records --> ceiling

This reader diagram is intentionally smaller than the generated doctrine-lattice graph.

Mechanism

The mechanism is a readiness reducer, not a theorem-proving backend. The runtime entrypoints run and run_projection_bundle both call _build_result, which loads public fixture or exported-bundle inputs, scans those inputs against the non-public-state exclusion policy, verifies copied source artifacts, and then combines corpus readiness, consumer gate, source-module import, negative-case, and scope limit fields into one metadata-only result.

validate_runtime_source_artifacts anchors the reducer to four source refs: the corpus readiness rows, tactic-affordance probe, Mathlib import probe Lean file, and tactic portfolio availability JSON. It checks expected SHA-256 digests, parses the JSON source artifacts, and runs a bounded Lean/Lake import probe that can show Std imports and Mathlib remains absent without running a Lake build or exporting Lean bodies.

validate_corpus_readiness normalizes seven corpus rows against those runtime source artifacts. A corpus is usable for Mathlib-dependent work only when the runtime evidence says the corpus exists, has a Lake file, and mathlib_lake_project_import_available is true. In the current fixture and bundle evidence that field remains false, so Mathlib-dependent capabilities are blocked, absent corpora are recorded, and stale alias fields such as mathlib_available cannot turn the gate green.

validate_consumer_gate_cases then derives consumer verdicts from the normalized readiness facts instead of trusting expected-decision labels. The translation smoke consumer can pass because it does not require a Mathlib Lake project and names an available Lean3 reference corpus; Mathlib-dependent or absent-corpus consumers stay blocked. validate_source_module_imports adds the exported bundle floor by requiring the manifest class copied_non_secret_macro_body, material classes, target/source digest agreement, and no body material in result records.

The proof consumers are the two component commands, the focused regression test tests/test_corpus_readiness_mathlib_absence_gate.py, the paper-module corpus check, and the command-card surfaces emitted by result_card. Together they exercise the success path, contradictory Mathlib claims, consumer-gate skips, source digest tampering, private-path rewrites, runtime-probe blocks, and result record body exclusion. The resulting evidence relates the bundle's two mechanisms to concept.formal_math_and_proof_witness_bundle, P-8, and AX-7 by making readiness visibility a precondition for downstream formal-math claims while keeping the scope limit below theorem, provider, benchmark, or launch-scope decision.

Public Surfaces

• Component runner: python -m microcosm_core.organs.corpus_readiness_mathlib_absence_gate run --input fixtures/first_wave/corpus_readiness_mathlib_absence_gate/input --out receipts/first_wave/corpus_readiness_mathlib_absence_gate
• Exported bundle runner: python -m microcosm_core.organs.corpus_readiness_mathlib_absence_gate run-projection-bundle --input examples/corpus_readiness_mathlib_absence_gate/exported_corpus_readiness_bundle --out receipts/runtime_shell/demo_project/organs/corpus_readiness_mathlib_absence_gate
• Standard: standards/std_microcosm_corpus_readiness_mathlib_absence_gate.json
• Source-module manifest: examples/corpus_readiness_mathlib_absence_gate/exported_corpus_readiness_bundle/source_module_manifest.json
• Runtime result record: receipts/runtime_shell/demo_project/organs/corpus_readiness_mathlib_absence_gate/exported_corpus_readiness_bundle_validation_result.json

Reader Evidence Routing

Read this module in five passes:

1. Start with the source record at core/paper_module_capsules.json::paper_modules[8:paper_module.corpus_readiness_mathlib_absence_gate]. It is the source authority that names source_authority: json_capsule, the component subject, two mechanism subjects, the resolved runtime code locus, the concept concept.formal_math_and_proof_witness_bundle, the dependency paper_module.tactic_portfolio_availability, P-8, and AX-7.
2. The reader proof is the current row shape: eight generated relationship edges, Mermaid available_from_capsule_edges, Atlas blocked_until_organ_atlas_owner_lane_binds_edges, and no unpopulated paper-module selective dependency residual for the tactic-portfolio edge. The structured source record is wiring evidence, not theorem-correctness, runtime-correctness, launch, provider, or production authority.
3. Inspect the runtime locus src/microcosm_core/organs/corpus_readiness_mathlib_absence_gate.py. The load-bearing symbols are run, run_projection_bundle, validate_corpus_readiness, validate_consumer_gate_cases, validate_source_module_imports, _build_result, write_receipts, result_card, EXPECTED_NEGATIVE_CASES, AUTHORITY_CEILING, SOURCE_MODULE_MANIFEST_NAME, BUNDLE_RESULT_NAME, and CARD_SCHEMA_VERSION.
4. For fixture evidence, use fixtures/first_wave/corpus_readiness_mathlib_absence_gate/input and the result records under receipts/first_wave/corpus_readiness_mathlib_absence_gate/ plus result records/sign-off/first_wave/corpus_readiness_mathlib_absence_gate_fixture_acceptance.json. The first-wave result result record records seven corpus rows, seven consumer cases, one allowed Lean3 translation-smoke case, six blocked absent or Mathlib-dependent cases, mathlib_lake_project_import_available: false, body_in_receipt: false, and the five negative cases mathlib_available_without_probe, consumer_skips_readiness_gate, private_corpus_source_ref, proof_body_leakage, and release_overclaim.
5. For exported-bundle evidence, use examples/corpus_readiness_mathlib_absence_gate/exported_corpus_readiness_bundle/source_module_manifest.json and receipts/runtime_shell/demo_project/organs/corpus_readiness_mathlib_absence_gate/exported_corpus_readiness_bundle_validation_result.json. The manifest verifies four copied source artifacts: corpus readiness JSON, tactic-affordance probe JSON, the Mathlib import probe Lean file, and tactic portfolio availability JSON. The exported result record records source_module_import_count: 4, copied_source_artifact_count: 4, source_modules_pass: true, body_in_receipt: false, and three blocked absent or Mathlib-dependent bundle consumer cases.

If a reader needs validation result records rather than prose, run the commands in ## Validation Result record Path, including the focused regression test and paper-module corpus check. Treat every result record as corpus-readiness boundary evidence only; it does not create Lean/Lake execution authority, Mathlib availability, theorem-proof authority, provider authority, private-system equivalence, or launch-scope decision.

Prior Art Grounding

This component is grounded in Lean corpus and neural theorem-proving work where library availability, premise access, and benchmark splits are part of the claim. The Lean mathematical library establishes Mathlib as a large community-maintained formal mathematics corpus, miniF2F gives a cross-system benchmark for formal Olympiad statements, and LeanDojo shows why reproducible corpus extraction and accessible-premise metadata matter for theorem-proving agents.

Microcosm borrows the readiness gate: corpus rows, Mathlib availability probes, blocked consumer cases, source-module digests, and negative leakage guards must be visible before retrieval, tactic-routing, or proof-witness language is allowed. It does not claim Mathlib is present or that any theorem was proved.

Research Bet

Formal-math agents fail when they treat "there is a corpus" as equivalent to "this corpus is usable for this proof route." This component makes that boundary runnable. It records seven corpus rows, blocks six absent or Mathlib-dependent consumer cases, allows only the Lean3 translation-smoke case, and keeps the Mathlib probe false until an actual passing probe is present.

The exported bundle carries four copied body artifacts: corpus readiness JSON, tactic-affordance probe JSON, the Mathlib import probe Lean file, and tactic portfolio availability JSON. Two rows are exact copies and two use a verified private-path rewrite. The result record records the manifest status, counts, material classes, digests, and metadata-only policy; the copied bodies stay under source_artifacts/, not inside result records.

Source-Backed Doctrine Binding

• Component: src/microcosm_core/organs/corpus_readiness_mathlib_absence_gate.py
• Bundle: core/paper_module_capsules.json#paper_module.corpus_readiness_mathlib_absence_gate
• Mechanism: core/mechanism_sources.json#mechanism.corpus_readiness_mathlib_absence_gate.validates_public_corpus_readiness_boundary
• Standard: standards/std_microcosm_corpus_readiness_mathlib_absence_gate.json
• Evidence class: core/organ_evidence_classes.json::corpus_readiness_mathlib_absence_gate records algorithmic_projection at rank 3.
• Source-module manifest: examples/corpus_readiness_mathlib_absence_gate/exported_corpus_readiness_bundle/source_module_manifest.json
• Sign-off result records: receipts/first_wave/corpus_readiness_mathlib_absence_gate/* and result records/sign-off/first_wave/corpus_readiness_mathlib_absence_gate_fixture_acceptance.json

Cold-Agent Use

Open the source-module manifest first, then the runtime bundle result record, then the first-wave result result record. The useful claim is not that Microcosm has Mathlib or can prove downstream theorems. The useful claim is that Microcosm can force a formal-math route to expose corpus availability, Mathlib absence, consumer gating, source-module digest evidence, copied-body boundaries, negative-case result records, and an explicit scope boundary before any proof route is treated as usable.

Re-entry condition: the current atlas row already points at this paper module. After the sibling organ_atlas.json lane releases, bind this bundle's mechanism ref and code locus into the atlas row and rerun python -m microcosm_core.doctrine_lattice --check.

Validation Result record Path

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

PYTHONPATH=src python3 -m microcosm_core.organs.corpus_readiness_mathlib_absence_gate run \
  --input fixtures/first_wave/corpus_readiness_mathlib_absence_gate/input \
  --out /tmp/microcosm-corpus-readiness-mathlib-absence-vrp
PYTHONPATH=src python3 -m microcosm_core.organs.corpus_readiness_mathlib_absence_gate run-projection-bundle \
  --input examples/corpus_readiness_mathlib_absence_gate/exported_corpus_readiness_bundle \
  --out /tmp/microcosm-corpus-readiness-mathlib-absence-bundle-vrp
PYTHONPATH=src python3 scripts/build_doctrine_projection.py --check-paper-module-corpus
PYTHONPATH=src .venv/bin/python -m pytest -p no:cacheprovider --basetemp=/tmp/microcosm-corpus-readiness-mathlib-absence-tests -q tests/test_corpus_readiness_mathlib_absence_gate.py
jq '{edge_count:(.relationships.edges|length), mermaid_status:.paper_module_payload.generated_projections.mermaid.status, atlas_status:.paper_module_payload.generated_projections.atlas_card.status, source_authority:.paper_module_payload.source_authority, unresolved_selective_relation_count:(.relationships.unpopulated_selective_relations|length)}' paper_modules/corpus_readiness_mathlib_absence_gate.json

The fixture command writes the public corpus-readiness board, result result record, and validation result record. The bundle command validates the exported source-module manifest and metadata-only runtime result record. The corpus check and jq structured source record query prove the bundle-derived projection currentness without hand-editing generated JSON. The focused test keeps the Mathlib absence boundary, consumer gate cases, source-module digest checks, non-public paths rewrite policy, and scope boundary behavior from regressing.

Passing these commands does not establish Mathlib is installed, rerun Lean/Lake, validate downstream formal-result correctness, benchmark a corpus, authorize external model access, or approve launch; it only proves the bounded fixture and exported bundle result records preserve the declared readiness boundary.

Full module

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.

Full module

Route Card

bridge_phase_continuity_runtime is the public, executable synthetic transport continuity membrane for detached bridge work. It lets a cold agent validate the disk-first observe/apply handoff without opening live bridge transport, model-output data, operator HUD/browser state, prompt-shelf bodies, private memory, or active phase runtime state.

Purpose

This paper module exists to make detached bridge continuity testable as a public fixture instead of a trust story about hidden agents or provider sessions. The component asks one bounded question: can a disk-first observe/apply handoff be represented by public synthetic transport inputs, validated through continuation, heartbeat, resource-pressure, resume, worker-skip, and completion result records, and kept below live bridge/provider/UI/source-file changes?

The important mechanism is not "run a bridge." It is a continuity membrane: every claim must pass through explicit packet fields, negative-case checks, metadata-only result record writes, and an scope limit that says heartbeat is liveness evidence, resume is resume evidence, and neither is proof that work landed.

First command:

microcosm bridge-phase-continuity-runtime run --input fixtures/second_wave/bridge_phase_continuity_runtime/input --out /tmp/microcosm-bridge-continuity

Prior Art Grounding

This runtime borrows from durable execution, workflow orchestration, leases, and provenance practice. Useful anchors include:

• Temporal, whose durable-execution model keeps workflow state resumable across process failure and retries.
• Apache Airflow DAGs, which separate task ordering and retry/timeout policy from task internals.
• Kubernetes Lease-based leader election, as a prior pattern for liveness evidence, lease renewal, and failover without confusing a heartbeat with work completion.
• W3C PROV, for provenance records that let readers evaluate how an output was produced.

Microcosm borrows the resumable-workflow, DAG, lease, and provenance shapes, but keeps the component to public synthetic observe/apply fixture sign-off. It does not run live bridge transport, use external model services, prove UI uptime, land work, change source files, or include launch operations.

Primary authority surfaces:

• Runtime: src/microcosm_core/organs/bridge_phase_continuity_runtime.py
• Standard: standards/std_microcosm_bridge_phase_continuity_runtime.json
• Fixture manifest: core/fixture_manifests/bridge_phase_continuity_runtime.fixture_manifest.json
• Source-module manifest: examples/macro_projection_import_protocol/exported_projection_import_bundle/observe_runtime_source_module_manifest.json
• Result record set: receipts/second_wave/bridge_phase_continuity_runtime/*.json

Shape

flowchart TD Inputs["Six synthetic transport inputs detached job, continuation packet, heartbeat rows, resource pressure, worker-skip result record, forbidden terms"] --> Transport["_validate_synthetic_transport_contract"] Transport --> Good{"Valid job? yielded to disk, packet not consumed, fresh heartbeat, phase and continuity match"} Good -->|"yes"| Accept["Positive path accepted"] Good -->|"no"| Refuse["Refusal floor: missing packet, missing fields, duplicate resume, heartbeat claims resume, stale heartbeat overclaim, dispatch blocked"] Refuse --> Codes["Concrete error codes"] Accept --> Fixture["_validate_fixture_contract source digests, completion finalizer, apply-failure rollback, public boundary"] Codes --> Fixture Fixture --> Scan["private_state scan fixture and transport inputs"] Scan --> Result records["Five metadata-only result records continuation, heartbeat, resource pressure, resume, completion transition"] Result records --> Gate{"Tracked result record-write gate"} Gate -->|"env set"| Written["Result records written"] Gate -->|"env absent"| Blocked["tracked_receipt_writes_blocked"] Written --> Ceiling["Scope limit: no live bridge transport, external model access, HUD/browser/private memory, source-file changes, launch, or whole-system proof"] Blocked --> Ceiling

The shape is the public continuity membrane: six synthetic transport inputs are checked for a single valid resumable job and against a refusal floor, the accepted and rejected paths both feed the fixture-contract and non-public-state checks, and only then are the five metadata-only result records written through the tracked-write gate. The result record roles delimit what a reader can trust.

Mechanism Pipeline

The runtime source locus is src/microcosm_core/organs/bridge_phase_continuity_runtime.py. Its public entry point run reads the fixture manifest, resolves public-relative fixture paths, and validates six synthetic transport inputs: detached_job.json, continuation_packet.json, heartbeat_rows.jsonl, resource_pressure.json, worker_skip_receipt.json, and private_state_forbidden_terms.json. JSONL heartbeat rows are streamed by _read_required_jsonl so malformed rows are findings, not a reason to ingest a whole live heartbeat body.

The central validator is _validate_synthetic_transport_contract. It separates five result record roles: continuation packet, heartbeat, resource pressure, resume result record, and completion transition. The implementation then writes the canonical result record set only through the result record-write gate. When the requested output is a tracked result record path and MICROCOSM_TRACKED_RECEIPT_WRITES=1 is absent, the component reports tracked_receipt_writes_blocked instead of silently refreshing tracked evidence.

The negative-case floor is source-declared in EXPECTED_NEGATIVE_CASES and validated from fixture contents. Missing continuation packets, missing required fields, duplicate resume attempts, heartbeat rows that claim resume authority, stale heartbeat overclaims, resource-pressure dispatch blocks, private HUD body leakage, resume-pass work-landing overclaims, and observe/apply validation rollback all become explicit error codes. A pass therefore means the fixture both accepted the positive path and observed the refusal floor.

Reader Evidence Routing

Reader evidence routes from this module to the runtime source locus, fixture manifest, source-module manifest, public result records, and focused regression. A diagram view and an atlas card are generated for this module. This page explains what a reader can infer from them.

What It Proves

The component proves a bounded public fixture contract:

• A yielded synthetic job can be resumed only through an explicit continuation packet.
• Missing packets, missing packet fields, and already consumed packets are rejected.
• Heartbeat rows stay liveness evidence only; fresh or stale heartbeat rows do not become resume authority or provider/UI uptime evidence.
• Resource pressure can block dispatch and must be recorded as a blocked decision.
• Resume success is resume-only; it does not establish work landed without the completion transition result record.
• Worker-skip result records dedupe a no-op without silently closing the claim.
• The fixture and result records stay metadata-only for private/live-state classes.

The reusable mechanism is not "subagents are good." It is the concrete continuity membrane that future agents can run before relying on observe/apply bridge resumption claims.

Source-Backed System

The runtime consumes seven public fixture inputs:

• observe_apply_session_fixture.json
• detached_job.json
• continuation_packet.json
• heartbeat_rows.jsonl
• resource_pressure.json
• worker_skip_receipt.json
• private_state_forbidden_terms.json

The fixture manifest declares five copied source body imports: codex_paths_body_import, markdown_routing_body_import, observe_memory_body_import, observe_surfaces_body_import, and observe_runtime_body_import. The component validates the copied target digests from observe_runtime_source_module_manifest.json; result record output keeps those bodies out of result records and records digest verdicts instead.

Result record Floor

A passing run writes five canonical result record roles:

• continuation_packet.json
• heartbeat.json
• resource_pressure.json
• resume_receipt.json
• closeout_transition.json

Each result record carries organ_id, fixture_id, validator_id, checker_id, status, continuation_packet_status, heartbeat_status, resource_pressure_decision, resume_once_status, duplicate_resume_rejection, worker_skip_receipt_status, private_state_scan, authority_ceiling, anti_claim, and the full result record path set.

The runtime also enforces tracked result record-write gating. A direct run to tracked result record paths without MICROCOSM_TRACKED_RECEIPT_WRITES=1 reports tracked_receipt_writes_blocked rather than mutating tracked evidence silently.

Negative Cases

The expected negative-case floor is source-declared in the runtime and manifest:

• missing_packet_duplicate_resume_and_resource_block
• continuation_packet_missing_required_fields
• heartbeat_claims_resume_authority
• bridge_packet_private_hud_body
• stale_heartbeat_overclaims_liveness
• resume_success_overclaims_work_landed
• apply_validation_failure_rolls_back_observe_promotion

The current result record error-code set includes MISSING_CONTINUATION_PACKET, MISSING_CONTINUATION_PACKET_FIELDS, CONTINUATION_PACKET_ALREADY_CONSUMED, HEARTBEAT_NOT_RESUME_AUTHORITY, STALE_HEARTBEAT_LIVENESS_CLAIM, RESOURCE_PRESSURE_DISPATCH_BLOCKED, BRIDGE_PACKET_PRIVATE_HUD_BODY, RESUME_PASS_OVERCLAIMS_WORK_LANDED, and OBSERVE_APPLY_VALIDATION_FAILED.

Validation Anchors

Focused tests:

./repo-pytest --host-pressure-policy=warn tests/test_bridge_phase_continuity_runtime.py

Source-form runtime:

cd microcosm-substrate && PYTHONPATH=src python3 -m microcosm_core.organs.bridge_phase_continuity_runtime run --input fixtures/second_wave/bridge_phase_continuity_runtime/input --out /tmp/microcosm-bridge-continuity

Compact card:

cd microcosm-substrate && PYTHONPATH=src python3 -m microcosm_core.organs.bridge_phase_continuity_runtime run --input fixtures/second_wave/bridge_phase_continuity_runtime/input --out /tmp/microcosm-bridge-continuity --card

Validation Result record Path

./repo-pytest --host-pressure-policy=warn tests/test_bridge_phase_continuity_runtime.py -q --basetemp=/tmp/microcosm_bridge_phase_continuity_runtime_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

Full module

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.

Full module

agent_closeout_faithfulness_audit checks the kind of sentence an agent writes when it finishes a task: "I committed the change, closed the ledger item, and the test passed." It runs the supplied public fixture evidence through real git and pytest subprocesses and refuses any claim that the evidence does not actually support.

Purpose

When an agent reports that work is done, the report is prose. The commit may or may not exist, the ledger row may or may not be there, and "the test passed" may mean the test ran, or it may mean nothing was checked at all. This component exists to answer one question over a fixed fixture: is each completion claim backed by an evidence object that genuinely exists, and is a "passed" claim backed by an explicit exit-zero status check rather than by the wording of the claim?

The approach is unusual in that it does not parse the completion prose or score it against a rubric. The fixture's public_fixture_repo is copied into a throwaway directory, initialised and committed with real git subprocesses, and its HEAD is read back with git rev-parse. A commit claim passes only when it points at that observed HEAD. A declared pytest span is run with python -m pytest <nodeid> inside that temporary repo, and only the exit code decides whether the span passed. The result record records the run as bytes of work that happened, not as a paraphrase of what the agent said.

The distinction the audit defends is narrow and easy to lose. "The span ran" and "the span passed" are separate facts, and a completion sentence that conflates them is the precise failure mode here. A pass claim is admitted only when pass_status_checked is true and the subprocess exited zero; a claim that expected a pass without that check is rejected with CLOSEOUT_PYTEST_PASS_STATUS_NOT_CHECKED. The same separation applies to commits and ledger caps, so a referenced commit object is not treated as a landed change and a named cap is not treated as closed work.

Route Card

• Component id: agent_closeout_faithfulness_audit
• Accepted-component evidence class: external_subprocess_witness
• Standard: standards/std_microcosm_agent_closeout_faithfulness_audit.json
• Runner: src/microcosm_core/organs/agent_closeout_faithfulness_audit.py
• Fixture input: fixtures/first_wave/agent_closeout_faithfulness_audit/input
• Runtime bundle: examples/agent_closeout_faithfulness_audit/exported_agent_closeout_faithfulness_audit_bundle
• Source manifest: examples/agent_closeout_faithfulness_audit/exported_agent_closeout_faithfulness_audit_bundle/source_module_manifest.json
• Primary result records: receipts/first_wave/agent_closeout_faithfulness_audit/agent_closeout_faithfulness_audit_result.json, receipts/first_wave/agent_closeout_faithfulness_audit/agent_closeout_faithfulness_audit_board.json, receipts/first_wave/agent_closeout_faithfulness_audit/agent_closeout_faithfulness_audit_validation_receipt.json, and result records/sign-off/first_wave/agent_completion_faithfulness_audit_fixture_acceptance.json
• Generated posture: this paper module is authored doctrine. Refresh them through their owner commands instead of patching them by hand.

Shape

This module is a completion-claim accounting fixture, not a completion oracle. Its single question is: did the supplied public fixture evidence support the completion claims, and did the result record refuse the overclaims that should not pass?

flowchart TD Claims[completion_claims.json 3 fixture claims] --> Audit[agent_completion_faithfulness_audit.run] Ledger[fixture_ledger.json 2 cap rows] --> Audit Repo[public_fixture_repo git fixture] --> Audit Pytest[tests/test_completion_fixture.py declared nodeid] --> Audit Manifest[source_module_manifest.json 1 exact-copy source body] --> Audit Audit --> Pass[pass result record 3 verified claims] Audit --> Neg[negative-case semantics 4 overclaim classes] Audit --> Ceiling[scope limit no live mutation or launch]

The accounting is source-backed:

Negative cases are part of the Shape rather than an appendix because they define the claim boundary. EXPECTED_NEGATIVE_CASES names fake commit, fake cap, fake pytest node, and unchecked-pytest-pass classes; the focused tests assert the first three directly against fixture mutation and assert unchecked pass rejection against CLOSEOUT_PYTEST_PASS_STATUS_NOT_CHECKED. The runtime-bundle result record observes all four classes, so a cold reader can distinguish "the span ran" from "the pass claim had exit-zero evidence."

The source-body route is deliberately narrow. The exported bundle copies exactly system/lib/agent_experience_diagnostics.py to examples/agent_closeout_faithfulness_audit/exported_agent_closeout_faithfulness_audit_bundle/source_modules/system/lib/agent_experience_diagnostics.py; the manifest carries the matching digest, 1703 lines, required anchors Agent Experience Grand Rounds and completion, and body_in_receipt: false. Result records carry refs, hashes, counts, verdicts, and scope boundaries only. They do not carry copied body text, private root paths, model-output data, account or browser state, live work log authority, live work log authority, source-file changes, launch-scope decision, or whole-system completion truth.

Technical Mechanism

The fixture validator is centered on evaluate() in src/microcosm_core/organs/agent_closeout_faithfulness_audit.py. It loads closeout_claims.json and fixture_ledger.json, copies public_fixture_repo into a temporary repository, initializes and commits that copy with real git subprocesses, and records the resulting HEAD through git rev-parse HEAD. Commit claims pass only when the claim ref is HEAD or the actual subprocess-observed HEAD; fixture cap claims pass only when the cap id appears in the fixture ledger.

For pytest claims, evaluate() runs python -m pytest <nodeid> -q inside the temporary public fixture repo. A span can be counted as observed when the nodeid runs, but a pass claim is accepted only when pass_status_checked is true and the pytest subprocess exits zero. The same source file carries evaluate_negative_case(), which mutates one claim row at a time to force the fake commit, fake cap, fake pytest node, and unchecked pass paths. The expected error codes are declared in EXPECTED_NEGATIVE_CASES, so the negative floor is source-bound rather than inferred from prose.

The exported-bundle path uses run_agent_closeout_bundle() against examples/agent_closeout_faithfulness_audit/exported_agent_closeout_faithfulness_audit_bundle. That path reuses the same evaluator while making the source-module manifest floor mandatory: the copied diagnostic body must match the manifest digest, include required anchors, and remain absent from result records. AUTHORITY_CEILING then records the scope boundaries in machine-readable form: no live repo mutation, no launch-scope decision, no work log closure, and no pytest-pass claim without exit-zero evidence.

Named Proof Consumers

• microcosm_core.organs.agent_closeout_faithfulness_audit.run is the first-wave fixture consumer. It materializes the public fixture repo, ledger, completion-claim rows, semantic negative cases, validation result record, board, and sign-off result record.
• microcosm_core.organs.agent_closeout_faithfulness_audit.run_agent_closeout_bundle is the exported-bundle consumer. It validates the source-open bundle and the copied diagnostic body manifest while preserving body_in_receipt: false.
• microcosm_core.organs.agent_closeout_faithfulness_audit.evaluate is the subprocess witness consumer. It checks commit, cap, and pytest-span claims against actual fixture evidence instead of accepting completion prose.
• microcosm_core.organs.agent_closeout_faithfulness_audit.evaluate_negative_case is the falsification consumer for fake commit, fake cap, fake nodeid, and unchecked pytest-pass overclaims.
• tests/test_agent_closeout_faithfulness_audit.py is the focused regression consumer. It asserts the public subprocess witness path, fake-claim rejections, semantic negative-case evaluation, exported-bundle metadata-only source manifest behavior, digest-mismatch rejection, and pytest-capable interpreter selection.

First Commands

From microcosm-substrate:

Validate the exported bundle when the question is whether the public source-open copy still matches the declared source body:

What It Proves

This component checks completion claims against public fixture evidence instead of trusting completion prose. A positive run proves four things:

• the fixture repo exists and the referenced commit object is visible to real git subprocesses;
• fixture HEAD is checked by subprocess evidence rather than by prose;
• the declared pytest span actually ran;
• work log style cap claims only point at rows present in the fixture ledger.

The useful distinction is narrow: verified means the referenced evidence object exists or the pytest span ran. A claim that a pytest span passed is valid only when the result record checked an explicit exit-zero status. That is the reader value of this component: it separates "I referenced a test" from "I proved the test passed."

Prior Art Grounding

This component is grounded in claim-verification and reproducibility patterns rather than in trust of summary prose. FEVER popularized fact extraction and verification as a separate task over cited evidence, while TruthfulQA made explicit that fluent model answers can be misleading without a truthfulness check. The artifact-review tradition also motivates separating a claim, its artifact, and its validation evidence instead of treating a report as self-validating.

Microcosm borrows that verification posture for agent completion: commit refs, work log refs, pytest spans, subprocess witnesses, and pass-status checks must line up before completion language is admitted. It does not certify all live completion prose or turn a referenced test into a passed test without exit-zero evidence.

Source-Backed System

The source-open body import is a single exact source body:

• system/lib/agent_experience_diagnostics.py

The copied target is:

• examples/agent_closeout_faithfulness_audit/exported_agent_closeout_faithfulness_audit_bundle/source_modules/system/lib/agent_experience_diagnostics.py

The manifest records:

• source_to_target_relation: exact_copy;
• body_copied: true;
• body_in_receipt: false;
• a 1703-line body;
• matching source and target sha256 digests;
• required anchors Agent Experience Grand Rounds and completion.

Result records carry refs, hashes, counts, verdicts, and scope boundaries only.

Result record Floor

A passing fixture run emits:

• agent_closeout_faithfulness_audit_result.json
• agent_closeout_faithfulness_audit_board.json
• agent_closeout_faithfulness_audit_validation_receipt.json
• agent_closeout_faithfulness_audit_fixture_acceptance.json

A passing runtime-bundle run emits:

• exported_agent_closeout_faithfulness_audit_bundle_validation_result.json
• agent_closeout_faithfulness_audit_board.json
• agent_closeout_faithfulness_audit_validation_receipt.json

The first-wave result must show:

• status: pass;
• real_substrate_disposition: real_substrate_capsule;
• body_in_receipt: false;
• source_module_manifest.status: pass;
• all_expected_digests_matched: true;
• all_required_anchors_present: true;
• secret_exclusion_scan.blocking_hit_count: 0;
• receipt_body_scan.status: pass.

The exercise floor is:

• three verified completion claims;
• six git subprocess witnesses;
• one pytest subprocess witness;
• one checked pass status;
• one ran pytest span;
• head_verified_by_subprocess: true.

Negative Cases

The current negative-case floor is:

• fake_commit_claim -> CLOSEOUT_FAKE_COMMIT_CLAIM
• fake_cap_claim -> CLOSEOUT_FAKE_CAP_CLAIM
• fake_test_claim -> CLOSEOUT_FAKE_TEST_CLAIM
• unchecked_pass_claim -> CLOSEOUT_PYTEST_PASS_STATUS_NOT_CHECKED

These cases are the claim-language guardrail. If they stop appearing in observed negative cases, the component no longer proves that public completion result records reject fabricated commit, cap, test-node, or unchecked-pytest-pass claims.

Evidence Binding

• JSON bundle authority: core/paper_module_capsules.json#paper_module.agent_closeout_faithfulness_audit.
• Mechanism source: core/mechanism_sources.json#mechanism.agent_closeout_faithfulness_audit.validates_closeout_evidence_claims.
• Component atlas edge: core/organ_atlas.json#agent_closeout_faithfulness_audit.
• Runtime source: src/microcosm_core/organs/agent_closeout_faithfulness_audit.py.
• First command: PYTHONPATH=src python3 -m microcosm_core.components.agent_completion_faithfulness_audit run --input fixtures/first_wave/agent_completion_faithfulness_audit/input --out result records/first_wave/agent_completion_faithfulness_audit --sign-off-out result records/sign-off/first_wave/agent_completion_faithfulness_audit_fixture_acceptance.json.

Reader Evidence Routing

• Start with the Route Card and JSON Bundle Binding to identify the component, standard, source row, runner, fixture input, exported bundle, and result record surfaces.
• For behavior questions, read src/microcosm_core/organs/agent_closeout_faithfulness_audit.py and the focused tests before trusting this prose.
• For source-open body questions, read the exported bundle's source_module_manifest.json; the manifest is the evidence for exact-copy relation, digest match, anchor match, and metadata-only result record posture.
• For claim-language questions, read the Negative Cases and Result record Expectations together; the pass path only matters if the overclaim cases still fail.
• Treat generated component Markdown, atlas cards, graphs, health files, and runtime result records as navigation or validation projections. They do not become source authority for broader completion truth.

Validation Result record Path

The focused proof consumer is tests/test_agent_closeout_faithfulness_audit.py. A passing result record has to show that completion language was checked against public fixture evidence: referenced commit objects, fixture work log rows, git subprocess witnesses, pytest subprocess witnesses, explicit pass-status checks, negative completion cases, and the exported source-module manifest. It must not rely on completion prose as its own proof.

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

For the focused test, the result record boundary is the asserted shape: three verified completion claims, at least five git subprocess witnesses, one pytest subprocess witness, one ran pytest span, one checked pass-status row, head_verified_by_subprocess=true, source-module digest and required-anchor matches, metadata-only result record posture, and semantic observation of the four negative completion classes. For the corpus check, the result record only proves bundle/instance parity; it does not close live work log work, mutate live work log state, certify arbitrary completion prose, prove launch-scope decision, or turn a referenced pytest span into a passed span without exit-zero evidence.

Validation Anchors

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

• public git and pytest subprocess witness behavior;
• fake commit rejection;
• unchecked pytest pass rejection;
• fake cap claim rejection;
• fake pytest node id rejection;
• metadata-only source manifest behavior in the exported bundle;
• source-module digest mismatch rejection;
• pytest-capable Python selection.

Full module

cold_reader_route_map makes Microcosm's first ten minutes executable. It validates a public route map whose rows bind the first-run sequence to runnable commands, docs refs, result record refs, and scope limits.

Purpose

A cold technical reader should not have to infer the product path from a long README or raw result record tree. The route map answers one question: what should I run first, and what evidence proves that path is wired?

The unusual part is how the validator checks that proof. It does not merely confirm that each route row carries the right fields. It replays every route against real source: each row's command, its docs refs, its result record refs, and the human-readable signals it claims to show are matched against the actual text of copied source modules and public docs. A command whose material tokens do not appear anywhere in that source corpus is blocked, as is a docs ref that does not resolve to a real heading and a result record ref that does not open a pass-status result record. So a route cannot promise a command the system does not actually run, which is the failure mode a hand-written quick-start guide drifts into the moment the commands change underneath it.

The evidence contract is source-open by default: public route cards, route result record bindings, route policy, exported bundle refs, and generated result records carry the system, while secret_exclusion_scan excludes only private source bodies, model-output data, account or browser material, secrets, and account secret-equivalent live-access data. Result record bodies are not inlined; they are represented by body_in_receipt: false plus public runtime refs.

Shape

flowchart LR subgraph Entry["First-screen entry"] Project["Public project path repo -> .microcosm"] First["First-screen card claim frame, first command, evidence legend, exit rule"] end subgraph Accounting["Route-map accounting"] Route["Ordered route rows command, result record ref, evidence class"] Ceiling["Scope boundary and scope limit attached to each row"] end subgraph ReaderBranch["Reader branch"] Branch["Reader branch choose one first action"] Safety["Safety/evals status, authority, workingness"] Hiring["Hiring reviewer first-screen card, legibility scorecard"] Developer["Peer developer tour, observe, explain or compile"] end subgraph Boundary["Proof boundary"] Drilldown["Drilldowns tour, status, explain, observe, compile, serve"] Result record["Result records and route refs public refs only; body_in_receipt false"] end Project --> First First --> Route Route --> Ceiling Route --> Branch Branch --> Safety Branch --> Hiring Branch --> Developer Safety --> Drilldown Hiring --> Drilldown Developer --> Drilldown Ceiling --> Result record Drilldown --> Result record

Reader Evidence Routing

Start with core/paper_module_capsules.json::paper_modules[13:paper_module.cold_reader_route_map], then read the generated JSON projection for the resolved relationships. A diagram view is generated for this module and an atlas card entry is available. The route-map fixture, exported bundle, source-module manifests, and temporary result records are evidence for replay shape. This Markdown gives cold readers the interpretation order, source-linked only.

Prior Art Grounding

This component is grounded in documentation systems that treat reader state and task shape as first-class. Diataxis separates tutorials, how-to guides, reference, and explanation so readers are not forced through one undifferentiated documentation pile. Knuth's literate programming is an older anchor for the idea that executable systems should be written for human comprehension as well as machine execution.

Microcosm borrows the reader-route pattern: first command, result record ref, evidence class, scope boundary, scope limit, and next drilldown are ordered for a cold reader. It does not make the route map source authority or substitute documentation sequence for validator evidence.

Reader-Specific Evidence Routing

The route map should make the evidence-count frame visible before the reader chooses a drilldown. Honest counters are not progress badges:

• A safety/evals engineer follows microcosm status --card, microcosm authority --card, and microcosm workingness --card first. The useful question is whether each claim names its evidence class, validator, failure mode, and scope limit.
• A hiring reviewer follows the first-screen card and legibility scorecard first. The useful question is whether small verified counts are framed as honest proof boundaries instead of hidden or inflated.
• A peer developer follows microcosm tour --card, microcosm observe --card, and then full microcosm observe, microcosm compile, or microcosm explain as drilldowns. The useful question is whether a fresh clone can reproduce the route/work/event/evidence chain locally without opening full event rows first.

The route map must therefore preserve both the command order and the evidence interpretation order: command, result record ref, evidence class, scope boundary, scope limit, then deeper route. Reader-specific branches may hide other branches, but they may not hide the accounting frame that prevents "1 verified import" from being read as either failure or marketing.

One-Screen Handoff Contract

The route map consumes the first-screen card as the handoff, not as another route row. A cold reader should see this sequence:

1. First-screen card: claim frame, microcosm hello <project>, shared proof, evidence legend, structural join, reader rail, and exit rule.
2. Route map: the accepted command order, with result record refs and scope limits attached to each command.
3. Reader branch: one audience-specific first action, one proof surface, one success criterion, and one next drilldown.

The handoff fails when the first screen turns into a complete route inventory, or when the route map assumes the reader already understands evidence classes. The first screen should compress; the route map should sequence; the reveal should demonstrate the path against public result records.

Comparison-Backed Route Rows

Each route row should make the unusual discipline visible by naming the normal failure mode it is avoiding. The route map is not just a command list; it is a sequence of claim-boundary checks:

Rows that omit the comparison cue are still technically navigable, but they make the rigor invisible to a cold reader. The validator should prefer a shorter row with command, result record, class, scope boundary, and failure mode over a longer row that lists more components without explaining what each boundary prevents.

Observable Drilldown Order

Browser-first readers follow the same route map as terminal-first readers. The route order is compressed, not replaced:

1. First-screen card or compact browser board.
2. microcosm tour --card <project> as the shared behavior proof.
3. Selected route plus work/event/evidence refs.
4. Compact observatory view for the same route.
5. Full route map, result records, standards, and raw JSON drilldowns.

The compact observatory row must carry the same command ref, result record ref, evidence class, scope boundary, and scope limit as the terminal route row. If the browser board cannot show those fields, it is a preview only and cannot serve as the cold-reader route handoff.

readme_onboarding_route is the selected route only for projects with a README; folders without one still get a route/work/event/evidence path through the selected route emitted by tour and compile.

Each route card must include a command and public docs refs. Each route id must also resolve to at least one result record ref. The sequence must be ordinal sorted so the public entry does not drift into a bag of impressive but unordered components.

Validation

The fixture observes negative cases for missing command refs, missing result record refs, route sequence gaps, launch/provider overclaims, and private source body fields. The exported bundle omits negative cases and validates the real runtime shape used by microcosm run, with synthetic result record stand-ins explicitly disallowed as product evidence. If focused validation reports an exact-copy source-module body mismatch, route that repair through microcosm_exact_copy_refresh; do not treat this Markdown projection as the authority for copied source bodies.

Validation Result record Path

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

The focused pytest file is the proof consumer for this Markdown section. It asserts the fixture status, ten-route command and result record-ref counts, front-door route order, expected negative cases, route-source replay support, exported bundle shape, copied source-module digest and anchor matches, source-open fixture-manifest counts, no source bodies in public result records, streamed line-count and digest handling, and fresh exported-bundle card reuse. The corpus check verifies that this page remains in the 98-module paper-module set and that the JSON bundle, generated Mermaid, Atlas card, and Markdown projection stay mutually consistent.

These result records validate the route-map fixture, exported bundle result records, copied cold-entry evidence, and paper-module corpus membership only; they do not grant route registry control, external model service, source-file changes, launch-scope decision, private-data equivalence, financial decisions, publishing-scope decision, hosted readiness, or whole-system correctness.

Full module

proof_diagnostic_evidence_spine sits one step before formal proof authority. It holds diagnostic evidence from the formal-math evaluation and premise-retrieval pipeline as result record-backed cells, and refuses to let any of them be read as a proof.

Purpose

The component answers a single question: does a diagnostic check that claims to be backed by real Ring2 runtime evidence actually recompute against that evidence, or is it asserting more than its refs support? Without this membrane, a check row could name a failure-taxonomy report or a graph-update candidate set, declare itself passing, and be trusted on its own word. The spine refuses that.

What is unusual is that the validator does not trust the fixture's own pass label. It ignores the legacy expected_result field as a non-authoritative fixture label and rederives the verdict itself. For each check it resolves the named source_ref to a real file, re-hashes that file with sha256, and confirms the hash matches the expected digest. It then opens the named result record anchor and checks that the result record payload actually contains that source ref and digest. A check is accepted only when the source, the digest, and the result record all agree. The pass is a recomputation, not a claim copied from the fixture.

The second idea is that negative evidence is kept rather than hidden. A stale source fingerprint is recorded as source_fingerprint_status: stale and retained as diagnostic evidence; a provider advisory row is preserved as metadata while being rejected as authority; a forbidden proof-body field turns a row into a regression fixture rather than silently dropping it. The board shows what did not hold, which is the point of an evidence membrane.

Teleology

proof_diagnostic_evidence_spine is the body-safe evidence membrane before formal proof work. It records proof/evidence diagnostics while rejecting proof bodies, provider output bodies, source-authority upgrades, stale coupling, and runtime-correctness overclaims.

Public Contract

The validator consumes failure-taxonomy records, graph-update traces, verifier-trace repair artifacts, and formal evidence-cell anchor result record refs from the formal-math evaluation and premise-retrieval pipeline, then emits diagnostic result records over those refs. Provider-advisory rows are bounded evidence authority. Passing diagnostic checks do not become formal proof authority or formal-result correctness.

How a check is accepted

A check row carries three lists: source_refs, receipt_anchor_refs, and source_digest_refs. The validator does not take the row's word for whether it passes. It recomputes the verdict from the system.

For each source_ref it resolves a real file, reads it, and hashes the bytes with sha256. That hash must equal the expected digest the component holds for the ref. It then opens each result record anchor and checks that the result record payload actually contains the source ref and its digest, so a check is only "result record-backed" if the result record it cites genuinely references it. On top of that the component applies a semantic floor: a check whose id mentions a failure taxonomy must point at a source file that carries a failure-taxonomy report with representative failures and at a result record that carries a failure-mode ledger; a graph-update check needs graph-update candidates with ids and a matching result record anchor. The check is accepted only when every source resolves, every digest matches, every cited result record backs the ref, the semantic floor is satisfied, and no expected-negative error code is declared.

The concrete failure mode this guards against is a plausible-looking row that names real artifact paths but does not actually recompute: a digest that has drifted, a result record that does not mention the ref it claims, or a check labelled as failure-taxonomy evidence while pointing at an unrelated file. Each of those becomes a rejection finding rather than a silent pass. The recompute is also why a passing check stays bounded. It establishes that the named evidence is present and coupled, not that the underlying runtime is correct, which is why a row that adds claims_runtime_correctness is rejected as an overclaim.

Shape

flowchart TD Check["Diagnostic check row source_refs, receipt_anchor_refs, source_digest_refs"] Resolve["Resolve source ref to real public file"] Hash["Re-hash file (sha256) compare to expected digest"] Result record["Open result record anchor does payload contain this ref and digest?"] Floor["Semantic floor failure-taxonomy / graph-update source and result record match"] Accept["Accepted check verdict = recomputed, body_in_receipt false"] Reject["Rejected / retained as diagnostic evidence"] Stale["Stale source fingerprint"] Provider["Provider advisory payload"] Proofbody["Forbidden proof-body field"] Check --> Resolve --> Hash --> Result record --> Floor Floor -->|all agree| Accept Floor -->|any mismatch| Reject Stale -. retained as evidence .-> Reject Provider -. metadata kept, authority denied .-> Reject Proofbody -. scrubbed, kept as regression .-> Reject Accept --> Board["diagnostic_board.json evidence accounting only"] Reject --> Board Board -. denies .-> Ceiling["no Lean/Lake run, no formal-result correctness, no provider authority, no launch"]

Evidence/accounting refs:

• Bundle authority: core/paper_module_capsules.json::paper_modules[14] sets source_authority: json_capsule, names subjects proof_diagnostic_evidence_spine and mechanism.proof_diagnostic_evidence_spine.validates_ring2_diagnostic_evidence_membrane, resolves code_loci[0].path to src/microcosm_core/organs/proof_diagnostic_evidence_spine.py, and keeps generated_projections.markdown.generated: false, generated_projections.mermaid.status: available_from_capsule_edges, and generated_projections.atlas_card.status: linked_from_capsule_edges.
• Generated instance boundary: paper_modules/proof_diagnostic_evidence_spine.json::paper_module_payload.projection_contract records authority_flip_status: not_flipped, while paper_modules/proof_diagnostic_evidence_spine.json::relationships.edges carries source-justified links to the component, mechanism, concept, principles, axioms, dependencies, and code locus.
• Component/source locus: organs/proof_diagnostic_evidence_spine.json::organ_payload.source_atlas_row names the first command, claim_ceiling_restated, mechanism_refs[0], wires_to, and the same code-locus symbols implemented in src/microcosm_core/organs/proof_diagnostic_evidence_spine.py (PROOF_AUTHORITY_CEILING, EXPECTED_NEGATIVE_CASES, validate_copied_macro_body_artifacts, validate_evidence_receipts, validate_provider_payload_policy, validate_authority_ceiling, run, and run_evidence_bundle).
• Standard contract: standards/std_microcosm_proof_diagnostic_evidence_spine.json::authority_boundary_detail limits the component to copied Ring2 diagnostic runtime artifacts, summary metrics, graph-variant metadata, and anchor result record refs. Its body_import_verification.source_open_body_import_floor records 13 copied artifact bodies, 10 exact copies, 3 public-light edits, and body_text_exported_in_receipts: false; its body_import_verification.public_organ_source_body_floor records one exact copied public component source body.
• Bundle floor: examples/proof_diagnostic_evidence_spine/exported_evidence_bundle/bundle_manifest.json has schema_version: proof_diagnostic_evidence_spine_exported_evidence_bundle_v1, bundle_id: ring2_proof_diagnostic_evidence_runtime_example, copied_macro_body_artifacts count 13, and an scope limit of Ring2 diagnostic result record refs only, not formal proof authority.
• Source-body floor: examples/proof_diagnostic_evidence_spine/exported_evidence_bundle/source_body_floor/source_module_manifest.json::modules[0] records source ref src/microcosm_core/organs/proof_diagnostic_evidence_spine.py, source_to_target_relation: exact_copy, sha256_match: true, body_in_receipt: false, and omitted material including model-output data bodies, account or browser state, browser UI live-access state, recipient-send state, private proof bodies, and oracle-needed premise ids.
• Result record behavior: receipts/first_wave/proof_diagnostic_evidence_spine/proof_evidence_validation_receipt.json records accepted_count: 2, rejected_count: 1, missing_negative_cases: [], body_in_receipt: false, source_fingerprint_status: stale, and observed negative cases for source-authority upgrade, missing result record fields, runtime-correctness overclaim, provider/proof body rejection, and stale coupling. The sibling provider_payload_policy_result.json::provider_payload_policy preserves advisory metadata while rejecting the forbidden proof-body payload, and diagnostic_board.json::authority_ceiling rejects model-output data authority, source-authority upgrade, runtime-correctness claims, and formal prover execution.
• Focused regression surface: tests/test_proof_diagnostic_evidence_spine.py asserts the observed negative cases match EXPECTED_NEGATIVE_CASES and checks the exported evidence bundle path. These tests support reader wiring and evidence accounting only; they do not establish formal-result correctness, provider authority, runtime correctness, publishing-scope decision, or launch-scope decision.

Reader Evidence Routing

Route currentness questions through ## JSON Bundle Binding and the validation commands in ## Validation Result record Path. The tests and corpus check confirm reader wiring and projection health; they do not establish proof authority.

Route source/body-floor questions through ## Source-Open Body Floor and the fixture/example paths named under ## Structured Lattice Bindings. The diagnostic artifact copies from the formal-math evaluation pipeline, public component-source copy, manifests, and digest coupling are evidence-accounting inputs; they are bounded evidence bodies, model-output data bodies, runtime correctness claims, or source-authority upgrades.

Route claim-safety and public-copy questions through ## Scope limit, ## Evidence-As-Accounting Shape, and ## Scope boundary, then pair this module with batch12_release_claim_language_gate when public wording is being checked. If the question is "did the validator still enforce the membrane?", use the focused pytest and corpus check in ## Validation Result record Path before citing the reader page.

Evidence-As-Accounting Shape

This component is the proof-adjacent evidence membrane behind Microcosm's scope limits. It accepts diagnostic runtime artifacts, result record refs, source digests, and negative-case results as evidence cells, while refusing to treat any of them as theorem authority.

The accounting rule is two-sided. A copied artifact from the formal-math evaluation and premise-retrieval pipeline can strengthen only the diagnostic claim named by its result record, digest, and validator; it cannot upgrade itself into formal-result correctness, provider authority, launch-scope decision, or private-system equivalence. Stale source coupling is retained as diagnostic evidence instead of hidden, and provider-advisory rows remain metadata without payload bodies.

Use this module with batch12_release_claim_language_gate when evaluating public copy: the evidence spine says what result record-backed cells exist, and the language gate decides whether a public sentence stays within that ceiling.

Prior Art Grounding

The evidence spine is grounded in assurance-case practice: evidence should be connected to claims, assumptions, and limits before it is treated as support. NASA's Goal Structuring Notation example for spacecraft assurance is a useful public analogue because it frames assurance as model-structured evidence rather than document-level persuasion: NTRS 20160005295.

The result record membrane also borrows from W3C PROV and observability practice: diagnostic artifacts are evidence cells with provenance, not theorem authority. That is why the component accepts digest-coupled diagnostic refs and negative cases while rejecting proof bodies, model-output data bodies, and stale source-coupling overclaims.

Validation Result record Path

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

Full module

proof_derived_governed_mutation_authorization is the public mutation-authority replay component for showing that a mutation proposal cannot grant itself authority. It validates a synthetic governed-mutation bundle where read-only inspection, scoped config write, and rollback proposals are admitted only when proof cells, visible pre-execution policy verdicts, side-effect logs, rollback result records, cold replay, negative cases, non-public-state scan, and scope limits line up.

This module is source-backed public doctrine, not the source of authority. The source rows are the JSON bundle, mechanism registry row, component atlas binding, standard contract, fixture, exported bundle, component source module, and result records named below. Markdown remains an authored projection over those rows.

Purpose

The component answers one question: can a mutation proposal acquire the authority to change something just by asserting that it should? In an agent system the danger is an action that grants itself permission, for example by claiming a standing account secret, by recording a governance-vote nobody can see, or by reporting success after the fact. This fixture is the boundary that refuses each of those moves.

Authorisation here is derived, not asserted. A proposal is admitted only when an independent chain resolves: redacted proof cells that name validator result records, at least two visible policy verdicts evaluated before any execution identity is minted, a logged side-effect diff for write and rollback proposals, a paired rollback result record, and a cold-replay result record. The validator recomputes an evidence-chain hash from those resolved rows and rejects the proposal if the declared hash does not match. Impressive language, an admin-looking identity, or a final answer that says it worked all fail on their own.

The less obvious part is the anti-bake gate. Passing the synthetic chain is not enough: every authorised proposal must also bind to a real repository record, a concrete git commit that the validator resolves with a git subprocess and checks touched this component's own source or its focused test. The validator then re-derives the proof, policy, and rollback refs from the evidence indices and compares them to what the record declares. A fixture cannot pre-bake its answer, because the answer is reconstructed from real commit scope and the resolved rows rather than read from the file. The fixture admits exactly three synthetic proposals (read-only inspection, scoped config write, rollback) and rejects eight named overclaims; none of this grants any live mutation authority.

Shape

• Subject: proof_derived_governed_mutation_authorization, with mechanism mechanism.proof_derived_governed_mutation_authorization.validates_synthetic_governed_mutation_authorization.
• Runtime locus: src/microcosm_core/organs/proof_derived_governed_mutation_authorization.py, especially run, run_authorization_bundle, validate_mutation_proposals, validate_proof_evidence_cells, validate_policy_verdicts, validate_side_effect_ledger, validate_rollback_receipts, validate_cold_replay, _source_module_manifest_result, _source_open_body_import_summary, EXPECTED_NEGATIVE_CASES, and AUTHORITY_CEILING.
• The positive fixture admits exactly three synthetic proposals: read-only inspection, scoped config write, and rollback.
• Every admitted proposal must bind intent bundle refs, proof-cell validator result records, visible pre-execution policy verdicts, ephemeral execution identity refs, an evidence-chain hash, cold replay refs, and an scope limit.
• Write and rollback proposals also need logged side-effect diff refs and a paired rollback result record before authorization.
• The exported bundle imports six copied source bodies through source_module_manifest.json and validates them by exact-copy digest evidence without exporting source body text in result records.

flowchart TD Proposals["mutation_proposals.json 3 synthetic proposals: read-only, scoped write, rollback"] subgraph Evidence["Resolved evidence chain"] ProofCells["proof_evidence_cells.json validator-backed proof refs"] Policies["policy_verdicts.json 2+ visible verdicts before execution identity"] Effects["side_effect_ledger.json logged diff for write / rollback"] Rollbacks["rollback_receipts.json paired rollback result record"] Replay["cold_replay.json cold rerun per proposal"] end Hash{"Recompute evidence-chain hash declared == derived?"} Records["governed_mutation_records.json real repo record + git commit ref"] AntiBake{"Anti-bake gate git commit touched this source/test? re-derived refs match declared?"} SourceManifest["source_module_manifest.json 6 copied source bodies verified by digest"] Negatives["8 negative cases standing account secret, hidden vote, policy-after-execution, ..."] Result records["metadata-only result records result, board, validation, sign-off"] Ceiling["scope limit no account secrets, live mutation, provider, source-file changes, hosting, public sharing, or launch"] Proposals --> Evidence Evidence --> Hash Hash -->|match| AntiBake Hash -->|mismatch| Negatives Records --> AntiBake AntiBake -->|real record bound| Result records AntiBake -->|unbound or baked| Negatives SourceManifest --> Result records Negatives --> Result records Result records --> Ceiling

How it works

Take the scoped config write proposal. To be admitted it must carry the fourteen required fields, including proof_cell_refs, policy_verdict_refs, policy_evaluated_before_execution, side_effect_class, evidence_chain_hash, and cold_replay_ref. The validator then checks each one against the other input files rather than trusting the proposal's own summary.

For the proof refs it confirms each cell names the same proposal, carries evidence refs and validator-result record refs, is body-redacted, and does not export a proof body. For the policy refs it counts how many verdicts are visible to the result record, are not hidden votes, read allow or warn, and resolve back to a proof cell for that proposal. Fewer than two visible resolving verdicts blocks the proposal under GOV_MUT_CONSENSUS_WITHOUT_EVIDENCE. Because a scoped write has a reversible side effect, it also needs a logged diff ref in the side-effect ledger and a passing rollback result record for the same proposal. A write or rollback proposal with no rollback ref is rejected as an irreversible mutation.

The validator then recomputes the evidence-chain hash. It hashes the resolved proof digests, policy digests, side-effect ref, rollback ref, and cold-replay ref together and compares the result to the proposal's declared evidence_chain_hash. A mismatch fails the proposal, so the hash cannot be a hand-written constant. Only after the synthetic chain resolves does the real-record gate run. The governed-mutation record must declare a repo record class, a forty-character-or-shorter hex commit ref, and source refs covering git, mission-transaction, work-landing, and ledger material. The validator shells out to git to confirm the commit exists and that its changed files include this component's source module or its focused test, and it re-derives the proof, policy, and rollback refs from the indices so the record's claims must match independently computed values. An authorised proposal whose proposal id is not in the accepted real-record set is downgraded to blocked. The result is that a green result record requires three synthetic proposals, three real records bound to real commits, and a matching anti-bake status, none of which a static fixture can fake.

Public Contract

• The source pattern is proof_derived_governed_mutation_authorization_compound.
• The fixture lives at fixtures/first_wave/proof_derived_governed_mutation_authorization/input/.
• The runtime example lives at examples/proof_derived_governed_mutation_authorization/exported_governed_mutation_authorization_bundle/.
• The validator is microcosm_core.organs.proof_derived_governed_mutation_authorization.
• The governing standard is standards/std_microcosm_proof_derived_governed_mutation_authorization.json.
• The component model row is core/organ_atlas.json#proof_derived_governed_mutation_authorization.
• The sign-off row is core/organ_registry.json#proof_derived_governed_mutation_authorization.

The fixture has three positive proposals: read-only inspection, scoped config write, and rollback. Every admitted proposal must cite an intent bundle, scope limit, proof cell, visible policy verdicts, ephemeral execution identity, evidence-chain hash, and cold replay ref. Write and rollback proposals also require logged side-effect diff refs and a verified rollback result record paired before the mutation is admitted.

Source-Backed Mechanism

The mechanism row mechanism.proof_derived_governed_mutation_authorization.validates_synthetic_governed_mutation_authorization points at these runnable source loci:

• run and run_authorization_bundle for fixture and exported-bundle entry.
• validate_mutation_proposals, validate_proof_evidence_cells, validate_policy_verdicts, validate_side_effect_ledger, validate_rollback_receipts, and validate_cold_replay for the authorization predicate.
• _source_module_manifest_result and _source_open_body_import_summary for digest-verified copied source-body evidence without body text in result records.
• EXPECTED_NEGATIVE_CASES and AUTHORITY_CEILING for falsification and scope boundary enforcement.

The exported governed-mutation bundle imports six source bodies through examples/proof_derived_governed_mutation_authorization/exported_governed_mutation_authorization_bundle/source_module_manifest.json. Those bodies are copied into source_modules/ with digest provenance:

• state/microcosm_portfolio/extracted_patterns_ledger.jsonl
• state/microcosm_portfolio/reconstruction/high_novelty_substrate_gap_scout_v1.json
• tools/meta/control/mission_transaction_preflight.py
• tools/meta/control/scoped_commit.py
• tools/meta/factory/work_ledger.py
• system/lib/work_landing_status.py

Result records may report module ids, refs, counts, classes, hashes, and verdicts. They may not duplicate source body text, proof bodies, governance-vote bodies, model-output data, account secrets, account refs, or live access material.

Reader Evidence Routing

• Open standards/std_microcosm_proof_derived_governed_mutation_authorization.json for required witnesses, negative-floor classes, denied authority, result record expectations, validator contract, and source refs.
• Open core/fixture_manifests/proof_derived_governed_mutation_authorization.fixture_manifest.json for positive fixture inputs, eight negative fixtures, body-import summary, durable result record refs, and source-open omission rules.
• Open examples/proof_derived_governed_mutation_authorization/exported_governed_mutation_authorization_bundle/source_module_manifest.json before inspecting copied source modules; result records carry refs, hashes, counts, and verdicts, not copied source body text.
• Open tests/test_proof_derived_governed_mutation_authorization.py for the focused assertions on proposal counts, negative cases, source-module digest mismatch, public-relative redaction, and card result record reuse.
• Run the fixture or exported-bundle route from microcosm-substrate/. The CLI supports --card, but it does not expose a --json flag.
• Use scripts/build_doctrine_projection.py --check-paper-module-corpus to verify this Markdown projection still satisfies the shared paper-module coverage contract.

First Commands

From microcosm-substrate/, a cold agent can refresh the fixture result records with:

The exported bundle validator proves the copied source-body floor without writing durable result records:

PYTHONPATH=src python3 -m microcosm_core.organs.proof_derived_governed_mutation_authorization run-authorization-bundle --input examples/proof_derived_governed_mutation_authorization/exported_governed_mutation_authorization_bundle --out /tmp/microcosm-proof-derived-governed-mutation --card

Evidence Result records

• receipts/first_wave/proof_derived_governed_mutation_authorization/proof_derived_governed_mutation_authorization_result.json
• receipts/first_wave/proof_derived_governed_mutation_authorization/proof_derived_governed_mutation_authorization_board.json
• receipts/first_wave/proof_derived_governed_mutation_authorization/proof_derived_governed_mutation_authorization_validation_receipt.json
• receipts/first_wave/proof_derived_governed_mutation_authorization/exported_governed_mutation_authorization_bundle_validation_result.json
• receipts/runtime_shell/demo_project/organs/proof_derived_governed_mutation_authorization/exported_governed_mutation_authorization_bundle_validation_result.json
• result records/sign-off/first_wave/proof_derived_governed_mutation_authorization_fixture_acceptance.json

Current result record evidence records three proposals, three authorized synthetic mutations, three proof cells, six visible policy verdicts, two logged side effects, two rollback passes, three cold replay passes, no missing negative cases, private_state_scan.status=pass, and body_in_receipt=false for copied source source modules.

Negative Cases

The fixture rejects the eight named negative cases in core/fixture_manifests/proof_derived_governed_mutation_authorization.fixture_manifest.json: standing account secret authority, policy-after-execution, hidden governance-vote, live cloud account secret, irreversible mutation, unlogged side effect, consensus without evidence, and final-answer-only success.

These negative fixtures are the security argument. A proposal with impressive language, an admin-looking identity, hidden votes, post-hoc approvals, or a final answer that says it succeeded still fails unless the public evidence tables resolve to the authorization predicate.

Prior Art Grounding

The governed-mutation shape is grounded in admission-control and policy-as-code practice: a proposed state change is evaluated before it mutates the system, and the decision is separate from the actor's own assertion. The closest public anchors are Open Policy Agent, which separates policy decision-making from enforcement over structured input, and Kubernetes admission controllers, which validate or mutate API requests before persistence.

The rollback and side-effect portions are also adjacent to controlled rollout practice, including feature-flag and canary-launch patterns described by Martin Fowler. Microcosm keeps the pattern synthetic and replay-only: the component validates visible policy verdicts, side-effect logs, rollback result records, and cold replay without granting live mutation authority.

Public Scope

This component is a synthetic, public, source-open replay. It validates fixture and exported-bundle result records plus copied source bodies with digest provenance. The replay stays inside local files and does not use standing account secrets, access live cloud or account systems, use external model services, change source files, expose private proofs, expose policy-vote bodies, or claim benchmark safety.

Validation Result record Path

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

Full module

Durable agent work-landing replay is the public work-spine component for showing how Microcosm treats agent work as a transaction instead of a chat claim. It binds owned-path claims, owner-native validation, scoped commit attempts, protected Git-metadata blockers, work log capture, work log finalizers, and seed reentry into a source-available replay contract.

The component is useful to a cold agent because it turns a landing claim into an evidence checklist: a row is not "landed" unless claimed paths, validation refs, commit-attempt refs, HEAD-before/after evidence, blocker capture, and ledger completion all line up in the recorded replay. It validates the replay contract and the negative fixtures. It does not perform the live landing itself.

Purpose

This component exists because an agent saying "I committed the fix" is cheap, and the claim is the part that tends to be wrong. The single question it answers is narrow: given a recorded landing attempt, does the evidence actually support the words used to describe it?

The approach worth noticing is that two ordinary-sounding rules are made into rejections rather than suggestions. A row that uses landed-commit language is rejected unless the recorded Git HEAD moved between before and after, so "I landed it" cannot stand on a HEAD that never advanced. A row on the commit path is rejected unless validation is recorded as preceding the commit attempt, so "it passed" cannot be back-filled after the fact. Those two checks, plus blocker capture for metadata-blocked rows and work log completion for every row, are what separate a transaction from a chat claim.

The replay is also source-backed rather than described from memory. The mechanics it checks rows against are not paraphrased; the actual source internal control files (work landing, mission preflight, scoped commit, the work log) are copied into the bundle by digest, so a reader can see which code the model was tested against. The component reads that evidence and rejects overclaims; it never runs Git, stages anything, or authorises a launch.

Shape

flowchart LR Fixture["Public replay fixture claimed rows, validation refs, commit attempts, blocker rows"] Source["Copied internal control source bodies work landing, preflight, scoped commit, work log"] Validator["durable_agent_work_landing_replay validator"] Mechanics["Replay mechanics claim before mutation, validate before commit, HEAD movement before landed language"] Negative["Negative floor live Git authority, missing completion, uncaptured blocker, private leakage"] Result record["Result records board, result, validation, sign-off; no live mutation authority"] Fixture --> Validator Source --> Validator Validator --> Mechanics Validator --> Negative Mechanics --> Result record Negative --> Result record

Public Contract

• The source pattern is durable_agent_work_landing_replay_compound.
• The fixture lives at fixtures/first_wave/durable_agent_work_landing_replay/input/.
• The runtime example lives at examples/durable_agent_work_landing_replay/exported_work_landing_replay_bundle/.
• The validator is microcosm_core.organs.durable_agent_work_landing_replay.
• The CLI command is microcosm durable-agent-work-landing-replay run-work-landing-bundle.
• The governing standard is standards/std_microcosm_durable_agent_work_landing_replay.json.
• The component model row is core/organ_atlas.json#durable_agent_work_landing_replay.
• The sign-off row is core/organ_registry.json#durable_agent_work_landing_replay.

Technical Mechanism

The replay fixture imports six source internal control bodies through examples/durable_agent_work_landing_replay/exported_work_landing_replay_bundle/source_module_manifest.json. Those bodies are copied into source_modules/ with digest provenance instead of being summarized from memory:

• system/lib/workitem_runtime_entrypoint.py
• system/lib/work_landing_status.py
• tools/meta/control/work_landing.py
• tools/meta/control/mission_transaction_preflight.py
• tools/meta/control/scoped_commit.py
• tools/meta/factory/work_ledger.py

The validator checks the replay rows against those source-backed mechanics rather than accepting a prose landing claim. validate_projection_protocol requires source pattern refs, projection result record refs, and public runtime refs. validate_landing_policy requires the scoped-commit, broad-checkpoint, metadata-blocked patch-bundle, and hard-stop lanes, with broad checkpointing kept behind explicit operator authorization and launch-scope decision kept false. validate_work_landing_runs enforces claim-before-mutation evidence, validation before commit attempt, HEAD movement before landed language, blocker capture before metadata-blocked completion, dirty-tree boundary evidence, and work log finalizer evidence.

The source-open body floor is enforced separately by validate_source_module_imports. The manifest must declare copied_non_secret_macro_body, body_in_receipt: false, exact-copy source-to-target relations, allowed public source material classes, expected digests, and required anchors inside each copied source body. That check keeps the reader claim tied to actual source internal control files while result records carry only refs, digests, counts, and verdicts.

The result builder merges projection-protocol, landing-policy, work-run, source-module, source-open-body, and secret-exclusion checks into one metadata-only result record set. The board result record records three claimed-path rows, two validation-before-commit mechanics, one metadata-blocked row, one landed-commit row, nine observed negative cases for the first-wave fixture, and zero authority for live Git mutation or launch.

Prior Art Grounding

This component is grounded in provenance and software supply-chain integrity patterns. The W3C PROV family provides a general model for entities, activities, and agents involved in producing an artifact. SLSA brings a similar concern to software builds: source, build process, provenance, and artifact integrity are tracked so consumers can reason about where an artifact came from and how it was produced.

Microcosm borrows that provenance posture for agent work landing: claimed paths, validation refs, commit attempts, HEAD-before/after evidence, blocker capture, Task/work log completion, and seed reentry are separate evidence fields. It does not perform a live Git landing or prove arbitrary commits outside the replay.

Reader Evidence Routing

Read the replay as an evidence-accounting component, not as a live landing controller. The board result record is the primary reader surface: it shows which claimed-path rows carried validation evidence, which rows were blocked by Git-metadata or dirty-tree constraints, and which rows had enough HEAD before/after evidence to use landed language.

Read the source-module manifest as provenance evidence for the imported control plane, not as a permission slip to mutate those source files. The manifest binds the copied bodies by digest and line count so a cold agent can see which mechanics the replay model was checked against.

Read negative cases as the authority floor. Rows that claim live Git mutation, broad checkpoint authority, missing work log completion, uncaptured blockers, launch-scope decision, or non-public paths/body export are supposed to fail. Passing those refusals is part of the positive claim.

Evidence Result records

• receipts/first_wave/durable_agent_work_landing_replay/durable_agent_work_landing_replay_result.json
• receipts/first_wave/durable_agent_work_landing_replay/durable_agent_work_landing_replay_board.json
• receipts/first_wave/durable_agent_work_landing_replay/durable_agent_work_landing_replay_validation_receipt.json
• result records/sign-off/first_wave/durable_agent_work_landing_replay_fixture_acceptance.json

Run the fixture result record refresh from microcosm-substrate with:

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

Run the exported bundle validator without mutating durable result records with:

PYTHONPATH=src python3 -m microcosm_core.organs.durable_agent_work_landing_replay run-work-landing-bundle --input examples/durable_agent_work_landing_replay/exported_work_landing_replay_bundle --out /tmp/durable-agent-work-landing-replay

Named Proof Consumers

• First-wave runtime consumer: microcosm_core.organs.durable_agent_work_landing_replay run consumes the fixture input, writes result, board, validation, and optional sign-off result records, and observes the nine negative cases declared in EXPECTED_NEGATIVE_CASES.
• Exported-bundle consumer: microcosm_core.organs.durable_agent_work_landing_replay run-work-landing-bundle consumes the exported bundle without durable result record mutation, validates the source-module manifest, checks copied source-body digests and anchors, and emits the command card path used by runtime-shell demos.
• Scope limit consumer: standards/std_microcosm_durable_agent_work_landing_replay.json, the component AUTHORITY_CEILING, and the fixture negative cases keep live Git mutation, broad checkpoint authority, unrelated dirty-path staging, live Task/work log mutation, external model access, source-file changes, public sharing, launch, non-public body export, and whole-system correctness outside this module.

Negative Cases

The fixture rejects the nine named negative cases in core/fixture_manifests/durable_agent_work_landing_replay.fixture_manifest.json: missing validation evidence, validation recorded after a commit attempt, missing recorded completion, commit-landed language without a HEAD advance, live Git side-effect authority, missing dirty-tree boundary, uncaptured metadata blockers, overbroad distribution claims, and non-public path/body leakage.

Validation Result record Path

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

Full module

Teleology

work_landing_control_spine makes the source work-landing control plane inspectable inside Microcosm by copying the command, reconcile, mission preflight, and private-index scoped commit source bodies into a public bundle. The point is not to let the public validator mutate Git or ledgers; it is to expose the real internal control mechanics that govern claims, owned paths, same-path conflicts, expected-parent checks, shared-index quarantine, finalizer ordering, and scoped commit discipline.

Purpose

The source repository this slice comes from is edited by several agents at once, so its hardest engineering problem is mundane: how does one agent land a small, finished commit without colliding with another agent's half-done work in the same files, and without claiming more than it actually did? The control plane that answers this lives in a handful of source modules. This module copies those bodies, non-secret, into a public bundle so a reader can inspect the real mechanics rather than take a description on trust.

The single question it answers is narrow: are these copied internal control bodies the genuine ones, with their load-bearing logic still present, and does the bundle keep within its stated limits? It is a witness over copied source, not a runner. It never touches Git, ledgers, or claims.

Two ideas in the copied source are worth a reader's attention. The first is the scoped commit. scoped_commit.py builds a throwaway Git index from the current HEAD, stages only the exact paths or hunks the agent declares it owns, writes a tree from that private index, and commits it against the captured parent with a compare-and-swap on the branch ref. The shared .git/index is never written. What was a three-step behavioural rule (add exact paths, check nothing else is staged, then commit) becomes an infrastructure invariant: an agent physically cannot sweep up a neighbour's dirty changes, because those changes were never in the index it committed from. The second is ordering. work_landing_status.py fixes a sequence of controller actions and a set of prerequisites, so that claims are only released after the work log session is finalised, and convergence is only recomputed after claims are released. The module checks that these anchors are still present in the copied bodies, which is what separates an honest copy from a stale hash bag.

Shape

flowchart LR A["Copied source source bundle 5 internal control bodies + manifest + contract"] --> B["Manifest digest and line-count check is the copy exact?"] B --> C["Required anchor scan is the load-bearing logic still present?"] C --> D["Runtime no-live-mutation contract are all authority flags false?"] D --> E["Secret-exclusion scan any private/account secret material?"] E --> F["Validation result record refs, hashes, counts, findings"] B --> G["Reject stale or missing source body"] C --> G D --> H["Reject authority overclaim"] E --> I["Reject private payload leakage"]

The shape is a public validation spine for copied work-landing internal control source. It validates exact copied module bodies, required anchors, contract flags, and secret-exclusion posture, then writes a result record that contains metadata, hashes, counts, gates, and findings. It does not execute live Git mutation, mutate work log or work log, launch claims, stage broadly, or run private-index commits.

Technical Mechanism

The validator in src/microcosm_core/macro_tools/work_landing_control_spine.py is a staged copied-source witness, not a live work-landing actuator. It loads bundle_manifest.json, source_module_manifest.json, and work_landing_control_runtime_contract.json; then it checks seven required inputs: five copied source source bodies plus the two manifest/contract JSON files. The source body rows must exist under source_modules/, keep the expected SHA-256 digests and line counts from the bundle manifest, stay inside the allowed material classes, and classify source modules as copied_non_secret_macro_body.

After file parity, the validator scans required anchors for each copied source body: work_landing.py must still expose the parser and admission/begin/status anchors; work_landing_status.py must still expose controller action and reconcile/finalizer models; the mission-transaction preflight wrapper and kernel must still expose owned-path, session-id, shared-index quarantine, and private-index admission anchors; and scoped_commit.py must still carry the private-index scoped-commit and shared-index non-mutation anchors. These anchor checks make the copied bundle more than a hash bag: the result record shows that the specific internal control mechanisms readers care about are still present.

The final gates are authority and payload boundaries. The runtime contract must keep every live-mutation flag false, including live Git mutation, work log mutation, work log mutation, claim launch, shared-index mutation, private-index commit execution, broad staging, external model access, public sharing, and launch-scope decision. The secret-exclusion scan runs over the copied source bodies and manifest/contract inputs, while the output result record records refs, hashes, counts, anchor rows, authority rows, and findings with body_in_receipt: false. Focused tests pin the pass case, the live-mutation overclaim blocker, streaming line-count behavior, source-manifest exact-copy checks, and the CLI smoke path.

Public Contract

The public command is:

PYTHONPATH=src ../repo-python -m microcosm_core.cli work-landing-control-spine \
  validate-control-bundle \
  --input examples/work_landing_control_spine/exported_work_landing_control_bundle \
  --out receipts/first_wave/work_landing_control_spine

The validator checks copied module digests, line counts, required source anchors, the no-live-mutation runtime contract, the originating overclaim Work item reference, and a secret-exclusion scan over the copied bundle. Source bodies live in the bundle; result records carry refs, hashes, counts, gates, and findings.

Governing Standard

standards/std_microcosm_work_landing_control_spine.json owns the result record contract, source refs, allowed public inputs, forbidden private inputs, and scope limit for this import.

Source System

The copied source bodies are:

• tools/meta/control/work_landing.py
• system/lib/work_landing_status.py
• tools/meta/control/mission_transaction_preflight.py
• system/lib/mission_transaction_landing_preflight.py
• tools/meta/control/scoped_commit.py

This closes the old work_landing_tool_body_import overclaim by adding an exact copied-source bundle beneath the existing public dry-run refactor.

Governing Doctrine Relations

The generated structured source record reports sixteen bundle-derived edges for this page and zero unresolved selective relations. Its subjects bind the paper module to macro_projection_import_protocol and mechanism.macro_projection_import_protocol.validates_public_macro_projection_imports; its code-locus edges bind the reader page to src/microcosm_core/macro_tools/work_landing_control_spine.py and src/microcosm_core/organs/macro_projection_import_protocol.py. The mechanism claim is therefore narrow: Microcosm validates a public source-projection import bundle by copied-source parity, required anchors, no-live-mutation flags, and secret-exclusion evidence.

The concept edges are concept.work_landing_and_continuity_control_bundle and concept.import_projection_and_drift_control_bundle. The governing principles are P-5, P-10, P-14, P-15, and P-16; the governing axioms are AX-4 and AX-9; and the declared paper-module dependencies are paper_module.macro_projection_import_protocol, paper_module.durable_agent_work_landing_replay, and paper_module.mission_transaction_work_spine. Together these relations explain why the validator treats source-copy fidelity, transaction preflight, private-index containment, and no-launch/no-live-mutation ceilings as one control mechanism rather than as separate prose claims.

Reader Evidence Routing

Read a passing control-bundle result record as "the copied source bodies matched the manifest, required anchors were present, the no-live-mutation scope limit held, and no forbidden private material was found." Do not read it as a live landing operation or a proof that future work sessions are safe.

Read digest and line-count failures as stale-copy evidence only.

Read authority-overclaim failures as launch-boundary evidence. A contract that claims live Git, ledger mutation, claim launch, broad staging, private-index commit execution, external model access, or launch-scope decision must stay blocked.

Named Proof Consumers

• Bundle validator consumer: PYTHONPATH=src ../repo-python -m microcosm_core.cli work-landing-control-spine validate-control-bundle --input examples/work_landing_control_spine/exported_work_landing_control_bundle --out /tmp/microcosm-work-landing-control-spine/result record consumes the copied source bodies, bundle manifest, source-module manifest, runtime contract, anchor scan, scope limit flags, secret-exclusion scan, and metadata-only result record writer.
• Focused regression consumer: PYTHONPATH=src ../repo-python -m pytest -p no:cacheprovider tests/test_work_landing_control_spine.py -q pins the green bundle path, exact-copy source-manifest relation, digest and line-count checks, live-mutation overclaim rejection, result record body omission, streaming line-count behavior, and CLI argument order.
• Corpus consumer: PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus verifies that this Markdown remains consistent with the structured source record and bundle-backed corpus. It is a read-only consistency result record; it is not permission to hand-edit generated projections or shared bundle rows.

Prior Art Grounding

The landing spine is grounded in version-control staging, deterministic workflow history, and provenance-control patterns. Git's index separates selected changes from the rest of a dirty worktree, which is the practical ancestor of scoped path ownership. Temporal workflows show the value of recorded event history and deterministic replay for long-running work. Microcosm imports those ideas as a public control spine: preflight, scoped selection, reconcile/finalize checks, and copied source-body digests make work landing auditable without broad staging, private-index leakage, or live mutation from the paper module itself.

Prior-art anchors:

• Git staging/index workflow: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository
• Temporal workflow event history and replay: https://docs.temporal.io/workflows

Validation Result record Path

Reader-verifiable bundle command, run from microcosm-substrate/:

PYTHONPATH=src ../repo-python -m microcosm_core.cli work-landing-control-spine \
  validate-control-bundle \
  --input examples/work_landing_control_spine/exported_work_landing_control_bundle \
  --out receipts/first_wave/work_landing_control_spine

The command writes the copied-source validation result record under receipts/first_wave/work_landing_control_spine/, including exported_work_landing_control_bundle_validation_result.json. That result record is the public replay boundary for module digests, required source anchors, secret-exclusion posture, and the no-live-mutation runtime contract.

This result record path is reader-verifiable evidence only. It does not flip Mermaid/Atlas status, create bundle authority, run live Git mutation, mutate work log or work log state, execute private-index commits, launch claims, or aggregate doctrine-lattice coverage.

Full module

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

Full module

macro_projection_import_protocol is the source-available membrane for bringing source system into Microcosm. It exists because Microcosm should be dense and alive without becoming a dump of private source bodies, operator context, model-output data, or launch material.

The component validates a projection packet with four public claims:

• source bodies are copied or source-faithfully refactored only when the target file, digest, provenance, validation refs, and metadata-only result record contract verify;
• private material is omitted with explicit omission result records;
• public runtime refs are fixtures, standards, paper modules, exported bundles, copied body targets, and result record refs;
• authority stays capped below launch, public sharing, private-system equivalence, and live source source authority.

Purpose

Microcosm grows by copying real material out of a much larger private codebase. The danger in that move is obvious: a dense public copy is exactly the kind of artefact that quietly carries a secret, an operator conversation, a model-output data, or launch material along with the genuinely useful code. This component exists to answer one question for every copied slice: was this body allowed out, and is the public copy honestly tied to the source it claims to come from?

The answer is an accounting check, not a trust statement. Each copied row declares its source ref, its public target ref, a content digest, and a material class. The protocol sorts that class into one of two sets. Five classes are source bodies (pattern, standard, tool, result record, proof) and may be copied with provenance. Nine classes are forbidden outright (source note, operator thread, model-output data, account secret, secret, recipient packet, launch packet, and the like) and can never appear as an imported body. Anything claiming to be must also carry a verification record naming the digest, the source-to-target relation, and the command or test that consumes the copy.

The unusual part is how the protocol treats a copy whose source has since changed. For an exact-copy row it re-hashes the live source file on disk and compares it against the digest recorded at import time. A mismatch is not reported as a failed import. It is recorded as live source drift: the original copy was still honest, the source has simply moved on, and the row is flagged for the refresh actuator rather than failed. The protocol deliberately separates a dishonest import from a stale one. That keeps the public copy faithful without forcing it to track every upstream edit in lock-step, and it stops a routine upstream change from being mistaken for a broken proof.

What the check does not do is just as load-bearing. A passing scan proves that the named slice omitted the forbidden material classes and kept result record bodies out of the result record. It does not establish the public copy is complete, equivalent to the private root, or ready to launch. The import is evidence about provenance and boundaries, never a launch decision.

Shape

The protocol is the membrane between source source and public Microcosm evidence. It reads projection cells, classifies the requested import, verifies source/target refs and digest relations, applies the secret-exclusion boundary, and emits metadata-only result records that a public reader can replay without gaining live source authority.

Its shape is deliberately two-level:

• fixture and exported-bundle commands validate whole projection packets, negative cases, omitted-material result records, and the intake/status board;
• source-module manifests bind each imported slice to source refs, target refs, digest relation, body-import class, validation refs, and scope limits.

That split keeps the component usable as a source-open body floor while preventing the paper module from becoming a static copy-count ledger. Counts, status totals, and current body-import floors live in result records and runtime status surfaces.

Runtime Shape

Run the fixture:

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

Run the exported bundle:

PYTHONPATH=src python3 -m microcosm_core.organs.macro_projection_import_protocol run-projection-bundle --input examples/macro_projection_import_protocol/exported_projection_import_bundle --out receipts/runtime_shell/demo_project/organs/macro_projection_import_protocol

Preview the next import slice without writing result records:

PYTHONPATH=src python3 -m microcosm_core.organs.macro_projection_import_protocol plan --input examples/macro_projection_import_protocol/exported_projection_import_bundle

The public CLI also exposes the same validator through:

The plan action emits macro_projection_import_intake_preview_v1. It does not write result records. It scores each proposed projection cell before import: source refs, public target refs, validation refs, selected pattern ids, copy policy, scope limit, omitted material, secret-exclusion scan count, verified body-import status, and ready/blocked status.

Exact-copy is a relation, not the whole protocol. Rows declared as exact-copy prove byte-identical source and target digests and may be maintained by the exact-copy refresh actuator. Rows declared as source-faithful public edits or refactors prove the source source digest and the improved public target digest separately, cite the rewrite or symbol mapping, and are maintained by their own validator/test lane. This is the lane for public-safety redaction, dependency trimming, Microcosm-standard compliance, or runnable local cleanup.

It also self-hosts the intake cell state machine. Every projection cell carries projection_status, cell_state, action_required, status reason, landed evidence refs, and a next runtime surface. The board totals those fields as status counts plus an open-actionable count so future passes can distinguish a ready but unlanded cell from a verified public runtime import, self-hosted protocol, or runtime bridge that is already consumed.

microcosm intake is the runtime bridge over that plan. It writes receipts/runtime_shell/intake_bridge/runtime_reveal_import_bridge.json, links the projection cells to the spine and reveal commands, and projects the same statuses into the first-run bridge. Current landed statuses are: public_runtime_import_landed for formal_math_readiness_extensions, self_hosted_status_protocol_landed for projection_protocol_self_host, and runtime_bridge_landed for runtime_reveal_import_bridge. These statuses do not raise authority above public metadata, fixture shape, and result record refs.

microcosm status and microcosm spine also expose the computed macro_body_import_floor. Treat that value as a result record-backed floor, not a stable prose constant: the current authority lives in result records/sign-off/first_wave/macro_projection_import_protocol_fixture_acceptance.json and the first-wave runtime result records under receipts/first_wave/macro_projection_import_protocol/. Cold readers should inspect public_safe_body_import_count, public_safe_body_import_status, projection_status_counts, open_actionable_cell_count, and secret_exclusion_scan there instead of trusting an old markdown count. The floor is still not a launch signal or private-system equivalence claim.

Trace-Bundle Source-Body Import

The trace-bundle slice is the current proof-grade example of a source-body import. Its source-module manifest is examples/macro_projection_import_protocol/exported_projection_import_bundle/trace_capsule_source_module_manifest.json; the projection cell is trace_capsule_prompt_edit_capture_source_modules_import. The cell imports four source source bodies into the bundle:

• tools/meta/observability/cli_prompt_trace.py -> source_modules/tools/meta/observability/cli_prompt_trace.py;
• system/server/tests/test_cli_prompt_trace_capsule.py -> source_modules/system/server/tests/test_cli_prompt_trace_capsule.py;
• tools/agent_trace_structurer/parser.mjs -> source_modules/tools/agent_trace_structurer/parser.mjs;
• tools/agent_trace_structurer/parser.test.mjs -> source_modules/tools/agent_trace_structurer/parser.test.mjs.

The manifest is the body-floor result record for this slice. It records module_count: 4, body_copied: true, body_in_receipt: false, sha256_match: true, line counts, byte counts, required anchors, source refs, target refs, and the shared copied_non_secret_macro_body classification. That means the public bundle carries the source bodies, while runtime result records carry paths, hashes, counts, anchors, and validation refs without duplicating the bodies.

flowchart TD A["Copied material row source ref, target ref, digest, material class"] --> B{"Material class?"} B -- "forbidden class (secret, account secret, source note, operator, provider, launch)" --> R["Reject: forbidden body import"] B -- "class (pattern, standard, tool, result record, proof)" --> C{"Verification record present and target digest bound?"} C -- "no" --> R2["Reject: unverified import"] C -- "yes, exact copy" --> D["Re-hash live source source on disk"] D --> E{"Source digest still matches?"} E -- "yes" --> F["body floor"] E -- "no" --> G["Flag live source drift (honest copy, refresh later)"] G --> F F --> H["Per-slice manifest + metadata-only result record"] H --> I["Reader projection"] H -. does not grant .-> J["live source authority, public sharing, launch, or source-file changes"]

The imported Python side supplies the trace-bundle runtime surface: cli_prompt_trace.py reads selected source files, rejects binary paths, supports line-range and symbol selection, redacts selected excerpt text, and emits numbered source lines with schema metadata. Its companion test module proves terminal validation semantics, repeated prompt interning, source excerpt priority, and completion-report behavior. The imported JavaScript side supplies the Agent Trace Structurer surface: parser.mjs preserves source_text as the exact copied string, treats source_lines and indexes as deterministic navigation projections, and builds lossless attachment clips where exact text is reconstructed from source_segments[].text. parser.test.mjs proves embedded file artifact indexing, Codex trace shape, final-message extraction, AIW thread classification, and bounded export behavior.

This is a mechanism/evidence claim, not a launch claim. The slice proves that these four named, source bodies were imported into the public bundle with manifest-backed digest and anchor checks, and that the parser and trace bundle behavior have public fixture coverage. It does not establish that live provider logs, browser UI state, account or browser state, account secrets, raw operator thread bodies, recipient-send material, or future trace-bundle bodies are or exported.

Those artifacts are the source-open floor. The result record bodies stay metadata-only, and private source note, operator thread content, model-output data bodies, account secrets, account or browser state, and launch or recipient material remain outside the public bundle.

Evidence Binding

The component's current public authority is the accepted component row in core/organ_registry.json plus the sign-off result record result records/sign-off/first_wave/macro_projection_import_protocol_fixture_acceptance.json. The JSON paper-module bundle is core/paper_module_capsules.json#paper_module.macro_projection_import_protocol, and the resolved mechanism row is core/mechanism_sources.json#mechanism.macro_projection_import_protocol.validates_public_macro_projection_imports. The runtime source locus is src/microcosm_core/organs/macro_projection_import_protocol.py, with focused regression coverage in tests/test_macro_projection_import_protocol.py.

The exported bundle does not have a single catch-all source-module manifest. It carries one *_source_module_manifest.json file per imported slice under examples/macro_projection_import_protocol/exported_projection_import_bundle/, plus copied targets under that bundle's source_modules/ tree. That per-slice manifest shape is part of the evidence: it lets each imported route, tool, standard, result record, proof, or runtime body keep its own source ref, target ref, digest relation, validation refs, and scope limit.

The first command for the fixture lane is:

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

Reader Evidence Routing

Use this order when checking the module:

1. Read the JSON bundle and standard to confirm the paper-module binding, scope limit, source-module manifest contract, and result record fields.
2. Run the fixture command to validate projection cells and negative cases against temporary result records.
3. Run the exported-bundle command to validate the public bundle and copied source-module surfaces.
4. Inspect the source-module manifests for exact-copy versus source-faithful edit relations before deciding which refresh lane applies.
5. Run the focused regression and paper-module corpus checks before landing a markdown or manifest update.

If a manifest is dry but a bundle-level validator still fails, check whether a bundle manifest carries its own expected digest or line-count rows. Do not infer that all companion manifest surfaces were refreshed just because an exact-copy source-module dry run is clean.

Prior Art Grounding

The import membrane follows established provenance and software-supply-chain patterns: copied or refactored artifacts need source refs, target refs, digests, validation refs, omission records, and a claim boundary. The closest public anchors are W3C PROV for describing entity/activity/agent provenance, the SLSA specification for artifact integrity and provenance in software supply chains, and in-toto for linking supply-chain steps through signed metadata.

Microcosm applies those patterns to a public/private projection boundary rather than to launch attestation. The per-slice source-module manifests, secret-exclusion scans, metadata-only result records, and omission result records are inspired by that provenance lineage, but they remain a local validator contract for public Microcosm fixtures and exported bundles.

Negative Cases

The validator intentionally rejects:

• private body import requests;
• omitted source material without omission result record refs;
• authority upgrades into live source source authority;
• projection cells without validation refs;
• launch, public sharing, recipient-work, or secret-export claims.

Validation Result record Path

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

These checks validate projection cells, per-slice manifests, omitted-material result records, and metadata-only result record policy only. A diagram view is generated for this module and an atlas card is linked. The checks do not authorize live source source authority, secret export, launch, public sharing, source-file changes, provider or Lean/Lake execution, or whole-system correctness.

Re-enter this module when a new projection cell lands, a source-module manifest is refreshed, or a result record count changes. The repair route is to rerun the component validator, refresh the first-wave and sign-off result records, and update the standard or paper module only where the result record contract changed. Do not raise the scope limit from documentation edits.

Full module

Purpose

This component exists because the riskiest moment in agentic code work is the one that feels safest: the agent runs a few checks, sees no errors, and concludes that its work is finished and committed. Those are different facts. A clean preflight describes the state of the checks. It says nothing about whether a competing claim already owns the same path, whether the branch has moved under the agent, or whether the commit ever actually landed. The single question this module answers is narrow and concrete: what evidence has to hold before a unit of work is allowed to land, and is that evidence checkable rather than asserted?

The interesting design choice is that the module refuses to trust its own declared verdicts. Most fixtures pass when their inputs carry the right labels. It then perturbs the input one field at a time: a same-path claim conflict, a stale expected-parent hash, a checkpoint lane mutated into an unauthorised broad commit. A genuine check has to break under each of those and stay clear under harmless ones, such as a claim on an unrelated path. That asymmetry, not the bare pass, is the claim.

The result is deliberately bounded. A pass means the public fixture, the exported source bodies, and the negative cases together preserve the work-landing contract and that its discriminating tests still discriminate. It does not touch the live work log, the live work log, or Git, and it grants no authority to commit, checkpoint broadly, back up, or launch.

Abstract

mission_transaction_work_spine is the public Microcosm paper module for work-landing discipline. Its telos is to make the boundary between "a check looked clean" and "work is actually allowed to land" inspectable as source, fixture, result record, and test evidence rather than as chat confidence or status arithmetic.

The component validates a fixed public mission-transaction bundle: Work item rows, work log path claims, dependency unlocks, transaction plans, result record drains, completion projections, scoped mutation policy, checkpoint-lane decisions, copied internal control source modules, and metadata-only result records.

The result is intentionally narrow. A pass means the public fixture and exported bundle preserve the mission-transaction contract, its source-open body floor, and its negative cases. It does not mutate work log, work log, or Git; it does not certify arbitrary live completion; and it does not grant broad checkpoint, backup, launch, public sharing, provider, or whole-system authority.

Problem

Agentic code work fails most often at transaction boundaries, not at isolated syntax checks. Common false positives include:

• treating a clean preflight as a landed commit;
• ignoring a competing work log claim on the same path;
• accepting a claim whose expected parent no longer matches the repository;
• marking a downstream Work item ready without hard-dependency evidence;
• reading a dirty tree as a blocker for scoped commits while allowing broad staging without explicit operator authorization;
• writing result records that smuggle private ledger or provider bodies into a public artifact.

The module turns those failures into a deterministic replay. A cold reader can inspect which public rows are projections, which copied source bodies implement the checks, which negative cases must be observed, and which authority claims remain forbidden even when every validator passes.

Shape

flowchart TD Bundle["JSON bundle paper_module.mission_transaction_work_spine"] Fixture["First-wave fixture Work items, claims, deps, lanes, result records"] Bundle["Exported bundle work log, work log, checkpoint, scoped commit, preflight source bodies"] Snapshot["Real work log session snapshot active claims, heartbeat, source hash"] Runtime["Component runtime mission_transaction_work_spine.py"] R3["R3 replay verdict runtime-derived, not label-derived"] Result records["metadata-only result records refs, hashes, counts, limits"] Ceiling["Scope limit no live ledger, git, launch, or provider authority"] Bundle --> Runtime Fixture --> Runtime Bundle --> Runtime Snapshot --> Runtime Runtime --> R3 Runtime --> Result records R3 --> Ceiling Result records --> Ceiling

This Mermaid diagram is the reader flow. The generated lattice Mermaid remains available_from_capsule_edges, and the generated Atlas card remains linked_from_capsule_edges; both are derived from bundle and doctrine-lattice rows, not from this prose.

Technical Mechanism

The component exposes two validator paths.

The first-wave fixture command validates the local replay fixture and writes the canonical result record set:

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

That path loads public fixture rows, validates dependency unlocks, claim preflight, scoped result record authority, private-marker rejection, preflight overclaim rejection, checkpoint lane policy, and the real active-claims snapshot.

The exported-bundle command validates source-open import and bundle replay:

PYTHONPATH=src python3 -m microcosm_core.organs.mission_transaction_work_spine \
  validate-mission-transaction-bundle \
  --input examples/mission_transaction_work_spine/exported_mission_transaction_bundle \
  --out receipts/first_wave/mission_transaction_work_spine

That path checks copied work log, work log, checkpoint, scoped-commit, and mission-preflight source modules by manifest, digest, anchor strings, secret-exclusion scan, and body_in_receipt: false. It also requires the real work log snapshot in the mission bundle. Commit da97bc6394 (Require real work log snapshot in mission bundle) landed the snapshot as a required bundle input; later source/test commits recomputed the snapshot verdict and bound the R3 claim to runtime evidence.

Prior Art Grounding

This component is the mission-transaction member of Microcosm's local work-landing family. Its closest sibling is durable_agent_work_landing_replay, which checks recorded landing rows, validation-before-commit ordering, HEAD movement, blocker capture, and work log completion evidence without performing live Git work. mission_transaction_work_spine narrows that pattern to the transaction preflight and work log seed-speed membrane: same-path claim conflicts, expected-parent mismatches, checkpoint-lane selection, dependency unlocks, result record drains, and session finalization posture.

It also supplies a source-import anchor used by adjacent public components such as concurrency_mission_control and macro_projection_import_protocol. Those links are structural evidence routes, not runtime invocation or launch-scope decision. The prior-art claim is therefore local and source-bounded: this paper module inherits the work-landing accounting shape, then tests the particular mission-transaction and work log session-snapshot boundary.

Data And Evidence Contract

The public evidence bundle is composed of source refs, hashes, rows, and result records. The source bodies live only in the exported bundle's source_modules/ tree; result records carry refs, counts, hashes, verdicts, and ceilings, not private or live internal control bodies.

• JSON bundle: core/paper_module_capsules.json::paper_modules[20:paper_module.mission_transaction_work_spine]
• Runtime locus: src/microcosm_core/organs/mission_transaction_work_spine.py
• Fixture input: fixtures/first_wave/mission_transaction_work_spine/input
• Exported bundle: examples/mission_transaction_work_spine/exported_mission_transaction_bundle
• Real snapshot: examples/mission_transaction_work_spine/exported_mission_transaction_bundle/real_work_ledger_active_claims_snapshot.json
• Fixture manifest: core/fixture_manifests/mission_transaction_work_spine.fixture_manifest.json
• Mechanism row: mechanism.mission_transaction_work_spine.validates_public_mission_transaction_bundle
• Standard: standards/std_microcosm_mission_transaction_work_spine.json

The result record floor includes preflight, dependency blocked, work landing attempt, claim preflight, scoped mutation, checkpoint lane, completion projection, dependency unlock scheduler, reconcile plan, and exported-bundle validation result records. The fields must preserve schema and component ids, validator id, command, status, observed and missing negative cases, error codes, scope boundary, secret-exclusion status, public work-landing status, body-import status, body_in_receipt: false, scope limit, and result record paths.

Discriminating Tests

The positive claim is not "the fixture passes." The positive claim is that the fixture accepts real-good evidence and rejects targeted perturbations.

• Real-good case: the real active-claims snapshot passes with R3 public_safe_real_work_ledger_session_snapshot_replay, a state/work_ledger/active_claims_snapshot.json source ref, a matching source hash, a bound session heartbeat, and five source-session claims.
• Same-path perturbation: adding a competing claim on the requested path blocks preflight through work_ledger_runtime.active_claim_collisions_for_paths and emits SAME_PATH_CLAIM_CONFLICT.
• Parent perturbation: changing the expected parent for a real claim blocks with EXPECTED_PARENT_MISMATCH; changing it back to the current parent clears.
• Disjoint perturbation: adding a claim on a disjoint path does not create a collision for the requested path, so the public preflight remains pass.
• Landing-row perturbation: mutating the checkpoint lane into an unauthorized broad checkpoint blocks with the checkpoint-lane violation floor.
• Private-body perturbation: a fixture row that carries live private work log body material is rejected, while source bodies copied into the public bundle remain outside result records.
• Overclaim perturbation: a clean preflight cannot claim that work is already landed.
• Dependency perturbations: dangling dependency refs and ready rows with incomplete hard dependencies remain blockers.

Focused regression coverage lives in tests/test_mission_transaction_work_spine.py. The R3 tests assert that the verdict is re-derived from runtime evidence, expected labels are not sufficient, source hashes are bound, mutated or stale snapshots are rejected, clear perturbations move the verdict, and body_in_receipt is false.

Reader Evidence Routing

Read this module as an evidence-accounting paper, not as a live controller.

1. Open the mechanism row and standard to see the required bundle fields: work items, claim table, dependency graph, transaction plan, result record drain, completion projection, scoped mutation policy, checkpoint lane policy, copied source imports, body import verification, scope boundary, and scope limit.
2. Inspect the real active-claims snapshot to see the source ref, source hash, snapshot time, source session id, owned paths, checkpoint lane case, runtime session, and metadata-only posture.
3. Read the focused tests to verify R3 is runtime-derived: same-path conflicts, stale parents, landing-row violations, disjoint paths, and equal-parent mutations are all discriminated.
4. Treat generated JSON, generated Mermaid, Atlas, public-site docs, and result records as projections or validator outputs.

Limits And Non-Claims

The module's useful claim is compact: public fixture rows, copied control source bodies, a real work log session snapshot replay, discriminating negative cases, metadata-only result records, and focused tests preserve the mission-transaction work spine at R3.

It may not claim live work log authority, live work log authority, live Git mutation, broad checkpoint authorization, private backup execution, current repository completion, source-file changes, provider behavior, browser UI state, launch-scope decision, publishing-scope decision, hosted-product readiness, or whole-system correctness.

Validation Result record Path

For this Markdown-only paper-module update, use non-mutating checks from repo root:

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

For a source, bundle, or projection landing, run the owner lane from microcosm-substrate:

PYTHONPATH=src python3 scripts/build_doctrine_projection.py --check-paper-module-corpus
PYTHONPATH=src python3 scripts/build_doctrine_projection.py --check

Do not run --write from this Markdown-only lane.

Full module

Teleology

formal_math_readiness_gate is the public runtime cell that turns the formal math slice from a deferred slogan into an executable boundary. It validates synthetic readiness metadata for corpus availability, tactic probes, premise indexes, target-shape routing, and provider context recipes before any future Lean witness can claim authority.

The page should let a cold reader answer one question without rereading the component: what evidence has Microcosm actually validated, and where does that evidence stop?

Purpose

Formal-math tooling fails quietly when a library, tactic, or corpus is assumed present rather than checked. A pipeline that routes a proof to aesop when aesop is not actually available, or that treats a premise index as proof evidence because it happens to carry a proof body, has already lost the boundary between "ready to attempt" and "proven". This component exists to make that boundary explicit before any downstream proof work begins. It answers one question: which declared formal-math inputs are well-formed and honest enough that a later proof witness could safely consume them, and where exactly does that warrant stop?

The mechanism is a deterministic reducer over five public JSON inputs: corpus readiness, tactic-portfolio availability, a premise index, target-shape routing, and provider context recipes. It does not run Lean or Lake. Instead it reads what those inputs declare and refuses the specific ways they can lie. A corpus that claims Mathlib is available without a passing probe is rejected. A tactic marked available without a probe result record is rejected. A premise row carrying a proof_body or oracle_needed_premise_ids field is rejected. A route that admits a tactic the portfolio probe already marked unavailable is rejected. The output is a readiness board, not theorem evidence.

The design choice worth noticing is that the gate proves its own discipline through negative cases. Alongside the positive inputs, the fixture carries five inputs that each commit a known overclaim, and the run passes only when every one of those overclaims is caught and no unexpected finding appears. The gate is therefore not merely asserting "we check Mathlib availability"; it is demonstrating, on each run, that a falsified Mathlib claim is actually refused. A second guard keeps the floor source-open without leaking: copied prover probe bodies are verified by digest through a manifest, while proof bodies, model-output data, and private state stay out of the result records entirely.

Shape

flowchart TD Inputs["Five public JSON inputs corpus, tactics, premises, routes, provider recipes"] Scan["Secret-exclusion scan zero blocking hits required"] Corpus["validate_corpus_readiness reject Mathlib-availability overclaim"] Tactics["validate_tactic_portfolio each available tactic needs a probe result record"] Premises["validate_premise_index reject proof_body / oracle premise ids"] Routing["validate_target_shape_routing reject route admitting an unavailable tactic"] Provider["validate_provider_context_recipes reject over-budget or proof-body recipe"] SourceFloor["validate_source_module_imports copied probe bodies, digest-checked"] Reconcile["Reconcile findings vs EXPECTED_NEGATIVE_CASES every known overclaim must be caught"] Board["Readiness board + extension board available / blocked capabilities, counts"] Ceiling["Scope limit no Lean/Lake, proof, provider, launch, or private-system authority"] Inputs --> Scan Scan --> Corpus Scan --> Tactics Scan --> Premises Scan --> Provider Tactics -->|unavailable tactic ids| Routing Corpus --> Reconcile Tactics --> Reconcile Premises --> Reconcile Routing --> Reconcile Provider --> Reconcile SourceFloor --> Reconcile Reconcile --> Board Board --> Ceiling

The machine graph remains the generated paper_module.formal_math_readiness_gate.mermaid projection derived from the source record, not from this hand-authored Mermaid block.

Reader Evidence Routing

Read this module in evidence order:

1. Start at core/paper_module_capsules.json::paper_modules[21:paper_module.formal_math_readiness_gate]. That row names the source authority, subjects, mechanism refs, code locus, Microcosm concept/principle/axiom refs, generated projection statuses, and the bundle scope limit.
2. Check the generated structured source record paper_modules/formal_math_readiness_gate.json. Its relationships.edges cite the bundle source refs and show the generated Mermaid status, Atlas status, source_authority: json_capsule, and unresolved selective-relation count.
3. Inspect the runtime locus src/microcosm_core/organs/formal_math_readiness_gate.py, especially run, run_readiness_bundle, validate_source_module_imports, write_receipts, EXPECTED_NEGATIVE_CASES, AUTHORITY_CEILING, and SOURCE_MODULE_MANIFEST_NAME.
4. Use fixture evidence for the gate behavior: fixtures/first_wave/formal_math_readiness_gate/input, receipts/first_wave/formal_math_readiness_gate/readiness_gate_result.json, formal_math_readiness_board.json, formal_math_readiness_extension_board.json, formal_math_readiness_validation_receipt.json, and result records/sign-off/first_wave/formal_math_readiness_gate_fixture_acceptance.json.
5. Use exported-bundle evidence for source-open body-floor claims: examples/formal_math_readiness_gate/exported_formal_math_readiness_bundle/source_module_manifest.json, bundle_manifest.json, source_artifacts/, source_body_floor/source_modules/, and receipts/runtime_shell/demo_project/organs/formal_math_readiness_gate/exported_formal_math_readiness_bundle_validation_result.json.
6. Use tests/test_formal_math_readiness_gate.py for the behavioral result record boundary. The tests cover negative cases, exported bundle sign-off, source-module digest and target-ref mismatch rejection, bounded command-card output, source-body omission from result records, secret-exclusion/public-relative result record paths, and non-writing plan preview.

Do not route a proof claim through this page. It routes readiness evidence, result record integrity, and source-body-floor accounting only.

Technical Mechanism

The runtime is a deterministic readiness reducer over declared public inputs. run() evaluates the first-wave fixture directory with positive and negative JSON cases enabled; run_readiness_bundle() evaluates the exported public bundle without fixture-negative cases and requires the bundle source-module manifest. Both entrypoints call _build_result(), so the fixture and exported bundle result records share one scope limit, one secret scan, one source-module digest checker, and one readiness-board schema.

_build_result() first loads the five public input families: corpus_readiness.json, tactic_portfolio_availability.json, premise_index.json, target_shape_tactic_routing.json, and provider_context_recipes.json. It then scans those inputs plus any declared source artifacts through secret_exclusion_scan.scan_paths, using the public Microcosm forbidden-class policy. The scan is not advisory: the result can pass only when the scan has zero blocking hits, source-module imports pass, all expected fixture-negative cases are observed, and no unexpected positive-case findings remain.

The mechanism is split into six validators:

• validate_corpus_readiness() records Lean and Mathlib readiness metadata and adds lean_std_synthetic_core:mathlib to blocked capabilities when Mathlib is unavailable. A Mathlib availability claim without a passing probe becomes MATHLIB_AVAILABILITY_OVERCLAIM.
• validate_tactic_portfolio() separates available from unavailable tactics and requires every available tactic to carry a probe result record. Synthetic probe labels are accepted only when _tactic_probe_realness_evidence() binds them to copied source modules or fixture-manifest source-open evidence.
• validate_premise_index() admits premise rows as metadata only. It counts premises, namespaces, retrieval terms, and split eligibility, but rejects proof_body, ground_truth_proof, provider_output_body, and oracle_needed_premise_ids.
• validate_target_shape_routing() intersects each route case's allowed tactics with the unavailable tactics emitted by the portfolio validator. Any overlap becomes ROUTING_ALLOWS_UNAVAILABLE_TACTIC, so routing cannot silently re-enable a tactic that the probe plane blocked.
• validate_provider_context_recipes() records byte budgets and deliverable shape while rejecting public recipes over 32,768 bytes or recipes that allow proof bodies or provider-body material.
• validate_source_module_imports() verifies the exported bundle's source_module_manifest.json, target refs, source refs, line counts, target digests, source digests, exact-copy rows, and the two permitted private-path rewrites. It reports digest/ref failures without placing copied source bodies in result records.

After the validators run, _merge_observed() and _merge_findings() compare observed fixture failures against EXPECTED_NEGATIVE_CASES. This is the local scope limit: the fixture run must prove that the known overclaims are caught, while the exported-bundle run must prove that the positive public bundle has no unexpected findings. _build_extension_board() then projects the accepted metadata into the extension board: selected pattern ids, namespace and split counts, tactic availability counts, Mathlib-dependent unavailable tactics, blocked route cases, provider budgets, source-body import counts, the scope limit, and the scope boundary.

Result record writing preserves the same boundary. write_receipts() emits the gate result, readiness board, extension board, validation result record, and sign-off result record for fixture mode. run_readiness_bundle() emits the exported-bundle result record. The focused test suite asserts the mechanism rather than just file existence: it checks the five expected negative case ids, local Lean/Lake probe metadata with Mathlib unavailable, six available tactics with aesop blocked, eleven premises, five route cases, three provider recipes, thirteen verified source artifacts, source/target digest mismatch rejection, target-ref mismatch rejection, secret-exclusion/public-relative result record paths, and result record omission of copied body text.

Public Contract

The component does not run Lean or Lake. It consumes public JSON fixtures and exported bundles, records which capabilities are available or blocked, rejects Mathlib availability overclaims, rejects unprobed tactics, rejects premise rows that contain proof bodies, rejects routes that admit unavailable tactics, and rejects provider recipes that exceed the public budget or allow proof bodies.

The accepted result is a readiness board. That board can tell a later component what is safe to attempt, but it is bounded evidence evidence, benchmark evidence, or permission to execute a theorem prover.

Prior Art Grounding

This component is grounded in formal-math benchmark and environment-readiness work where the presence of a library, tactic, or corpus is not enough by itself. miniF2F motivates explicit benchmark split discipline for formal mathematics, LeanDojo motivates reproducible theorem-proving environments, and mathlib makes the availability of library imports a concrete precondition rather than a vague capability claim.

Microcosm borrows the readiness-gate pattern: corpus availability, Mathlib probes, tactic probes, premise indexes, target-shape routing, and context budgets must be checked before downstream proof or retrieval language is allowed. It excludes Lean execution or proof authority.

Runtime Surfaces

• python -m microcosm_core.organs.formal_math_readiness_gate run --input fixtures/first_wave/formal_math_readiness_gate/input --out receipts/first_wave/formal_math_readiness_gate
• python -m microcosm_core.organs.formal_math_readiness_gate run-readiness-bundle --input examples/formal_math_readiness_gate/exported_formal_math_readiness_bundle --out receipts/runtime_shell/demo_project/organs/formal_math_readiness_gate
• python -m microcosm_core.organs.formal_math_readiness_gate plan --input fixtures/first_wave/formal_math_readiness_gate/input
• microcosm formal-math-readiness-gate run --input fixtures/first_wave/formal_math_readiness_gate/input --out receipts/first_wave/formal_math_readiness_gate
• microcosm formal-math-readiness-gate plan --input fixtures/first_wave/formal_math_readiness_gate/input

Relationship To Lean Witness

formal_math_lean_proof_witness remains deferred. This gate makes the deferral typed and testable: Mathlib is absent until a passing probe says otherwise, unavailable tactics cannot be routed, premise indexes cannot carry proof or oracle bodies, and provider recipes cannot smuggle proof-body deliverables.

Validation Result record Path

./repo-pytest tests/test_formal_math_readiness_gate.py -q --basetemp=/tmp/microcosm_formal_math_readiness_gate_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus
jq '{edge_count:(.relationships.edges|length), mermaid_status:.paper_module_payload.generated_projections.mermaid.status, atlas_status:.paper_module_payload.generated_projections.atlas_card.status, source_authority:.relationships.source_authority, unresolved_selective_relation_count:(.relationships.unpopulated_selective_relations|length)}' paper_modules/formal_math_readiness_gate.json

Expected generated-row proof: edge_count: 15, mermaid_status: available_from_capsule_edges, atlas_status: blocked_until_organ_atlas_owner_lane_binds_edges, source_authority: json_capsule, and unresolved_selective_relation_count: 0.

Full module

Purpose

This component exists to make one claim checkable instead of asserted: that Microcosm can actually run the Lean toolchain, not merely talk about it. The single question it answers is whether the installed Lean toolchain will compile a declared, tiny synthetic Lean project end to end, and whether that run can be recorded without leaking the proof.

The unusual part is the discipline around the run, not the run itself. The component copies a bounded public Lake project into a temporary workspace and invokes lake build, but the result record keeps only the return code, the standard-output and standard-error line counts, the source hashes, and the declaration names pulled out by a regular expression. The proof text and the raw command output never reach the result record. A reader gets evidence that the build happened and what it contained, without the page becoming a copy of the proof.

Two failure modes drive the design. The first is a proof-assistant integration that reports success without ever running the checker; the witness guards against that by executing a real subprocess and recording its exit status, and by deliberately compiling an invalid Lean file in a negative case to confirm the toolchain rejects it. The second is a circular pass, where the manifest quietly carries the answer. The component refuses manifests that embed a proof_body, a ground-truth proof, provider output, or oracle premise ids, so a green result cannot be smuggled in through the inputs.

The scope is small on purpose. Imports of Mathlib, Aesop, and Batteries are rejected before anything runs, so this is a witness for a toy theorem under a local toolchain, not a claim about library-dependent proof work. That boundary is the point: it shows the result record discipline a larger formal-math component would need, without borrowing authority it has not earned.

Teleology

formal_math_lean_proof_witness is the bounded public crossing from formal-math readiness into an actual local Lean/Lake run. It exists so a cold reader can see Microcosm compile a tiny synthetic proof witness with the installed toolchain while the result records stay redacted, public-relative, and honest about the narrow authority boundary.

Shape

flowchart TD A["First-wave fixture fixtures/first_wave/.../input"] --> B["run() include_negative=true"] C["Exported public bundle examples/.../exported_lean_proof_witness_bundle"] --> D["run_witness_bundle() include_negative=false"] B --> E["Validate witness manifest: reject embedded proof bodies, oracle ids, non-public source refs"] D --> F["Validate source_module_manifest.json: copied public source digests, exact-copy vs replacement"] E --> G["Copy Lake project to temp workspace lake build MicrocosmProofWitness"] G --> H["Negative cases run real Lean: invalid proof rejected, Mathlib/Aesop/Batteries import blocked"] F --> I["Standalone exported-witness contract or fresh bundle result record reuse (no live build)"] G --> J["metadata-only JSON result records: return code, line counts, hashes, declaration names"] H --> J I --> J J --> K["Scope limit: toy public witness only"]

Reader Evidence Routing

Route bundle/currentness questions through ## JSON Bundle Binding, the source record, and the structured source record. The expected generated-row evidence is source_authority: json_capsule, edge_count: 8, Mermaid available_from_capsule_edges, Atlas blocked_until_organ_atlas_owner_lane_binds_edges, and zero unresolved selective relations. That evidence proves reader wiring and source authority placement, not formal-result correctness.

Route runtime questions through the runtime locus and the two public input surfaces. The first-wave fixture runs run() against the public Lake project and checks the four expected negative cases. The exported bundle runs run_witness_bundle() against copied public source modules, validates source_module_manifest.json, and records digest/source-module status without placing proof bodies in JSON result records.

Route result record and test questions through the required result record paths, the focused pytest, and the corpus check. The focused test asserts local Lake build success for the tiny witness when Lean/Lake are available, eight compiled declarations, four negative-case observations for the fixture, public-relative redacted result records, five exported source-module rows, source digest checks, metadata-only result record policy, and tamper-blocking behavior. Those validation result records do not authorize Mathlib-dependent proofs, external model access, private proof import, benchmark claims, launch-scope decision, deployment posture, public sharing, hosted deployment, source-file changes, or private-system equivalence.

Public Contract

The component copies examples/formal_math_lean_proof_witness/exported_lean_proof_witness_bundle or the first-wave fixture Lake project into a temporary workspace and runs lake build. The public result record records tool availability, Lake build status, source hashes, declaration names, line counts, negative-case coverage, and the scope limit. It does not export proof bodies in JSON result records.

The accepted witness scope is deliberately small:

• public synthetic Lean source is allowed;
• JSON manifests and result records may not embed proof bodies;
• Mathlib, Aesop, and Batteries imports are rejected until a wider scope limit exists;
• non-public source refs, model-output data, oracle proofs, and private source run bodies remain outside the public root.

Prior Art Grounding

This component is grounded in the Lean proof-assistant lineage and the broader small-kernel theorem-proving tradition. The Lean theorem prover system description anchors the local Lean/Lake witness route, and the Lean mathematical library shows why proof authority depends on explicit imports, declarations, and checked environments.

Microcosm borrows the proof-witness discipline: a local toolchain run, source hashes, declarations, negative cases, and metadata-only result records must be visible before Lean witness language is allowed. It does not claim Mathlib-dependent proof authority or benchmark performance.

Validation Result record Path

./repo-pytest tests/test_formal_math_lean_proof_witness.py -q --basetemp=/tmp/microcosm_formal_math_lean_proof_witness_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus
jq '{edge_count:(.relationships.edges|length), mermaid_status:.paper_module_payload.generated_projections.mermaid.status, atlas_status:.paper_module_payload.generated_projections.atlas_card.status, source_authority:.relationships.source_authority, unresolved_selective_relation_count:(.relationships.unpopulated_selective_relations|length)}' paper_modules/formal_math_lean_proof_witness.json

Expected generated-row proof: edge_count: 8, mermaid_status: available_from_capsule_edges, atlas_status: blocked_until_organ_atlas_owner_lane_binds_edges, source_authority: json_capsule, and unresolved_selective_relation_count: 0.

Full module

formal_math_verifier_trace_repair_loop is the source-available replay of a source proof-lab pattern over copied Ring2 run system: verifier feedback becomes a teaching signal only after a trace grade, a repair action, a failure-mode ledger append, a curriculum delta, and a cold rerun result record.

It is deliberately not a Lean/Lake proof component. It sits between the existing readiness, premise retrieval, tactic routing, proof diagnostic, and Lean witness surfaces so a cold reader can inspect real failure taxonomy, graph-update candidates, and oracle-repair contrast rows without seeing proof bodies, oracle premise ids, model-output data bodies, or private run logs.

Purpose

A failed proof attempt is cheap to throw away and expensive to learn from. The question this component answers is narrow: can a verifier's failure be turned into a reusable repair signal, on the public side, without that signal quietly inheriting the authority of a real theorem prover? It exists because the interesting work in a proof-repair loop is the bookkeeping, not the proving, and that bookkeeping is where overclaim usually creeps in.

The design choice worth noticing is that the loop refuses to collapse its stages into a single verdict. A verifier failure only counts as a teaching signal once it carries a trace grade backed by trace events, a repair action named against the verifier failure class it responds to, a failure-mode ledger append, a curriculum delta, and a cold-rerun result record. Each of those is a separate field, and promotion is blocked until the cold-rerun result record is present. The same separation keeps the dangerous material out: proof bodies, oracle-needed premise ids, and model-output data bodies are forbidden keys, so a row may name a failure class without ever exposing the proof or the oracle answer that produced it.

The failure mode it guards against is stale copied rows pretending to be live proof-lab evidence. The repair rows here are imported from a real Ring2 benchmark run, so the temptation is to treat the copy as if the run were happening now. The realness gate is the answer: it only reaches its top rung when every verifier attempt and curriculum row replays cleanly against the imported source bodies, and the focused tests deliberately perturb an oracle row, a manifest digest, an attempt label, and a curriculum count so that any drift downgrades the verdict rather than passing quietly. A single deterministic toy-theorem rerun is the one thing actually executed here, and it is plain arithmetic over public inputs, not a Lean proof.

Shape

flowchart TD Input["Fixture input or exported bundle copied Ring2 rows + source-module manifest"] Protocol["Projection protocol copied-material provenance"] Manifest["Source-module manifest digest, line and byte match, body_in_receipt false"] Secret["Secret-exclusion scan proof bodies, oracle ids, model-output data forbidden"] Attempts["Verifier-attempt replay grade needs trace events, repair needs failure class"] Curriculum["Repair-curriculum replay failure-mode ledger, curriculum deltas"] Promotion["Promotion policy requires cold-rerun result record"] Toy["Deterministic toy rerun fail then repair over public inputs"] Realness["Realness gate clean source replay -> top rung; any drift downgrades"] Result records["metadata-only result records result, board, validation, sign-off"] Ceiling["Scope limit repair-loop accounting, bounded evidence"] Input --> Protocol Protocol --> Manifest Manifest --> Secret Secret --> Attempts Attempts --> Curriculum Curriculum --> Promotion Promotion --> Toy Attempts --> Realness Curriculum --> Realness Toy --> Realness Realness --> Result records Result records --> Ceiling

Technical Mechanism

The named mechanism mechanism.formal_math_verifier_trace_repair_loop.validates_public_verifier_trace_repair_bundle is a staged public verifier-repair validator, not a proof executor. _build_result composes five checks over the fixture or exported bundle: projection-protocol density, copied source-module manifest integrity, verifier attempt replay, repair-curriculum replay, promotion policy, and one deterministic toy-theorem repair rerun. The result is pass only when the projection protocol has copied-material provenance, the secret scan has no blocking hits, source modules pass when required, verifier attempts and curriculum rows replay against their imported Ring2 source bodies, promotion requires a cold rerun reference, and the toy rerun succeeds.

The exported-bundle path is intentionally stricter than the fixture path. validate_source_module_manifest requires a source import class, body_in_receipt: false, one row for each declared Ring2 source ref, matching target digests, line counts, and byte counts, and a metadata-only source_open_body_imports summary. _validate_attempt_source_replay then dereferences the premise-run row, oracle-repair contrast row, and graph-update candidate for each verifier attempt. Mismatches become typed findings such as VERIFIER_TRACE_SOURCE_REPLAY_MISMATCH, VERIFIER_TRACE_ORACLE_REPLAY_MISMATCH, VERIFIER_TRACE_COLD_RERUN_SOURCE_MISMATCH, or VERIFIER_TRACE_CANDIDATE_REPLAY_MISMATCH; curriculum-source mismatches are checked separately by validate_repair_curriculum.

The realness gate is also mechanical. _runtime_realness_evidence reaches the R4 state only for an exported bundle with verified source modules, at least 30 source replay checks, zero source replay mismatches, at least three attempts, at least nine trace events, at least three failure modes, and a passing toy rerun. The focused tests deliberately perturb the oracle source row, a manifest digest, a verifier-attempt source label, and a curriculum source count; each mutation blocks the verdict or downgrades the realness evidence instead of letting stale copied rows masquerade as proof-lab evidence.

The proof consumer is tests/test_formal_math_verifier_trace_repair_loop.py: it asserts five attempts, 15 trace events, five repair actions, three cold-rerun promotions, three toy-theorem failures repaired into four passing rerun inputs, seven exported source modules, 37 source replay checks, compact-card omission and fresh-result record reuse, public-relative result record paths, no private/body fields in result records, and exact source module copies. Those checks consume the same fixture, bundle, source-module manifest, and mechanism row cited by this page, so the evidence is executable replay accounting rather than a prose-only description.

The governing lattice is deliberately narrow: the bundle binds the module to concept.formal_math_and_proof_witness_bundle, principles P-1, P-2, P-3, P-6, and P-8, axioms AX-1, AX-2, AX-5, and AX-7, and dependency modules for the Lean standard premise index, tactic portfolio availability, target-shape tactic routing, and formal-math premise retrieval. The standard allows only copied Ring2 verifier-trace repair result record schemas and metadata-only public fields. It does not widen a passing replay into Lean/Lake authority, formal-result correctness, proof-body evidence, oracle premise authority, provider authority, human-approval proof authority, publishing-scope decision, launch-scope decision, or whole-system correctness.

Evidence/accounting:

• Bundle authority: core/paper_module_capsules.json::paper_modules[23:paper_module.formal_math_verifier_trace_repair_loop] sets source_authority: json_capsule, binds the component, binds mechanism.formal_math_verifier_trace_repair_loop.validates_public_verifier_trace_repair_bundle, and resolves src/microcosm_core/organs/formal_math_verifier_trace_repair_loop.py.
• Generated instance: paper_modules/formal_math_verifier_trace_repair_loop.json reports paper_module_payload.source_authority: json_capsule, Mermaid available_from_capsule_edges, Atlas linked_from_capsule_edges, 17 relationship edges, and resolved paper_module.depends_on.paper_module edges to the Lean standard premise index, tactic portfolio, target-shape routing, and formal-math premise retrieval modules named by the active standard.
• Runtime, fixture, and bundle: src/microcosm_core/organs/formal_math_verifier_trace_repair_loop.py exposes run, run_loop_bundle, validate_source_module_manifest, _write_receipts, EXPECTED_NEGATIVE_CASES, AUTHORITY_CEILING, and SOURCE_MODULE_MANIFEST_REF. The fixture input and exported bundle replay copied Ring2 verifier-trace repair metadata, source-module digests, failure classes, repair actions, promotion gates, and one deterministic public toy-theorem rerun.
• Result record and test floor: receipts/first_wave/formal_math_verifier_trace_repair_loop/formal_math_verifier_trace_repair_loop_result.json, verifier_trace_repair_board.json, formal_math_verifier_trace_repair_loop_validation_receipt.json, and result records/sign-off/first_wave/formal_math_verifier_trace_repair_loop_fixture_acceptance.json are metadata-only evidence. tests/test_formal_math_verifier_trace_repair_loop.py checks source-module manifest validation, negative cases, toy rerun evidence, and scope limits.
• Claim boundary: standards/std_microcosm_formal_math_verifier_trace_repair_loop.json and the generated structured source record limit this module to copied Ring2 verifier-trace repair metadata, source-module digests, public fixture result records, and deterministic toy rerun evidence. They do not authorize Lean/Lake authority, formal-result correctness, proof bodies, oracle premise ids, external model access, human approval as proof authority, launch-scope decision, publishing-scope decision, or whole-system correctness.

Reader Evidence Routing

Those rows prove reader wiring, not formal-result correctness.

Route runtime and replay questions through ## Runtime, ## Receipts, and the fixture/bundle paths in the validation command. The fixture runner, exported bundle runner, CLI route, standard, and fixture manifest show how verifier-trace repair accounting is replayed over copied public rows without importing proof bodies, oracle-needed premise ids, model-output data bodies, or private logs.

Route claim-safety questions through ## What It Proves, ## What It Refuses, ## Result record Expectations, and ## Scope limit. If the question is whether the repair loop is still body-safe and result record-backed, run the focused pytest and paper-module corpus check before citing this page.

Prior Art Grounding

This component is grounded in interactive theorem-proving feedback loops and learning environments where failed proof attempts become structured training or repair signals. GamePad and HOList both expose theorem-proving interaction data for machine-learning experiments, while LeanDojo reinforces the need to keep proof assistant feedback, retrieval, and proof-state interaction reproducible.

Microcosm borrows the repair-loop accounting pattern: verifier events, grades, failure classes, repair actions, curriculum deltas, and cold rerun result records are separate fields. It does not treat human or provider advice as formal-result correctness.

Runtime

• Component runner: python -m microcosm_core.organs.formal_math_verifier_trace_repair_loop run --input fixtures/first_wave/formal_math_verifier_trace_repair_loop/input --out receipts/first_wave/formal_math_verifier_trace_repair_loop
• Exported bundle runner: python -m microcosm_core.organs.formal_math_verifier_trace_repair_loop run-loop-bundle --input examples/formal_math_verifier_trace_repair_loop/exported_verifier_trace_repair_bundle --out receipts/runtime_shell/demo_project/organs/formal_math_verifier_trace_repair_loop
• CLI: microcosm formal-math-verifier-trace-repair-loop run-loop-bundle --input examples/formal_math_verifier_trace_repair_loop/exported_verifier_trace_repair_bundle --out receipts/runtime_shell/demo_project/organs/formal_math_verifier_trace_repair_loop
• Standard: standards/std_microcosm_formal_math_verifier_trace_repair_loop.json
• Fixture manifest: core/fixture_manifests/formal_math_verifier_trace_repair_loop.fixture_manifest.json

What It Proves

• A public verifier replay can require trace events before trace grades.
• Copied Ring2 failure rows can feed a repair curriculum without becoming proof authority.
• A repair action must name the verifier failure class it responds to.
• A failure-mode ledger update can be represented without proof bodies.
• Promotion requires a cold rerun result record reference.
• Human or provider advice stays advisory until checker evidence exists.

What It Refuses

• Proof bodies in public verifier traces.
• Oracle-needed premise ids in public inputs.
• model-output data bodies in fixtures or result records.
• Human approval as checker authority or theorem-quality evidence.
• launch, public sharing, secret export, or general theorem-proving claims.

Result records

• receipts/first_wave/formal_math_verifier_trace_repair_loop/formal_math_verifier_trace_repair_loop_result.json
• receipts/first_wave/formal_math_verifier_trace_repair_loop/verifier_trace_repair_board.json
• receipts/first_wave/formal_math_verifier_trace_repair_loop/formal_math_verifier_trace_repair_loop_validation_receipt.json
• result records/sign-off/first_wave/formal_math_verifier_trace_repair_loop_fixture_acceptance.json

Validation Result record Path

./repo-pytest tests/test_formal_math_verifier_trace_repair_loop.py -q --basetemp=/tmp/microcosm_formal_math_verifier_trace_repair_loop_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus
jq '{edge_count:(.relationships.edges|length), mermaid_status:.paper_module_payload.generated_projections.mermaid.status, atlas_status:.paper_module_payload.generated_projections.atlas_card.status, source_authority:.relationships.source_authority, unresolved_selective_relation_count:(.relationships.unpopulated_selective_relations|length)}' paper_modules/formal_math_verifier_trace_repair_loop.json

Expected generated-row proof: edge_count: 17, mermaid_status: available_from_capsule_edges, atlas_status: linked_from_capsule_edges, source_authority: json_capsule, and unresolved_selective_relation_count: 0.

Full module

formal_evidence_cell_anchor_resolver makes Microcosm's formal-math evidence claims inspectable without turning result record summaries into proof authority. It resolves paper-module claims to evidence-cell ids, checks source-anchor refs, records machine-anchor classes, and enforces a claim-strength boundary before any proof-language claim can pass. Its formal-math trace cell anchors the real Ring2 verifier-trace repair result records.

It is not a theorem prover. It does not execute Lean or Lake, expose proof bodies, expose non-public source refs, use external model services, or claim formal-result correctness. It emits real runtime result records over the imported evidence-cell system, carries digest-bearing Ring2 failure-taxonomy and graph-update source refs, and uses secret-exclusion scanning only for account secret-equivalent or non-result record body payloads.

Purpose

Proof-adjacent prose is the easiest place for a claim to drift. A paper module can write "this proves the theorem" or "this is certified" and a cold reader has no cheap way to tell whether the words are backed by a checked artifact or by nothing at all. This component answers one question: when a claim uses proof language, can the words be resolved to a specific piece of public evidence, and does that evidence stay below theorem-correctness authority?

The mechanism is an evidence cell. A cell is a stable id that stands in for a bundle of result record-backed evidence: its source-anchor refs, a machine_anchor_class that names what kind of machine artifact backs it, and the list of claim strengths the cell is allowed to support. The policy proof_language_requires_machine_anchor is the rule that makes the resolver useful. A claim that uses proof language must name a cell, the cell must resolve in the registry, and its source anchors must point at files that actually exist on the public path. A claim that uses proof language but names no cell, or names a cell that is not in the registry, lowers the run to a blocked status rather than passing as green prose.

What is worth noticing is what the cell id buys. It is a compressed handle: one short reference that a reader can follow back to the real result records behind a claim, instead of inlining proof bodies or trusting narrative. Two boundaries sit on top of that handle. Claim strength is capped by the cell, so a claim cannot assert more than its anchored evidence allows. And human approval is refused as a substitute for a machine anchor, which keeps a sign-off from being treated as proof.

Shape