Elnor Repo Reader

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

---

# DAMS V5 — Red-Team Adjudication Delta

**Document type:** Pre-spec adjudication card.  
**Scope:** Updates the prior DAMS V4.1 red-team adjudication with the latest conceptual clarifications on Topics, Scope, Assertions, CUs, Libraries, extraction, injection, policy, and review sequencing.

---

## 0. Executive decision

Proceed toward a real DAMS V5 / Memory Control Plane specification, but do **not** draft the final operative spec until reviewers have attacked this pre-spec conceptual model.

The next artifacts should be:

1. **DAMS V5 / Memory Control Plane Specification** — real spec, not narrative proposal. DAMS becomes one substrate inside this spec.
2. **Flatten-and-Unify Execution Plan** — separate procedural document with gates, audits, lints, source-freeze, OP-A disposition, and pilot slices.
3. **Worked Examples / Fixtures Appendix** — mandatory, not optional.
4. **Research-to-Requirements Matrix** — short but normative; external research findings become implementation requirements.

---

## 1. Decisions accepted from red-team and subsequent clarification

### 1.1 DAMS demotion

**Decision:** Accept.

DAMS is not the memory system. It is the attenuator / capacity-prior / salience substrate inside the Memory Control Plane.

**Spec inclusion:** DAMS V5 should have a dedicated section named something like:

```text
DAMS Attenuator and Capacity-Prior Substrate
```

It should own:

- attenuator contributors;
- signed additive-deviation composition;
- scope-equivalence collapse for capacity scoring;
- role-band / bucket hints;
- false-suppression guardrails;
- capacity priors;
- cold-start defaults.

It should not own:

- durable truth;
- source extraction;
- policy evaluation;
- final prompt assembly;
- rendering;
- final-prompt truth;
- learning computation;
- UI controls;
- EC writes.

---

### 1.2 Control-problem framing

**Decision:** Accept, but operationalize.

The reframe is useful, but only if it becomes a contract. The spec should not say “memory is a control problem” as rhetoric. It should define the control loop.

**Spec inclusion:** Add a `MemoryControlLoop` / `MemoryCoordinationTrace` model that records:

```text
observed event → state estimate → controller → action → policy decision → context product / write decision → feedback channel → version vector
```

The controlled state should be practical, not mystical: packet quality, stale-injection rate, unwarranted-assertion rate, false-suppression rate, resume success, page-fault rate, context-product outcomes, and user corrections.

---

### 1.3 Nine-plane functional framing

**Decision:** Accept.

The latest discussions moved beyond DAMS into the outline for the flattened memory system. That is good. The memory spec should be organized by functions, not predecessor document names.

**Spec inclusion:** Use these planes as top-level organizing principles:

1. Source and Evidence Plane
2. Stored Memory Object Plane
3. Organization and User Interaction Plane
4. Temporal and Working-State Plane
5. Policy and Permission Plane
6. Scope Resolution and Coordination Plane
7. Extraction and Ingestion Plane
8. Runtime Assembly and Delivery Plane
9. Learning and Evaluation Plane
10. UI / Inspector / Control Surfaces

These are planes / contract groups, not necessarily separate documents.

---

### 1.4 Source and Evidence Plane

**Decision:** Add as first-class.

Prior drafts underweighted source as a layer. This is wrong because every later decision depends on source authority, source span support, ingestion quality, prompt-injection risk, policy, and materialization state.

**Spec inclusion:** Add `SourceEnvelope` or equivalent:

```ts
type SourceEnvelope = {
  source_ref: SourceRef;
  source_kind:
    | "chat"
    | "note"
    | "document"
    | "pdf"
    | "email"
    | "browser_page"
    | "task_output"
    | "library_source"
    | "external_llm_carryover"
    | "user_direct_statement";
  source_authority_class:
    | "user_direct"
    | "primary_source"
    | "secondary_source"
    | "model_generated"
    | "system_observed"
    | "party_argument"
    | "task_output"
    | "unknown";
  visibility_class: VisibilityClass;
  extraction_quality?: ExtractionQuality;
  prompt_injection_risk?: PromptInjectionRiskFlags;
  source_policy_tags: SourcePolicyTag[];
  materialization_state?: MaterializationState;
  source_segment_refs?: SourceSegmentRef[];
};
```

---

### 1.5 Assertion as canonical truth-apt object

**Decision:** Adopt.

Use **Assertion** as the canonical domain-agnostic truth-apt memory structure. This is clearer than treating Claim, Premise, and Understanding as peer truth stores.

**Spec inclusion:**

- `AssertionCandidate` = staged extracted truth-apt statement.
- `Assertion` = durable canonical truth-apt object with variants.
- `AssertionVariant` = scoped / temporal / authority-specific formulation.
- `Premise` = use role in reasoning / injection, not a separate truth store.
- `Claim` = namespaced only: `LegalClaim`, `EvaluationClaim`, `ClaimExtractorOutput`, etc.
- `ConsolidatedUnderstanding` = source-bound synthesis, not canonical reusable truth.

Normative rule:

```text
The same substantive assertion extracted through a Topic, Library/corpus, chat, Project mode, task output, or manual user action MUST resolve through the same AssertionCandidate → AssertionResolution → Assertion/AssertionVariant pipeline.
```

---

### 1.6 Assertion lifecycle, temporal profile, and disposition routing

**Decision:** Add as mandatory.

Not every truth-apt statement should become durable truth. “Qwen is not working” is usually an incident or friction event, not a durable Assertion.

**Spec inclusion:** Add:

```ts
type AssertionTemporalProfile =
  | "instant_status"
  | "session_lifetime"
  | "short_incident"
  | "rolling_operational"
  | "project_bounded"
  | "source_bounded"
  | "domain_assertion"
  | "standing_preference"
  | "procedure_heuristic"
  | "historical_fact";
```

and:

```ts
type AssertionCandidateDisposition =
  | "discard_not_memory"
  | "retain_ephemeral_observation"
  | "retain_session_note"
  | "record_friction_event"
  | "update_issue_frame"
  | "retain_as_evidence_only"
  | "retain_as_cu_component"
  | "create_or_merge_assertion"
  | "create_directive_candidate"
  | "create_procedure_candidate"
  | "evaluation_only";
```

Assertions should degrade in warrant before deletion:

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

---

### 1.7 Topic is lens plus optional extraction directive

**Decision:** Modify prior treatment.

Topic is not merely a passive organization/search/injection lens. It can also drive extraction through a separate `TopicCollectionDirective`.

**Spec inclusion:** Split:

```text
TopicLens = user-visible semantic lens / search / injection surface.
TopicCollectionDirective = governed extraction rule that may backfill existing memory, scan a selected Library/corpus, or watch future eligible sources.
```

Normative rule:

```text
A Topic may drive extraction, but extracted truth-apt statements must enter the common AssertionCandidate pipeline. Topic membership is an edge, not a truth object.
```

Candidate Topics may group and search already-collected local items, but may not silently enable standing collection, export, delegation, global learning, or broad proactive substantive injection.

---

### 1.8 Library vs corpus

**Decision:** Clarify.

User sees **Library**. Internal ingestion may use `Corpus`, `SourceCollection`, `CorpusIndex`, `SharedCorpusView`, or `MaterializationState`.

**Spec inclusion:**

```text
Library = user-visible source collection.
Corpus / SourceCollection = internal source-processing and deep-ingestion state behind a Library.
```

A Library/corpus can produce EvidenceRecords, CUs, AssertionCandidates, TopicMembershipEdges, IssueFrame updates, and source slices. It does not itself own truth.

---

### 1.9 CU vs Assertion

**Decision:** Clarify and preserve DOC73 semantics.

A `ConsolidatedUnderstanding` is source-bound synthesis. It can generate/support Assertions, but it does not replace the Assertion pipeline.

**Spec inclusion:**

```text
Assertion = reusable truth-apt proposition.
CU = source-bound synthesis over a source set.
```

Example:

```text
CU: “The Marex briefing record shows plaintiff relied on confidential witnesses and insider sales for scienter.”
Assertion: “Insider sales may support scienter only if unusual or suspicious.”
```

The first is source-set-specific. The second is reusable doctrine / proposition.

---

### 1.10 IssueFrame / working-state distinction

**Decision:** Adopt, but rename carefully.

Do not use “IssueFrameEvent.” Use `WorkingStateEvent` or `IssueFrameUpdate`.

**Spec inclusion:**

```text
IssueFrame = live workbench state for an active problem.
WorkingStateEvent / IssueFrameUpdate = append-only update to that state.
```

IssueFrame contains:

- open questions;
- hypotheses;
- rejected paths;
- decision checkpoints;
- blocking source needs;
- next actions;
- linked AssertionCandidates where truth-apt statements are present.

It is not another assertion system.

---

### 1.11 Project optionality

**Decision:** Accept.

Project mode is helpful, but memory must work well without it. The system should assume users often open free chats and do not activate Projects.

**Spec inclusion:**

```text
Project mode is an enhancement layer, not a prerequisite for good memory.
```

Default-mode memory should still use prompt content, entities, recent episodes, Topics, Libraries, directives, normal graph retrieval, working-state events, and explicit search.

Do not introduce “Focus” or “Work Scope” as new user-visible primitives.

---

### 1.12 Policy plane

**Decision:** Separate plane.

Policy is not merely a field inside `MemoryContextPlan`. It governs collection, extraction, write, retrieval, rendering, injection, export, delegation, carryover, learning, UI visibility, and inspection.

**Spec inclusion:**

- `MemoryPolicyDecision`
- `PolicyObligation`
- `PolicyStamp`
- `PolicyStampInvalidation`
- `ScopeMembrane`
- `EpisodePolicyEpoch`

Plans consume policy decisions; they do not define policy.

---

### 1.13 Scope resolution and coordination

**Decision:** Accept modified scope model.

`ScopeRoot` remains valuable but should be decomposed into a scope plane:

```text
ScopeIdentityRoot       — what body of work / knowledge this is.
ScopeEquivalenceBinding — which references are equivalent for dedupe/collapse.
ScopeContainerRelation  — how Projects, Libraries, Topics, and sources contain/overlap/relate.
ScopeMembrane           — policy boundary for egress/export/delegation/learning.
ScopeAffinity           — direct/secondary/shared/analogical/background relation.
ScopeResolutionTrace    — auditable resolution for extraction/injection/UI decisions.
```

Scope coordinates but does not own policy, delivery, rendering, truth, or writes.

---

### 1.14 Three coordination plans

**Decision:** Adopt.

Use three plans tied by `MemoryCoordinationTrace`:

1. `ExtractionContextPlan` — what gets collected/extracted/written.
2. `MemoryContextPlan` — what gets injected, offered as searchable, blocked, or reference-only.
3. `UserContextSurfacePlan` — what the user sees in UI.

These plans prevent scope, policy, extraction, injection, and UI from being treated as one blob.

---

### 1.15 Context products

**Decision:** Adopt as central injection primitive.

DOC24 should not inject generic “memories.” It should assemble context products:

```text
Direct Memory Item
Assertion / Premise Packet
Topic Notice
Topic Slice
Library Notice
Library Source Slice
Recent Work Orientation
IssueFrame Orientation
Directive Block
Procedure Block
Warning / Constraint
Search Affordance
Blocked / Reference-Only Notice
```

Each product must have purpose, allowed roles, source support, warrant, prompt shell, token budget, learning target, and inspection fields.

---

### 1.16 Learning target separation

**Decision:** Accept.

Learning differs by target:

```text
storage/extraction learning
classification/policy learning
organization/membership learning
scope-resolution learning
injection learning
UI learning
prompt-shell learning
```

BDSM/DOC8 should learn whether the **context product** helped, not only whether a card was present.

---

## 2. Decisions rejected or revised

### 2.1 Reject “Focus” as a new primitive

“Focus” was introduced during discussion as a bridging term. It is not in the current specs and conflicts with the Project proposal’s “no global focus mode” posture.

Use Project mode when the user deliberately activates a Project. Otherwise use normal/default mode with inference, Topics, Libraries, recent episodes, and search.

---

### 2.2 Reject “Work Scope” as user-visible primitive

“Work Scope” was also a bridging term. The Project proposal explicitly dropped Work Context as a separate new object and folded it into existing DOC72 work_context / matter / project machinery.

Use internal `ScopeIdentityRoot` / scope model only. Do not expose “Work Scope” by default.

---

### 2.3 Reject Topic as only passive saved view

A Topic can be a saved view / lens, but V4.1 also gives it a prospective extraction face. The better design is:

```text
TopicLens = saved-view/lens semantics.
TopicCollectionDirective = separately governed extraction rule.
```

This preserves user value while preventing overcollection.

---

### 2.4 Reject path-dependent truth stores

A statement extracted from a Topic, Library, corpus, task, Project mode, or chat must not be stored as different truth objects.

Route affects provenance, support, policy, confidence contribution, membership, review requirement, and learning — not canonical identity.

---

### 2.5 Reject “Claim” as unqualified canonical memory term

Claims are not legal-only, but the term is overloaded across legal claims, evaluation claims, task claim extractor outputs, and ordinary truth assertions.

Use `Assertion` as canonical and namespaced `Claim` only where unavoidable.

---

## 3. Open decisions for final review

1. Should the canonical term be `Assertion`, with `Premise` as use role? Current recommendation: yes.
2. Should existing DOC73 `VersionedClaim` map to `AssertionVariant`, CU component, or remain DOC73-specific? Current recommendation: require mapping table by case.
3. Should TopicLens be a first-class object or a saved view with persistent identity? Current recommendation: governed saved view with object identity, but no truth ownership.
4. Should `TopicCollectionDirective` be owned by the memory spec or by PropA/DOC23/EC? Current recommendation: memory spec defines the seam; PropA/EC/DOC23 execute/govern.
5. Should `MemoryContextPlan` be part of DOC24 proper or the new flattened memory spec consumed by DOC24? Current recommendation: define contract in Memory Control Plane; DOC24 owns packet assembly using it.
6. Should lifecycle and learning live in one rebuilt DOC8 family or split into lifecycle and learning docs? Current recommendation: keep coupled in review pack, decide after Phase B audit.
7. Should `MemoryFlowCertificate` be mandatory for every memory movement? Current recommendation: mandatory for durable write, render, export, carryover, delegation, learning attribution; not required for every internal candidate read.