Voice to Doctrine Self-Improvement Loop

It decides from the files alone whether each lesson in a self-improvement pass actually moved a named surface or only left a note claiming it did. This component checks whether a claim of self-improvement is backed by evidence. The system it comes from turns a local lesson into a durable change: a piece of pressure is sensed, classified, assigned to an owner surface, changed or captured there, validated, and closed with a condition for revisiting it later. This component takes a folder describing one pass of that loop and decides, from the files alone, whether each lesson really moved a named surface or only produced a note that says it did.

It runs on local files and emits metadata-only records, requiring every lesson's refs to resolve to real files and reporting only ids, counts, hashes, and status. It runs on local files and writes metadata-only result records. Every lesson names the surface it changed, the action it took, and the refs that show the change held. Each ref must resolve to a real file. The result records report ids, counts, hashes, and pass or fail status, never the private text behind them.

The run entry point validates the test fixture, while run_voice_to_doctrine_bundle validates the exported example bundle instead. The entry point is run in src/microcosm_core/organs/voice_to_doctrine_self_improvement_loop.py. A second entry point, run_voice_to_doctrine_bundle, validates the exported example bundle instead of the test fixture.

Purpose

Learning is easy to assert, hard to back

A claim that the system learned is easy to assert, so this component recomputes the verdict from evidence and ignores any label a lesson gives itself. "The system learned from its work" is easy to assert and hard to back. A log line, a closed ticket, and a confident summary all read as progress. If a check accepts that language at face value, a run can pass by describing success rather than showing it. This component refuses that. It recomputes the verdict from the evidence and ignores any label a lesson gives itself.

Three trusts a loose version would make

A loose check would trust a lesson's stated status, an unverified ref, and a refinement that changed nothing, and the checks below close all three gaps. A loose version would trust three things this one does not: the lesson's own stated status, a ref that names a file without checking the file exists, and a refinement that changed nothing. Each of those lets an unbacked claim through. The checks below close all three.

How it works

run loads inputs and five validators

run loads four input files plus six negative-case files, then runs five validators in order and merges their findings. run loads four input files from the chosen directory: projection_protocol.json, propagation_policy.json, owner_surfaces.json, and local_lessons.json, plus six negative-case files. It then runs five validators in order and merges their findings.

validate_projection_protocol checks three source refs

validate_projection_protocol requires the three source pattern refs the loop is built from, recording any missing one as a required-source-pattern-ref-missing code. validate_projection_protocol checks that the protocol declares the three source pattern refs the loop is built from: recursive_self_improvement_operating_loop, doctrine_population_loop, and local_to_general_propagation. A missing ref is recorded as VOICE_DOCTRINE_REQUIRED_MACRO_PATTERN_REF_MISSING.

validate_policy requires the seven-step sequence

validate_policy requires the full seven-step sequence from sense_local_pressure through publish_reentry_condition and rejects any policy allowing result record-only progress. validate_policy checks that the policy carries the full seven-step sequence, from sense_local_pressure through publish_reentry_condition, and rejects any policy that authorizes result record-only progress.

validate_owner_surfaces maps surface authority

validate_owner_surfaces builds a map where each surface needs a stable id, a public ref, and a declared mutation authority to own a change. validate_owner_surfaces builds a map of owner surfaces. Each surface needs a stable id, a public ref, and a declared mutation authority. A surface that names none of these cannot own a change.

validate_lessons resolves every ref

validate_lessons, the core, requires each lesson's fields, a mapped owner surface, one of four typed outcomes, and every ref resolving through _resolve_ref to an anchor. validate_lessons is the core. For each lesson it checks the required fields are present, the selected owner surface exists in the map, and the outcome is one of four: refined_existing_surface, workitem_captured, nothing_to_refine, or already_propagated_verified. It then resolves every ref the lesson carries (changed_surface_ref, evidence_ref, evidence_refs, validation_ref, closeout_ref) through _resolve_ref, which reads the target file and confirms the anchor text after :: is present. A refinement with no changed surface is result record-only progress and fails. A capture with no re-entry condition fails. A nothing_to_refine with no stewardship and next-best-lane check fails.

Asserted labels cannot rescue a row

A lesson's expected_label or expected_verdict is counted then ignored when the row is not genuinely backed, so a fixture cannot pass by declaring its own success. The defense against self-grading lives here too. A lesson may carry expected_label, expected_status, expected_outcome, or expected_verdict. validate_lessons counts those keys, then computes whether the lesson is genuinely backed from the other checks. If the lesson is not backed, the asserted label is recorded as ignored under VOICE_DOCTRINE_BAKED_EXPECTED_LABEL_IGNORED and cannot rescue the row. A fixture cannot pass by declaring its own success.

_source_module_result verifies eight copied bodies

_source_module_result confirms each of eight copied source bodies by hash, byte and line count, and anchors, allowing an exact copy unless a row declares a verified light edit. _source_module_result validates the copied source bodies listed in source_module_manifest.json. For each of the eight rows it confirms the target file exists, its sha256, byte count, and line count match the manifest, every required anchor is present in both the copied body and the live source file, and the copy is exact unless the row declares a verified light edit. Seven bodies are exact copies; one, the task-ledger skill body, is a verified light edit with the operator's raw gesture removed.

This page is a checked surface

This page is itself a checked surface, with lesson refs pointing at literal anchors here; deleting one leaves a ref unresolved and fails the run, though the fixture resolves nineteen. This page is one of the surfaces the fixture checks. Its lesson rows point evidence and completion refs at named anchors in this file, including Public Mechanics, Shape, Reader Proof Boundary, Body Handling, and Scope boundary. _resolve_ref looks for each anchor as literal text; if an anchor is deleted, the ref does not resolve, validate_lessons records VOICE_DOCTRINE_SURFACE_REF_UNRESOLVED, and the run fails. The fixture resolves nineteen refs with none unresolved.

Secret scan, gating, and record writers

After the validators run secret-scans inputs and copied bodies and passes only on clean findings, then writes three metadata-only records, with the bundle entry requiring the source manifest. After the validators, run runs a secret-exclusion scan over the input paths and copied bodies, merges the observed negative cases, and passes only when there are no blocking findings, no missing negative cases, a clean scan, and verified source modules. _build_board and the result and validation writers then emit voice_to_doctrine_self_improvement_loop_result.json, ..._board.json, and ..._validation_receipt.json, each carrying body_in_receipt: false. run_voice_to_doctrine_bundle calls run with negative cases off and the source-module manifest required, then stamps the bundle id.

What the fixture describes

The fixture spans four lessons over five owner surfaces: two refinements, one deferred capture with a re-entry condition, and one verified no-op. The fixture describes four lessons across five owner surfaces: two refine an existing surface, one captures deferred work with a re-entry condition, and one records a verified no-op.

Shape

flowchart TD Load["Load inputs protocol, policy, owner surfaces, lessons"] Protocol["validate_projection_protocol 3 source pattern refs"] Policy["validate_policy 7-step sequence"] Owners["validate_owner_surfaces id, public ref, mutation authority"] Lessons["validate_lessons fields, owner, outcome, resolve every ref"] Recompute["Ignore expected label recompute from evidence"] Negative["validate_negative_cases 6 refusals"] Source["_source_module_result 8 copied bodies: hash, anchors, exact copy"] Result records["metadata-only result records result, board, validation"] Load --> Protocol Load --> Policy Load --> Owners Owners --> Lessons Lessons --> Recompute Load --> Negative Load --> Source Protocol --> Result records Policy --> Result records Recompute --> Result records Negative --> Result records Source --> Result records

Negative cases

validate_negative_cases reads six files, each a shape the loop must refuse, and records a fixed code for each: validate_negative_cases reads six files, each a shape the loop must refuse, and records a fixed code for each:

• raw_operator_voice_export carrying a forbidden body key gives VOICE_DOCTRINE_RAW_OPERATOR_BODY_FORBIDDEN.
• doctrine_node_hand_edit that edits a principle, concept, mechanism, or axiom by direct file write gives VOICE_DOCTRINE_DIRECT_NODE_EDIT_FORBIDDEN.
• consume_without_deposit with no deposit outcome gives VOICE_DOCTRINE_CONSUME_WITHOUT_DEPOSIT.
• pattern_receipt_only_progress whose owner action is append-result record-only gives VOICE_DOCTRINE_RECEIPT_ONLY_PROGRESS.
• global_promotion_without_owner_validation that requests promotion without owner validation gives VOICE_DOCTRINE_GLOBAL_PROMOTION_WITHOUT_OWNER_VALIDATION.
• private_thread_body_export carrying a forbidden body key gives VOICE_DOCTRINE_PRIVATE_THREAD_BODY_FORBIDDEN.

Fixture, bundle, and tampering modes

In fixture mode all six cases must be observed without blocking, in bundle mode none is expected, and source-module tampering each drops the verified-body count and adds a blocking code. In fixture mode these six cases are expected: they must all be observed for the run to pass, and they do not block. In bundle mode the negative inputs are absent and none is expected. The source-module tests also exercise tampering: a changed hash, a rehashed body edit, a wrong source ref, and a missing live source each drop the verified-body count and add a blocking code.

Prior Art Grounding

After-action review and pattern language

It follows after-action review and pattern-language practice, but a lesson becomes durable only with evidence, an owner surface, a validation ref, and a bounded re-entry path. This component follows after-action review, lessons-learned practice, and pattern-language work. NASA's Lessons Learned Information System is a public example of preserving operational lessons so later work can reuse them, and pattern-language practice gives a vocabulary for turning repeated local solutions into named reusable forms. This component keeps that direction without collapsing a local lesson into doctrine: a lesson becomes durable only when it has evidence, an owner surface, a validation ref, and a bounded re-entry path.

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

Validation Result record Path

Run from microcosm-substrate:

What a green record means

A green record means the lessons named a real owner surface, resolved every ref, observed the negative cases, and passed the secret scan, and nothing beyond that. A green fixture or bundle record means the lessons named a real owner surface, resolved every ref, observed the negative cases, and passed the secret scan. It means nothing beyond that.