Elnor Repo Reader

# Cross-Spec Issues Punch List V1

**Source:** Gemini's "deeper pass" findings during DOC73 V1.4.1 Adjudication Card V3 red-team review (2026-04-28), plus selected cross-doc obligations not yet anchored to a specific spec revision.

**Purpose:** Track architectural, mathematical, and database-level issues that emerged during DOC73 review but extend beyond DOC73 V1.5 scope. These are real ELNOR concerns that need addressing in the relevant spec; without this list they're likely to get lost between DOC sessions.

**How to use this list:**
- When opening a session for any of the listed owning specs (DOC18, DOC72, EC Core, PropA, BDSM, SUBAGENT V4), reference the relevant items here as inputs.
- The DOC73 V1.5 obligations listed in V4 OP-A handle DOC73-derived requirements. This punch list captures issues that aren't DOC73-derived.
- Items marked "TRACKED" are already in V4 OP-A as cross-doc rows; they're listed here for completeness but don't need separate tracking.
- Items marked "NOT TRACKED" need to be folded into the relevant spec's work plan or into a standalone tracker.

---

## 1. SQLite Writer Starvation Mitigation

**Severity:** CRITICAL  
**Owning spec:** EC Core  
**Status:** PARTIALLY TRACKED (DOC73 V4 will declare its mutations route through EC writer; EC Core spec needs the actual single-writer middleware specification)

**Description:** SQLite WAL mode supports infinite concurrent readers but strictly one concurrent writer. With multiple sub-agents (MemoryAgent, DocumentIntelligenceAgent, future specialists) potentially attempting to commit results in parallel, naive multi-connection writes will produce `SQLITE_BUSY` exceptions at any meaningful load. Will's existing architecture treats EC as the sole durable writer, but the actual middleware mechanism needs explicit specification.

**Recommended fix in EC Core spec:**
- Define a `Write_Intent` queue (in-memory or persistent) that all agents emit to.
- Specify a single dedicated EC Database Worker that consumes `Write_Intents` and commits serially.
- Add invariant: agents may NOT hold direct write connections to SQLite. CI lint enforces no `BEGIN IMMEDIATE` or `INSERT/UPDATE/DELETE` outside the EC writer worker.
- Define backpressure semantics: what happens when the queue depth exceeds a threshold (block, drop with receipt, error).
- Specify atomicity boundaries: which write intents form a transaction.

**Reference:** Gemini deeper-pass Issue 1.1.

---

## 2. Vector Index Tombstone Filtering and GC

**Severity:** CRITICAL  
**Owning spec:** DOC18 (vector store) — with DOC73 V4 §8 carrying the consumer-side invariant  
**Status:** PARTIALLY TRACKED (DOC73 V4 §8 will require vector lane filtering by node status; DOC18 itself needs to specify the GC mechanism and the SQL view)

**Description:** `sqlite-vec` does not natively understand graph state machine. When a CU is retracted, superseded, or collapsed, its embedding remains in the vector index. Semantic searches return retracted CUs because they're semantically relevant, silently poisoning LLM context windows with dead facts. This is particularly dangerous in legal practice where superseded case law presented as current would be malpractice.

**Recommended fix in DOC18:**
- Mandate that vector queries go through a SQL view or query wrapper that joins `vec_nodes` against `nodes` table and filters by `nodes.status IN ('active', 'under_revision')`. Direct `SELECT FROM vec_nodes` is non-conformant.
- Specify the nightly consolidation job: `DELETE FROM vec_nodes WHERE rowid IN (SELECT id FROM nodes WHERE status IN ('retracted', 'superseded', 'collapsed') AND retracted_at < NOW() - 7 days)`. The 7-day window allows for restoration if a retraction is reversed.
- Add metric: `vector_lane_filtered_retract_hits_per_query` to detect filter-effectiveness regressions.
- Consider whether stale-with-flag is permitted (e.g., a query that explicitly asks for historical superseded content) — if so, the flag must be on the query, not bypass-able by default.

**Reference:** Gemini deeper-pass Issue 1.2.

---

## 3. FTS5 Tokenizer Configuration for Legal Citations

**Severity:** HIGH  
**Owning spec:** DOC18 (or wherever FTS5 keyword retrieval lane is configured)  
**Status:** TRACKED in DOC73 V4 OP-A as `OBL-D18-NEW-02`

**Description:** Default FTS5 tokenizer (`unicode61`) breaks tokens on punctuation. A search for `15 U.S.C. § 78j(b)` tokenizes into `[15, U, S, C, 78j, b]`, destroying exact-match retrieval for statutes, case citations, court docket numbers, and SEC accession numbers. For Will's securities litigation deployment, this is a substantive defect — keyword lane is supposed to provide defensive grounding for exact citation lookup.

**Recommended fix in DOC18:**
- Specify FTS5 tokenizer configuration. Trigram tokenizer (`tokenize="trigram"`) is the default safe choice; alternatively a custom tokenizer that preserves citation formats.
- Document which tokenizer is in use and what character classes are preserved as atomic.
- Add test fixtures with sample legal citations to verify tokenization.
- Note the tradeoff: trigram tokenizer increases index size; for ELNOR's M4 Pro single-user deployment this is acceptable.

**Reference:** Gemini deeper-pass Issue 1.3.

---

## 4. Beta-Distribution Skeptical Prior for LLM Extractions

**Severity:** HIGH  
**Owning spec:** Multiple — entry point in DOC73 §3.3 / §6.7 (DOC73 V4 will add); ongoing tuning in PropA / BDSM; underlying confidence math in DOC72  
**Status:** PARTIALLY TRACKED (DOC73 V4 will set entry-time prior to α=1, β=4; PropA and BDSM iteration is separate)

**Description:** With uniform Beta prior (α=1, β=1, confidence=0.5), a single LLM extraction adding one positive observation moves confidence to 2/3 = 0.66, which crosses validity thresholds. A single hallucinated extraction can promote a fact past tier promotion gates. For securities litigation use, this is unacceptable — wrong facts presented at >0.5 confidence in a legal memo are malpractice exposure.

**Recommended fix:**
- **DOC73 V4 §3.3 (entry-time prior):** New CUs from LLM extraction enter with skeptical Beta prior α=1, β=4 (initial confidence 0.20). A single LLM observation insufficient to cross any tier promotion threshold. Tier promotion requires either (a) multiple corroborating extractions from distinct source families, OR (b) one human explicit approval (+5 α equivalent).
- **PropA territory:** PropA may iterate the prior parameters post-deployment per §6D. Iteration must preserve the property "single LLM observation cannot cross validity threshold."
- **DOC72 confidence math:** DOC72 should document the Beta math used for confidence aggregation and the entry-time prior contract.

**Reference:** Gemini deeper-pass Issue 2.1.

---

## 5. Contextual Novelty Asymptote in Dense Corpora

**Severity:** HIGH  
**Owning spec:** DOC72 §1 (Contextual Novelty Gate)  
**Status:** NOT TRACKED — needs standalone obligation in DOC72's work plan

**Description:** Cosine-similarity-threshold-based novelty rejection (e.g., reject if similarity > 0.85 to existing graph) becomes increasingly aggressive as a corpus grows. By 150 documents in a Marex-sized matter, the vector space is dense enough that almost everything new will exceed the threshold. The extraction pipeline asymptotically grinds to halt, rejecting nuanced new evidence as "duplicate."

**Recommended fix in DOC72:**
- Algorithm change: `Novelty_Score = Raw_Distance × Decay_Multiplier(Time_Since_Similar_Fact_Added)`. Recent similar facts decay the rejection signal more aggressively than old ones.
- Alternative: when `Similarity > 0.85`, route to a fast LLM disambiguation pass — "Do these two similar statements contain a legally meaningful distinction?" — rather than auto-dropping.
- Add corpus-density telemetry so the system can detect when it's entering the asymptotic zone and adjust thresholds.
- Consider corpus-segmented thresholds: novelty thresholds appropriate for a 10-document corpus differ from those for a 500-document corpus.

**Recommended OP-A row (for DOC72 work plan):**
```
| OBL-D72-NEW-NOVELTY-01 | DOC72 | Address contextual novelty asymptote in dense corpora: time-decay multiplier on similarity threshold, OR fast LLM disambiguation pass on near-duplicate flags, OR corpus-density-adjusted thresholds. Default cosine threshold becomes overly aggressive as corpus grows beyond ~100 documents. | [REQ] [MISSING] |
```

**Reference:** Gemini deeper-pass Issue 2.2.

---

## 6. Sub-Agent Read-Only Discipline (Self-Fulfilling Prophecy Prevention)

**Severity:** CRITICAL  
**Owning spec:** Multiple — DOC73 V4 §15.7 (consumer-side invariant); SUBAGENT V4 §1.8/1.9 (specialist contract); EC Core (ephemeral store enforcement)  
**Status:** PARTIALLY TRACKED (DOC73 V4 will add the invariant; SUBAGENT V4 needs the corresponding contract; EC Core needs to specify the ephemeral session_context store)

**Description:** If MemoryAgent or DocumentIntelligenceAgent writes intermediate synthesis, scratchpads, query plans, or reasoning traces back into the durable knowledge graph, the next time those specialists query the graph they retrieve their own past summaries instead of source documents. The AI begins talking to itself, drifting from ground truth with every hop. This is a notorious failure mode for retrieval-augmented systems and Will's spec architecture has the right boundary but no enforcement mechanism.

**Recommended fix:**
- **DOC73 V4 §15.7:** MemoryAgent and DocumentIntelligenceAgent operate `READ_ONLY` against canonical durable graph. Intermediate synthesis MUST be written to ephemeral `session_context` store wiped at session end. Promotion to durable storage requires user approval through standard CU creation pipeline.
- **SUBAGENT V4 §1.8/1.9:** Specialist contracts include explicit READ_ONLY assertion against DOC72 graph and DOC73 CU store. Non-conformant specialists are quarantined.
- **EC Core:** Specify the ephemeral `session_context` store: scope, lifecycle, wipe semantics, isolation between concurrent sessions, what happens if a session is resumed.
- Add CI lint: any specialist code path that writes to `nodes`, `edges`, `cus`, or `vec_nodes` is non-conformant.

**Reference:** Gemini deeper-pass Issue 3.1.

---

## 7. AVAPO Schema Evolution Migration Discipline

**Severity:** MEDIUM  
**Owning spec:** PropA (AVAPO ownership) with DOC73 §6D adaptation engine integration  
**Status:** PARTIALLY TRACKED (DOC73 V4 §6D will add the migration-plan requirement; PropA needs to actually implement it)

**Description:** When AVAPO improves an extraction prompt that changes output schema (field rename, type change, structural change), the database accumulates CUs in mixed schemas. Aggregation queries (`SELECT SUM(revenue)`) crash because data shape mutated. Without migration discipline, AVAPO's own optimization process silently corrupts downstream queries.

**Recommended fix:**
- **DOC73 V4 §6D:** Adaptation proposals altering extraction output schema MUST include migration plan: (a) re-extract historical nodes through new prompt, OR (b) maintain parallel schemas with `extraction_schema_version` field on every CU, with consumers handling both versions until migration completes. Adaptations without migration plan MUST NOT be applied automatically.
- **PropA:** Implement schema-change detection in AVAPO. When a prompt change crosses a schema boundary (defined by structural diff against extraction output), AVAPO holds the proposal until migration plan is generated and approved.
- Define what counts as a schema-changing diff: field renames yes, type changes yes, structural changes yes, prompt wording changes that don't alter output structure no.

**Reference:** Gemini deeper-pass Issue 3.2.

---

## Already-tracked items (in V4 OP-A as cross-doc rows; listed for completeness)

These are tracked in DOC73 V4's OP-A consolidation and don't need separate tracking on this punch list. They're DOC73-derived obligations on other specs:

- **`OBL-D15-NEW-OCM-01`** — DOC15 publishes OCM and cil_advisor lifecycle/timeout/degraded-output contract.
- **`OBL-D72-NEW-PBE-CLUSTER-01`** — DOC72 exposes graph-clustering API/result contract consumable by DOC73 PBE cluster detection.
- **`OBL-EC-NEW-PBE-RECEIPT-01`** — EC Core implements `PBEOperationReceiptLite` wrapper enforcement.
- **`OBL-D18-NEW-02`** — FTS5 tokenizer for legal citations (also listed above as Item 3).
- **`OBL-EC-AGT-NEW-01`** — SpecialistRegistry exposes owner-doc, timeout class, health endpoint, degraded-response schema ref, lifecycle owner for all named specialists.

---

## Notes on usage

When working on DOC18, DOC72, EC Core, PropA, BDSM, or SUBAGENT V4 in future sessions:

1. Reference this list as input alongside the spec's existing materials.
2. Items 1, 2, 5, 6 are CRITICAL for ELNOR to function correctly under load; defer at architectural risk.
3. Items 3, 4 are HIGH for legal-practice deployment specifically; non-securities deployments would assess differently.
4. Item 7 is MEDIUM but compounds over time as PropA iterates more aggressively.

This list is V1; items get removed as their owning spec absorbs them. Update this file when items land in their owning specs.