Elnor Repo Reader

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

---

# DOC80 Memory Rebuild — Architect Decision Queue

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Initialized:** 2026-05-25 (Stage 4)
**Last updated:** 2026-06-01 (Stage 6 E0 charter **ratified** — discharge note: ADQ-203/208/210/211/310/313 landed in E0 / DOC80 core; ADQ-207/209/312 *consumed-not-resolved* by E0 (honored; resolution authority unchanged); ADQ-403/404 remain future-completion obligations; **no ADQ status was changed** — all were already resolved at the Stage 4 gate); 2026-05-30 (Stage 6 E0 design discussion — ADQ-406/407/408 added + resolved: TopicCollectionDirective suppression / global recycle bin / restore-from-backup); 2026-05-28 (Stage 5R3 Pass 2 ratification — ADQ-PASS2-01 + ADQ-PASS2-02 added and resolved at landing per Bucket C; both `batch_for_architect`. Prior: Stage 5R2c — tier distribution count corrected `architect_stop: 5 → 6` (D-SEED-1, D-SEED-2, D-SEED-3, D-SEED-4, ADQ-310, ADQ-220); ADQ-312 trigger owners reframed `DAMS V5 → DOC84 (DAMS substrate)` per SM-020 and `DOC8` purged per Stage 5R2 synthesis #5 + ADQ-221; ADQ-222 framing clarified. 2026-05-27 (Stage 5R2b — ADQ-219 text updated with `SourceBoundSynthesisAdapter` rename + OPA-035 cross-ref).)
**Rows:** 49 (48 resolved + 1 open)

ArchitectDecisionQueueItem rows per plan §11.4 schema. Plan §11.4 rule: `default_if_no_response` is FORBIDDEN for `decision_tier = architect_stop`; allowed only for non-blocking batch items.

**Tier distribution:**
- `architect_stop`: 6
- `batch_for_architect`: 43

**Status distribution:**
- `resolved`: 48
- `open`: 1 (ADQ-222 — opened at Stage 5R2 per synthesis must-fix #11; tier = `batch_for_architect`. **Blocking scope (Stage 5R2c clarification):** does NOT block any Stage 6 charter — `blocks_slices = None`. **Conditionally gates Stage 7 schema-body work**: IF architect resolves "draft Phase-1 schemas now," then `PublishedViewEnvelope` / `TaskSharedMemoryExposureContract` / `PublishedLibraryCorpusExposureContract` schemas are drafted at Stage 7. The §11.4 `default_if_no_response = (none)` reflects this Stage 7 gating — the "blocking" word in the row note refers to that conditional Stage 7 schema-body gate, NOT to any Stage 6 charter.)

## Resolved seed decisions (no action required)

| decision_id | tier | question | architect_answer | source_refs |
|---|---|---|---|---|
| D-SEED-1 | architect_stop | Is DOC80 a single spec, a spec family, or a coordinating owner spec? | Spec family. The memory corpus is too large for one document; it must be reviewable, red-teamable, and editable in owner-bounded members. | runbook §13 Task F seed |
| D-SEED-2 | architect_stop | Is the DOC80 family a real owner doc in the ELNOR hierarchy, or a coordination layer that re-homes nothing? | Real owner doc / family. After flattening, the memory schemas must have one authoritative home rather than staying scattered across DOC72/DOC24/DOC73. | runbook §13 Task F seed |
| D-SEED-3 | architect_stop | Are archived / parked / lineage files in active scope for the rebuild? | No. Active scope = Current Specs + Memory Rebuild Docs + active OP-A + Design Mockups + Active Working. Archives are out; reference-on-demand only. | Will, Stage 1 gate 2026-05-25 |
| D-SEED-4 | architect_stop | Are operations/meta docs (plan, runbook, start prompt, review-pack process files, repo navigation) source for DOC80? | No. The 19 operations/meta files (plan, runbook copies, start prompt, review-pack process files 00/01/06/07/09A-F/11, README, manifest) govern HOW we flatten; they are not source content for DOC80. | Will, Stage 3 gate 2026-05-25 |
| ADQ-201 | batch_for_architect | Is `Assertion` the canonical truth-apt term, with `Premise` as use role only? | Yes — `Assertion` canonical, `Premise` use role only, namespaced `Claim` allowed (LegalClaim, EvaluationClaim, ClaimExtractorOutput). | 01_Adjudication_Delta §3 item 1; ABC R0.2 §3.1; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-202 | batch_for_architect | Is Corpus an internal ingestion/read-model state, a higher-level source aggregation scope, or both under different names? | Internal deep-ingestion / source-processing structures (Corpus / SourceCollection / CorpusIndex) sit BEHIND user-visible Libraries. Do NOT make Corpus a user-facing parallel Library. Keep enough internal hierarchy to support provider profiles, source bindings, dedupe, and corpus-scope extraction. Full hierarchy details resolved at Stage 6 E4 charter — HARD COMMITMENT, not infinite defer. | 01_Adjudication_Delta §3 item 4; ABC R0.2 §6.5; 08_Coverage_Audit §3 item 4; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-203 | batch_for_architect | Should `ContextProduct` live in the Memory Control Plane or be absorbed directly into DOC24? | Define ContextProduct contract in Memory Control Plane (DOC80 core); DOC24 owns packet assembly using it. | 01_Adjudication_Delta §3 item 5; 08_Coverage_Audit §3 item 2; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-204 | batch_for_architect | Should TopicLens be a first-class object or a saved view with persistent identity? | Governed saved view with object identity, but no truth ownership. | 01_Adjudication_Delta §3 item 3; 08_Coverage_Audit §3 item 4; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-205 | batch_for_architect | Should `TopicCollectionDirective` be owned by the memory spec or by PropA / DOC23 / EC? | Memory spec defines the seam (TopicCollectionDirective schema, governance rules); PropA / EC / DOC23 execute and govern. | 01_Adjudication_Delta §3 item 4; Adjudication Delta §1.7; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-206 | batch_for_architect | Is IssueFrame necessary, or does it risk becoming a phantom working-state layer? | Necessary — IssueFrame is the workbench (open questions / hypotheses / blocking source needs); IssueFrameUpdate is append-only; truth-apt content must enter AssertionCandidate pipeline. | 08_Coverage_Audit §3 item 6; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-207 | batch_for_architect | Should `MemoryFlowCertificate` be mandatory for every memory movement? | Mandatory for durable write, render, export, carryover, delegation, learning attribution; NOT required for every internal candidate read. | 01_Adjudication_Delta §3 item 7; Round D R0.2 §9.2; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-208 | batch_for_architect | Where does `PromptShellVariant` belong: DOC24, KDA, BDSM/DOC8, or the Memory Control Plane as a cross-cutting contract? | Cross-cutting contract in Memory Control Plane (DOC80 core); DOC24 + KDA + BDSM consume it. | 08_Coverage_Audit §3 item 3; Concept Model §17.9; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-209 | batch_for_architect | Is the three-plan model (ExtractionContextPlan / MemoryContextPlan / UserContextSurfacePlan) too much structure or necessary? | Necessary — separation prevents extraction / injection / UI from being treated as one blob; MemoryCoordinationTrace ties them together. | 08_Coverage_Audit §3 item 7; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-210 | batch_for_architect | Should the flattened memory spec be titled around DAMS lineage or renamed fully to Memory Control Plane? | Title: Memory Control Plane (DOC80 family). DAMS is one substrate inside it. | 08_Coverage_Audit §3 item 8; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-211 | batch_for_architect | Should `MemoryContextPlan` be part of DOC24 proper or the new flattened memory spec consumed by DOC24? | Define contract in Memory Control Plane (DOC80 core); DOC24 owns packet assembly using it. | 01_Adjudication_Delta §3 item 5; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-212 | batch_for_architect | Should lifecycle and learning live in one rebuilt DOC8 family or split into lifecycle and learning docs? | Keep coupled in review pack; decide after Phase B audit (Stage 5/6 architecture confirmation). | 01_Adjudication_Delta §3 item 6; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-213 | batch_for_architect | Should high-confidence, low-risk Topic auto-creation be safe enough if collection and substantive injection remain gated? | Yes, BUT auto-create as INERT, REVIEWABLE LENS only (auto_created_lens state). NO prospective collection, NO substantive injection, NO hidden expansion until TopicRiskClass evaluation AND explicit user confirmation permit each. The lens/notice is cheap and reversible; collection and injection stay gated. | 08_Coverage_Audit §3 item 5; Concept Model §17.4; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-219 | batch_for_architect | Does the Concept Model `ConsolidatedUnderstanding` exactly match DOC73's CU semantics, and if not, does it need a wrapper / adapter name (e.g., `SourceBoundSynthesisAdapter`)? | Conditional rule: (1) DOC73 owns ConsolidatedUnderstanding semantics. (2) DOC80 must NOT redefine CU; DOC80 treats CU as source-bound synthesis only — never canonical reusable truth (reusable truth runs through the AssertionCandidate → Assertion pipeline). (3) If DOC73's CU semantics match the source-bound-synthesis contract, DOC80 consumes DOC73 CU directly. (4) If DOC73's CU diverges, DOC80 uses `SourceBoundSynthesisAdapter` as the DOC82-facing wrapper (renamed from `SourceBoundSynthesisProjection` at Stage 5R2b — see `DOC80_Retired_Names.md` lineage-only entry), with an explicit DOC73 CU → DOC82 mapping table. The adapter is classified under `SemanticProjectionContract` as a `KnowledgeProjection` wrapper case (Owner Map Stage 5R2b additions). (5) The E3/E4 charter performs the DOC73 reconciliation and finalizes either path BEFORE drafting; reconciliation is pinned to that charter, not 'before final spec' in the abstract. (6) Escalation: if the reconciliation surfaces divergence that a wrapper + mapping table cannot cleanly absorb, raise an `architect_stop` — do NOT silently extend the wrapper. (7) Convergence obligation logged as OPA-035 (Stage 5R2b): if the adapter activates, DOC73 must converge OR architect blesses permanent divergence via a new ADQ. Permanent unblessed wrapper activation is a `code_smell`. Dependency: SM-005 depends on this. (SM-202 does NOT depend on it; SM-202's issue was enum vintage and is already fixed in the Supersession Matrix.) | ABC R0.2 §4.5, §16.4, §21.12 item 2; reviewer comments 2026-05-25 (Claude review + GPT review); resolved by Will, Stage 4 gate, 2026-05-25; updated at Stage 5R2b (2026-05-27) with rename + OPA-035 convergence-obligation cross-ref |
| ADQ-301 | batch_for_architect | What is the exact DAMS attenuator formula (signed additive-deviation operator)? | Treat the tanh soft-knee open-interval formulation as the CANDIDATE formula requiring E7 test vectors — NOT finally locked at Stage 4. Architectural decision: DAMS V5 is an attenuator / capacity-prior substrate; exact formula remains test-vector-gated and is finalized in the E7 charter, not here. | Round D R0.2 §8.2; DAMS V5 Outline §13.3; ABC R0.2; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-302 | batch_for_architect | What is the exact promotion criterion for FrictionPattern → Assertion? | Promote ONLY through AssertionCandidate pipeline when: (a) ≥2 consistent FrictionEvents with source support and no contradictory FrictionEvent; OR (b) ONE authoritative / system-confirmed diagnostic event with source support and no contrary FrictionEvent. Either path produces an AssertionCandidate; no direct promotion bypass. Owner: EC. | ABC R0.2 §7.14; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-303 | batch_for_architect | What are the exact numeric thresholds for content_faithfulness fail / unknown / unacceptable in SourceParseQualitySidecar? | Domain-profile-specific thresholds in DAMS V5 / DOC25 owner doc; defer to Stage 6 E4 (Source / Evidence) charter. | ABC R0.2 §7.11; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-304 | batch_for_architect | Cascading source invalidation: precisely what counts as 'losing the LAST active support edge'? | Variant retires or becomes audit_only iff NO OTHER lawful support edge from another source remains; partial loss → warrant degradation only. | Round D R0.2 §10.2; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-305 | batch_for_architect | Which prompt headers are stable vs volatile in DynamicHeaderLedger (for KV-cache reuse on policy change)? | Headers are stable ONLY if BOTH hash-pinned AND policy-invariant. System role: stable only if hash-pinned and unchanged by profile / policy / model class / destination; otherwise volatile. Stable candidates: model identity, version_pinning. Volatile: policy_generation_id, scope_resolution_result, ContextProduct policy stamps, profile-dependent role variants. Owner DOC24/KDA finalizes manifest in E7 charter. | Round D R0.2 §9.3; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-306 | batch_for_architect | What is the review-queue auto-archive TTL for nonblocking items? | Auto-archive = REMOVE FROM PRIMARY (NONBLOCKING) QUEUE; preserves audit and search visibility (NOT deletion or loss of audit trail). User-dismissible + configurable TTL; default 7–14 days depending on domain. Architect picks default at Stage 6 E10 charter. | Round D R0.2 §11.2; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-307 | batch_for_architect | What is the Topic future-watch velocity threshold → action matrix? | low → continue; medium → cluster; high → degrade; unbounded_requires_review → pause + ask. Tiers/actions: 4×4 matrix to be filled at Stage 6 E10. | Round D R0.2 §12.2; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-308 | batch_for_architect | What vocabulary is approved for safe labels in Inspector? Where does the registry live? | Central vocabulary registry maintained by PropA/EC; labels must not be derived from protected content (Round D §6.2). | Round D R0.2 §6.2; fixtures D-3; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-309 | batch_for_architect | ProjectAutoLinkState: TTL / grace period for quarantine? | Fixed TTL (architect picks duration) OR user-dismissible; policy-safe resolution clears immediately. Recommended: 48-hour TTL + user-dismissible. | Round D R0.2 §0A.5, §4.1; fixtures D-10; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-310 | architect_stop | Who owns the canonical ReasonCode registry? | DOC80 core/contracts member owns the canonical ReasonCode registry and namespace rules; EC / PropA / DOC24 / DOC8 / DOC20 / etc. own producer-specific reason-code entries within that registry. This unblocks E0/E1/E2 — they can refer to the registry without inventing local reason-code systems. | Round D R0.2 §0A.3; resolved by Will, Stage 4 gate, 2026-05-25 |
| ADQ-311 | batch_for_architect | Should the qualifier_set mismatch always block auto-merge of Assertions, or are there exceptions? | Absolute; qualifier_set mismatch → never auto-merge (no exceptions). | ABC R0.2 §3.7; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-312 | batch_for_architect | Is the warrant degradation trigger list (ABC §7.13) exhaustive, and who owns each trigger? | ABC §7.13 list is the INITIAL CONTROLLED REGISTRY (not permanently exhaustive). New trigger kinds require owner/architect approval and go through the Architect Decision Queue. Initial owners (Stage 5R2c — `DAMS V5` reframed to `DOC84 (DAMS substrate)` per SM-020; `DOC8` purged per Stage 5R2 synthesis #5 + ADQ-221, proof_gated_outcomes reassigned to DOC85): user_correction → EC; time_window → DOC84 (DAMS substrate); confidence → DOC84 (DAMS substrate); contrary_source → EC; policy_change → PropA/EC; supporting_CU_stale → DOC73; parse_quality_audit → DOC25; proof_gated_outcomes → DOC85; session_bound_expiry → DOC24. | ABC R0.2 §7.13; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable); trigger-owner names reframed at Stage 5R2c (2026-05-28) per SM-020 / Stage 5R2 synthesis #5 / ADQ-221 |
| ADQ-313 | batch_for_architect | How are domain profiles registered, and what is the fallback if no profile exists? | Central domain profile registry (Memory Control Plane); explicit fallback rule: missing profile → use 'conservative' default profile (highest restrictiveness). | ABC R0.2 §3.7; Round D R0.2 §3.6; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-314 | batch_for_architect | Should the (temporal_class, epistemic_kind) combinations be enumerated as a validity table? | Yes — create validity table at Stage 6 E3 charter; invalid combos (e.g., instant_status + standing_preference) flagged at lifecycle transition. | ABC R0.2 §3.8; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-315 | batch_for_architect | AssertionRelationEdge traversal: what scope checks apply per relation kind? | Owner-doc EC specifies: relation_kind → required scope checks + render gating. Decision deferred to Stage 6 E1 charter (Scope/Policy lockstep). | Round D R0.2 §3.7; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-316 | batch_for_architect | Policy restamp: what can it preserve / downgrade / block? | Restamp may keep, downgrade, or block under current policy_generation_id; CANNOT grant access beyond original ceilings (formalize in EC policy evaluator decision table). | Round D R0.2 §5.4; fixtures D-14; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-317 | batch_for_architect | Disclosure class selection: who decides suppressed_manifest_only vs generic notice? | EC policy evaluator with decision table based on disclosure_class. | Round D R0.2 §6.1, §6.3; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-318 | batch_for_architect | Where should the full consolidated supersession table be authoritatively documented? | Supersession_Matrix.md (this file) — referenced by skeletal DOC80 §section_map and the Stage 5 retired-name table. | Round D R0.2 §0A.4; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-401 | batch_for_architect | Should DOC25 file-materialization + provider profiles proposal land in DOC80 V5 core, defer to future, or federate to DOC25? | include_as_future_completion_obligation; minimum_completion_for_v5 = schema_plus_owner_boundary; owner DOC25 + DOC80 core. | AC-001; Stage 3 capability cap-doc25-file-materialization-and-provider-profiles-proposal-v1; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-402 | batch_for_architect | Should DOC73 corpus-source-bindings proposal land in DOC80 V5 core, defer to future, or federate to DOC73? | include_as_future_completion_obligation; minimum_completion_for_v5 = schema_plus_lints_and_fixtures; depends on ADQ-202 (Corpus hierarchy). | AC-002; Stage 3 capability cap-doc73-corpus-source-bindings-proposal-v1; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-403 | batch_for_architect | Should the Memory Intake and At-Use Disciplines proposal land in DOC80 V5 core or defer? | include_as_future_completion_obligation; minimum_completion_for_v5 = schema_plus_lints_and_fixtures; owner Memory Control Plane (DOC80 core) + DOC25 + DOC73. | AC-004; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-404 | batch_for_architect | Should EC Core Addendum A intake-routing for corpus bindings land in DOC80 V5 core? | include_as_future_completion_obligation; depends on ADQ-202 (Corpus hierarchy); owner EC Core + Memory Control Plane. | AC-005; resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-405 | batch_for_architect | Should DOC73 RecentActivityRollup mechanism (§6.4 mechanism 4) land in DOC80 V5 core, and how is the DOC73↔DOC80 seam tracked? | RecentActivityRollup lands in DOC80 V5 core as an orientation-only crown-jewel family per plan §6.4 and ABC R0.2 §4.4. **Owner seam:** DOC73 owns generation / source-bound rollup semantics; DOC80 owns the consumption contract, the `can_orient_only` invariant, delivery constraints, and lints/fixtures. **Minimum completion for V5:** `schema_plus_lints_and_fixtures` (plan §7 enum) — NOT merely `schema_plus_owner_boundary`. RecentActivityRollup is a dangerous seam; without a concrete lint/fixture it can quietly become evidence, recency bias, or pseudo-truth. **Required E6 lint/fixture must prove:** (a) RecentActivityRollup MAY orient the model / user; (b) MAY support resume / orientation; (c) MAY point to source refs or episodes; (d) MAY NOT supply evidentiary warrant; (e) MAY NOT justify an Assertion; (f) MAY NOT be cited as support unless the underlying source is separately retrieved AND policy-cleared through the canonical evidence/assertion path. **Cross-doc seam tracked via OPA-024.** DOC24/KDA consume only policy-cleared orientation products. | AC-003; ABC R0.2 §4.4; plan §6.4 (RecentActivityRollup crown-jewel family); plan §7 (minimum_completion_for_v5 enum); reviewer comments 2026-05-25 (Claude review + GPT review); resolved by Will, Stage 4 gate, 2026-05-25 (per reviewer-mediated approval; modifications already applied to recommended_answer where applicable) |
| ADQ-220 | architect_stop | Where should organization/membership live in the DOC80 family — DOC82 (knowledge), DOC84 (delivery), DOC86 (UI), or a new dedicated member? | **Create an 8th family member, DOC87 — Memory Organization & Membership.** Membership (the durable `member → container` relation across Topic / Library / Project / Episode / IssueFrame / Entity) is upstream of both DOC84 (delivery consumes membership) and DOC86 (UI renders membership), so it cannot live inside either. It is also a cross-plane edge that does NOT belong in DOC82 (knowledge — would force canonical-knowledge to define what a Topic/Library/Project is). DOC87 owns: `MemoryMembershipEdge`, `MembershipLifecycleState`, `MembershipSource`, `MembershipInvalidationPolicy`, the membership invariants, `TopicLens` organization semantics, `TopicActivationState` (the Topic lifecycle), the Topic object, Library-as-organizational-container. DOC87 does NOT own truth (DOC82), source/corpus (DOC25/DOC73/DOC82), extraction (DOC83), `TopicCollectionDirective` (DOC83 — references DOC87's Topic identity via lateral import), policy/scope (DOC81), delivery/prompt (DOC84), learning (DOC85), UI rendering (DOC86/DOC20), Project mode (DOC20), durable writes (EC), or graph storage (DOC72). Plan §12 slice list amended to insert organization/membership slice between E6 and E7. Family count 7 → 8. | (forbidden — architect_stop tier) | Stage 5 round-1 red-team review (Claude-synthesizer pass) 2026-05-26; reviewer-architect adjudication; resolved by Will, Stage 5R gate, 2026-05-26 |
| ADQ-221 | batch_for_architect | What is the formal status of BDSM and DOC8 as DOC85 dependencies — real, partial, or phantom? Which BDSM surfaces may DOC85 consume? | **BDSM `dependency_status` = `partial`.** BDSM v6.5 Draft v0.3.1 (`Current Specs/DOC24/DOC24_Addendum_A_BDSM_V6_5_DRAFT_v0_3_1.md`) is the operative source — well-drafted but not complete; will require review and revision rounds, and will be revised / reorganized / improved alongside the new DOC80 memory system. **DOC8 = capability-mining input only**, not a runtime dependency: very old, essentially a skeleton sketch, contains useful concepts but needs a full rewrite. **Specific BDSM surfaces DOC85 may consume are deferred to the DOC85/E9 charter at Stage 6**, where DOC85 drafting coordinates with BDSM's own revision work (the new memory system architecture changes what BDSM needs to expose). | E9 (Learning) charter at Stage 6 (resolved before Stage 5R round-2 finalized — no longer blocks) | (none — resolved) | Stage 5 round-1 red-team review §II-3 + §III ADQ-221 recommendation 2026-05-26; resolved by Will, Stage 5R inter-round, 2026-05-26 |

| ADQ-PASS2-01 | batch_for_architect | Does `PBEClusterDetectionResult` live in DOC72 as the superset read-model (DOC73 consumes a minimum projection), or in DOC73 as the owner (DOC72 stores a denormalized copy)? | **DOC73 owns the schema; DOC72 stores graph payload; EC writes durably.** PBE is the producer; the schema lives with the producer. This follows the existing pattern in the post-flatten architecture: DOC73 owns ConsolidatedUnderstanding as source-bound synthesis; DOC72 stores graph payload; EC writes. Cluster detection results are PBE-mechanism output (source-bound), not standalone graph features. If PBE design later proves cluster membership to be pure graph-derived state (i.e. changes only when graph edges change, not when PBE state changes), reopen as a follow-up ADQ. Unblocks E3 (DOC82 knowledge) cluster-detection read-model consumption + the DOC72 graph-schema freeze. OP-A V4 candidate: `OBL-D72-NEW-PBE-CLUSTER-01` retargets DOC72 → DOC73; DOC72 referenced as storage executor in the row body. | Stage 5R3 Pass 2 Bucket C item 1; OPA V3.18 line 534 + line 2437; mirrors OPA-001 (Assertion: DOC82 schema + DOC72 storage + EC write) and ADQ-219 (CU: DOC73 schema + source-bound); resolved by Will, Stage 5R3 Pass 2 ratification, 2026-05-28 |
| ADQ-PASS2-02 | batch_for_architect | Who owns the canonical corpus↔'library' identity mapping: DOC24 (search/onboarding), DOC87 (E_org membership identity), or DOC25 (ingestion)? And is `OBL-D24-CORPUS-LIB-MAP-01` the same obligation as `OBL-D7-NEW-LIBRARY-NAMING-01` (merge) or distinct (keep both)? | **(a) Identity authority: DOC87 owns the canonical corpus↔library identity mapping.** Library lives at DOC87 as organizational container per ADQ-220 (Owner Map: `Library-as-organizational-container` → DOC87); identity-authority stays where the container lives. DOC25 owns the corpus storage side (CorpusIndex / SourceCollection); DOC24 consumes the mapping at search/onboarding time but does not own it. **(b) Dup question: NOT a dup.** The merge question was already resolved at the V3.8 landing — see OPA V3.18 line 3431 ("Architect merge decision: see Appendix A — V3.7 row is UI rendering; V3.8 row is schema-level reconciliation gate. Both should remain."). The two rows are distinct: OBL-D7-NEW-LIBRARY-NAMING-01 is the UI rendering rule (retargets cleanly DOC7 → DOC86 in OP-A V4); OBL-D24-CORPUS-LIB-MAP-01 is the schema-level identity reconciliation gate (retargets DOC24 → DOC87 in OP-A V4 per this resolution). Both remain in V4. Unblocks E1 (DOC81 scope) corpus/library vocabulary + E_org (DOC87) membership identity; ties to SM-040 + OPA-032 TopicIdentityContract. | Stage 5R3 Pass 2 Bucket C item 2; OPA V3.18 line 3426 (V3.8 row), line 3431 (architect merge decision pointer recording the dup resolution); ADQ-220 (DOC87 organization/membership identity); Owner Map row `Library-as-organizational-container` (DOC87); resolved by Will, Stage 5R3 Pass 2 ratification, 2026-05-28 |
| ADQ-406 | batch_for_architect | Should `TopicCollectionDirective` carry a suppression/exclude polarity so user-defined "privacy topics" prevent collection on those subjects — a topic-level privacy layer atop EC §1 surface toggles? | Yes. Add a `collection_mode` (collect / suppress / exclude) to `TopicCollectionDirective`; **DOC81 owns the suppression governance rules** (memory-family seam per ADQ-205); the **EC §1 collection gate enforces** at admission; user-defined "privacy / dummy topics" are topics whose directive is `suppress`. Stacks with EC §1 per-surface toggles + §1.3 incognito as defense-in-depth. Implementation deferred to the DOC81 (E1/E2) charter; tracked via OP-A `OBL-D81-TOPIC-COLLECTION-SUPPRESSION-01` + DOC80 card §15.4 gate row. | Will, Stage 6 E0 design discussion 2026-05-30; extends ADQ-205; EC Core Addendum A V3.3 §1 / §1.3 |
| ADQ-407 | batch_for_architect | Should soft-delete / recycle-bin / restore be a GLOBAL deletion-&-recovery service spanning all object types (documents, artifacts, chats, tasks, presets, memory) plus background deletions, rather than memory-only? | Yes — a global EC / control-plane deletion-&-recovery service. EC Core Addendum A V3.3 already owns the machinery: node `tombstoned` state, `gc_policy` (purge / archive / tombstone), the §8 artifact-retention matrix, and the §4 BackgroundJobOrchestrator for expiry sweeps. Every object-owner conforms (two-stage: soft-delete/tombstone → retention window → restore OR purge). DOC80 memory deletion conforms and adds the memory-specific proof layer (`ErasureMFC` / `RestoreMFC`). Retention window ("Empty now" / "Save N days", changeable) is a global memory SETTING in EC §1.1 (NOT DOC23). Recycle-bin entries MUST carry a human-readable label + openable preview (library title; openable memory) for restore. Tracked via OP-A `OBL-EC-GLOBAL-RECYCLE-BIN-01`. | Will, Stage 6 E0 design discussion 2026-05-30; EC Core Addendum A V3.3 §1.1 / §4 / §8 |
| ADQ-408 | batch_for_architect | Is there a first-class "restore / provision from full backup into a fresh install" flow, or only export (EC §8) + node sync / import-merge (EC §7)? | Add a named restore / provision-from-backup flow composing EC §8 `full_raw_backup` export → fresh-install import (the §7 import/merge case is trivial when the destination store is empty), with verify-on-completion. EC §7 / §8 owns it. Needed for the new-computer case (back up memories on the old machine; reinstall ELNOR and re-load). Tracked via OP-A `OBL-EC-RESTORE-FROM-BACKUP-01`. | Will, Stage 6 E0 design discussion 2026-05-30; EC Core Addendum A V3.3 §7 (migration/import) / §8 (export/backup) |

## Open decisions (batch for architect)

| decision_id | tier | question | recommended_answer | blocks_slices | default_if_no_response | source_refs |
|---|---|---|---|---|---|---|
| ADQ-222 | batch_for_architect | Network / sharing forward-compatibility — should DOC80 V5 explicitly support Phase-1 sharing (DOC73 web-shared Library/Corpus pages; DOC23 task pages / artifacts / deliveries shared outside the full DOC20 shell)? If yes, full envelope/contract schema bodies (`PublishedViewEnvelope`, `TaskSharedMemoryExposureContract`, `PublishedLibraryCorpusExposureContract`) are drafted at Stage 7 with the appropriate OP-A seam wiring. If no, OPA-034 stays as a tracked seam only and schemas wait for V6 or later. **Phase 2 networking** (mobile sync, multi-device, shared Projects, cross-user memory, remote write authority) is out-of-scope for V5 regardless per the V5 non-goal sentence in DOC80 §1. | Phase-1 sharing recognition + OP-A seam rows (OPA-034 already added); full schema bodies deferred to Stage 7 conditional on architect saying "draft them now." Recommended path: **DEFER schema bodies to Stage 7** — the recognition + seam invariant (DOC23 owns task graph mechanics; DOC73/DOC25 own Library/Corpus mechanics; DOC80 governs ONLY memory-derived exposure on those shared surfaces) is enough at Stage 5R2. | None (does not block Stage 6 charters in general; gates only Stage 7 schema-body work IF architect resolves "draft Phase-1 schemas now") | (none — blocking on the schema-body question per plan §11.4) | Stage 5R2 synthesis §7; OPA-034 seam row; Codex round-2 cross-user/sharing gap finding |

## Verification

- ✓ No unresolved `architect_stop` row carries a `default_if_no_response` (plan §11.4 enforcement).
- ✓ All open blocking batch rows have no default (plan §11.4: defaults allowed only for non-blocking batch items).