Governed experiential learning

AncientOS implements a first advisory experiential-learning substrate in LifeVault. It records independently certified observations about strategies and their outcomes, creates deterministic scoped snapshots, and attaches those snapshots to immutable LegionCommander development plans after deterministic task-graph construction.

Experience is advice, not policy or authority. It cannot select an intent or domain, alter semantic routing, modify Rubick readiness or authority_mode, satisfy Lich approval, authorize mutation, continue a pending action, or choose an executor.

Memory distinctions

• Episodic records describe what occurred in a particular event or request.
• Semantic memory stores governed information available for retrieval.
• Experiential assertions describe a scoped situation, attempted strategy, and independently observed outcome that may advise later planning.

Experiential candidates begin as ordinary unpromoted LifeVault working memory. They are not eligible for experiential snapshots. The governed certification workflow converts an approved, evidence-sufficient certification proposal into the existing memory_review and memory_promotion lifecycle before creating a canonical assertion. Direct callers of the lower-level certifier must still provide an already promoted candidate.

Certification

Certification requires resolved evidence with an integrity hash, a supported deterministic source kind, an outcome-compatible status, and an independent producer. The lower-level certification vocabulary allowlists test runners, Zeus, governed action executors, and explicit operator correction, but it does not resolve or trust those labels by itself. Runtime certification accepts only evidence returned by its composed canonical adapters. Model output is not an accepted certifier.

The certification vocabulary reserves classifications for deterministic test results, Zeus evidence, observed postconditions, rollback receipts, precondition mismatches, and explicit correction. The runtime supports durable governed-action execution and rollback receipts linked to matching Zeus after-state evidence, plus canonical deterministic pytest receipts. Other evidence forms do not yet have a canonical durable adapter and fail closed.

The governed-action adapter validates the exact proposal/receipt relationship, the receipt's after-evidence relationship and hash, the candidate's explicit governed_proposal:<id> subject binding, outcome compatibility, and a bounded freshness horizon. Completed execution supports success; completed rollback supports failure; an uncertain external receipt is inconclusive. Mixed success and rollback evidence is conflicting and cannot be promoted automatically. An execution receipt whose proposal later records a rollback is exposed as contradicted rather than as current success.

Repeated references to the same evidence ID are deduplicated and cannot inflate an assertion. Confidence and frequency ranking are intentionally absent from this slice: neither is permission or proof.

Deterministic-test receipts

DeterministicTestReceipt is an immutable, integrity-bound record stored in the governed SQLite database. Its identity covers the exact pytest node, test framework and version, producer, run ID, repository revision, timestamps, exit status, JUnit counts, bounded command, output hash, and exact subject-file hashes before and after execution. Raw test output is not stored.

The development-side producer runs one repository-local pytest node without a shell and writes a receipt only after parsing its JUnit result. A pass requires exit status zero, at least one passed test, and no failures or errors. An all-skipped run is inconclusive rather than success evidence. A pytest assertion failure is failure evidence. Collection errors, missing results, and a subject that changes during execution are inconclusive and cannot certify success.

Subject binding combines the exact validation identity with a deterministic hash of the named subject files. This prevents a test for version A, a different test node, or a narrow contract from certifying version B or a broader proposition. The shared experiential-evidence freshness horizon defaults to 90 days and applies to both governed-action and deterministic-test receipt completion times. One runtime setting configures both adapters. Pass/fail counts describe that one validation run; they are neither confidence scores nor reinforcement weights.

The runtime does not execute tests. An operator uses the bounded receipt producer in a development/validation environment, then supplies the durable receipt ID through the existing exact certification commands. The resolver revalidates receipt integrity, subject stability, binding, freshness, and outcome compatibility before it can request the existing Lich persistence approval.

Canonical artifacts

experiential_assertion records preserve:

• exact domain, subsystem, and optional actor scope;
• situation class and problem;
• strategy and claimed outcome;
• certified outcome state;
• evidence IDs, integrity hashes, producer, and observed time;
• candidate and LifeVault promotion provenance;
• supersession references and validity state;
• a content-derived ID and schema version;
• an explicit advisory-only authority posture.

experiential_snapshot records preserve the exact scope, source-state hash, ordered assertion IDs, bounded assertion projections, evidence/provenance, and the result bound. Assertions are ordered by stable content fields and ID. Cross-domain transfer is not implicit; scope matching is exact.

Certified successes and failures may appear in snapshots. Inconclusive, stale, and contradicted outcomes remain auditable but are excluded. A later certified assertion may name existing assertions in the same exact scope that it supersedes. Missing or cross-scope supersession targets fail closed. The older artifacts are retained, while current snapshots deterministically exclude superseded advice.

LegionCommander and replay

Development request interpretation and deterministic task-graph construction complete before LifeVault lookup. The resulting immutable plan then receives an advisory_experience block and declares the injection order as after_deterministic_task_graph.

The plan contains the snapshot ID, state hash, ordered assertion IDs, certification states, and evidence/provenance. The content-addressed LifeVault snapshot contains the same projection. Later LifeVault changes therefore produce a different snapshot rather than silently rewriting historical plan context.

Governed certification workflow

The transport-neutral runtime accepts exact, bounded operator commands to:

1. create an untrusted candidate bound to one supported exact evidence subject;
2. assess an exact durable receipt and propose certification;
3. inspect the candidate, outcome, evidence, provenance, scope, supersession, expiry, and proposed durable effect;
4. approve or decline the exact certification through Lich; and
5. separately promote an approved certification.

The deterministic resolver decides evidence sufficiency. An operator may propose a candidate. Lich owns the decision to permit persistence. The post-approval service performs only the exact LifeVault review, promotion, and assertion write bound into the approval. Declined or expired approvals cannot promote. New evidence may be assessed in a new proposal; an old approval is not transferable.

The Lich approval effect is persist_advisory_experiential_assertion_only. It does not approve the action described by the experience, repeat that action, satisfy another Lich gate, or authorize future execution.

The durable audit chain is:

working_memory_entry → experiential_certification_assessment → experiential_certification_proposal → lich_approval → memory_review → memory_promotion → experiential_assertion → experiential_certification_receipt → experiential_snapshot.

Assessments freeze normalized governed-action or deterministic-test receipt identity, validation identity, subject binding, state, integrity, timestamp, and provenance. Promotion re-resolves the evidence and requires the assessment identity to remain unchanged. Certified assertions retain that normalized evidence record, and later snapshots retain the evidence reference, so newer test runs cannot rewrite the historical certification chain.

Current limits and deferred work

• There is no automatic experience extraction from model responses.
• There is no confidence or reinforcement scoring, frequency-based ranking, adaptive strategy weighting, learned routing, learned readiness, learned authority or approval, generalized self-optimization, or automatic cross-domain transfer.
• There is no automatic promotion or contradiction adjudication. Promotion is separately Lich-governed, and contradiction or supersession remains explicit.
• LegionCommander is the only advisory consumer; additional consumers require separate architecture and adoption review.
• Canonical governed-action execution, rollback, and deterministic pytest receipts have runtime certification adapters. Standalone Zeus, lifecycle, and explicit-correction adapters remain future work.
• The test producer supports one exact pytest node and file-based subject versions. Aggregate-suite receipts, non-pytest frameworks, commit/tree-only subjects, generalized artifact/tree binding, and automatic receipt production remain deferred.
• Arbitrary model-authored claims cannot become durable experiential truth.

Future confidence or reinforcement work is explicitly deferred. It requires the evidence, scope, correlation, replay, determinism, governance, anti-feedback-loop, and explainability review defined by the canonical portfolio roadmap.