ELNOR REPO READER TEXT MIRROR Original path: Active Working and Red Team/Instructions and Prompts/ELNOR_UNIFIED_CARRYOVER_PROMPT.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # ELNOR — Unified Context Carryover Prompt for New Chat Windows You are assisting Will, the principal architect of ELNOR, a local-first AI orchestration platform built on OpenClaw (Node.js/npm). This prompt provides comprehensive architectural context. Stand by for instructions at the end — you may be red-teaming a spec, preparing amendments, reviewing code, adjudicating findings, writing operative sections, or performing integration analysis. ## Header — Repository state (2026-05-27) **Repo:** `/Users/OpenClaw1/Elnor/Elnor Specs/` — GitHub `wbrody/Elnor-Specs`, branch `main`. Migrated 2026-05-27 from old `ECQ Development/CURRENT SPECS AND BUILD DOCS/` tree. **Filename convention:** GitHub tracks history. **No version suffixes on new filenames.** Pre-existing version-suffixed files (`DOC72_HYPER_INTELLIGENCE_OVERLAY_R5_73.md`, `OPA_V3_18.md`, etc.) are legacy — they remain as-is until Will renames them. Do not create new versioned copies. **Per-DOC subfolders:** Specs live under `Current Specs/DOC#/.md`, not flat. Each DOC# subfolder may hold the parent spec + addenda + proposals + helper docs. **Top-level folders in repo:** - `Current Specs/` — operative specs (per-DOC subfolders) - `Active Working and Red Team/` — RT folders + Instructions and Prompts (where this carryover lives) - `Memory Rebuild Docs/` — Flattening Plan + DOC80 family target baseline + execution ledger - `OP-A and Operations and Trackers/` — SPEC_STATE, ADDENDA_STATE, DRIFT_LOG, MASTER_SPEC_DOCUMENT_LIST, OPA, BACKUP_LOG, RECENT_WORK_SUMMARY, dashboard.html (gitignored) - `Archived and Subsumed Specs and Lineage/` — history (out of scope for nightly sync) - `Design Mockups/` — UI design - `Parked and Abandoned Specs/` — not active **Flattening Plan in progress — Stage 5R:** Will is restructuring the memory system into a DOC80-DOC87 family (8 members; DOC87 added at Stage 5R for Membership/Organization). Round 1 patches applied; awaiting Round 2 red-team review. Stage 6 (Slice Charters) blocked until Round 2 ratifies. Skeletal target baseline at `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md`. Plan at `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md`. Current state at `Memory Rebuild Docs/Flattening/Execution Ledger/Master/RUN_STATE.md`. DOC80 has a single proposal; DOC81-DOC87 don't yet have spec files. The older DOC72/DOC73/DOC1 memory stack remains operative until Stage 7+ ships replacements. **Volatile state lives on the dashboard**, not in this carryover. For current in-flight items, recommended next actions, per-workstream backlog, and the per-document "where I left off" summary, see `dashboard.html` (in `OP-A and Operations and Trackers/`) — its Recent Work Summary panel is refreshed nightly. The carryover holds STABLE architectural context. **Workstream map A through K** (Capability Registry Sweep added 2026-04-27 as workstream K). Plus the in-progress Memory Rebuild / Flattening Plan workstream. See dashboard for per-workstream state. ## 0. What ELNOR Is ELNOR is a **local-first orchestration platform** for long-running AI work. It is not a magic chat wrapper. It is a real system that: - stores durable truth as files on disk, - routes work deterministically through Elnor Core (EC), - keeps UI, runtime, memory, and retrieval boundaries honest, - supports structured red-teaming, review, learning, and multi-step workflows, - and makes every user-visible control map to something real. Will is still in the **spec completion / red-team / design-hardening phase**. **Nothing is considered final. Nothing is implemented yet.** The goal is to make specs complete enough that future implementation does not drift, guess, leave out UI/data contracts, or recreate prior "phantom button / phantom memory / phantom wiring" failures. The primary user is a securities litigator, but the architecture must be **domain-agnostic** — the same system with different domain profiles should work for a developer, a musician, a doctor, or anyone doing sustained knowledge work. Legal is one profile, not the foundation. **Runtime environment:** Single M4 Pro MacBook under an isolated macOS user account ("OpenClaw1"), Node.js/npm, multi-model architecture: - Gemini 2.5 Pro — primary LLM - Kimi 2.5 / DeepSeek — bulk processing - Ollama (local) — privacy-sensitive work, embedding, cheap extraction - Claude API — high-stakes tasks only - Qwen3-Embedding-0.6B via MLX — embedding infrastructure (locked, not configurable) --- ## 1. Core Architecture — Three Systems ELNOR is built from three distinct systems. Understanding the boundaries prevents overlap. ### 1.1 Knowledge System (the brain) — understands the world | Doc | Role | |---|---| | **DOC72** | Hyper Intelligence Overlay — entity graph architecture, node taxonomy, confidence model, knowledge intake pipeline, domain signal profiles, goals, standing procedures, temporal resilience, embedding infrastructure, semantic folding, six-dimension knowledge framework | | **DOC73** | **(NEW, operative)** Positronic Brain Enhancement (PBE) — additive enhancement layer over DOC72: deep knowledge corpora, context-aware extraction, universal living memory with carve-outs, ConsolidatedUnderstanding compositional reasoning primitive, cluster emergence, self-improvement engine, corpus extraction architecture, operational layer | | **DOC25** | **(NEW)** Document Intelligence & Universal Ingestion Architecture — defines `DOC25_IngestionResult` consumer contract; tiered context management (Tier 1 Full PDF / Tier 2 Cached / Tier 3 Summary+Excerpts); document type classification; pre-computation pipeline. Promoted from former "Document Intelligence Spec" addendum. | | **DOC1** | Memory Resilience — Write Gate, maturity lifecycle, confidence calibration, authority memories, contradiction detection | | **DOC8** | Self-Learning — friction detection, positive signals, cross-graph pattern detection, behavioral optimization, extraction threshold tuning, BDSM computational engine | | **DOC3** | App Skills — skill acquisition pipeline, observe → synthesize → propose → review → promote | ### 1.2 Operations System (the nervous system) — communicates and coordinates | Doc | Role | |---|---| | **DOC24** | Unified Knowledge, Capability, and Onboarding Architecture — capability registry, routing cascade, tool packs, MCP, receipts, packet assembly, knowledge-to-LLM delivery architecture | | **DOC15** | Cognitive Infrastructure Layer (CIL) — injection hierarchy, authority injection, token budgets, context assembly | | **DOC10** | Unified Engagement Orchestration — cross-surface orchestration, route behavior, traces, receipts | | **DOC11** | OpenClaw Gateway — runtime truth, model routing, auth, session state machines | | **DOC4** | OpenClaw Bridge — native tools, ambient baseline | ### 1.3 Body (the muscles) — acts in the world | Doc | Role | |---|---| | **DOC23** | Task System — 36-module modular automation pipelines (Eurorack-inspired, typed cables, gates, validation) | | **DOC12** | Inter-Agent Communication — rooms, panels, forums | | **DOC16 Entry 16.7** | M365 deep integration (email, calendar, Teams, 40 case calendars) | | **DOC18** | LlamaIndex Retrieval Sidecar — corpus-scoped semantic retrieval (NOT canonical memory) | | **DOC20** | Browser, Notes, Document Viewer — Q's content surfaces | | **DOC14** | CANDOR — universal adversarial review engine | | **DOC17** | Overlay Library, Prompt Advisor, Prompt Lab | ### 1.4 Information Flow - **Perceiving:** World events → Body → Operations (routes) → Knowledge (learns, updates graph) - **Acting:** User request → Operations (routes, resolves, mounts packs, assembles packet from Knowledge) → Body (executes) → Operations (captures receipt) → Knowledge (updates graph) - **Learning:** Knowledge produces intelligence → Operations delivers it → Body executes → outcomes flow back through Operations to Knowledge. Loop continues. --- ## 2. Elnor Core (EC) — The Deterministic Orchestrator EC is the **deterministic orchestrator and sole durable writer**. EC owns: - command ingestion - durable writes under `ELNOR_MEMORY/` - memory extraction and current views - orchestration state - indexing/control-plane coordination - nightly jobs - learning ingestion and derived-state rebuilds - cross-surface truth assembly Durable state: - **SQLite** (WAL mode, single writer, append-only JSONL audit) — entity graph + DOC1 memories - **Atomic JSON current views** for fast reads - **Optional derived indexes/caches** only if rebuildable from canonical truth **Do not introduce a second hidden durable writer.** This is non-negotiable. ### 2.1 Q — The Dashboard / UI Control Surface Q does NOT own durable truth. Q: - submits structured commands - renders current/durable state - shows inspectors, browsers, traces, suggestions, health, receipts, rooms, panels Q must not become a fake shell with buttons that do nothing. Every meaningful action maps to: ``` user action → EC command → durable write (or explicit no-op/degraded path) → telemetry → visible read-model ``` Q Dashboard is the Electron desktop application. Built with React + Vite + TypeScript + Tailwind CSS. Canonical design source: `Q_UNIFIED_WORKSPACE_V8_0_1.jsx`. Monochrome tonal aesthetic ("Bloomberg Terminal meets Linear"). ### 2.2 OpenClaw — The Native Runtime OpenClaw owns: - native prompt/session history - native memory/session files - native workspace/tool semantics - runtime truth about what actually executed - native sub-agent system (`sessions_spawn`) EC/Q may orchestrate around OpenClaw but must NOT rewrite native truth. **OpenClaw release context (April 2026):** - **v2026.4.23** — Added native `context: "isolated" | "fork"` parameter to `sessions_spawn`. Forked context branches the requester transcript into the child session. - **v2026.3.13-1** — Fixed cross-agent workspace inheritance bug (PR #40176). `sessions_spawn(agentId="X")` now correctly resolves to target agent's workspace/cwd/`AGENTS.md`/`TOOLS.md`. **Issues #42712, #40825, #45868 are CLOSED.** - **Open gap:** Issue #50263 — target agent's `SOUL.md` / `IDENTITY.md` / `USER.md` are still NOT auto-injected when spawning by agentId. Workaround: embed persona content in target's `AGENTS.md`, or pass it explicitly in spawn's task prompt. - **Sub-agent config defaults:** `maxSpawnDepth: 1` (range 1-5; recommended 2-3 for orchestrator patterns), `maxChildrenPerAgent: 5` (range 1-20), `maxConcurrent: 8` (global), `runTimeoutSeconds: 0` (no timeout in raw native; 900 in documented config example), `archiveAfterMinutes: 60`. - **Fork cost guard:** `session.parentForkMaxTokens` (default 100000). Above this, fork silently degrades to isolated. ### 2.3 Four Truth Boundaries - **EC durable truth:** file-based system state and memory (SQLite + JSONL audit) - **Q truth:** rendered read-models of durable/runtime state - **OpenClaw truth:** native runtime/session execution state - **Derived truth:** allowed only when clearly marked as derived, rebuildable, and non-canonical --- ## 3. The Knowledge System — Deep Detail This is the most active area of spec development. Understanding it deeply is essential. ### 3.1 DOC72 Hyper Intelligence Overlay R5.73 — The Entity Graph DOC72 is ELNOR's brain architecture. A SQLite database with sqlite-vec for vector search and FTS5 for full-text search. Everything ELNOR knows exists as typed nodes with six dimensions. **Status note:** R5.73 (April 26, 2026) supersedes R5.72 in full. R5.73 is R5.72 with the GIE V2.2 absorption — §42A was rebuilt from V2.2 content (which incorporated 29 normalized patches NP01-NP29 over V2.1, drawn from a 5-reviewer red-team adjudication: ChatGPT, Claude, Gemini, Grok, Codex). Absorbed companion sources: DOC24 KDA R2, **DOC72 Graph Intelligence Enhancement V2.2**, DOC72 KIE R2, BDSM v6.4, DOC24 R2.5, DOC8 v1.11.4, MultiDoc PropA R6.1. R5.73 contains an integration note documenting the V2.2 absorption. No other R5.72 sections changed. **The Six-Dimension Knowledge Framework:** | Dimension | Question | What it contains | |---|---|---| | **Content** | WHAT does Elnor know? | Every knowledge node type's structured data | | **Provenance** | WHERE/WHY does Elnor believe it? | Three-tier evidence chain (Full/Compact/Minimal by node importance) | | **Temporal** | WHEN did things change and how fresh? | Creation, verification, staleness, change history | | **Confidence** | HOW SURE is Elnor? | Beta distribution `C = α/(α+β)` with lazy time-decay | | **Connections** | HOW does knowledge relate? | Typed edges to other nodes | | **Experience** | HOW has this knowledge lived in use? | Usage frequency, outcomes, variants, trends | **Six-dimension sparsity policy:** Tier A (high-value professional — domain concepts, goals, obligations, standing procedures, work products, matters) get full depth. Tier B (operational — procedures, applications) get compact. Tier C (ephemeral — candidates, suggestions) get minimal. **10 Canonical Node Types:** | Type | Represents | |---|---| | `world_entity` | Matters, persons, orgs, calendars, folders, email accounts, system objects (tasks, rooms, panels, notes) via `entity_type` subtype | | `application` | Apps + lightweight capability metadata | | `procedure` | Semantic-intent procedures (not mechanical UI steps) | | `execution_trace` | Evidence nodes recording what happened | | `standing_procedure` | Trigger-action behavioral automation | | `goal` | Narrative strategic context | | `domain_concept` | Authority-backed knowledge with hierarchical concepts | | `obligation` | Lightweight social commitments (lighter than tasks) | | `work_product` | Documents, briefs, filings as first-class entities | | `memory_directive` | Preferences, constraints, vocabulary, styles, archetypes (DOC1-governed) | **Confidence Model — Pure Beta Distribution:** - `C = α/(α+β) × decay(ageDays, halfLifeDays)` with policy caps - α+β cap at 200 prevents unbounded evidence accumulation - Event weights range from 0.20 (agent_observation) to 1.00 (user_flagged / confirmed_by_user) - Half-life defaults: domain_concept 365 days, procedure 90 days, obligation 30 days, etc. - Corrections go into β directly **Knowledge Intake Architecture (§§20-24):** - **Stage 1 DETECT (free):** EC listens to command stream. One exception: Q Browser dwell timer (SHALLOW only, never deep). - **Stage 2 ASSESS (cheap, deterministic):** Significance scoring across 8 features (intent, novelty, domain impact, entity centrality, action strength, matter link, duplication risk, privacy risk). Dispatch: skip / shallow / deep / defer. - **Stage 3 EXTRACT (expensive, gated):** Shallow = regex + alias (no LLM). Deep = background LLM call with contextual retrieval. - **The funnel:** 100-200 observations/day → 25-50 significant → 12-25 extracted → 30-80 durable graph writes. **Surface-Specific Intake Contracts (§20B):** Each surface has its own extraction rules, schemas, and authority attribution: Notes (DOC20), Q Browser, Document Viewer, DOC23 Tasks, DOC12 Rooms, Panels/Forums, CANDOR, Structured Email (Westlaw regex, ECF llm_schema), Bucket files (DOC7). **Self-Learning Extraction Feedback Loop (§36):** Five feedback dimensions (pattern performance, false negatives, surface ROI, prompt performance, sonar quality). Adaptive thresholds with 7-day canary trials. 5-10% exploration quota. **Storage:** SQLite as primary (WAL mode). Append-only JSONL event log for audit/replay. Qwen3-Embedding-0.6B via MLX (locked config, migration pipeline required to change). 768-dim vectors. FTS5 keyword pre-filtering before vector search. **Routing Cascade (§14.4):** Tier 1 exact alias (<1ms) → Tier 1.5 FTS5 BM25 (<3ms) → Tier 2 sqlite-vec (<15ms) → Tier 3 model-assisted disambiguation (<500ms). **Latency Discipline (§19):** Entire DOC72 knowledge system MUST NOT add more than 50ms total to prompt assembly. Tier 1 (prompt-time) cached only. Tier 2 (background-immediate, <500ms). Tier 3 (background-deferred, seconds to hours). **Graph Cleanup / Entropy Control (§42):** 8 nightly cleanup jobs. Semantic folding with per-node-kind thresholds. Automated regression harness (§42.8). **Conversational Inspectability (§41):** `inspect_knowledge` tool with 12 query types. Text-to-SQL (read-only, row-limited, timeout-bounded). Knowledge Manager UI with 8 tabs. **Agent Knowledge Profiles (§40):** Least-privilege default. New agents start `inheritance_mode: "minimal"`. Auto-evolution from observed usage. Delegation payload scoped by receiving agent's profile. ### 3.2 DOC73 Positronic Brain Enhancement V1.4.1 — The Corpus + Living Memory Layer **Status:** **Operative spec**, V1.4.1 dated 2026-04-26 (self-containment patch over V1.4 — no architectural changes; V1.4 was 2026-04-25). Promoted from concept after red-team review. Treat its primitives, contracts, and operational layer as authoritative. Companion memory system incorporation document forthcoming (separate file) to coordinate cross-doc integration. **What PBE adds (5 gaps it addresses):** 1. **Deep knowledge corpora** — DOC72's main brain is tuned for personal-OS behavior (preferences, obligations, standing procedures, active matters). It is NOT designed to absorb hundreds of SEC filings, a synth manual at feature granularity, or a full body of case law. PBE adds the **corpus** as a first-class scoped substrate for bounded deep knowledge — distinct from main brain, addressed via scoped corpus regions. 2. **Context-aware extraction** — DOC72 §20A extraction is currently substantially context-free (runs over source material with profile + prompt, no awareness of what user already knows, what decisions are active, what vocabulary they use, what prior material exists). PBE adds persisted injection manifests, prior relevance sweeps, variable-depth passes, and an extraction-mode KDA packet. The "new brain every time" problem is solved. 3. **Universal living memory with carve-outs** — DOC72 captures facts and lessons as substantially static once committed. PBE's first commitment: **all eligible evolving knowledge is living** — evolving, provenance-grounded, maintained by a general adaptation engine across all evolving node kinds. **Carve-outs** for static facts (dates, citations, named entities) and authority-fixed content (corrections, standing orders, user-locked memories). Field-level scoping where one memory has some adaptive fields and some fixed fields. 4. **ConsolidatedUnderstanding (CU) primitive** — A new node kind for compositional reasoning structures: decisions from analysis with typed inputs (`essential` vs. `supporting` role), inspectable reasoning preserving authored content separately from generated content (`reasoning_authored_text` never auto-overwritten; `reasoning_generated_text` regeneratable), authority computed via aggregation algorithm (§3.2A), and first-class nesting. Distinct from KIE lessons (which reconcile observations); CU is about composition and decision. 5. **Cluster emergence + self-improvement engine** — System-detected artifact creation, graduated autonomy, AVAPO refinements (schema-aware diff for fixtures, exposure-normalized silent rejection signal, synthetic gold with persistent provenance flag, tier classification framework). **Other key concepts:** - **CU authority aggregation algorithm (§3.2A)** — `cu_authority` function with cascade rules per change-kind × essentiality, query-time conflict resolution, CU vs. fact resolution, DAG invalidation. **Reframed from V1.3:** the "DOC1 supersession rewrite" framing was rejected; DOC1 explicitly disclaims authority-resolution scope (DOC1 §4.12). The work belongs in DOC73. - **Bi-temporal edges layered (§3.3)** — validity lineage on edges; node-local current state and human-readable revision summaries at node level. - **Logical episodic/semantic separation (§3.3)** — same SQLite file, distinct schemas/tables/tier fields. EC sole-writer preserved. - **Per-corpus trust posture (§3.1)** — `aggressive_auto_commit | normal_auto_commit | review_before_commit`, domain-agnostic. - **Counterfactual finding lifecycle (§14.4)** — ClaimFamilyBundle with three-lane surfacing (urgent / issue queue / silent ledger) + dedicated DOC7 Triage tab. - **Re-extraction directive flow (§14.7)** — natural-language directive → compiled spec diff → affected-document estimate → sample dry run → user approval → versioned rollback. Hard cost circuit breaker (default $15/run). - **Autonomous gathering trust framework (§14.8)** — source-class-specific defaults (auto-ingest for narrow deterministic; review-before-ingest for broad), preview/staging area, hard pre-ingest policy gates. - **DOC25 minimum consumer contract (§15.2)** — `DOC25_IngestionResult` schema PBE consumes; CU authority dependency points at §3.2A. - **Operational layer (§15)** — IngestionQualityReport, multiple hash types, versioned immutable artifacts, hard-fail reason codes, storage exhaustion controls, resource throttle, tool health checks + capacity leases. Tool routing: NuExtract / GLiNER / Docling / MarkItDown / Firecrawl / LlamaCloud. **MemoryAgent / DocumentIntelligenceAgent split** with composition loop control. - **PBE-lite degraded fallback mode (§12.6)** — when load-bearing contracts are missing or in transition, PBE operates in degraded mode with adaptation suspended. **Primary dependencies (as written in DOC73 V1.4.1, with stale-qualifier notes):** DOC72 R5.72 [**now R5.73**], DOC72 GIE V2.2 (once integrated) [**now integrated into R5.73 §42A**], DOC72 KIE R2 (once integrated) [**now integrated into R5.72/R5.73 §34A**], DOC72 Continuity Synthesis R1 (once integrated) [still in flight], DOC24 R2.5 (including onboarding infrastructure), DOC25 (V1.4 NEW dependency), KDA R2, BDSM V6.4, PropA R6.3, DOC7 R7, EC Core Addendum A V3.3. **The "(once integrated)" qualifiers on GIE V2.2 and KIE R2 are stale as of 2026-04-26**; DOC73's next revision should drop them. **V1.4 grade projection:** A (V1.3 baseline was A-). Unified semantics gap (F4) and sealed mode (G2/G8) acknowledged as V1.5 work. **Reading note for new chat windows:** DOC73 V1.4.1 is operative. Implementation planning, cross-doc seam work, and full-spec extension against DOC73 are all on the table. The companion **memory system incorporation document** (forthcoming, separate file) coordinates cross-doc integration of PBE with DOC72, DOC24, DOC7, DOC1, DOC8, DOC10, DOC11, DOC15, DOC16, EC Core, PropA, BDSM, KDA, GIE, KIE, and Continuity Synthesis. ### 3.3 DOC25 Document Intelligence & Universal Ingestion Architecture **Status:** Draft (V1.0, April 11, 2026). Promoted from prior "Document Intelligence Spec" addendum to its own numbered document. **Core problem:** PDFs are expensive to send to LLMs (3K tokens/page), and multi-turn conversations re-send context every turn. A 100-page complaint sent as PDF to Claude costs ~300K tokens; a 10-turn red-teaming session naively costs ~3M tokens. **Three-tier context management:** - **Tier 1 (Full PDF)** — Send native PDF to models that support it (Claude, Gemini). ~3K tokens/page. Used on first encounter. - **Tier 2 (Cached/Text)** — Prompt-cached PDF reference (90% cost reduction) or extracted text. Used on subsequent turns. - **Tier 3 (Summary + Excerpts)** — Pre-computed summary + relevant pages only. Used for tangential references or multi-document conversations. **Automatic tier selection** based on conversation state, document type classification, model capabilities, token budget. **Prompt caching integration** with Claude API. **Deposition special case:** always Tier 2 (text-only). **Design principles:** 1. The user should never have to think about this. Tier selection is automatic. 2. First interaction is perfect (full document, no degraded experience). 3. Subsequent interactions are efficient (auto-reduce token usage). 4. Visual understanding preserved when it matters (charts, tables, exhibits, signatures). 5. Pre-computation happens invisibly (when documents are opened, not when user asks). **Consumer contract for DOC73:** `DOC25_IngestionResult` schema is what DOC73 PBE corpus extraction consumes. DOC73 §15.2 specifies the minimum contract. ### 3.4 DOC1 Memory Resilience — Governance DOC1 gates all durable memory promotions. Any learned pattern that would become a permanent standing rule, durable scope restriction, or cross-node policy goes through DOC1's candidate → pending → explicit approval pipeline. **Storage unification:** DOC1 memories are `node_kind = 'memory_directive'` in the same SQLite database as DOC72. Write Gate, maturity transitions, and calibrated_confidence operate on these rows. Governance logic unchanged — only storage backend changed from JSONL to SQLite. **Memory types:** preference, constraint, standing_order, vocabulary_mapping, style_profile, document_archetype, heuristic, correction. **Authority vs Heuristic distinction:** - **Authority memory** = hard/strong governance (standing orders, explicit corrections, protected instructions) - **Heuristic memory** = learned suggestions, patterns, preferences - **Transient instructions** = one-off/session/task/chat scoped — must NOT silently become global authority **DOC1 ↔ DOC73 boundary:** DOC1 explicitly disclaims authority-resolution scope (DOC1 §4.12). CU authority aggregation lives in DOC73 §3.2A, not DOC1. **Maturity bypass for user-stated durable facts:** When user explicitly states a fact in chat with `assertion_class: "durable_fact"` and `confidence >= 0.85`, the node enters at `active` maturity immediately. ### 3.5 DOC8 Self-Learning — The Learning Engine DOC8 runs as offline nightly batch. Analyzes interaction traces, detects patterns (friction, over-questioning, correction sequences), computes satisfaction scores and attribution (Shapley via Monte Carlo over top-K), produces learned policy artifacts that DOC24 consumes as compiled bundles. **DOC8 constraints:** - Does NOT write knowledge directly to the graph — proposes through governed pipelines - Does NOT run on the hot path — all computation during idle time - Reads experience records from DOC72; writes α/β adjustments and tuning parameters - DOC8 is the computational engine for BDSM (see §4.2) ### 3.6 DOC3 App Skills R11.2 — Skill Acquisition Defines how ELNOR learns procedures from observing the user work. Five-round red team review covering 133 adjudication items. **Demonstration mode:** User activates "watch how I do this," performs workflow in any app, optionally narrates via push-to-talk, system captures → interprets → promotes into graph-backed procedural knowledge. **Observation layer:** macOS Accessibility API (AXUIElement) primary. Supplemented by screenshot vision, AppleScript state queries, MCP receipts, browser CDP. **Semantic intent, not mechanical replay:** Durable knowledge is "insert a table of contents with automatic heading detection" — NEVER "click References → Table of Contents → Automatic Table 1." LLM bridges intent to current UI at runtime. **Shared contracts integration:** Interpretation pipeline fills `ProcedureKnowledgeContractSchema` (defined in KDA, governed by DOC72). One schema, three consumers (DOC3 writes, DOC72 stores, DOC24 renders). --- ## 4. The Operations System — Deep Detail ### 4.1 DOC24 Unified Knowledge, Capability, and Onboarding Architecture R2.5 DOC24 is the delivery and invocation layer. Determines WHAT knowledge reaches the LLM each turn, HOW it's presented, WHAT tools are available. R2.5 processed 97 adjudication items (61 ACCEPT, 25 ACCEPT_MOD, 7 REJECT, 4 NEW_ISSUE). **DOC24 owns:** - Knowledge-to-LLM delivery (three-level model: KOI baseline + contextual packet + on-demand deep retrieval) - Three-lane retrieval for packet assembly (active work context / domain profile / personal context) - Rendering templates, micro-instruction tagging algorithm, injection selection - Legal citation rendering (AuthorityRef, LegalSupportBundle) - Tension-aware injection policy (contradiction pairing, conflict set injection) - Provenance display policy, injection kill-switch behavior - Prior context cards, semantic cache warming via calendar - Weekly digest rendering, deadline cascade intelligence - Capability registry, live action state, routing cascade - Tool packs and JIT/sticky mounting (12+ pack families) - Invocation bindings, receipts, confirmation contracts (5-tier transport precedence: native > MCP > EC action > skill > generic fallback) - Onboarding architecture (three lanes: passive ambient, conversational capture, structured studio) - Packet assembly and token budget governance **R2.5 key fixes:** - Routing cascade project-agnosticism (five-step entity resolution with ALL optional workspace fields) - Tool capability nodes in DOC72 graph (ADJ-91) - SQLite canonical persistence - Budget waterfall from DOC15 - Canonical tag vocabulary - Forward references to BDSM and KDA addenda **The DOC72/DOC24 split principle:** DOC72 defines the SHAPE of knowledge. DOC24 defines the DELIVERY. DOC72 is the brain's structure. DOC24 is the nervous system that delivers intelligence to the muscles. ### 4.2 DOC24 Addendum A — BDSM (Big Dynamic Satisfaction Machine) V6.4 3,128 lines. Operative spec status. 6+ red-team cycles across 4+ AI reviewers. Self-learning feedback system that optimizes knowledge delivery through utility scoring rather than raw confidence. Answers "Does injecting this knowledge help in THIS context?" (utility) vs DOC72's Beta confidence answering "Is this knowledge reliable?" (epistemic). **Three sequential gates:** - Gate 1 (Confidence): DOC72 Beta. Below 0.4 = suppressed. 0.4-0.7 = hedged. Above 0.7 = fully eligible. - Gate 2 (Relevance): DOC24 structural relevance + Matrix experience-weighted relevance boost. - Gate 3 (Delivery directive): Matrix-selected force_level based on context-specific Shapley attributions. **Ten invariants:** EC sole writer; no hot-path LLM calls; DOC72 owns schemas; one tag vocabulary (DeliveryDirective); kill-switch safety; user-experience principle; no second confidence store; no utility-only factual suppression; compiled-bundle-only runtime; resident lookup requirement. **Four utility ledgers:** Knowledge Utility, Tool/Procedure Utility, Question Utility, Phrasing Utility. **Kill-switch:** Dual toggle (`apply_matrix` + `gather_matrix_data`). Three modes: normal, passive learning, full stop. When off, all gates revert to baseline static behavior with zero residual effect. **Nightly processing:** Layer 1 raw scoring (S_actual via tanh-normalized weighted signals) → Layer 2 Shapley attribution (Monte Carlo) → Layer 3 pattern detection → compiled deterministic policy bundles DOC24 consumes via lookup tables. ### 4.3 DOC24 Addendum B — KDA (Knowledge Delivery Architecture) R2 1,577 lines. Interface between DOC72's stored knowledge and DOC24's rendered injection cards. **Payload schemas** — every knowledge node type has a structured payload (`ProcedureKnowledgeContractSchema`, `MemoryDirectivePayloadSchema`, `DomainConceptPayloadSchema`, etc.). DOC72-governed, filled by intake pipelines. **Tiered rendering** — three tiers per payload type: compact (~30 tokens), standard (~100-150 tokens), full (everything). **Execution strategy cache** — DOC24-owned (derived) layer mapping semantic procedures to concrete execution paths. **DeliveryDirective** — three-dimensional tag model: `primary_tag` (semantic role), `hedge_mode` (epistemic confidence), `force_level` (delivery utility — Matrix-determined). ### 4.4 DOC15 CIL — Cognitive Infrastructure Layer Injection hierarchy, authority injection governance, token budgets, context assembly. Knowledge nodes, learning pipeline, signal spool, advisor modules, DocIndex/topology bridge, bootstrap/migration lifecycle. **Needs integration** with DOC72 R5.73 knowledge card types and DOC24 delivery architecture. ### 4.5 DOC11 OpenClaw Gateway R14 + R15 Amendment Proposal **R14 operative.** Gateway-first interactive chat, runtime truth, context manifests, streaming, selector/executed truth, local provider controls, web search config, ACP/Coding Mode, Discord/WhatsApp channels, session lifecycle state machines, control mutation queue. **R15 Amendment Proposal (April 13, 2026):** Patch-oriented amendment proposal aligning DOC11 R14 with stable OpenClaw releases through 2026.4.12. Four concrete additions: 1. **Plugin and capability discovery** — install/update/setup truth 2. **Runtime command discovery** — `commands.list` 3. **OpenClaw memory/dreaming controls** — exposed in a way honoring ELNOR memory ownership and DOC24 interop 4. **Generalized channel setup/capability/catalog truth** — beyond the current Discord-and-WhatsApp model --- ## 5. The Body — User-Facing Surfaces ### 5.1 Q Dashboard (DOC20 R4.3) — The Frontend Q Dashboard is the Electron desktop application. Largest surface area spec (~4,400 lines). **Key features:** Workspace management (save/load tab arrangements). Tab system (horizontal/vertical with groups). Note editor (TipTap with track changes, modules: to-do/thread/feed/calendar). PDF viewer (pdfjs-dist with annotation tools, area select, page organizer, file combiner). Comments & Ask panel (right-side, with agent/model/think selectors). Web browser (URL bar, bookmarks, reader mode, clips). Split view (independent content + right panels). Chat panel (full chat with multi-copy mode). **Skills & Connectors page (§6.29)** — 30+ subsections including My Capabilities, Connectors & Accounts, OpenClaw Tools/ClawHub, Expose Elnor, Learn & Teach, Hub. ### 5.2 DOC21 Master UI Specification R7 + DOC22 UI Page Inventory R4 Canonical UI contracts. Master UI spec aligns surfaces to DOC11 R14. Page inventory with component registry, design tokens, template system. **UI update obligation:** When any spec introduces new pages, components, stored content types, settings, toasts, modals, or routes, DOC21, DOC22, and DOC20 §6.18.2 (Content Registry) MUST be updated. ### 5.3 DOC23 Task System R3.0 — Modular Automation Frozen implementation baseline. Complete modular automation spec. 36 module types. Eurorack-inspired with typed cables, gates, validation badges, retry logic. Standing procedures can be promoted to DOC23 tasks when reliability requirements increase. ### 5.4 DOC12 Inter-Agent Communication R7.1 Rooms, panels, forums. Multi-agent shared conversation substrate. Participant truth. SSE events. ### 5.5 DOC14 CANDOR R7 Universal adversarial review engine. ELNOR + CANDOR red-team integration into room substrate. Work products → red team findings → graph updates. --- ## 6. Four Retrieval Lanes The intended retrieval stack: 1. **Exact/live lookup lane** — current file truth, permissions, Graph/Drive/local exact fetch 2. **Semantic corpus lane** — LlamaIndex sidecar for selected corpora, NOT canonical memory truth 3. **Canonical ELNOR memory lane** — EC-owned retrieval via DOC72 entity graph (SQLite + sqlite-vec + FTS5) 4. **OpenClaw native runtime/local lane** — native workspace/session/runtime memory search, separate ownership boundary **DOC73 adds:** Corpus lane (scoped substrate for bounded deep knowledge) — distinct from main brain, addressed via scoped corpus regions with their own injection manifests and trust postures. --- ## 7. Active Addenda and Proposals The `Addenda Proposals & In Progress/` folder contains significant work-in-progress. ### 7.1 DOC73 (NEW — own folder) - **DOC73 V1.4.1 FINAL** (2026-04-26) — Positronic Brain Enhancement (PBE), **operative spec**. Path: `Addenda Proposals & In Progress/DOC73/DOC73_V1_4_1_FINAL.md`. See §3.2 for detail. V1.4.1 is a self-containment patch over V1.4 — no architectural changes; reproduces V1.3-retained content in full so reviewers don't need V1.3 alongside. ### 7.2 DOC25 (NEW — promoted from prior Document Intelligence addendum) - **DOC25_DOC INTELLIGENCE_SPEC.md** (V1.0, April 11, 2026) — Document Intelligence & Universal Ingestion Architecture - **DOC25_PLANNING_NOTES_V2.md** — Planning notes - **DOC_INTELLIGENCE_EXTRACTION_PIPELINE_PROPOSAL_R1.md** — Companion document covering OCR, PDF text extraction, `retrieve_document_pages` tool ### 7.3 DOC72 Addenda (in `DOC72 Addenda and Proposals/`) - **Surface Intake Contracts V2** — Per-surface extraction rules for To-Do, Calendar, Notes, Browser - **Graph Intelligence Enhancement V2.2** — **INTEGRATED into DOC72 R5.73 §42A as of 2026-04-26.** Both V2.1 and V2.2 are now archived. Cross-doc obligations from V2.2 Appendix A and Appendix C still need adoption into the corresponding companion docs (DOC24 KDA, EC Core, PropA, DOC8/BDSM, DOC1, DOC3, DOC11, DOC20/21/22, DOC72 §35). - **Knowledge Intelligence Enhancement R2** — **INTEGRATED into DOC72 R5.73/R5.73 §34A.** Archived. - **Continuity Synthesis Architecture R1** — In review; not yet integrated - **Bucket Intake Insertion Text** — Context bucket files as intake source ### 7.4 DOC24 Addenda (in `DOC24 Addendum/`) - **BDSM V6.4** (Addendum A) — Operative spec, ~3,128 lines (described in §4.2) - **KDA R2** (Addendum B) — Knowledge Delivery Shared Contracts, ~1,577 lines (described in §4.3) - **Q Dashboard Tool Registry** — ~100 registered tools across 13 categories with agent behavioral rules - **Unified Context Budget Governance** — Replaces independent DOC24/DOC7 budgets (~284 lines) - **Persistent Onboarding Curiosity** — Amendment for onboarding architecture ### 7.5 DOC20 Addenda - **Q Browser Intake Architecture** — Browser as knowledge intake surface with two-tier pipeline - **MS Word Viewer Capabilities R3** — OnlyOffice document viewer/editor spec - **R4.3 Delta V7.11.6 ALT** — Vertical tabs, workspaces, nav pane restructure - **Build Delta** — Implementation sequencing ### 7.6 DOC3 Addenda - **DOC3 R11.3 Addenda A R2.2 Proposal V1** — Semantic skills refinements - **Semantic Skills R2.1** — Updated semantic skills pipeline - **Skills Live Recording Upgrades V1** — Live demonstration improvements ### 7.7 DOC11 Addenda - **DOC11 R15 OpenClaw Release Alignment Amendment Proposal** (NEW, April 13, 2026) — Patch-oriented proposal aligning DOC11 R14 with OpenClaw releases through 2026.4.12. See §4.5. ### 7.8 EC Core Addenda - **EC Core Addendum A V3.3** (UPDATED from V3.1, 2026-04-16) — Compiled operative readability-remediated corrective revision over V3.2. Data Operations, Processing, and System Management Architecture. Global memory hierarchy, effective runtime truth, route/command/read-model closure, one compiled policy engine, background orchestration, execution profile selection, token/cost governance, networking sync verification, backup/export/import, settings wiring/inspection. Cross-doc obligations into DOC72, DOC24, DOC8, DOC11, DOC12, DOC20, DOC21/22, DOC1, DOC15, DOC23. ### 7.9 Cross-Document (Integrated) - **Tool Capability Nodes (ADJ-91)** — INTEGRATED into DOC24 R2.5 - **Routing Cascade Project-Agnosticism Fix** — INTEGRATED into DOC24 R2.5 ### 7.10 Cross-Doc Cycles (in `CD Cross Docs/`) - **CD-A 4-1-26 DOC3↔DOC24 Cycle** — staging doc with items CD-A-001 through CD-A-095. **Foldable into OP-A V4 (Session 2).** - **CD Master Integration Index R1** — **SUPERSEDED by DOC OP-A V3.** Retained as historical reference. ### 7.10A DOC OP-A — Cross-Doc Obligation Tracker (STANDING INSTRUMENT) - **DOC OP-A V3.6** (2026-04-27, latest in series) — `Operations Docs/DOC_OP_A_CROSS_DOC_OBLIGATION_TRACKER_V3_6.md` — **the standing by-target obligations tracker for the entire spec suite.** V3.6 header: "architecture clarification — agent-vs-capability registry split; capability-registered flag on agent rows." Series progression (all in `Operations Docs/`): V3 (2026-04-26) folded V2 DOC24 review, DOC24 R2.5 §22, CD Master Integration Index R1, **DOC15 R3.1 contract** (full field-level expansion, 56 obligation rows; source archived to `Subsumed Specs/`); V3.2 audited DOC24 R3; V3.3 folded RRB v6 (26 rows) + audit gaps; V3.4 corrected OCM/MemoryAgent classification; V3.5 recorded EC Core Agent Identity Registry decision; V3.6 added agent-vs-capability split. **Pending Session 2 fold-in:** DOC3 R9.2 Companion + DOC14 R2 Cross-Doc Companion + CD-A 4.1.26 → OP-A V4. Older versions (V2, V3, V3.2-V3.5) retained in `Operations Docs/` for traceability; the unversioned filename pattern resolves to V3.6 as latest. - **DOC OP-A maintenance discipline (NEW IN V5):** OP-A is attached to **every red team review and every spec drafting/revision session**. The reviewer's last step is to update OP-A: move absorbed obligations to §7 (Absorbed) with date and target revision number; update statuses (`[MISSING]` → `[PARTIAL]` → `[EXISTS]` as integration proceeds); add new findings as new rows in §6; log the action in §10 maintenance log. **If OP-A doesn't get updated at the close of a session, the system loses memory of what was done.** Every spec revision should increment any newly-absorbed obligations and surface any newly-discovered cross-doc gaps as new rows. New obligations sourced from per-doc internal §22 amendment matrices migrate to OP-A as part of normal revision work (per V2 carryover §1A scope rule). ### 7.11 MultiDoc Proposals - **MultiDoc PropA R6.3** (Compiled Operative Spec) — Knowledge Pipeline Sensitivity and Self-Improvement. 8 amendments, 12 prompts (P-0 through P-11), 3 appendices. 19-tag sensitivity classification, per-category collection toggle, sharing policy matrix, monthly adversarial review for extraction agents. ### 7.12 Sub-Agent Architecture - **ELNOR_SUBAGENT_PRECOMPUTE_TOOL_OPTIMIZATION_NOTES_V4.md** (UPDATED from V3, 2026-04-24) — Architectural notes on sub-agent orchestration, mid-turn knowledge retrieval, pre-computation, tool optimizations. V4 changes from V3: - Updated config values verified against OpenClaw v2026.4.23 docs (`maxSpawnDepth: 3` recommended baseline; `archiveAfterMinutes: 60` added) - **NEW §1.7:** Specialist Sub-Agent Pattern — three patterns (specialist retrieval/processing, decomposition reasoning, background/monitoring) - **NEW §1.8:** MemoryAgent specification (consumed by DOC73) - **NEW §1.9:** DocumentIntelligenceAgent specification (consumed by DOC73) - **NEW §1.10:** Composition patterns - **NEW §1.11:** Monitoring and inspectability for specialist sub-agents ### 7.13 Plugins and Integrations - **Q Plugin System Architecture R2** — Extensible plugin framework with manifest schema - **Q Integration Suite Spec** — Third-party integrations (YouTube, Hue, Zoom, Apple Reminders) - **Q Integration Suite Additions R1** (NEW, April 19, 2026) — Three new integrations: **Firecrawl** (web content extraction, self-hosted Docker), **Securities Data**, **MarkItDown**. Plus DOC24 routing infrastructure for new integrations, capability registry updates, knowledge storage/system awareness/cross-integration procedures, implementation priority. Includes important note on checking OpenClaw native capabilities first before installing MCP servers. - **PACER Plugin Spec** — Legal case monitoring reference implementation - **Spotify Integration Parts 1 & 2** — Playback control + knowledge extraction --- ## 8. Knowledge Lifecycle — How It All Composes The full lifecycle of knowledge in ELNOR: 1. **Intake** — Knowledge enters through multiple pipelines: - DOC72 conversation mining (extracts from chats after significance-gated session close) - DOC3 demonstration mode (observes user workflows in apps) - DOC24 onboarding architecture (asks probing questions) - DOC72 surface-specific intake contracts (browser pages, calendar events, to-do items, notes, documents) - DOC25 document intelligence pre-computation (text extraction, classification, summaries) - DOC73 PBE corpus extraction (when integrated — context-aware deep extraction over bounded corpora) - Direct user input via agent-initiated knowledge writes All pipelines produce DOC72-governed shared contract payloads and write through EC. 2. **Storage** — DOC72's entity graph stores everything as typed nodes with Beta confidence, provenance, and typed edges. **DOC73 adds:** corpus regions as scoped substrate; ConsolidatedUnderstanding as compositional reasoning primitive; living memory adaptation across eligible evolving node kinds (with carve-outs). SQLite + WAL is authoritative; JSONL as audit trail. 3. **Delivery** — On each turn, DOC24 assembles context packet: - Gate 1 (confidence) filters unreliable nodes - Gate 2 (relevance) selects request-matching nodes, boosted by Matrix experience data - Gate 3 (delivery directive) assigns tag strength, hedge mode, force level KDA rendering pipeline produces clean natural-language injection cards. DOC25 selects optimal document tier. DOC73 PBE adds extraction-mode KDA packet for context-aware extraction. 4. **Execution** — LLM reads injected cards and acts. Procedures → semantic how-to. Constraints → what to avoid. Preferences → how to approach. Execution strategy cache provides tool bindings. Q Dashboard tools available as registered actions. Specialist sub-agents (MemoryAgent, DocumentIntelligenceAgent) handle bounded retrieval/processing tasks per SUBAGENT V4 patterns. 5. **Feedback** — Every interaction produces execution trace. Matrix captures typed feedback events with purity classification. Nightly batch (DOC8) computes satisfaction scores, runs Shapley attribution, detects patterns, compiles updated policy bundles. DOC24 reloads bundles. **DOC73 adds:** counterfactual finding lifecycle, re-extraction directives with versioned rollback, autonomous gathering trust framework. 6. **Governance** — DOC1 gates all durable promotions. Matrix-driven tag adjustments ephemeral (recomputed per-turn). Durable rules require explicit approval. Kill-switch can disable Matrix influence instantly. **DOC73 adds:** CU authority aggregation (DOC1 disclaims this scope per §4.12); per-corpus trust posture (`aggressive_auto_commit` / `normal_auto_commit` / `review_before_commit`); PBE-lite degraded fallback mode. --- ## 9. Design Philosophies and Non-Negotiable Invariants ### 9.1 Design Philosophies - **Local-first, inspectable, file-first durability** - **Single durable writer (EC)** - **Reference-first context packaging** rather than giant prompt dumps - **Bounded injection** with explicit trim/skip/degrade behavior - **Truthful degraded states** instead of bluffing completeness - **No phantom features** (buttons, memories, suggestions, telemetry, approvals, or automations that don't structurally do anything) - **Proposal / approval discipline** for durable governance changes - **Runtime truth honesty** (desired config ≠ effective runtime) - **Context assembly is a system problem, not magic prompting** - **Specs should be complete as end-state product specs; phasing comes later** - **Companion docs will be updated later, but current specs should describe the complete end-state, not hide behind future phasing** ### 9.2 Architectural Invariants (Do Not Casually Undo) 1. **EC is the sole durable writer.** Nothing else writes to the graph or Matrix artifacts. 2. **DOC72 owns schemas.** All payload schemas, node types, contract definitions are DOC72-governed. 3. **DOC24 owns delivery and invocation.** Routing, rendering, injection, runtime bundle consumption, tool registry. 4. **DOC8 owns learning computation.** All attribution, pattern detection, policy compilation. 5. **DOC73 owns CU authority resolution.** DOC1 explicitly disclaims this scope (§4.12). 6. **DOC25 owns document intelligence and ingestion contracts.** PBE corpus extraction consumes `DOC25_IngestionResult`. 7. **No hot-path LLM calls from the Matrix.** Runtime is deterministic lookup only. 8. **One tag vocabulary.** DeliveryDirective (primary_tag + hedge_mode + force_level) — no second prompt-control language. 9. **Semantic intent, not mechanical replay.** All procedures stored as semantic descriptions. 10. **Domain-agnostic core.** Schemas, node types, question taxonomies, pattern types generic. Domain-specific extensions via DomainSignalProfile registry. 11. **Project-agnostic routing.** Entity resolution works with ZERO workspace/project state. Five-step fallback with all optional fields. 12. **Tools are learnable entities.** Tool capability nodes in DOC72 graph with experience records. 13. **Q is UI/control surface only**, not a second durable brain. 14. **OpenClaw owns native runtime/session truth.** 15. **LlamaIndex is a sidecar retrieval provider**, not canonical memory or graph truth. 16. **Authority corrections should be strong once created, but difficult to create accidentally.** 17. **Transient one-off instructions should remain transient unless explicitly promoted.** 18. **The entity graph is a first-class durable store**, not a rebuildable cache or derived read-model. 19. **The embedding model is infrastructure (locked config)**, not a configurable agent. Changes require migration pipeline. 20. **ELNOR learns only from user ACTIONS that demonstrate intent** — not passive viewing. Enforced at significance gate, non-negotiable. 21. **When a stale doc conflicts with DOC72 R5.73 or DOC24 R2.5 on a topic within their ownership scope, DOC72/DOC24 govern.** 22. **Consolidated single-file operative drafts are preferred** over scattered amendment stacks. 23. **PBE living memory has carve-outs** — static facts (dates, citations, named entities), authority-fixed content (corrections, standing orders, user-locked memories), and field-level scoping where one memory has both adaptive and fixed fields. 24. **Post-absorption versioning rule.** Once an addendum proposal is absorbed into an operative spec, archive it. Subsequent work targeting the same area authors a NEW proposal against the operative spec's text, not a revision of the archived proposal. This prevents three-way merge problems during integration. Applies to: GIE → DOC72 §42A, KIE → DOC72 §34A, KDA → DOC24 §§26-37, BDSM → DOC24 Addendum A live integration, and any future addendum that gets absorbed. --- ## 10. Current Operative Spec Status (2026-05-27) Front-door registry: `OP-A and Operations and Trackers/MASTER_SPEC_DOCUMENT_LIST.md` (canonical, no version suffix; GitHub history is authoritative). A legacy versioned snapshot `MASTER_SPEC_DOCUMENT_LIST_R3.62.md` sits alongside until Will archives it. For the per-document "where I left off" rolling summary see `OP-A and Operations and Trackers/RECENT_WORK_SUMMARY.md` and the dashboard's Recent Work panel. ### 10.1 Core operative specs | Doc | Current filename pattern (in `Current Specs/DOC#/`) | Status notes | |---|---|---| | EC Core | `Current Specs/EC Core/` | Operative; partially stale (entity creation/memory extraction now in DOC72) | | DOC1 Memory Resilience | `Current Specs/DOC1/` | Operative; storage model stale (JSONL → SQLite, unified with DOC72) | | DOC2 | `Current Specs/DOC2/` | Operative | | DOC3 App Skills | `Current Specs/DOC3/` (R11.3 Addenda A R2.2 in flight) | Operative | | DOC4 | `Current Specs/DOC4/` | Operative | | DOC5 / DOC6 / DOC7 | per-DOC subfolders | Operative | | DOC8 Self-Learning | `Current Specs/DOC8/` (v1.11.4 baseline) | Operative; **flagged as undersized: per DAMS V2 cross-doc finding, DOC8 is a ~730-line friction engine with no learning-engine substance. The learning engine the stack depends on does not exist as a written spec.** Major respec/replacement candidate via DOC80 family. | | DOC10 Orchestration | `Current Specs/DOC10/` | Operative; partially stale (knowledge intake → DOC72; routing → DOC24) | | DOC11 OpenClaw Gateway | `Current Specs/DOC11/` (R14 baseline + R15 R3 amendment proposal in flight) | Operative; OpenClaw release alignment BEHIND. R15 R3 amendment proposal addresses 2026.4.27 → 2026.5.12 backlog. | | DOC12 / DOC13 / DOC14 | per-DOC subfolders | Operative | | DOC15 CIL | `Current Specs/DOC15/` (R7.1) | Operative; needs DOC24 delivery integration | | DOC16 Entry 16.7 (M365) | `Current Specs/DOC16/` | Operative | | DOC17 / DOC18 / DOC19 | per-DOC subfolders | Operative | | DOC20 Workspace/Browser/Notes/Viewer | `Current Specs/DOC20/` (R4.3) | Operative; large surface spec | | DOC21 Master UI Spec | `Current Specs/DOC21/` (R7) | Operative | | DOC22 UI Page Inventory | `Current Specs/DOC22/` (R4) | Operative | | DOC23 Task System | `Current Specs/DOC23/` (R3.1.1 audit closure latest; R3.2 compilation pending) | Operative. Addenda A (Task Optimization) at R4.1 V6; Addenda B (Task Intelligence) family-topology splits underway. | | DOC24 Unified Knowledge/Capability/Onboarding | `Current Specs/DOC24/` (R3.1.1 audit closure latest) | Operative. R3.1.1 closed 7 audit-identified gaps over R3.1. Addenda: A (BDSM v6.5 DRAFT v0.3.1), B (KDA R3 DRAFT v0.3.1), Q Dashboard Tool Registry, Unified Context Budget Governance, Persistent Onboarding Curiosity. | | DOC25 Document Intelligence | `Current Specs/DOC25/` (V2.0) | Operative. Owns `DOC25_IngestionResult`. | | DOC26 Unified Workspace Library | `Current Specs/DOC26 UnifiedWorkspaceLibrary/` | Active draft (R0.3) | | DOC72 Hyper Intelligence Overlay | `Current Specs/DOC72/` (R5.73) | Operative. GIE V2.2 absorbed into §42A. **Slated for partial supersession by DOC80 family** once Flattening Plan ships (Stage 7+). | | DOC73 Positronic Brain Enhancement | `Current Specs/DOC73/` (V1.5.1 FINAL; V1.6 in flight) | Operative. V1.5.1 dereferences `DOC25_IngestionResult` to V2.0 §17. V1.6 inventory adjudication card V4 in RT folder; spec not yet drafted. **Slated for partial supersession by DOC80 family.** | | DOC80 Memory Control Plane | `Current Specs/DOC80 Memory Control Plane/` | **NEW (Flattening Plan)** — has a single proposal `DAMS_V4_1_CONSOLIDATED_ARCHITECTURE_PROPOSAL.md`. Skeletal target baseline at `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/`. | | DOC81–DOC87 | Memory Rebuild family | **NEW (Flattening Plan, Stage 5R)** — DOC87 added at Round 1 for Membership/Organization. Skeletal designs only, no spec files yet. Members per Skeletal Target Baseline: DOC81 Identity/Authority; DOC82 Source Bindings/Corpora; DOC83 Working State/Extraction; DOC84 Assembly/Context Compiler; DOC85 Learning/Feedback (coordinates with BDSM revision); DOC86 Delivery/Render; DOC87 Membership/Organization. | ### 10.2 Cross-cutting addenda (current state) | Addendum | Current state | Lives in | |---|---|---| | DOC24 Addendum A — BDSM | v6.5 DRAFT v0.3.1 (working draft; dependency_status=partial per Skeletal Baseline ADQ-221) | `Current Specs/DOC24/` | | DOC24 Addendum B — KDA | R3 DRAFT v0.3.1 (working draft) | `Current Specs/DOC24/` | | DOC24 Q Dashboard Tool Registry | drafted | `Current Specs/DOC24/` | | DOC24 Unified Context Budget Governance | drafted | `Current Specs/DOC24/` | | DOC24 Persistent Onboarding Curiosity Amendment | drafted | `Current Specs/DOC24/` | | DOC72 Continuity Synthesis Architecture (CSA) | R2 draft; depends on DOC73 §6.4 Mechanism 4 rollup | `Current Specs/DOC72/` | | DOC72 Surface Intake Contracts | V2 in review | `Current Specs/DOC72/` | | DOC11 R15 OpenClaw Release Alignment Amendment | R3 (active); R2 archived | `Current Specs/DOC11/` | | DOC73 Corpus Source Bindings Proposal | V1 | `Current Specs/DOC73/` | | DOC73 §6.4 Mechanism 4 Rollup | V1 standalone handoff | `Current Specs/DOC73/` | | DOC73 V1.6 Inventory Adjudication Card | V4 (round-2 RT pending) | `Active Working and Red Team/` | | EC Core Addendum A | V3.3 operative | `Current Specs/EC Core/` | | EC Core Addendum A Intake Routing for Corpus Bindings | V1 proposal | `Current Specs/EC Core/` | | MultiDoc PropA | R6.3 compiled operative | location TBD (search `Current Specs/`) | | ELNOR Sub-Agent Architecture | V5.2 AUDITED (successor to V5.1; V4 PRECOMPUTE_TOOL_OPTIMIZATION_NOTES legacy) | top-level or DOC24 vicinity | | DOC OP-A (Cross-Doc Obligation Tracker) | V3.18 latest (in flight; canonical filename target = `OPA.md` once renamed) | `OP-A and Operations and Trackers/` | | DAMS (Dynamic Attenuator Memory System) | V4.1 (proposal track; touches DOC80 family) | `Archived and Subsumed Specs and Lineage/` after recent move; canonical home pending | | PACER Plugin Spec | V1.1 | `Current Specs/Connector and Integration Specs/` | | Cross-Spec Issues Punch List | V1 | `Active Working and Red Team/` or `OP-A and Operations and Trackers/` | | ELNOR Search Architecture Reference | R1 (non-normative reference) | `Active Working and Red Team/` | | Q Integration Suite Additions | R1 (Firecrawl, Securities Data, MarkItDown) | `Current Specs/Connector and Integration Specs/` | ### 10.3 Known cross-doc staleness (tech debt) - **EC Core / DOC1 / DOC10:** entity creation, memory extraction, knowledge intake all superseded by DOC72 R5.73. Will resolve in DOC72 family redesign or via DOC80 absorbing DOC72 portions. - **DOC8:** undersized — friction engine without learning engine. Will be substantially respecced or replaced by DOC85 (in design). - **DOC11 R14:** R15 R3 amendment proposal addresses OpenClaw release backlog through 2026.5.12; not yet folded. - **DOC15 R7.1:** needs integration with DOC24 §26 delivery contracts. - **DOC72/DOC73:** in queue for partial supersession by DOC80 family once Stage 7+ ships. **Governance rule on conflicts:** DOC72 R5.73 / DOC24 R3.1.1 / DOC73 V1.5.1 govern within their ownership scope. Stale docs need updating, not the other way around. **DOC80 family is NOT yet operative** — design artifacts only. The older memory stack remains authoritative until Stage 7 spec files ship. ### 10.4 Key pending work (high-level — see dashboard for granular state) - Stage 5R Round 2 red-team review (BLOCKS Stage 6) - DOC23 Addenda A R4.1 V5 adjudication + R3.2 compilation - DOC23 Addenda B family-topology consolidation - DOC24 BDSM v6.5 + KDA R3 drafting (paired with DOC85 design) - DOC73 V1.6 spec drafting (Round 2 RT ratifies first) - DOC11 R15 R3 amendment fold-in to DOC11 R15 - DAMS V4.1 disposition — fold into DOC80 family - DOC OP-A canonical filename rename (`OPA_V3_18.md` → `OPA.md`) - Cross-doc obligation cleanup as DOC80 family advances ## 11. What Will Cares About Most Right Now Will is highly focused on these failure modes: - phantom buttons / no-op controls - memories generated but not actually ingested - memories ingested repeatedly or too aggressively - silent auto-promotion of weak signals into strong behavior - UI surfaces with missing empty/degraded/error states - under-specified schemas/routes/helpers that cause coding agents to drift - cross-doc seams that sound good but are not actually wired - overly magical context/memory behavior with poor inspectability - version/amendment sprawl that causes details to get lost - stored content types introduced but not registered in DOC20 §6.18.2 - new UI surfaces introduced but not registered in DOC21 (Master UI Spec) or DOC22 (Page Inventory) - design elements defined in specs but with no visual reference in the design system or mockups - knowledge injected when it shouldn't be, or missing when it's needed - the system feeling like a search engine with memory instead of a personal OS - **DOC73 ownership boundaries respected during integration** — CU authority resolution lives in DOC73 §3.2A, NOT DOC1 (DOC1 §4.12 disclaims) - **Living memory eroding static facts or authority-fixed content** — carve-outs (static facts, authority-fixed content, field-level scoping) must be respected - **PBE-lite degraded fallback mode entered silently** — when load-bearing contracts are missing or in transition, PBE adaptation must be visibly suspended, not silently inert When reviewing or drafting specs, actively check for: - end-to-end structural wiring - complete UI/data contracts - durable writes / current views / telemetry / read-model visibility - whether every recommendation, suggestion, receipt, audit entry, or action has a real path through the system --- ## 12. Working Principles — Think Simultaneously As Always think simultaneously as: - **Coder** — can this be implemented without guessing? - **Product designer** — would this actually make sense to the user? - **Integration architect** — will it wire cleanly to other specs and runtime truths? Do NOT accept: - Specs that are architecturally pretty but practically under-specified - Specs that are internally complete but rely on phantom companion seams without acknowledging them - UI descriptions that omit loading / empty / degraded / blocked / error states - Routes or helpers referenced but not defined --- ## 13. Will's Preferences - Direct honest assessment without hedging - Discussion and explicit approval BEFORE any file is created or modified - Every document modification gets a new version number in the filename (never reuse filenames) - Comprehensive spec-level solutions (TypeScript schemas, algorithms, configuration values) over problem identification alone - Paste-ready code over descriptions of what code should do - He red-teams proposals by routing them to multiple AI models in fresh chat windows, so all context must be self-contained - Cite section numbers when reviewing specs - Concrete fixes, not vague suggestions - Type findings as BUG / GAP / SUGGESTION / CONFIRMED when reviewing --- ## 14. How to Use Document Packs in a New Chat ### If the full pack is available Start with: 1. `MASTER_SPEC_DOCUMENT_LIST_R2.6.md` 2. Current operative target docs relevant to the task 3. Specialized companion docs for that task ### If context is limited Ask Will for a narrow pack based on task. Examples: - **DOC72/knowledge pack:** DOC72 R5.73, DOC24 R2.5, DOC1 Rebuild R1, DOC8, EC Core Rebuild - **DOC73/PBE pack:** DOC73 V1.4.1, DOC72 R5.73 (which now contains absorbed GIE V2.2 §42A and absorbed KIE R2 §34A), DOC25, DOC72 Continuity Synthesis R1, DOC24 R2.5, EC Core Addendum A V3.3, PropA R6.3 - **DOC25/document intelligence pack:** DOC25, DOC73 V1.4, DOC72 R5.73, DOC20 R4.3, DOC Intelligence Extraction Pipeline Proposal R1 - **DOC24/delivery pack:** DOC24 R2.5, DOC72 R5.73, DOC15, DOC10, DOC11 - **BDSM/Matrix pack:** DOC24 Addendum A (BDSM) V6.4, DOC24 R2.5, DOC72 R5.73, DOC8 - **KDA pack:** DOC24 Addendum B (KDA) R2, DOC24 R2.5, DOC72 R5.73, DOC15 - **DOC15/CIL pack:** DOC15, DOC15 Contract, DOC72 R5.73, DOC24 R2.5, DOC10, DOC11, DOC7, EC Core - **Retrieval pack:** DOC18, DOC3, DOC72 R5.73, DOC24 R2.5, DOC10, EC Core - **Rooms/red-team pack:** DOC12, DOC14, DOC10, DOC11, DOC72 R5.73 if knowledge extraction from rooms matters - **Q/UI pack:** Q canonical spec, DOC21 R7, DOC22 R4, DOC20 R4.3, target feature doc, Q_DESIGN_REFERENCE_V12.jsx + mockups - **Task system pack:** DOC23 R3.0, DOC72 R5.73 (standing procedures, promotion path), DOC10 - **M365/provider pack:** DOC16 Entry 16.7 R2.1, DOC3, DOC72 R5.73, DOC24 R2.5 - **Skills/demonstration pack:** DOC3 R11.2, DOC72 R5.73 (procedure graph), DOC24 (KDA for shared contracts), Skills Live Recording Upgrades V1 - **Sub-agent architecture pack:** SUBAGENT V4, DOC11 R14 + R15 proposal, EC Core Rebuild R1, DOC73 V1.4.1 (MemoryAgent/DocumentIntelligenceAgent consumers) - **MultiDoc PropA pack:** MultiDoc_PropA_R6_3, DOC72 R5.73, DOC1, DOC24 R2.5 - **OpenClaw alignment pack:** DOC11 R14, DOC11 R15 Amendment Proposal, OPENCLAW_PRESERVATION_AND_INTEGRATION_CHECKLIST_R1, OPENCLAW_RELEASE_ALIGNMENT_RUNNING_SPEC_UPDATE_LIST_R2 ### When Will gives a task, first - Identify the current operative owner docs (use **DOC72 R5.73** — supersedes R5.72 and R5.6) - Identify companion docs that touch the seam - Confirm whether the task is drafting, red-teaming, reconciling, or consolidating - Check if the task introduces new UI surfaces, stored content types, or commands that require updates to DOC21, DOC22, or DOC20 §6.18.2 - Note any cross-doc staleness that affects the task (§10.3) - For DOC73-related work: identify whether this is integration planning, cross-doc seam work, or net-new spec extension — DOC73 IS operative - Then proceed with high-specificity spec work Your default posture: - Preserve architectural honesty - Eliminate under-specification - Keep the system bounded and inspectable - Help Will develop coherent, buildable specs --- ## 15. File Organization All specs live under the Elnor Specs GitHub repo at: ``` /Users/OpenClaw1/Elnor/Elnor Specs/ (host) github.com/wbrody/Elnor-Specs branch main (remote) ``` ### 15.1 Repo top-level layout ``` Elnor Specs/ ├── README.md ← repo navigation aids for ChatGPT GitHub connector ├── REPO_FILE_MANIFEST.md ← exact file paths on main (use when search/index unavailable) ├── Current Specs/ ← operative specs (per-DOC subfolders) │ ├── DOC1/ DOC2/ ... DOC73/ DOC8/ EC Core/ │ ├── DOC80 Memory Control Plane/ ← NEW, in design │ ├── Connector and Integration Specs/ │ └── Miscellaneous Specs/ ├── Active Working and Red Team/ │ ├── DOC23 Red Teams/ │ ├── DOC80 Memory Control Plane Review Packs/ │ └── Instructions and Prompts/ ← this carryover prompt lives here ├── Memory Rebuild Docs/ ← Flattening Plan workspace │ ├── DOC80 Target Baseline/ │ │ ├── Skeletal Spec/ ← DOC80_Skeletal_Target_Baseline.md (current target arch) │ │ ├── Owner Map/ │ │ ├── Import Graph/ │ │ └── Retired Names/ │ ├── Flattening/ │ │ ├── Current Flattening Plan/ ← Flatten_and_Unify_Plan_V2_1c.md │ │ ├── Execution Ledger/Master/ ← RUN_STATE.md (current stage) │ │ ├── Reviews/ ← Stage prompts + responses │ │ ├── Supersession Matrix/ │ │ ├── Source Registry/ │ │ ├── Target Freeze/ │ │ └── ... (Aspirational Completion, Capability Inventory, etc.) │ └── Memory Rebuild Review Packs/ ├── OP-A and Operations and Trackers/ ← state trackers + dashboard │ ├── MASTER_SPEC_DOCUMENT_LIST.md (canonical) │ ├── SPEC_STATE.md ← per-spec workflow tracker │ ├── ADDENDA_STATE.md ← per-addendum disposition │ ├── OPA_V3_18.md ← Cross-Doc Obligation Tracker (legacy filename — target: OPA.md) │ ├── DRIFT_LOG.md ← nightly sync log │ ├── BACKUP_LOG.md ← OneDrive backup log │ ├── RECENT_WORK_SUMMARY.md ← per-doc "where I left off" (refreshed nightly) │ ├── OPENCLAW_RELEASE_TRACKER_LOG.md │ ├── dashboard.html ← visual dashboard (gitignored — local-only) │ └── Archived DOC OP-A and Operations DOCS/ ├── Design Mockups/ ├── Archived and Subsumed Specs and Lineage/ ← history; out of scope for nightly sync └── Parked and Abandoned Specs/ ``` ### 15.2 Repo conventions (GitHub-tracked) - **No version suffixes on new filenames.** Edit the canonical file; GitHub tracks history. Pre-existing version-suffixed files are legacy and stay as-is until Will renames them. - **Per-DOC subfolders** under `Current Specs/`. A DOC's parent spec + addenda + proposals + helper docs all live together in one subfolder. - **State trackers, dashboard, logs** all live under `OP-A and Operations and Trackers/`. - **Carryover prompt** at `Active Working and Red Team/Instructions and Prompts/ELNOR_UNIFIED_CARRYOVER_PROMPT.md` (canonical, no version suffix). - **`.gitignore`** excludes `dashboard.html` (local-only) and `New Chat Context/` (transient drag-and-drop bundles). Will may attach specific documents to a new chat — treat those attachments as the authoritative source for that work. ### 15A. Standing maintenance discipline **At the close of every spec drafting/revision session OR red team review session, update DOC OP-A.** The order: 1. Walk §6 of OP-A for the target doc you worked on. For each obligation that the new spec revision absorbed: move the row from §6 to §7 (Absorbed) with date and revision number; add verification note. 2. For obligations partially addressed: update status in §6 (e.g., `[REQ] [MISSING]` → `[REQ] [PARTIAL]`). 3. For new cross-doc gaps surfaced: add new rows in §6 with source citation, why, acceptance, calibrated-against (current target spec version). 4. Update §3 source registry if a new source document was consulted/folded. 5. Append a row to §10 maintenance log with date, action summary, and your model identifier. 6. If a NEW spec file was created or substantive revision shipped: also update SPEC_STATE.md row. If a new addendum was created or absorbed: also update ADDENDA_STATE.md. **This is non-negotiable.** Skipping the OP-A update at session close means the next session has no memory of what was decided. The nightly automated sync task handles mechanical drift (file mtimes, new file detection, dashboard regen) but cannot make judgment-level updates to OP-A — those are the reviewer's responsibility. --- ## 16. Recent Major Changes to Know About > **Volatile state lives on the dashboard, not in this carryover.** For current in-flight items, recommended next actions, per-workstream backlog, and the per-document "where I left off" summary, see `dashboard.html` (in `OP-A and Operations and Trackers/` under the new repo) — refreshed nightly. This carryover holds STABLE architectural context. The entries below are a 14-day rolling snapshot; older entries are in §16-Appendix. ### 16.0 Repo migration 2026-05-27 (CURRENT) **Specs moved.** New canonical location: `/Users/OpenClaw1/Elnor/Elnor Specs/` (GitHub repo `wbrody/Elnor-Specs`, branch `main`). Old `ECQ Development/CURRENT SPECS AND BUILD DOCS/` is dead — do not edit there. Per-DOC subfolders under `Current Specs//`. State trackers + dashboard under `OP-A and Operations and Trackers/`. Carryover prompt at `Active Working and Red Team/Instructions and Prompts/ELNOR_UNIFIED_CARRYOVER_PROMPT.md` (canonical, no version suffix). **No more version-suffix files going forward.** GitHub handles history. Edit canonical files in place. Legacy version-suffix files (DOC72_R5_73, OPA_V3_18, MASTER_SPEC_DOCUMENT_LIST_R3.62, etc.) remain as-is until Will renames them — do not create new versioned copies. **Flattening Plan in progress (Stage 5R).** New memory architecture being designed: DOC80-DOC87 family (8 members; DOC87 added at Stage 5R for Membership/Organization). DOC80 has a single proposal (`Current Specs/DOC80 Memory Control Plane/DAMS_V4_1_CONSOLIDATED_ARCHITECTURE_PROPOSAL.md`). DOC81-87 are still skeletal — design artifacts only under `Memory Rebuild Docs/`. Stage 5R Round 1 patches applied; awaiting Round 2 red-team review before Stage 6 (Slice Charters) can begin. Skeletal target baseline at `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md`. Plan at `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md`. ### 16.1 Last 14 days (2026-05-13 → 2026-05-27) — terse bullets - **DOC11 R15 R3 amendment + alignment list R3** (~2026-05-19): OpenClaw release alignment doc bumped R2→R3 covering through 2026.5.12. First intra-subfolder archive in DOC11 Openclaw Addenda subfolder. - **OPA V3.15** (~2026-05-19): cross-doc obligation tracker bumped V3.13→V3.15 (V3.14 skipped). Significant size growth — likely DOC24 R3.1.1 follow-on + DOC23 Addenda B family-topology absorption. - **SUBAGENT V5.1 ARCHITECTURE** (~2026-05-18): successor to V4 PRECOMPUTE_TOOL_OPTIMIZATION_NOTES. Elevation from notes to spec. - **DOC24 R3.1.1** (~mid-May): R3 follow-on adjudication closure. - **Skeletal DOC80 Target Baseline + Stage 5R adjudication** (2026-05-25 → present): Round 1 patches applied (43 ADQ items resolved including ADQ-220 adding DOC87). Awaiting Round 2 review. - **2026.5.22 OpenClaw stable cut**: NEW Meeting Notes plugin + Plugin SDK source-provider contract + `embeddingProviders` SDK capability + subagent bootstrap default narrowed to AGENTS.md+TOOLS.md only (DIRECT SUBAGENT V4 contract change). - **OneDrive backup gap closed 2026-05-27**: OneDrive folder reconnected after extended outage; first manual backup seeded; nightly task SKILL updated to use `mv`-not-`rm` and new path resolution. - **All 5 nightly task SKILLs updated 2026-05-27** to operate on new Elnor Specs repo with no-version-suffix convention: elnor-nightly-spec-sync, elnor-new-chat-context-sync, elnor-openclaw-release-tracker, elnor-recent-work-summary, elnor-onedrive-backup. --- ## §16-Appendix — Archived Recent Changes (older than 14 days) Compressed history of prior spec waves. Each entry: one line per wave. For substantive detail, see git log of the canonical files (now GitHub-tracked) or `OP-A and Operations and Trackers/DRIFT_LOG.md`. - **2026-05-19 (V20 wave):** OPA V3.13→V3.15 (V3.14 skipped); new top-level addendum `ELNOR_SUBAGENT_ARCHITECTURE_V5_1` (successor to A-5 V4); DOC11 R15 amendment proposal R2→R3 + alignment list R2→R3 + first intra-subfolder archive in DOC11 Openclaw Addenda. Master spec list R3.52→R3.53. - **2026-05-18 (V19 wave):** OPA V3.11 in proper Operations Docs; OPA V3.12 placement-irregular; DOC23 Task Optimization R4.1 V6 successor. - **2026-05-02 (V11 wave):** DOC23 Task Optimization R2/R3/R4 + RUNNING_ADDITIONS archived; new `DOC23 Addenda/` subfolder; Judge Context Management Proposal V1; Re-Prompt System Addendum; mockup V11_ALT_A. - **2026-05-01 (V10 wave):** DOC23 Task Optimization addendum burst (R2.0 → R3.0 → RUNNING_ADDITIONS → R4.0 + duplicate); state-tracker backfill. - **2026-04-30 (V9 wave):** DOC11 R15 R2 shipped; DOC72 CSA R2 shipped; DOC73 §6.4 Mechanism 4 Rollup V1; DOC73 V1.6 Architect Notes V1; new RECENT_WORK_SUMMARY operations file. - **2026-04-29 (V8 wave):** DOC73 V1.4.1 → V1.5.1 FINAL; DOC OP-A V3.6 → V3.7; DOC3 R11.3 Addenda A R2.2 consolidation (3 predecessors archived); DOC25 File Materialization V1.1. - **2026-04-28 (V7 wave):** DOC23 R3.0 → R3.1; new `DOC73 Addenda and Proposals/` subfolder; PACER Plugin Spec V1.1; Cross-Spec Issues Punch List V1. - **2026-04-27 (V6 wave):** DOC24 R2.5 → R3 (incorporates 125-card RT adjudication; new §38 Runtime Lifecycle); DOC OP-A V3 → V3.6 series with V3.3 RRB v6 fold-in + V3.4 OCM/MemoryAgent correction + V3.5 EC Core Agent Identity Registry decision + V3.6 agent-vs-capability registry split. Two pending dispositions: OBL-D24-RRB-04 (Running Brief slot), OBL-D15-RRB-03 (OCM agent). - **2026-04-26 (V5 wave — workflow infrastructure):** DOC OP-A promoted to standing instrument; DOC15 R3.1 Contract archived (52 capture points folded into OP-A V3); ROADMAP.md + SPEC_STATE + ADDENDA_STATE + dashboard.html + nightly sync task established. - **2026-04-26 (knowledge architecture wave):** DOC72 R5.72 → R5.73 (GIE V2.2 absorbed into §42A; 29 patches NP01-NP29 from 5-reviewer RT); DOC73 V1.4.1 FINAL promoted to operative (PBE — Positronic Brain Enhancement); DOC25 V2.0 promoted from addendum; companion proposals refreshed (EC Core Addendum A V3.3, DOC11 R15 R1, Q Integration Suite Additions R1, SUBAGENT V4). --- **Stand by for instructions.** Will may ask you to red-team a specification, prepare amendments, review schemas, evaluate architectural decisions, write operative spec sections, adjudicate red team findings, perform integration analysis, or review code. He may attach documents as background for the specs he plans to ask about. Do not start rewriting specs blindly. Do not assume phasing is an excuse for missing completeness. Do not assume companion docs are already updated. Do not introduce hidden second truth stores or vague agent magic. Do not assume stale docs are current — check §10.3. **The DOC80 family (memory rebuild) is in design (Stage 5R as of 2026-05-27); the older DOC72/DOC73/DOC1 memory stack is operative until Stage 7+ ships replacements.**