Skip to main content

Learning and procedures

The clean-slate design retires experience as a top-level architectural owner. The replacement model is simple:

  • outcomes land as evidence
  • repeated useful patterns become candidates
  • verified candidates become procedures
  • optional skills are one packaging surface for those verified procedures

Why retire experience as a top-level owner​

The older framing created repeated overlap:

  • it looked like a second memory system
  • it competed with continuity and recall when contributors asked where truth lived
  • it blurred the line between observed evidence and reusable workflows
  • it made skill promotion feel loosely governed

The new design closes that gap by making learning a loop that starts from evidence and ends in procedures.

The learning objects​

OutcomeEvidence​

A normalized outcome record in EvidenceGraph. It captures what happened, what changed, which tools ran, what artifacts were produced, and whether the result was useful.

PatternCluster​

A repeated family of successful or instructive outcomes. This is an analysis object, not yet a reusable runtime asset.

ProcedureCandidate​

A distilled candidate workflow with:

  • title and summary
  • triggering conditions
  • ordered steps and constraints
  • supporting evidence references
  • confidence and review state

VerificationBundle​

The replay, evaluation, or review material used to prove a candidate should be trusted.

Procedure​

The promoted reusable pattern stored in ProcedureLibrary. This is the durable learning asset.

SkillPackage​

An optional packaging surface for a verified procedure when a skill-shaped runtime overlay is useful.

The runtime flow​

1. Capture outcome evidence​

After a turn completes, the runtime writes normalized outcome evidence into EvidenceGraph. This phase should stay cheap and deterministic.

2. Cluster repeated patterns​

Later analysis groups outcomes that appear to share goals, tool sequences, correction patterns, or workspace context.

3. Distill procedure candidates​

When a cluster is coherent enough, the runtime extracts a candidate workflow.

4. Verify​

Candidates must be verified before promotion. Verification can use replay, evaluation scenarios, failure-case regression, or operator review for higher-impact procedures.

5. Promote​

Accepted candidates become durable Procedure records. When a richer prompt-time body helps, Aegis may package that procedure as a skill.

6. Activate selectively​

Procedures and skills are optional overlays. They should only be loaded when relevant to the active SessionFrame.

Boundary rules​

Learning must not take ownership away from the other durable owners.

It does not own profile truth​

Preferences, relationship expectations, and collaboration posture still belong in ProfileGraph.

It does not own work truth​

Goals, blockers, and decisions still belong in WorkGraph. A procedure may help execute work, but it does not become the owner of the plan.

It does not own evidence truth​

Raw evidence, recall reasons, and correction chains stay in EvidenceGraph. Learning consumes evidence and emits procedures; it does not replace evidence.

Skill packaging rule​

A SkillPackage is one rendering of a verified procedure, not the authoritative source of that workflow.

In practice, that means:

  • edit the procedure first
  • regenerate or patch the skill package from the procedure
  • do not hide the only correct version of the workflow inside a skill body

Operator controls​

The target procedure surface should allow operators to:

  • browse draft candidates
  • inspect supporting evidence
  • review verification bundles
  • promote, reject, retire, or patch procedures
  • trace which runtime sessions used a given procedure

Where to go next​

Once the learning loop is clear, the next question is implementation. Continue with Technical stack.