Elnor Repo Reader

# Reviewer Prompt — DAMS V5 / Memory Control Plane Pre-Spec Review Pack

**Send to:** prior DAMS reviewers and fresh reviewers with ELNOR background.  
**Attach:** all files in the DAMS V5 Pre-Spec Review Pack.  
**Do not send to:** execution agents as implementation instructions. This is a conceptual/spec red-team prompt.

---

## Orientation — read first

You are reviewing a **pre-spec review pack**, not a final operative specification.

The goal is to determine whether the latest conceptual model is clear enough to support drafting the real DAMS V5 / Memory Control Plane spec and the separate Flatten-and-Unify Plan.

The review must keep two things distinct:

1. **Memory architecture / DAMS V5 concept model** — the proposed canonical memory concepts, extraction pipeline, assertion model, Topics, Libraries, CUs, scope, policy, injection products, and learning targets.
2. **Flatten-and-Unify plan** — the procedural plan for consolidating existing overlapping memory specs without creating a half-migrated mess.

You may find one sound and the other flawed. Say so cleanly.

---

## Background

ELNOR is a local-first AI orchestration platform for sustained, high-stakes knowledge work. It is being specified now; nothing is final. A core discipline is **no phantom features**: every control, schema, route, prompt product, and learning signal must map to something real and inspectable.

DAMS V4.1 was a proposal that demoted DAMS from “the memory system” to a substrate inside a broader memory architecture. The latest discussion moved beyond the V4.1 frame and introduced a clearer flattened architecture:

- sources and evidence;
- canonical memory objects;
- organization surfaces like Topics and Libraries;
- temporal/working-state memory;
- policy and permissions;
- scope resolution;
- extraction/ingestion;
- DOC24 runtime delivery;
- learning/evaluation.

The most important new rule is:

```text
Extraction route must not determine canonical knowledge identity.
```

A truth-apt statement extracted through a Topic, Library/corpus, chat, Project mode, task output, or manual user action must enter the same AssertionCandidate → AssertionResolution → Assertion/AssertionVariant pipeline.

---

## What to review

Read these files in order:

1. `00_README_DAMS_V5_PreSpec_Review_Pack.md`
2. `01_Adjudication_Delta.md`
3. `02_Concept_Model_and_Canonical_Knowledge_Resolution.md`
4. `05_Worked_Examples_and_Fixtures.md`
5. `06_Research_to_Requirements_Matrix.md`
6. `03_DAMS_V5_Spec_Outline.md`
7. `04_Flatten_and_Unify_Plan_V1.md`

---

## Required report structure

# Part 1 — Architecture judgment

Give a bottom-line disposition:

```text
Adopt as basis / adopt with modifications / do not proceed yet / reject core model
```

Then answer:

1. Does the nine-plane framing clarify the memory architecture or create unnecessary abstraction?
2. Does the Source / Route / Object / Organization / Delivery distinction work?
3. Does the canonical Assertion pipeline avoid parallel truth stores?
4. Is `Assertion` the right canonical term, or should the spec retain `PremiseFamily`, `Claim`, or `Understanding` differently?
5. Does the CU vs Assertion boundary work?
6. Does the TopicLens + TopicCollectionDirective split capture both Topic use and Topic-driven extraction?
7. Does the Library/corpus distinction work from both user and implementation perspectives?
8. Does IssueFrame / WorkingStateEvent avoid becoming another assertion system?
9. Does the assertion lifecycle handle ephemeral, recurring, durable, source-bound, and historical claims?
10. Can an extraction agent actually apply the proposed decision tree?

# Part 2 — Injection judgment

Answer:

1. Does the context-product model improve injection clarity?
2. Are the proposed context products complete?
3. Should DOC24 inject a Memory Use Contract before memory sections?
4. Are Topic Notice / Topic Slice and Library Notice / Library Source Slice well-defined and useful?
5. Does the model prevent prompt clutter and context jumble?
6. Does it sufficiently inform the model what more is available without flooding context?
7. Are role, warrant, source support, freshness, and scope relation the right item headers?
8. Are the research-derived injection rules actionable enough?
9. Are there missing product-level learning signals?
10. Does this duplicate or conflict with DOC24/KDA/DOC15/BDSM boundaries?

# Part 3 — Policy and scope judgment

Answer:

1. Is Policy Plane correctly separate from MemoryContextPlan?
2. Is typed MemoryPolicyDecision sufficient, or is more policy structure required?
3. Is Scope Resolution over-structured or necessary?
4. Does the scope model coordinate Projects, Topics, Libraries, Episodes, and memories without becoming UI clutter?
5. Does it prevent cross-scope/ethical-wall leakage?
6. Does it avoid over-relying on Project mode?

# Part 4 — Worked examples stress test

For each fixture in `05_Worked_Examples_and_Fixtures.md`, classify it as:

```text
passes cleanly / mostly passes / ambiguous / fails
```

For every ambiguous/failing fixture, state:

- what object type is unclear;
- what route or policy is unclear;
- what injection product is unclear;
- what spec change fixes it.

You must specifically address:

1. Qwen not working.
2. Qwen locked model config.
3. Memory system broken due to underspecified specs.
4. Ninth Circuit scienter from Topic and Library/corpus.
5. Marex briefing CU.
6. Call me Will.
7. Mix harsh at 3kHz.
8. Pineapple allergy updated.
9. Topic extraction over same corpus as Library ingestion.
10. RecentActivityRollup orientation-only.

# Part 5 — Flattening-plan judgment

Answer:

1. Does Phase 0 Source Freeze solve status/normative-weight confusion?
2. Is A0/B0/A1/B1 sequencing correct?
3. Are the audit records sufficient?
4. Is the learning-engine reconstruction deliverable sufficient?
5. Is Phase C.5 skeletal spec gate strong enough?
6. Are tracer bullets plus vertical pilot necessary or redundant?
7. Does the DesignDecisionLedger prevent AI agents from silently adjudicating design wins?
8. Does the RetirementMap / OP-A disposition / lint system prevent half-migration?
9. What is missing before Phase E execution?

# Part 6 — Final recommendations

Provide:

1. Items you would accept unchanged.
2. Items you would modify.
3. Items you would reject.
4. Missing ideas.
5. Highest-risk remaining ambiguities.
6. Suggested revised outline for DAMS V5, if different.
7. Suggested revised flattening plan, if different.

---

## Review style

Be direct. Do not smooth disagreement. If two concepts are overlapping, say so. If the naming is bad, propose better naming. If a fixture does not classify cleanly, treat that as strong evidence the concept model is not ready.

Every identified bug should include a fix.

Every proposed new concept should include:

```text
what writes it;
what reads it;
what it changes;
how it is inspected;
what happens if it fails.
```

---

## Specific issues reviewers should attack hard

1. Whether Assertion / CU / Topic / Library are truly distinct.
2. Whether Topic-driven extraction can share the same canonical pipeline as corpus extraction.
3. Whether ephemeral assertions are handled without memory pollution.
4. Whether IssueFrame is necessary or another phantom layer.
5. Whether DOC24 context products are too many, too few, or wrong.
6. Whether the policy plane is too broad or under-specified.
7. Whether Scope Resolution is doing too much.
8. Whether the learning split is implementable.
9. Whether Project optionality is preserved.
10. Whether this is now a broader flattened memory system rather than DAMS, and whether the spec naming should reflect that.