DOC73_V1_6_CSA_INTEGRATION_TRACE_R0.1.md
Current Specs/DOC73/Audit and Process Records/DOC73_V1_6_CSA_INTEGRATION_TRACE_R0.1.md
# DOC73 V1.6 — CSA → DOC73 Integration Trace R0.1
**Document kind:** Step 9 supplemental deliverable for V1.6 release wave handoff package.
**Date created:** 2026-05-03 (post-architect triage of BUILD_QUESTIONS Tier B items).
**Author:** Claude (per architect Will's request 2026-05-03).
**Status:** R0.1 — initial trace. Companion to V1.6.1 deferred review item `DOC2_CSA_INTEGRATION_REVIEW` in `DOC73_V1_6_DEFERRAL_INVENTORY_R1.md` §1.2.
---
## ★ POST-EXTRACTION STATUS (added 2026-05-04 per architect CSA extraction prompt)
**CSA references have been EXTRACTED from DOC73 V1.6 release wave** (architect prompt 2026-05-04; see `DOC73_V1_6_CSA_EXTRACTION_PRE_REPORT.md` + `DOC73_V1_6_CSA_EXTRACTION_REPORT.md` for the surgical extraction record).
The two question-sets in this document now have DIFFERENT post-extraction status:
**§1-§10 (Q-CSA-1 through Q-CSA-22): MOOT for DOC73 V1.6 post-extraction.**
These questions tracked CSA R2 → DOC73 V1.6 absorption calibration ("did CSA R2 spell out this invariant? did CSA R2 specify this entry kind?"). Post-extraction, DOC73 V1.6 no longer absorbs CSA; CSA is DOC72's architectural concern. These questions remain relevant for **DOC72 + DOC2 architecture on their own timelines** (when DOC72 designs CSA orchestration, these questions resurface in that context — but not at V1.6 level).
**§11 (Q-MECH4-1 through Q-MECH4-6): STILL OPEN; arguably MORE relevant post-extraction.**
These questions track DOC73's own Mechanism 4 V1 proposal fidelity (storage format, cadence model, PBE feedback loop, token budgets, named knob, worked example) — INDEPENDENT of CSA. Post-extraction, V1.6 Mechanism 4 has ADDITIONAL divergences from the V1 proposal (CSA orchestration scaffolding removed entirely; consumer contract pointer added per OBL-D73-RECENT-ACTIVITY-ROLLUP-CONSUMER-CONTRACT-01). The fidelity review item `MECH4_PROPOSAL_FIDELITY_REVIEW` in `DOC73_V1_6_DEFERRAL_INVENTORY_R1.1.md` §1.2 remains active.
**`DOC2_CSA_INTEGRATION_REVIEW` deferral item:** SUPERSEDED 2026-05-04 (see `DOC73_V1_6_DEFERRAL_INVENTORY_R1.1.md` §1.2).
**`MECH4_PROPOSAL_FIDELITY_REVIEW` deferral item:** STILL ACTIVE (updated description; see `DOC73_V1_6_DEFERRAL_INVENTORY_R1.1.md` §1.2).
**`DOC73_TO_DOC72_CSA_INTERFACE_REVIEW` deferral item:** NEW per CSA extraction (see `DOC73_V1_6_DEFERRAL_INVENTORY_R1.1.md` §1.2).
This trace document is preserved as historical record per architect Phase 3 deferral discipline. Prior revisions of artifacts (R0.4 / R0.3 / R0.2) are also preserved as historical record so the extraction can be rolled back if any unwanted change surfaces.
---
## §0. Why this document exists
### §0.1 Architect concern (verbatim, 2026-05-03)
> "I didn't realize the CSA had been folded in. I was not done with that. Doc 2 is going to be integrated into it. I should have paid more attention. But this seems to be a pretty good version of it. So maybe it's okay. ... My note: it was an open item. I wasn't sure what I was going to do. I hadn't reviewed doc two yet. But that was the plan is that the CSA negates the need for doc two integration. What I would also say is that I should keep the CSA as written or so it could be reviewed as an overall document to see what was missing. Or do a separate review of all the CSA features that were folded into Doc 73 to make sure they're complete because I hadn't made final decisions on it at all. And now it's all part of Doc 73, but the review of it will be scattered. So that should be noted somewhere so that I come back to it or something of that nature. Maybe even with guideposts so I can tell where it was folded into Doc 73."
### §0.2 Background
V4 (the inventory adjudication card produced 2026-05-01) folded CSA R2 ("Continuity Synthesis Architecture R2") into the V1.6 release wave via Mechanism 4 RecentActivityRollup. This happened before the architect had:
- Finalized CSA R2's design.
- Reviewed DOC2 to determine whether DOC2 integration was required or whether CSA R2 superseded the need for DOC2 integration entirely.
- Made final decisions on CSA structure, scope, or feature set.
V4 / V1.6 absorbed CSA R2 across multiple artifacts:
- **Artifact 1 §16** — Mechanism 4 RecentActivityRollup canonical schema (the primary CSA absorption site).
- **Artifact 1 §A.4** — OrientationContextEntry type.
- **Artifact 1 §A.5** — WorkPhaseEntry, CorpusActivityEntry, CaseActivityEntry, ArtifactEntry, UnresolvedThreadEntry types.
- **Artifact 2 §25** — Group N legal-corpus-aware CSA consumer surface.
- **Artifact 4 §18** — CSAInjectionTierPolicy runtime.
- **DOC72 R5.74+** (cross-doc forecast) — primary CSA R2 absorption target per `OBL-D72-CSA-R2-DOC73-ALIGN-01`.
### §0.3 What this document does
This document maps **every CSA R2-derived feature, schema, invariant, or runtime concept** to its precise location in DOC73 V1.6 release wave. Architect can review CSA completeness in one pass without grepping across 5 artifact files.
**§11 added 2026-05-04:** parallel fidelity check for the Mechanism 4 V1 proposal (`DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1.md`) → V1.6 absorption. CSA R2 named the proposal as a CRITICAL cross-doc obligation; §11 confirms the proposal was honored and surfaces specific divergences (especially the cadence-model shift). Architect reviews CSA + proposal in one pass.
### §0.4 What this document does NOT do
- Does NOT re-author CSA R2 (CSA R2 source-of-truth presumably exists separately; this document maps what was absorbed, not what was originally specified).
- Does NOT decide whether DOC2 integration is required (architect decision; deferred to V1.6.1 review per `DOC73_V1_6_DEFERRAL_INVENTORY_R1.md` §1.2 `DOC2_CSA_INTEGRATION_REVIEW`).
- Does NOT modify any V1.6 release wave content (read-only trace).
- Does NOT include V1.6.1+ CSA work that may extend the absorbed footprint.
### §0.5 How to use this document
1. Architect reviews each row of §1-§5 against CSA R2 source (when available).
2. Architect flags any CSA R2 features that did NOT make it into DOC73 V1.6 (gaps).
3. Architect flags any DOC73 V1.6 features that diverged from CSA R2 design intent (drift).
4. Architect decides re: DOC2 integration: (a) CSA absorption is sufficient and DOC2 integration is moot (as V4 assumed), OR (b) DOC2 integration still required and V1.6.1 must add it, OR (c) needs further review.
5. Architect dispositions tracked in `DOC73_V1_6_DEFERRAL_INVENTORY_R1.md` §1.2.
---
## §1. CSA R2 → Mechanism 4 schema fold-in (PRIMARY ABSORPTION SITE)
**Canonical home:** `DOC73_Artifact1_R0.4.md` §16.
### §1.1 Section structure (Artifact 1 §16)
```text
Artifact 1 §16 = §6.4 Mechanism 4 RecentActivityRollup Canonical Schema
(V4 NEW per V4-§0.4-2 reclassification from Artifact 2)
§16.1 V4 NEW reclassification framing + CSA R2 cross-doc dependency
§16.2 RecentActivityRollup canonical schema (the central CSA fold-in)
§16.2A RecentActivityRollup writer contract (R0.2 NEW per audit CRIT-2)
§16.3 Cadence + decay policy
§16.4 INVs INV-N-ORIENTATION-1 + INV-N-NO-CIRCULAR-EVIDENCE-1
§16.5 Consumer contract (cross-references Artifact 2 §25 + Artifact 4 §18)
§16.6 OP-A row tracking
```
### §1.2 RecentActivityRollup schema (CSA R2 → V1.6 mapping)
CSA R2 concept of "continuity log" → V1.6 RecentActivityRollup schema (Artifact 1 §16.2):
```text
CSA R2 concept → V1.6 RecentActivityRollup field
─────────────────────────────────────────────────────────────────────────────────
continuity_log entries → RecentActivityRollup record
rollup cadence → rollup_kind enum: weekly | monthly |
session_summary | hourly_orientation
storage path → canonical_store_path (JSONL per V3-N-2;
NOT MD)
session linkage → doc73_session_summary_id
6 entry-array kinds (per V3-N-1):
orientation entries → orientation_entries: OrientationContextEntry[]
(Artifact 1 §A.4)
work phase entries → work_phase_entries: WorkPhaseEntry[]
(Artifact 1 §A.5)
corpus activity entries → corpus_activity_entries: CorpusActivityEntry[]
case activity entries → case_activity_entries: CaseActivityEntry[]
(legal-domain; per Artifact 2 §25.1
consumer surface)
artifact entries → artifact_entries: ArtifactEntry[]
unresolved thread entries → unresolved_thread_entries:
UnresolvedThreadEntry[]
CSA R2 alignment ref → csa_r2_continuity_log_ref
(pointer to original CSA R2 entry per
V3-N-3 "wrap" decision)
CSA injection consumer linkage → csa_injection_tier_consumer_refs[]
(Artifact 4 CSAInjectionTierPolicy
consumers)
decay policy → decay_class on each entry kind:
ephemeral_hourly | session_lifetime |
weekly_rollup | monthly_rollup
INV enforcement flags → orientation_only_invariant_enforced
(INV-N-ORIENTATION-1)
no_circular_evidence_invariant_enforced
(INV-N-NO-CIRCULAR-EVIDENCE-1)
receipt wrapping → standard receipt patterns per
PBEOperationReceiptLite + downstream
kernel envelope (Artifact 3)
```
### §1.3 Open questions for architect re: §1.2 mapping
**Q-CSA-1:** Does CSA R2 specify additional entry kinds beyond the 6 above? V1.6 ships exactly 6.
**Q-CSA-2:** Does CSA R2 specify additional rollup cadences beyond the 4 above? V1.6 ships: weekly, monthly, session_summary, hourly_orientation.
**Q-CSA-3:** Is `csa_r2_continuity_log_ref` the right alignment shape? V1.6 treats CSA R2 as a continuity-log producer that V1.6 RecentActivityRollup wraps; CSA R2 logs remain queryable via this ref.
**Q-CSA-4:** Is the storage format choice (JSONL per V3-N-2; NOT MD) consistent with CSA R2 expectations? V4 made this decision; architect should confirm.
---
## §2. CSA R2 → entry-kind type definitions (Artifact 1 §A.4-§A.5)
**Canonical home:** `DOC73_Artifact1_R0.4.md` §A.4 + §A.5.
Each of the 6 entry kinds has its own type schema:
### §2.1 OrientationContextEntry (§A.4)
```typescript
type OrientationContextEntry = {
entry_id: string;
entry_kind: "work_phase_summary" | "active_matter_summary" |
"recent_corpus_activity" | "session_focus_summary";
narrative_text: string;
cited_node_refs: NodeRef[]; // entities mentioned (NOT evidence ref;
// per INV-N-NO-CIRCULAR-EVIDENCE-1)
generated_at: ISO8601;
decay_class: "ephemeral_hourly" | "session_lifetime" |
"weekly_rollup" | "monthly_rollup";
schema_version: 1;
};
```
**CSA R2 mapping:** orientation prose for case/work-phase context surfacing. V1.6's narrative_text + cited_node_refs structure preserves CSA R2's intent that orientation text references entities WITHOUT establishing evidentiary citation chains.
**Open question Q-CSA-5:** Does CSA R2 specify additional entry_kinds beyond the 4 above (work_phase_summary / active_matter_summary / recent_corpus_activity / session_focus_summary)?
### §2.2 WorkPhaseEntry (§A.5)
```typescript
type WorkPhaseEntry = {
entry_id: string;
phase_label: string; // e.g., "drafting", "research", "review"
active_matter_refs: NodeRef[];
active_corpus_refs: CorpusRef[];
duration_estimate_minutes: number;
schema_version: 1;
};
```
**CSA R2 mapping:** work-phase context — what the user is currently doing.
**Open question Q-CSA-6:** Does CSA R2 specify a closed enum for phase_label (vs free-form string)? V1.6 leaves it free-form.
### §2.3 CorpusActivityEntry (§A.5)
```typescript
type CorpusActivityEntry = {
entry_id: string;
corpus_id: CorpusRef;
activity_kind: "ingestion" | "extraction" | "review" |
"synthesis" | "browsing";
document_count: number;
cu_count: number;
schema_version: 1;
};
```
**CSA R2 mapping:** which corpora active + activity-kind + counts.
**Open question Q-CSA-7:** Does CSA R2 specify additional activity_kinds beyond the 5 above?
### §2.4 CaseActivityEntry (§A.5)
```typescript
type CaseActivityEntry = {
entry_id: string;
matter_ref: NodeRef; // active matter / case ref (DOC72
// world_entity)
activity_kind: "filing_review" | "deposition_prep" | "brief_drafting" |
"discovery_review" | "settlement_negotiation" | "trial_prep";
filing_unit_refs: FilingUnitRef[];
schema_version: 1;
};
```
**CSA R2 mapping:** legal-domain-specific activity context.
**Open question Q-CSA-8:** Does CSA R2 specify CaseActivityEntry as a legal-domain extension or as a base concept? V1.6 ships it in core (§A.5) but legal-domain consumer surface lives in Artifact 2 §25.1.
**Open question Q-CSA-9:** Does CSA R2 specify additional activity_kinds beyond the 6 legal ones above?
### §2.5 ArtifactEntry (§A.5)
```typescript
type ArtifactEntry = {
entry_id: string;
artifact_ref: SourceArtifactRef;
// (additional fields per V4 R-CL4 #11; full schema in Artifact 1 §A.5)
schema_version: 1;
};
```
**CSA R2 mapping:** specific documents under focus.
**Open question Q-CSA-10:** Does CSA R2 specify what "artifact" means in this context — SourceArtifact (Artifact 5) or something broader (any work_product)? V1.6 uses SourceArtifactRef.
### §2.6 UnresolvedThreadEntry (§A.5)
```typescript
type UnresolvedThreadEntry = {
entry_id: string;
// open questions / loose ends from prior sessions
// (full schema in Artifact 1 §A.5)
schema_version: 1;
};
```
**CSA R2 mapping:** open questions / loose ends from prior sessions.
**Open question Q-CSA-11:** Does CSA R2 specify rich semantics for unresolved threads (e.g., automatic expiration after N days; user-resolution closure; cascade resolution)? V1.6 leaves this minimally specified.
---
## §3. CSA R2 → INV invariants
**Canonical home:** `DOC73_Artifact1_R0.4.md` §16.4.
### §3.1 INV-N-ORIENTATION-1
```text
INV-N-ORIENTATION-1 (canonical home Artifact 1 §16.4):
CSA orients query framing only; never satisfies legal evidence query.
RecentActivityRollup entries are framing context for the LLM, NOT
retrievable evidence.
Implementation:
- search router (Artifact 4 §15) MUST filter RecentActivityRollup
entries OUT of search result candidate sets.
- CU synthesis (Artifact 1 §8.2 INV-MVC-CU-1) MUST NOT cite
OrientationContextEntry.cited_node_refs as evidence.
- audit replay (Artifact 3 §6) treats RecentActivityRollup as
inputs to LLM context construction, NOT as evidence in the
causal chain.
```
**CSA R2 mapping:** This is a CSA R2 invariant absorbed into V1.6. The "orientation only" property is load-bearing for keeping CSA-injected context separate from analytical evidence chains.
**Open question Q-CSA-12:** Did CSA R2 spell out this invariant, or did V4 introduce it? Either way, it's correctly load-bearing — without it, orientation prose could contaminate analysis.
### §3.2 INV-N-NO-CIRCULAR-EVIDENCE-1
```text
INV-N-NO-CIRCULAR-EVIDENCE-1 (canonical home Artifact 1 §16.4):
orientation entries' cited_node_refs are NEVER used as evidence
(search results, ranking signals, authority computation). Legal-aware
framing is framing only.
Implementation:
- cu_input_edges (Artifact 1 §8.2) MUST NOT have CSA orientation
entries as input nodes.
- search ranking (Artifact 4 §15.4 INV-M-ACCESS-RANK-1) MUST NOT
use OrientationContextEntry.cited_node_refs as ranking signal.
- cu_authority (Artifact 1 §9 + Artifact 3 §8) MUST NOT propagate
authority through orientation entries.
```
**CSA R2 mapping:** This pairs with INV-N-ORIENTATION-1. Together they form a hard guardrail preventing CSA injection from contaminating analytical evidence chains.
**Open question Q-CSA-13:** Same as Q-CSA-12 — confirm CSA R2 spelled this out.
---
## §4. CSA R2 → consumer surfaces
### §4.1 Group N legal-corpus-aware consumer (Artifact 2 §25)
**Canonical home:** `DOC73_Artifact2_R0.3.md` §25.
```text
Section structure:
§25.1 Legal-corpus-aware consumer surface for RecentActivityRollup
§25.2 Group N consumer behavior contract (R0.2 NEW per HIGH-A2-4)
(domain detection: 4 conditions identify "legal-aware" rollup
entries; producer/consumer split semantics)
```
**CSA R2 mapping:** CSA R2 likely specifies a domain-specific consumer concept (e.g., "legal" vs "general"). V1.6 implements this via `domain_profile = "legal"` field + 4-condition domain detection in §25.2:
```text
A RecentActivityRollup entry is "legal-corpus-aware" iff:
(a) entry.corpus_ref points to a knowledge_corpus world_entity
with CorpusProfile.extraction_spec.domain_profile = "legal", OR
(b) entry.matter_ref points to a legal case (CaseRef per §11.3
ResolvedCaseIdentity), OR
(c) entry.filing_unit_refs[] non-empty.
```
**Open question Q-CSA-14:** Does CSA R2 specify domain awareness this way? V1.6 V3-N-1 + V3-N-3 absorbed this; Q-3-A2-3 (architect-triaged 2026-05-03 ACCEPT) confirmed this consumption path.
### §4.2 CSAInjectionTierPolicy runtime (Artifact 4 §18)
**Canonical home:** `DOC73_Artifact4_R0.3.md` §18.
```text
Section structure:
§18.1 V4-§0.4-2 reclassification framing
§18.2 CSAInjectionTierPolicy schema with 4-tier enum +
**DEFAULT tier_3_minimal_orientation** (R0.3 PATCH per
architect triage 2026-05-03 Q-3-A4-7)
§18.3 Consumer contract for RecentActivityRollup
§18.4-§18.X Tier-specific behavior + per-session overrides
```
**CSA R2 mapping:** CSA R2 likely specifies "how to inject the CSA into a session." V1.6 expanded this to a 4-tier policy:
- `tier_1_full_orientation` — every session injects full RecentActivityRollup AND continues per-query re-injection
- `tier_2_targeted_orientation` — inject only when query_intent = "orientation" or "session_handoff"
- `tier_3_minimal_orientation` — inject ONCE on session start; not per query (**V1.6 DEFAULT**)
- `tier_4_disabled` — no CSA injection
**Open question Q-CSA-15:** Did CSA R2 specify a tier hierarchy or just one injection mode? V4 introduced the 4-tier abstraction; architect should confirm whether this matches CSA R2 design intent.
**Open question Q-CSA-16:** The R0.3 default of tier_3 is architect-chosen 2026-05-03. CSA R2 may or may not have specified a default; architect should confirm.
### §4.3 CSA writer agent (Artifact 1 §16.2A)
**Canonical home:** `DOC73_Artifact1_R0.4.md` §16.2A (R0.2 NEW per audit CRIT-2).
```text
RecentActivityRollup writer contract:
- Writer agent: nightly trigger (configurable cadence per rollup_kind)
- Budget: capped per-rollup token budget
- INV enforcement: writer MUST honor INV-N-ORIENTATION-1 +
INV-N-NO-CIRCULAR-EVIDENCE-1 at write time
- Source: aggregates session activity logs, kernel event log,
extraction events, search activity
- Output: RecentActivityRollup row (durable per
INV-V16-RETENTION-DURABLE-1)
```
**CSA R2 mapping:** Who writes the CSA continuity log? V1.6 specifies a nightly writer agent with budget + INV enforcement. CSA R2 may have specified this differently.
**Open question Q-CSA-17:** Does CSA R2 specify writer agent semantics, cadence, or budget? V1.6 R0.2 introduced this contract per audit CRIT-2; should be reviewed against CSA R2.
---
## §5. CSA R2 → cross-doc forecasts
### §5.1 DOC72 R5.74+ absorption
**Owner:** DOC72 (cross-doc forecast per V4 §0.4 calibration table).
```text
DOC72 R5.74+ ships:
- CSA R2 absorption (primary canonical home)
- filing-relationship edge types per OBL-D72-V16-DOCREL-01
- WorkContextConstellation read-model per OBL-D72-NEW-05
- decay floor per OBL-D72-D24-DECAY-FLOOR-01
- StorageRegistryEntry consumer surface per
OBL-D72-STORAGE-REGISTRY-CONSUMER-01
OP-A row: OBL-D72-CSA-R2-DOC73-ALIGN-01 (cross-doc dependency)
```
**CSA R2 mapping:** CSA R2 may live primarily in DOC72 namespace; DOC73 V1.6 release wave consumes via cross-doc forecast.
**Open question Q-CSA-18:** Is CSA R2 a DOC72 spec, a DOC73 spec, or a separate spec that DOC72 absorbs? V4 treats it as DOC72-absorbed; DOC73 V1.6 release wave consumes via OBL-D72-CSA-R2-DOC73-ALIGN-01.
**Open question Q-CSA-19:** Per Q-0a-1 in BUILD_QUESTIONS (architect triage 2026-05-03 ACCEPT): rename `OBL-D72-CSA-R2-MECH4` → `OBL-D73-CSA-R2-MECH4` in OP-A V4. This naming acknowledges DOC73 ownership of the absorption surface even if CSA R2 source-of-truth is in DOC72.
### §5.2 DOC2 freshness manager retirement
**Per Artifact 1 §16.1 framing:**
> "V1.6 cross-doc dependency: OBL-D72-CSA-R2-DOC73-ALIGN-01 — DOC72 R5.74+ absorbs CSA R2 (Continuity Synthesis Architecture R2); **DOC2 freshness manager retires per CSA R2 supersession.**"
**CSA R2 mapping:** This is the architect's "CSA negates the need for DOC2 integration" hypothesis encoded in V4. V1.6 ships AS IF DOC2 freshness manager is being retired. If architect's V1.6.1 review concludes DOC2 integration is still required, this assumption needs revisiting.
**This is the SINGLE LARGEST OPEN QUESTION about V1.6 CSA absorption.** If DOC2 retirement was not the right call, V1.6 has gaps in functionality that DOC2 was supposed to provide.
**Open question Q-CSA-20:** Architect: review DOC2 to determine whether CSA R2 + Mechanism 4 in V1.6 covers DOC2's responsibilities completely, OR whether V1.6.1 needs to add DOC2-derived features.
---
## §6. CSA R2 acceptance tests
### §6.1 V3-AT-12 — CSA continuity log INV-0B.1 compliance
**Source:** V4 §6 acceptance tests; V3-AT-12.
```text
V3-AT-12: CSA continuity log entries comply with INV-0B.1 (kernel
discipline — every audit-relevant event has a receipt).
Implementation home: Artifact 1 §16 (Mechanism 4 absorbs CSA R2 +
INV-0B.1 receipt discipline applies via standard PBEOperationReceiptLite
wrapping).
```
### §6.2 V3-AT-22 — CSA recent_activity orientation only
**Source:** V4 §6 acceptance tests; V3-AT-22.
```text
V3-AT-22: CSA recent_activity orientation only — INV-N-ORIENTATION-1
+ INV-N-NO-CIRCULAR-EVIDENCE-1 enforcement verified at runtime.
Implementation home: Artifact 1 §16.4 (canonical INV declarations) +
Artifact 2 §25 (legal-corpus consumer enforcement) + Artifact 4 §15.4
(search router orientation filtering) + Artifact 3 §8 (cu_authority
propagation through orientation entries blocked).
```
**Open question Q-CSA-21:** Are these the ONLY CSA-related acceptance tests V1.6 ships? V4 lists ~40 acceptance tests; only V3-AT-12 + V3-AT-22 explicitly reference CSA. CSA R2 design may have additional implicit test obligations not surfaced here.
---
## §7. CSA R2 → V1.6.1 / V1.7+ deferrals (CSA-related)
Per `DOC73_V1_6_DEFERRAL_INVENTORY_R1.md`:
### §7.1 Indefinite deferral
```text
CSA_CONTINUITY_LOG_CARVE_OUT_OPTION (V1.7+ if ephemeral-staging case
emerges) — per V4 §6 indefinite items list.
Reason: V1.6 absorbs CSA R2 fully into Mechanism 4; if a future case
emerges where CSA continuity logs need to ephemerally stage outside
the durable Mechanism 4 path, that's a V1.7+ design question.
```
**Open question Q-CSA-22:** Does this V1.7+ deferral correctly reflect CSA R2 design intent? CSA R2 may have specified ephemeral staging as a base feature.
### §7.2 V1.6.1 deferral (added 2026-05-03 per architect note)
```text
DOC2_CSA_INTEGRATION_REVIEW (V1.6.1 review item) — per
DOC73_V1_6_BUILD_QUESTIONS.md §11.3 architect triage 2026-05-03 +
this document §0.
Reason: V4 / V1.6 absorbed CSA R2 into Mechanism 4 before architect
finalized CSA design + reviewed DOC2 integration. Companion document:
this trace.
```
---
## §8. Summary: open questions for architect
The 22 open questions surfaced in §1-§7:
```text
Q-CSA-1 Are 6 entry kinds the complete set per CSA R2?
Q-CSA-2 Are 4 rollup cadences the complete set?
Q-CSA-3 Is csa_r2_continuity_log_ref the right alignment shape?
Q-CSA-4 Is JSONL (not MD) storage format correct per CSA R2?
Q-CSA-5 Are 4 OrientationContextEntry.entry_kinds complete?
Q-CSA-6 Is WorkPhaseEntry.phase_label closed enum or free-form?
Q-CSA-7 Are 5 CorpusActivityEntry.activity_kinds complete?
Q-CSA-8 Is CaseActivityEntry legal-domain or base concept?
Q-CSA-9 Are 6 CaseActivityEntry.activity_kinds complete?
Q-CSA-10 Is "artifact" in ArtifactEntry = SourceArtifact?
Q-CSA-11 Should UnresolvedThreadEntry have richer semantics?
Q-CSA-12 Did CSA R2 spell out INV-N-ORIENTATION-1?
Q-CSA-13 Did CSA R2 spell out INV-N-NO-CIRCULAR-EVIDENCE-1?
Q-CSA-14 Does CSA R2 specify domain awareness via 4-condition
detection?
Q-CSA-15 Did CSA R2 specify the 4-tier injection hierarchy?
Q-CSA-16 Did CSA R2 specify a default tier (we chose tier_3)?
Q-CSA-17 Does CSA R2 specify writer agent semantics?
Q-CSA-18 Is CSA R2 a DOC72, DOC73, or separate spec?
Q-CSA-19 OP-A row prefix DOC72 vs DOC73 (Q-0a-1 ACCEPTED rename
to D73)?
Q-CSA-20 ★ DOC2 retirement decision — single largest open question.
Q-CSA-21 Are V3-AT-12 + V3-AT-22 the ONLY CSA acceptance tests?
Q-CSA-22 Does V1.7+ ephemeral-staging deferral match CSA R2 intent?
```
**Q-CSA-20 is the load-bearing one.** All other Q-CSA-* items are calibration questions (does the absorbed structure match CSA R2 source?). Q-CSA-20 is the architectural decision — does CSA R2 + Mechanism 4 actually obviate DOC2 integration as V4 assumed?
---
## §9. Recommended architect review process
When you (Will) come back to this:
```text
Step 1: Read CSA R2 source-of-truth (whatever document(s) hold it).
Likely candidates:
- A standalone CSA R2 design document
- DOC72 R5.73 §X (or a draft of R5.74+)
- V4 inventory adjudication card §2.3 Group N (where V4
absorbed CSA R2 into V1.6)
Step 2: Read DOC2 source-of-truth.
Determine what DOC2 specifies that CSA + Mechanism 4 may
or may not cover.
Step 3: Walk through this trace document §1-§5 row by row.
For each row, check CSA R2 source for completeness:
- Did CSA R2 specify a feature that didn't make it into
DOC73 V1.6? (gap)
- Did DOC73 V1.6 add a feature that diverges from CSA
R2 design intent? (drift)
Step 4: Answer Q-CSA-20 specifically:
- DOC2 retirement is correct (CSA absorption sufficient)
- DOC2 integration still required (V1.6.1 / V1.7 work)
- Needs further design
Step 5: If gaps or drift identified → V1.6.1 patch list with
targeted additions to specific DOC73 V1.6 sections.
Step 6: Update DOC73_V1_6_DEFERRAL_INVENTORY_R1.md §1.2
DOC2_CSA_INTEGRATION_REVIEW row with disposition:
- "Reviewed; CSA absorption complete; no V1.6.1 patch needed"
- "Reviewed; gaps identified; V1.6.1 patch required" + list
- "Reviewed; DOC2 integration required; V1.6.1 / V1.7 work
scoped" + scope summary
```
**Estimated time:** 2-4 hours of focused review (depending on how much CSA R2 / DOC2 source material exists and how it's organized).
---
## §10. File locations for review
For convenience:
```text
PRIMARY REVIEW FILES (CSA absorption):
DOC73_Artifact1_R0.4.md — §16 Mechanism 4 schema +
§A.4-§A.5 entry kinds
DOC73_Artifact2_R0.3.md — §25 Group N consumer
DOC73_Artifact4_R0.3.md — §18 CSAInjectionTierPolicy
SUPPORTING FILES:
DOC73_V1_6_BUILD_QUESTIONS.md — §11 architect triage
(Q-3-A4-7 tier_3 default
disposition)
DOC73_V1_6_DEFERRAL_INVENTORY_R1.md — §1.2 DOC2_CSA_INTEGRATION_REVIEW
row
DOC73_V1_6_HELPER_HOMES_R0.1.md — §1.27 lookup_latest_rollup
helper for Mechanism 4
consumer
CROSS-DOC FORECAST FILES (NOT IN BUILD FOLDER; cross-doc forecast):
DOC72 R5.74+ — primary CSA R2 absorption
target
DOC2 — to be reviewed for retirement
vs integration question
(Q-CSA-20)
V4 ANCHOR:
DOC73_V1_6_INVENTORY_ADJUDICATION_CARD_V4 (1) copy.md
§2.3 Group N (CSA absorption
source)
PROPOSAL SOURCE (per §11):
/Users/OpenClaw1/Documents/Elnor Docs Folder/Q and EC Build Working/
ECQ Development/CURRENT SPECS AND BUILD DOCS/Addenda Proposals & In Progress/
DOC73 Addenda and Proposals/
DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1.md
442 lines; 2026-04-29; origin
spec for §6.4 Mechanism 4
cited in V1.6 Artifact 1
§16.2A.1
```
---
---
## §11. Mechanism 4 V1 Proposal → V1.6 fidelity check
**Source proposal:** `/Users/OpenClaw1/Documents/Elnor Docs Folder/Q and EC Build Working/ECQ Development/CURRENT SPECS AND BUILD DOCS/Addenda Proposals & In Progress/DOC73 Addenda and Proposals/DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1.md`
**Date of proposal:** 2026-04-29
**Date of V1.6 absorption:** V4 inventory adjudication card 2026-05-01 → V1.6 release wave R0.1-R0.4 2026-05-02 to 2026-05-04
**Added to this trace:** 2026-05-04 (per architect request)
### §11.0 Why this section exists
Architect surfaced concern 2026-05-04: was the original Mechanism 4 V1 proposal actually folded into V1.6, and faithfully? This section captures the proposal-vs-V1.6 fidelity check so architect can review proposal absorption in the same pass as the broader CSA integration review (§9 above).
The Mechanism 4 V1 proposal was DOC73-authored (2026-04-29) and is the origin spec for §6.4 Mechanism 4. CSA R2 (DOC72-side, drafted same day) named this proposal as a CRITICAL cross-doc obligation. Together they define the Tier 2 fresh-surface injection model. This section maps the proposal feature-by-feature against V1.6 absorption.
### §11.1 Proposal explicitly cited as origin spec in V1.6
V1.6 Artifact 1 §16.2A.1 (RecentActivityRollup writer contract) cites this proposal verbatim as the origin spec:
> "Per V4 §2.3 Group N + V3.7 §10.2 row A-38 (`DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1` — origin spec for §6.4 Mechanism 4 + §6 design discipline)"
The fold-in was intentional and tracked. The cross-reference confirms architect's authority over Mechanism 4 was honored — the V4 inventory adjudication card consumed the proposal as input rather than re-inventing.
### §11.2 What landed faithfully (high fidelity)
```text
Proposal feature → V1.6 absorption Status
─────────────────────────────────────────────────────────────────────────────────────────────────────
RecentActivityRollup canonical schema → Artifact 1 §16.2 ✓ landed
(with V4 expansion: 6 entry-array kinds)
Per-work-context segmentation → work_phase_entries + ✓ landed
corpus_activity_entries +
case_activity_entries (legal-domain) +
artifact_entries +
unresolved_thread_entries +
orientation_entries
CSA R2 cross-doc alignment → csa_r2_continuity_log_ref field ✓ landed
DOC24 consumption at fresh-surface boot → Artifact 4 §18 CSAInjectionTierPolicy ✓ landed
(with R0.3 default = tier_3 per
architect triage 2026-05-03)
Writer agent contract → Artifact 1 §16.2A ✓ landed
(R0.2 NEW per audit CRIT-2;
architect chose option (a) MemoryAgent
reuse from proposal §2.5)
Single LLM call discipline per cadence → §16.2A.3 ✓ landed
(with chunking exception when input
exceeds context window)
<$0.01/day cost discipline → §16.2A.2 budget guidance ✓ landed
Off hot-path / nightly cadence → §16.2A.2 ✓ landed
(EC scheduler nightly job)
OpenClaw Dreaming explicitly disabled → preserved per proposal §3.5; ✓ landed
Mechanism 4 is ELNOR-native equivalent
of (narrative-summary part of) Dreaming
Three cross-doc obligations:
- DOC24 R3 new tag + card rendering → Artifact 4 §18 ✓ landed
- EC Core nightly job + storage → §16.2A.2 + §16.2A.5 + ✓ landed
OBL-EC-V16-K-ROUTING-OUTBOX-01
- DOC73 R-next promotion → V1.6 ships specification ✓ landed
INV-N-ORIENTATION-1 → §16.4 (canonical) ✓ landed +
SHARPENED in V4
INV-N-NO-CIRCULAR-EVIDENCE-1 → §16.4 (canonical) ✓ landed +
SHARPENED in V4
PBEOperationReceiptLite wrapping → §16.2A.4 INV-0B.1 enforcement ✓ landed
(V3-AT-12 acceptance test)
Storage path discipline (canonical artifact → §16.2A.5: jsonl_append_log canonical ✓ MODIFIED
+ rendered view) + rendered_view markdown (see §11.3)
```
### §11.3 What changed significantly (proposal → V1.6 deltas)
#### §11.3.1 Storage format — markdown vs JSONL (your proposal Q1)
**Proposal §2.2:** canonical artifact = markdown file at `ELNOR_MEMORY/rollup/recent_activity.md`.
**V1.6:** canonical artifact = `ELNOR_MEMORY/rollup/recent_activity_rollups.jsonl` (JSONL append log); markdown is rendered view at `ELNOR_MEMORY/rollup/recent_activity.md` (regenerated nightly from JSONL canonical).
**Decision basis:** V4 §5 V3-REJECT — "recent_activity.md as canonical store" rejected per V3-N-2 (canonical truth must be structured for downstream consumers; markdown is render-only).
**Architect surfaced this as Q1 in proposal §5.** V4 answered Q1 without surfacing back to architect. Reasonable answer (structured truth + render view is good engineering); but worth confirming this matches your intent.
**Q-MECH4-1:** Architect: do you accept JSONL canonical + markdown rendered view, or did you intend markdown as canonical?
#### §11.3.2 Cadence model — daily 14-day file vs hourly+weekly+monthly+session_summary (your proposal Q3) — **BIGGEST SEMANTIC SHIFT**
**Proposal §2.3:** three cadences:
- **Nightly daily file** with 14-day rolling window — the canonical Tier 2 source for fresh-surface injection
- **Weekly** with 30-day window
- **Monthly** with 90-day window
**V1.6 §16.2A.2 + §16.3:** four cadences:
- **Hourly orientation buffer** with 24h decay — ephemeral; serves as the always-fresh layer for Tier 2 injection
- **Weekly rollup** (Sunday → Saturday window) with 30-day retention
- **Monthly rollup** (first → last of month window) with 365-day retention
- **Session summary** with session-lifetime retention (ephemeral; expires at session_end + 7 days)
**Net effect:** the 14-day daily rollup file as a specific named artifact is gone in V1.6. V1.6 substitutes:
- (a) hourly buffer for freshness (24h auto-expiry)
- (b) weekly + monthly for depth and durable forensic record
- (c) session_summary for per-session context capture
**Why this matters:** the proposal's design was "a single file showing the user's last two weeks of work, refreshed nightly." V1.6's design is "an hourly orientation buffer for fresh-surface, plus weekly/monthly rollups for record." The user-visible artifact a litigator might pull up to ask "what have I been doing the last two weeks" is no longer canonically present.
**Q-MECH4-2:** Architect: was the 14-day daily rollup essential to your Mechanism 4 design intent? If yes, V1.6.1 candidate to add it back as a 4th durable cadence (`recent_activity_14day` rollup_kind). If no, V1.6's hourly+weekly+monthly+session_summary is acceptable.
#### §11.3.3 V4 ADDITIONS beyond proposal
V1.6 added features the proposal did not specify:
```text
V4 NEW Source V1.6 location
─────────────────────────────────────────────────────────────────────────────────────────
INV-N-ROLLUP-VIS-1 V4-N-1 §16.2A.4
(visibility ceiling enforcement at write)
— writer halts if rollup_visibility_class
exceeds ceiling per RollupGenerationRequest
ephemeral_hourly cadence V4 §2.3 Group N §16.2A.2 + §16.3
(proposal had only daily/weekly/monthly)
session_summary cadence V1.5.1 §6.3 alignment §16.2A.2 + §16.3
(proposal didn't include session-scoped
rollup; V1.6 adds it for §6.3 alignment)
Multi-model architecture for writer LLM ELNOR multi-model §16.2A.2
(Kimi 2.5 / DeepSeek for weekly bulk;
local Ollama for monthly + hourly)
Capacity/budget tracking via V4 §3.2 Group A §16.2A.3
RollupGenerationRequest schema KernelCostGovernance
Failure mode taxonomy V4 + R0.2 audit §16.2A.6
(budget exhausted / visibility breach /
LLM unavailable / policy mismatch)
```
**Q-MECH4-3:** Architect: are these V4 additions consistent with your Mechanism 4 design intent? Particularly INV-N-ROLLUP-VIS-1 (which adds a hard write-time check on visibility class ceilings) and the ephemeral_hourly cadence (which is a tighter loop than your proposal's nightly file).
### §11.4 What did NOT carry forward
#### §11.4.1 The 14-day daily rollup file (as named in proposal §2.3)
**Proposal:** primary canonical artifact for Tier 2 fresh-surface injection.
**V1.6:** absent. Replaced by hourly buffer (24h) + weekly (30-day retention).
**Mitigation if needed:** V1.6.1 add `recent_activity_14day` as a 4th durable cadence; tracking row would be `OBL-D73-V161-RECENT-ACTIVITY-14DAY-01`.
**Q-MECH4-4:** see Q-MECH4-2 above.
#### §11.4.2 PBE feedback loop (proposal §3.4)
**Proposal §3.4:** "monthly rollups can feed DOC73 PBE living memory consolidation as a 'stability signal' — work contexts and topics that appear in multiple consecutive monthly rollups are candidates for promotion to PBE living memory."
**Status in proposal:** marked OPTIONAL ("This is OPTIONAL. The basic mechanism works without this feedback loop. The loop is an enhancement.").
**V1.6:** not carried forward. No explicit feedback path from RecentActivityRollup to PBE consolidation.
**Q-MECH4-5:** Architect: still want this feedback loop? V1.6.1 candidate `OBL-D73-V161-MECH4-PBE-FEEDBACK-01` to track if yes.
#### §11.4.3 Worked markdown example (proposal §2.2)
**Proposal §2.2:** included a fully worked markdown example with Henderson Appeal / DOC73 V1.5 Red Team / Smith v. Acme / Modular Synth Exploration sections to illustrate per-work-context segmentation.
**V1.6:** no inline worked example (consistent with broader architect decision 2026-05-03 to defer cross-artifact worked examples to V1.6 implementation time).
**Mitigation:** the schema declarations in §16.2 + §A.4-§A.5 entry-kind types are sufficient for coding agents to infer the structure. A worked example can be added at V1.6 implementation time (writes against real session data).
**No question raised** — proposal §5 didn't ask for worked example confirmation; this falls under the broader worked-examples-deferred decision.
#### §11.4.4 Token budgets per cadence (proposal §2.5)
**Proposal §2.5:** explicit token caps:
- nightly (14-day window): 300-600 tokens output
- weekly (30-day window): 500-900 tokens output
- monthly (90-day window): 700-1200 tokens output
**V1.6:** budgets moved to consumer side. Artifact 4 §18 CSAInjectionTierPolicy enforces budget at fresh-surface render time (tier_3_minimal_orientation default — per architect triage 2026-05-03).
**Decision basis:** V4 design — writers produce structured records of arbitrary size; consumers truncate/select per their context budget. This is more flexible than fixed write-time budgets.
**Q-MECH4-6:** Architect: do you accept consumer-side budget enforcement (more flexible) over write-time budget caps (more predictable)?
#### §11.4.5 `rollup_synthesis_model` configuration knob (proposal §2.5)
**Proposal §2.5:** "Configurable via `dreaming.model` knob OR a new DOC73-specific knob `rollup_synthesis_model` (preferred — separates concerns from DOC73 §6.3 model choice)."
**V1.6:** does not declare a named configuration knob. §16.2A.3 has `llm_model_ref: ModelRef` field on RollupGenerationRequest (per-request model selection).
**Mitigation:** at V1.6 implementation time, expose a config knob (suggested name: `DOC73_MECH4_ROLLUP_SYNTHESIS_MODEL`) that defaults the `llm_model_ref` field. Hygiene only; no spec change needed.
#### §11.4.6 Open Questions Q1-Q6 from proposal §5 — disposition status
```text
Proposal Q What it asked V1.6 disposition
─────────────────────────────────────────────────────────────────────────────────────────
Q1 Markdown vs DOC73 manifest as canonical V4 chose JSONL canonical;
markdown rendered view (V3-N-2)
[see §11.3.1 Q-MECH4-1]
Q2 Storage paths for §6.3 manifests + Mechanism 4 §16.2A.5 declares
coordination ELNOR_MEMORY/rollup/* layout
Q3 Nightly cadence — right default? V4 chose hourly+weekly+monthly+
session_summary (4 cadences,
not 3)
[see §11.3.2 Q-MECH4-2]
Q4 Should Mechanism 4 inputs include PBE living V4 followed proposal — NOT
memory contents? included (avoid Tier 3
duplication); but PBE
feedback loop also dropped
[§11.4.2 Q-MECH4-5]
Q5 Unified-prompt extension — should §6.3 + V4 followed proposal — KEEP
Mechanism 4 merge into one LLM pass? SEPARATE (Mechanism 4 is
separate LLM pass over §6.3
outputs)
Q6 Post-absorption versioning rule N/A — V1.6 ships R0.4 of
(Architectural Invariant #24) Artifact 1 with normal R0.X
versioning discipline
```
### §11.5 Summary: open questions for architect (Q-MECH4-* series)
```text
Q-MECH4-1 Storage format: JSONL canonical + .md rendered view OK,
or did you intend markdown as canonical? (proposal Q1)
Q-MECH4-2 Cadence model: 14-day daily rollup essential, or is V1.6's
hourly+weekly+monthly+session_summary acceptable? (★ biggest
semantic shift; see §11.3.2)
Q-MECH4-3 V4 additions consistent with intent? (INV-N-ROLLUP-VIS-1
visibility ceiling + ephemeral_hourly cadence + V1.6
multi-model architecture)
Q-MECH4-4 (re: §11.4.1 — same as Q-MECH4-2)
Q-MECH4-5 Re-add PBE feedback loop as V1.6.1?
Q-MECH4-6 Consumer-side budget enforcement vs write-time budget caps?
```
**Q-MECH4-2 is the load-bearing one.** All other Q-MECH4-* items are calibration; Q-MECH4-2 is the architectural decision. The 14-day daily rollup was your proposal's primary Tier 2 source artifact. V1.6 substituted a different mix.
### §11.6 Recommended review process (paired with §9 CSA review)
When you do the CSA review per §9, do the proposal-vs-V1.6 review in the same pass:
```text
Step 1: Read DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1.md
(your original, 442 lines).
Step 2: Read Artifact 1 R0.4 §16 (the V1.6 absorption).
Walk §11.2 row by row to confirm faithful items.
Step 3: Walk §11.3 row by row to assess significant changes.
Decide each Q-MECH4-* per §11.5.
Step 4: Walk §11.4 row by row to assess what was dropped.
Decide each Q-MECH4-* per §11.5.
Step 5: Cross-reference your decisions against §9 CSA Q-CSA-* questions
(the CSA-level questions and Mechanism 4-level questions
should be coherent — e.g., if you decide Q-CSA-15 says CSA R2
specified a tier hierarchy, that may inform Q-MECH4-2 cadence
decision).
Step 6: Update DOC73_V1_6_DEFERRAL_INVENTORY_R1.md §1.2:
- DOC2_CSA_INTEGRATION_REVIEW row with disposition
- Add new row MECH4_PROPOSAL_FIDELITY_REVIEW with disposition
Step 7: V1.6.1 patch list (if any) per architect dispositions:
- 14-day daily rollup re-add (if Q-MECH4-2 = essential)
- PBE feedback loop (if Q-MECH4-5 = yes)
- Other adjustments per dispositions
```
**Estimated additional time:** 1-2 hours (on top of CSA review per §9).
---
— End of DOC73_V1_6_CSA_INTEGRATION_TRACE_R0.1.md —