generated from coulomb/repo-seed
CYA-WP-0005 T03 done (ralph iter 3): Profiles 1–3 definitions + capability matrix
- MemoryVision.md: New major section 'Profiles 1–3: Definitions and cya Integration Plans' with crisp, self-contained definitions for each profile (intent, core loop, cya mapping, delta, phase-memory fit, safety/explainability) + full 'Profile Capability Matrix' table.
- Added short appendix in the workplan itself ('Profile Definitions Reference (T03)') pointing to MemoryVision as the living spec.
- All content synthesized from the persisted research artifact with heavy references.
- T03 acceptance criteria fully met (definitions + matrix in MemoryVision + workplan note; docs-only).
Committed as ralph iter 3. Next: T04 (phase-memory suggestions doc polish).
This commit is contained in:
121
MemoryVision.md
121
MemoryVision.md
@@ -196,6 +196,127 @@ All of them must continue to satisfy the invariants above and must continue to w
|
||||
|
||||
---
|
||||
|
||||
## Profiles 1–3: Definitions and cya Integration Plans
|
||||
|
||||
**Date:** 2026-05-28 (CYA-WP-0005 T03)
|
||||
**Source:** Synthesized from `history/2026-05-28-CYA-Agentic-Memory-Research-Variations.md` (the deep research artifact). These are the authoritative working definitions for the self-improving memory profiles. All three preserve cya's non-negotiable contract: user-controlled, fully explainable, safety-first (memory only increases caution), explicit seam to phase-memory.
|
||||
|
||||
The three profiles are ordered by increasing agentic power and implementation cost.
|
||||
|
||||
### Profile 1 — Reflexion-Style Verbal Self-Improvement Loop
|
||||
|
||||
**Intent:** Enable lightweight, high-explainability self-improvement by capturing and preferentially activating natural-language "lessons" and verbal reflections from user interactions and retrospection sessions.
|
||||
|
||||
**Core Loop (condensed):**
|
||||
1. Normal assistance with current Profile 0 activation.
|
||||
2. Outcome capture (accept/revise/reject or explicit `cya retrospect`).
|
||||
3. Verbal reflection generated (1–3 concise lessons in plain English).
|
||||
4. Stored with new or extended `kind` (e.g. `reflection` or `verbal_lesson`) via `remember_retrospection_outcome` / new helper.
|
||||
5. Future recall boosts these kinds + activation_context; they are prepended with high salience.
|
||||
6. Visible in `--explain-context` and final output ("3 verbal reflections influenced this...").
|
||||
|
||||
**cya Mapping (builds directly on 0003):**
|
||||
- ~80% already exists (`KIND_RETROSPECTION`, `remember_retrospection_outcome`, `cya retrospect` flow, kind filter in recall, activation_context boost).
|
||||
- Small delta: lightweight "capture lesson" step at end of retrospect (or auto after notable outcomes); new `kind` values; preferential activation logic tweak.
|
||||
- Orchestrator already has the wiring to surface them.
|
||||
|
||||
**Delta Required:** Minor enhancements to retrospect CLI flow and recall boosting; new `kind` constant(s).
|
||||
|
||||
**Phase-memory Fit:** Minimal for MVP — good native `kinds` filter + provenance. Later: a lightweight "reflection planner" for compaction of duplicate lessons.
|
||||
|
||||
**Safety / Explainability:** Reflections that touch risky patterns still go through the rule-based RiskClassifier. All items carry full provenance. Users can inspect/edit/forget them directly.
|
||||
|
||||
**See also:** Research doc Variation 1, Shinn et al. (Reflexion), current `docs/cya-memory-activation-and-retrospection-concept.md`.
|
||||
|
||||
### Profile 2 — Generative-Agents-Style Hierarchical Memory Stream + Synthesis
|
||||
|
||||
**Intent:** Move from passive storage to active synthesis of higher-order knowledge (project conventions, recurring workflows, "in this scope we always...") so the assistant becomes meaningfully smarter over time with citations back to source events.
|
||||
|
||||
**Core Loop:**
|
||||
1. Episodic capture of every turn/outcome/retrospection (structured records with ts, kind, scope, activation_context, payload, provenance).
|
||||
2. Periodic synthesis (user-triggered via `cya retrospect --synthesize`, or phase-memory planner): LLM clusters recent fluid memories and produces abstractions with citations.
|
||||
3. Store synthesized items with elevated phase hint ("stabilized") and dedicated kinds (`KIND_SYNTHESIZED_CONVENTION`, `KIND_PROJECT_PATTERN`, etc.).
|
||||
4. Retrieval uses multi-factor scoring (recency + importance + relevance + profile/scope match) + existing activation boost.
|
||||
5. Hierarchy emerges naturally (raw → synthesized → higher-order).
|
||||
6. Compaction / phase transitions proposed with dry-run + user review.
|
||||
|
||||
**cya Mapping:**
|
||||
- Local JSON already provides a usable episodic stream.
|
||||
- `export_memory` + recall with activation_context already return provenance.
|
||||
- Orchestrator already injects memory into ContextEnvelope.
|
||||
- Extend `retrospect` to offer synthesis as an explicit option.
|
||||
- Add lightweight importance scoring on remember.
|
||||
- Synthesized items flow through the same recall path (different kinds/phases).
|
||||
|
||||
**Delta Required:** Synthesis entrypoint (or call into phase-memory planner), new kinds, importance scoring, UI affordance in retrospect for "synthesize patterns".
|
||||
|
||||
**Phase-memory Fit (strong alignment):**
|
||||
- Synthesis / reflection planner entrypoint (cya can request "run reflection pass").
|
||||
- Structured objects with citation/provenance fields.
|
||||
- Phase transition proposals (fluid → stabilized) with dry-run diffs.
|
||||
- Multi-factor retrieval API that cya can parameterize.
|
||||
|
||||
**Safety / Explainability:** Every synthesized item carries machine + human readable citations. All influence is visible in `--explain-context`. Synthesis proposals are always reviewable (dry-run first).
|
||||
|
||||
**See also:** Research doc Variation 2, Park et al. (Generative Agents), MemoryVision phases section.
|
||||
|
||||
### Profile 3 — Procedural / Meta-Policy Evolution (Aspirational)
|
||||
|
||||
**Intent:** Allow the assistant to evolve its own high-level "how I should behave" rules and procedures as first-class, auditable, evolvable memory — the highest-leverage form of self-improvement, with the strongest guardrails.
|
||||
|
||||
**Core Loop:**
|
||||
1. Base behavior driven by a dedicated tier of procedural memory items (`procedural_rule`, `meta_policy`, `explanation_strategy`, `safety_tuning`).
|
||||
2. Meta-reflection (after retrospect or explicit "improve my rules"): LLM reviews recent outcomes + current rules + safety incidents and proposes patches.
|
||||
3. Proposal + audit: phase-memory / cya presents structured diff ("+1 rule, safety impact: tightens") for user review/edit/approve/veto.
|
||||
4. On approval: rule stored with high stability/phase and becomes active in future activation, prompt construction, and risk hints.
|
||||
5. Guardrails: changes are additive or tightening only by default; every rule has provenance + last-review date; RiskClassifier treats procedural items as strong "force confirmation" signals.
|
||||
|
||||
**cya Mapping:**
|
||||
- New dedicated kinds + `remember_procedural_rule` helper.
|
||||
- New `cya improve-rules` (or retrospect extension) that triggers meta-reflection.
|
||||
- Orchestrator / safety layer gives procedural items highest priority for injection.
|
||||
- Export/inspect surfaces the procedural layer prominently.
|
||||
- Tight integration with existing rule-based RiskClassifier.
|
||||
|
||||
**Delta Required:** New kinds + helper, meta-reflection flow + UI, prominent procedural layer in export/explain, stronger safety injection.
|
||||
|
||||
**Phase-memory Fit (most demanding):**
|
||||
- First-class procedural memory collection + dedicated policy evolution planner.
|
||||
- Proposal/diff semantics with structured review objects (dry-run).
|
||||
- Explicit meta-reflection hooks with bounded context.
|
||||
- Safety/policy gateway enforcing "cannot weaken risk posture without override".
|
||||
- Versioning/rollback for the procedural layer.
|
||||
- Profile-level "aggressiveness" setting (conservative / balanced / bold).
|
||||
|
||||
**Safety / Explainability:** Highest bar. All proposals declare safety impact. User veto is mandatory for anything that could relax posture. Full audit trail.
|
||||
|
||||
**See also:** Research doc Variation 3, LangMem procedural, A-Mem, LEGOMem, cya `risk/classifier.py`.
|
||||
|
||||
### Profile Capability Matrix
|
||||
|
||||
| Aspect | Profile 0 (baseline) | Profile 1 (Verbal Reflexion) | Profile 2 (Hierarchical Synthesis) | Profile 3 (Procedural Evolution) |
|
||||
|-------------------------------|---------------------------------------|------------------------------------------|---------------------------------------------|-----------------------------------------------|
|
||||
| Primary new kinds | preference, retrospection, interaction_goal | reflection / verbal_lesson | synthesized_convention, project_pattern | procedural_rule, meta_policy, safety_tuning |
|
||||
| Activation model | scope/profile boost + recency | + kind boost for reflections | + multi-factor (recency + importance + relevance) | + highest priority for procedural items |
|
||||
| Synthesis / Reflection | None (user only via retrospect) | Lightweight verbal lessons (user or light auto) | Periodic LLM synthesis with citations (planner or user-triggered) | Meta-reflection proposes rule patches (strong audit) |
|
||||
| Procedural support | None | None | None | First-class tier + evolution planner |
|
||||
| User control surface | remember / forget / export / retrospect | + "capture lesson" in retrospect | "synthesize patterns" option + review dry-runs | Full proposal review, veto, rollback |
|
||||
| Safety impact | Additive only (never downgrades) | Same + reflections can force confirmation | Same + synthesis proposals carry impact tags | Highest: cannot relax risk without explicit override |
|
||||
| cya implementation effort | Already shipped | Small (retrospect step + kind boost) | Medium (synthesis entrypoint + importance) | High (new flow + UI + safety injection) |
|
||||
| phase-memory effort (key) | N/A (local approximation) | Minimal (kinds + provenance) | High (synthesis planner, phase proposals, multi-factor retrieval) | Highest (procedural planner, diff/review objects, policy gateway) |
|
||||
| Explainability | Full provenance + --explain-context | + actual reflection text | + citations on every synthesized item | + full audit trail on every rule change |
|
||||
|
||||
**Notes on the matrix:** Costs are relative. Profile 1 is designed to deliver quick wins on top of existing 0003 machinery. Profiles 2 and 3 require increasing collaboration with phase-memory planners and stronger dry-run/audit primitives.
|
||||
|
||||
### Handoff & Next Steps (within CYA-WP-0005)
|
||||
- T04 turns the suggestions section of the research doc into the polished, standalone `docs/phase-memory-optimization-suggestions.md` (or equivalent) for sister-repo coordination.
|
||||
- T05+ explore minimal implementation spikes (starting with Profile 1) only after the definitions and phase-memory feedback are reviewed.
|
||||
- All profile work must preserve the Profile 0 invariants documented above.
|
||||
|
||||
See the full research artifact for deeper citations (Shinn, Park, LangMem, etc.) and the detailed phase-memory feedback list.
|
||||
|
||||
---
|
||||
|
||||
## cya ↔ phase-memory Integration Contract (CYA-WP-0002 T01)
|
||||
|
||||
**Date:** 2026-05-26 (ralph iter 1)
|
||||
|
||||
@@ -94,9 +94,11 @@ completed: "2026-05-28 ralph iter 2"
|
||||
|
||||
```task
|
||||
id: CYA-WP-0005-T03
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "6f292b8b-b17d-4495-99b3-db031f6fb339"
|
||||
started: "2026-05-28 ralph iter 3"
|
||||
completed: "2026-05-28 ralph iter 3"
|
||||
```
|
||||
|
||||
**Description**: Turn the research synthesis into concrete profile definitions, each with: intent, core loop, mapping to existing cya ports/kinds/orchestrator/retrospect/risk, delta required, phase-memory dependencies, safety/explainability notes, and acceptance criteria sketch. Include a simple profile selection / capability matrix.
|
||||
@@ -253,3 +255,14 @@ When complete:
|
||||
- External: Shinn Reflexion (2023), Park Generative Agents (2023), LangMem / A-Mem / MemGPT literature (see research doc for links)
|
||||
|
||||
This completes the planning artifact requested in the 2026-05-28 user query.
|
||||
|
||||
---
|
||||
|
||||
## Appendix: Profile Definitions Reference (T03)
|
||||
|
||||
The authoritative, living definitions for Profiles 0–3 (including the Capability Matrix) live in **MemoryVision.md** under the sections:
|
||||
|
||||
- "Profile 0 Baseline (Post-0003 / Current Shipped)"
|
||||
- "Profiles 1–3: Definitions and cya Integration Plans" (with detailed intent, core loops, cya mappings, phase-memory fit, safety notes, and the full matrix table)
|
||||
|
||||
These were added during T03 and are the single source of truth for the self-improving memory model. The research artifact `history/2026-05-28-CYA-Agentic-Memory-Research-Variations.md` remains the deep background with citations.
|
||||
Reference in New Issue
Block a user