Elnor Repo Reader

ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Flattening/Proposals/Attachment_Triggered_Memory_Retrieval_And_Injection_PROPOSAL.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# Deferred-Item Capture — Attachment as a Memory-Retrieval Signal

**Status:** CAPTURE NOTE (not a proposal for review). The design happens at DOC84 drafting; this note + the OPA rows + the Open Issues Map line are the capture so it is not lost. Supersedes the earlier over-scoped proposal at this path.
**Date:** 2026-05-31. **Decision: B** (skip a review round; capture only), per architect.

## The narrow finding
DOC24 shapes memory retrieval/injection from the **typed prompt only** — `RouterInput` (§13.1) has no attachment field; three-lane retrieval (§27) is seeded from that. So a current-turn attachment does not drive *which memories* surface. Document **delivery** to the model already works (DOC25 §3 tiers / §22 chat-attachment / §4 caching), so "summarize the attached" functions today; only the memory-shaping is missing.

## What to do (and where)
- **DOC84 (delivery/retrieval; slices E7/E8) — the work.** Make the current-turn attachment a first-class **input** to memory retrieval, seeded from the attachment's bounded **DOC25 structured summary** (§5.1 step 3), never the raw document (so the cue is bounded regardless of document length). Retrieved memories then flow through DOC24/DOC84's **existing** injection machinery — this adds an input; it does not redefine how injection selects/budgets/renders.
- **DOC25 — the small enabler.** Expose the structured summary (+ entities/classification) as a retrieval **seed**, not only a delivery payload. The step-3 summary suffices for chat attachments (no full corpus indexing needed).
- **DOC80 — nothing required.** The control plane is governance/policy/egress/lifecycle/provenance and is trigger-agnostic; memory injected because of an attachment passes the same DOC80 controls as any injected memory. Optional, DOC84-era only: an `injection_trigger` field on the existing R3 §22 `E0PerSourceTurnLedgerRow` for Inspector/audit. **DOC80 (E0) can finalize as-is.**

## Architect consideration for DOC84 drafting (do not lose)
Documents should **not** necessarily be treated the same as the typed prompt for determining what gets injected into memory. They likely warrant **different weight, relevance, precedence, or treatment** in some manner. This needs deliberate consideration when DOC84 is drafted. The broader "how injection decides what to surface" design (core-vs-catalog, budgets, etc.) is a separate, deeper DOC24/DOC84 review — not resolved here. (Architect note, 2026-05-31.)

## Tracking
- **OPA §6.Z4:** `OBL-D84-ATTACHMENT-RETRIEVAL-SIGNAL-01` (DOC84) + `OBL-D25-SUMMARY-AS-RETRIEVAL-SEED-01` (DOC25). The flatten plan forces E7/E8 charters to pull their OPA rows (§13/§16), so this surfaces automatically at DOC84 drafting.
- **Open Issues Map §2.A**, E7 row.

*End of capture note.*