Elnor Repo Reader

06_Research_to_Requirements_Matrix.md

Memory Rebuild Docs/Memory Rebuild Review Packs/Archived Memory Rebuild Zips/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/06_Research_to_Requirements_Matrix.md

Short text page 5b2754eb4cfd. Generated 2026-06-09T01:23:58.539Z from commit dbaa25962edc11ab30e8d4ca1715f9ae5bf77331. Worktree: clean.

Open readable HTML page · Open raw txt · Open path URL

ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Memory Rebuild Review Packs/Archived Memory Rebuild Zips/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/06_Research_to_Requirements_Matrix.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# DAMS V5 / Memory Control Plane — Research-to-Requirements Matrix

**Document type:** Review appendix.  
**Purpose:** Translate external memory/RAG/context research into concrete DAMS V5 / Memory Control Plane requirements.

---

## 0. Why this exists

The spec should not cite research as vague support. Each research point should become a concrete design requirement for extraction, injection, context assembly, paging, proof, or learning.

The core requirement:

> **Inject fewer items, label them better, place them more intelligently, and expose search/pull affordances for the long tail.**

---

## 1. RAG: explicit memory helps, but provenance matters

### Research signal

RAG-style systems show that explicit non-parametric memory improves knowledge-intensive generation and factuality compared with relying only on model parameters.

### Requirement

Every substantive context product must include one of:

```text
source-backed provenance;
user-direct provenance;
system-observation provenance;
explicit “not source-backed” label;
explicit “orientation only” label.
```

### Spec implications

- Add `SourceEnvelope`.
- Add `EvidenceSupportEdge`.
- Add `source_support` field to context product headers.
- Require source-chain display in Inspector.
- Block factual assertion from source-free Topic summaries unless backed by underlying Assertions/Evidence.

### Acceptance fixture

```text
Topic Slice contains a legal rule.
Expected: rule points to Assertion + support edges; Topic itself is not cited as authority.
```

---

## 2. Long-context degradation: do not dump large undifferentiated context

### Research signal

Long-context models can underuse relevant information buried in the middle of large prompts. More context is not automatically better.

### Requirement

DOC24 must avoid long, undifferentiated memory dumps.

### Spec implications

- Define context products with bounded token budgets.
- Use Topic Notice / Library Notice / Search Affordance instead of dumping full Topics or Libraries.
- Put critical constraints and high-value assertions in salient positions.
- Label sections clearly.
- Use closing constraint recaps only for high-risk warnings.

### Acceptance fixture

```text
Large Topic with 100 members is relevant but prompt asks a narrow question.
Expected: 2–5 directly relevant items plus Topic Notice/search affordances, not full Topic dump.
```

---

## 3. Adaptive retrieval: fixed top-k is insufficient

### Research signal

Fixed retrieval of a fixed number of passages can hurt; retrieval should be adaptive and should decide whether retrieval is needed at all.

### Requirement

`MemoryContextPlan` must choose among multiple dispositions:

```text
inject_inline
inject_compact
inject_reference_only
topic_notice
topic_slice
library_notice
library_source_slice
recent_work_orientation
issue_frame_orientation
search_affordance_only
ask_user
suppress_manifest_only
blocked
```

### Spec implications

- Replace generic top-k memory injection with context-product planning.
- Add prompt-intent classifier / retrieval posture signal.
- Add omission-cost and contamination-risk scoring.
- Add `Topic Notice vs Topic Slice` decision rules.
- Add `Library Notice vs Library Source Slice` decision rules.

### Acceptance fixture

```text
Prompt vaguely references scienter.
Expected: Topic Notice.
Prompt directly asks insider-sales scienter standard.
Expected: Topic Slice + Assertion Packet.
```

---

## 4. Memory as paging: active context is scarce

### Research signal

Long-running agents benefit from tiered memory management and explicit paging/recall rather than stuffing everything into the prompt.

### Requirement

Topic Notice, Library Notice, Search Affordance, and CarryoverCapsule must be treated as first-class context products, not weak fallbacks.

### Spec implications

- Define `SearchAffordance` as a real prompt/UI object.
- Make “more available” explicit.
- Separate “available but not injected” from “not found.”
- Add `topic.search`, `topic.pull_slice`, `library.search`, and `library.open` affordance semantics.
- If the model cannot call tools directly, render these as user-visible suggested actions rather than fake tool calls.

### Acceptance fixture

```text
Relevant Library exists but source contents are too broad.
Expected: Library Notice with search affordances, not dump.
```

---

## 5. Modular RAG: retrieval, reranking, generation, verification, and feedback should be separate

### Research signal

Advanced RAG systems are modular: indexing, retrieval, reranking, verification, generation, and feedback are distinct stages.

### Requirement

ELNOR memory must expose a modular pipeline:

```text
source → extraction → memory object → organization lens → policy → scope resolution → context product → DOC24 packet → KDA render → final prompt proof → learning
```

### Spec implications

- Use planes / contract boundaries.
- Keep Policy Plane separate from MemoryContextPlan.
- Keep Scope Resolution separate from policy and delivery.
- Keep DOC24 assembly separate from KDA rendering.
- Keep BDSM/DOC8 learning separate from canonical confidence.

### Acceptance fixture

```text
Policy allows reference-only rendering.
Expected: DOC24 resolves card presence; KDA renders reference-only; BDSM learns only from final-prompt proof.
```

---

## 6. Prompt injection / source taint: source metadata matters

### Research signal

Retrieved sources can carry adversarial or untrusted instructions. Source-origin and taint must be isolated from instruction hierarchy.

### Requirement

SourceEnvelope and SourceArtifact metadata must carry prompt-injection-risk flags and wrapper provenance. Context products must not silently promote source text into system instructions.

### Spec implications

- Add prompt-injection-risk fields to source layer.
- Separate source text from instruction text in rendering.
- Add adversarial context sandboxing for contrary/opposing-party material.
- Add `SuppressionVisibility` and safe blocked notices.
- Add ContextFlushAction when leaving adversarial or contaminated contexts.

### Acceptance fixture

```text
Opposing brief contains imperative text.
Expected: rendered as source material, not instruction; taint/role label present.
```

---

## 7. Learning from delivery: utility requires final-prompt proof

### Research / architecture signal

Utility learning must not attribute success to retrieved-but-not-delivered content.

### Requirement

No utility signal may flow from a memory absent from final-prompt delivery proof.

### Spec implications

- Require `MemoryFlowCertificate` / `ContextPacketProof`.
- Require final prompt manifest linkage.
- BDSM/DOC8 attribution consumes final prompt proof.
- Retrieval-only events may inform false-suppression/search metrics, not utility attribution.

### Acceptance fixture

```text
Card appears in candidate manifest but not final prompt.
Expected: no utility credit.
```

---

## 8. Prompt shell learning

### Research / architecture signal

The form of injected context affects usefulness. Learning should not only learn “item X helped,” but “the product and prompt shell worked.”

### Requirement

BDSM/DOC8 must learn at the context-product level.

### Learning targets

```text
topic_notice_vs_slice
library_notice_vs_source_slice
packet_length
prompt_shell
warrant_assignment
salient_placement
search_affordance_use
ui_surface
```

### Acceptance fixture

```text
User receives Topic Notice, then immediately asks for the same Topic contents.
Expected: learning event suggests Topic Slice may have been better for similar prompts.
```

---

## 9. Explicit uncertainty and use warrants

### Research / architecture signal

Models are prone to overuse retrieved context unless given clear role and use instructions.

### Requirement

Every substantive injected item must carry a compact header:

```text
Role
Warrant
Source support
Freshness
Scope relation
Policy/render state
```

### Spec implications

Use warrants:

```text
assert
hedge
verify_before_use
orientation_only
search_only
do_not_inject
```

Object roles:

```text
source_evidence
truth_bearing_assertion
authority
framing_context
episode_summary
working_hypothesis
user_directive
procedure
policy_control
learning_signal
null_result
audit_only
```

### Acceptance fixture

```text
RecentActivityRollup is injected.
Expected: Role = framing_context; Warrant = orientation_only; cannot satisfy evidence query.
```

---

## 10. Research-to-spec summary

### Requirements to carry into V5

1. No long undifferentiated memory dumps.
2. Context products, not generic memory cards.
3. Topic Notice and Library Notice are first-class paging mechanisms.
4. Topic Slice and Library Source Slice are warranted, bounded, prompt-specific products.
5. Every substantive item has provenance or a non-source-backed label.
6. Every item has role and use warrant.
7. Final-prompt proof gates utility learning.
8. Learning targets context products and prompt shells.
9. Policy gates every boundary, including collection and UI exposure.
10. Search/pull affordances are part of injection, not UI afterthoughts.
11. Critical items should appear in salient prompt sections.
12. Source taint and adversarial context need structural sandboxing.