DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1.md
Current Specs/DOC73/DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1.md
ELNOR REPO READER TEXT MIRROR
Original path: Current Specs/DOC73/DOC73_PROPOSAL_SECTION_6_4_MECHANISM_4_ROLLUP_V1.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z
---
# DOC73 Proposal — §6.4 Mechanism 4 Specification: Recent-Activity Rollup
**Date:** 2026-04-29
**Status:** Draft normative proposal for DOC73 R-next integration. Standalone handoff document.
**Target:** DOC73 V1.5.1 §6.4 Mechanism 4 (currently named but undefined).
**Origin:** Identified as a gap during CSA R2 (DOC72 Continuity Synthesis Architecture R2) drafting. The CSA R2 three-tier fresh-surface injection model has a Tier 2 ("recent activity narrative") that depends on DOC73 §6.4 Mechanism 4 producing a cross-context rollup file. Without Mechanism 4 specified, CSA Tier 2 cannot land.
**Authority:** DOC73 owns this mechanism. CSA R2 names the dependency and consumes the output. This proposal is for the DOC73-working session to evaluate, modify as needed, and integrate into DOC73 R-next.
---
## 0. What this proposal is, in one paragraph
DOC73 V1.5.1 §6.4 Mechanism 4 is currently a single sentence: "Weekly/monthly rollup summaries by background jobs anchor longer-term context." There is no schema, no file path, no trigger rules, no content definition. This proposal fills in those details so DOC73 R-next can specify the mechanism completely. The output is a single markdown file (`ELNOR_MEMORY/rollup/recent_activity.md`) that gets refreshed nightly, containing a cross-work-context narrative summary of "what the user has been doing lately" segmented per work context. The file is consumed by DOC24 R3's packet assembly as a `recent_activity` injection card at fresh-surface boot, alongside Tier 1 (CSA continuity card) and Tier 3 (DOC73 PBE living memory). The whole thing is a single LLM call per day on a configurable cheap model (e.g., Kimi or local Ollama), at <$0.01/day cost.
---
## 1. Context for the receiving session
If you are picking this up cold, here is the minimum context you need to evaluate this proposal:
### 1.1 The architecture gap
When a fresh agent surface opens (new chat window, model switch, fresh IDE session), the agent has zero context about what the user has been doing. The user typically pastes a preamble: "I'm working on Smith v. Acme, drafting opposition…" CSA R2 (DOC72 Continuity Synthesis Architecture R2, drafted 2026-04-29 by Will + Claude) specifies a three-tier injection that delivers this context automatically:
- **Tier 1 — Continuity card (`resume` tag).** Per-work-context work-state. "Where you are right now in this thread." 60-120 tokens. Source: CSA continuity log (per-work-context JSONL files). Generated event-triggered via OpenClaw `afterTurn` and `compact` hooks.
- **Tier 2 — Recent activity card (`recent_activity` tag).** Cross-context narrative summary. "What you've been doing lately across all your work." 100-200 tokens. **Source: this proposal.**
- **Tier 3 — Living memory card (`living_memory` tag).** Stable user facts and preferences. 50-100 tokens. Source: DOC73 V1.5.1 PBE living memory (existing infrastructure).
Tiers 1 and 3 have full specs. **Tier 2 has no spec — DOC73 V1.5.1 §6.4 Mechanism 4 is named but undefined.** This proposal fills that gap.
### 1.2 Why this matters
Without Tier 2, fresh-surface injection covers only "this thread's state" (Tier 1) and "stable user facts" (Tier 3). The user loses the middle ground — the rolling cross-context narrative that Claude.ai and ChatGPT memory systems provide, but with the cross-context structure ELNOR can do better.
Will explicitly identified this as a feature he wants: "A new session might get here's what Will was just working on, and also, here's generally what's been going on lately, similar to the Claude/OpenAI running memory."
### 1.3 What DOC73 V1.5.1 already specifies (don't reinvent)
DOC73 V1.5.1 §6.3 and §6.4 already specify three related mechanisms. Mechanism 4 should INTEGRATE with them, not duplicate them.
| DOC73 mechanism | Cadence | Output | Status |
|---|---|---|---|
| §6.3 — Session summarization at close | Per session, at session close | `session_summary` field in session manifest (200-500 tokens narrative) | Specified |
| §6.4 Mechanism 1 — Manifest consolidation | Per session-close cycle | Compact session manifest (500-1000 tokens) | Specified |
| §6.4 Mechanism 3 — Cross-session topic consolidation | On-demand, topic-scoped | Topic-scoped state-of-play summary (500 tokens) | Specified |
| §6.4 Mechanism 4 — Weekly/monthly rollup | Nightly + weekly + monthly | **UNDEFINED** | **This proposal** |
### 1.4 What CSA R2 adds (not part of DOC73's responsibility, but for context)
CSA R2 specifies:
- A continuity log (`ELNOR_MEMORY/continuity/{work_context_id}.jsonl`) capturing per-work-context structured entries (open_questions, key_decisions, work_phase_changes, cross_conversation_updates).
- A continuity agent that fires on OpenClaw `afterTurn` / `compact` hooks.
- Three-tier fresh-surface injection (§6 of CSA R2).
- A unified-prompt model where DOC73 §6.3's session-summarization LLM pass also extracts CSA's structured extras (open_questions, key_decisions, work_phase) — one pass, two outputs.
CSA R2 §A.4 declares this proposal's output as a CRITICAL cross-doc obligation:
> "Specify §6.4 Mechanism 4 weekly/monthly rollup. Currently named in V1.5.1 but undefined. Tier 2 (`recent_activity` card, §6.2) depends on this."
---
## 2. The proposed Mechanism 4 specification
### 2.1 Purpose
Produce a single cross-work-context narrative summary file that is refreshed nightly (with weekly and monthly variants), summarizing the user's recent activity across all work contexts. The file is consumed by DOC24 R3's packet assembly as the source for the `recent_activity` injection card at fresh-surface boot.
### 2.2 Output artifact
A single markdown file:
```
ELNOR_MEMORY/rollup/recent_activity.md
```
**Content structure (per-work-context segmented):**
```markdown
---
generated_at: 2026-04-29T03:00:00Z
window_days: 14
window_start: 2026-04-15T00:00:00Z
window_end: 2026-04-29T00:00:00Z
synthesis_model: ollama/llama3.1:8b
schema_version: 1
work_contexts_included:
- wc_smith_v_acme
- wc_doc73_v15_red_team
- wc_modular_synth_exploration
- wc_henderson_appeal
---
# Recent Activity (Past 14 Days)
## wc_henderson_appeal — Henderson Appeal
Active 2026-04-22 → 2026-04-28 (5 sessions).
Heavy on scienter argument formulation. Drafted three iterations of opposition §III. Cited Tellabs strong-inference standard. Decided to focus on price impact approach over corrective disclosure alone (4/24). Open: need to address Dura more directly in §I intro.
## wc_doc73_v15_red_team — DOC73 V1.5.1 Red Team
Active 2026-04-19 → 2026-04-27 (3 sessions).
Resolved authority salience boundary in PBE living memory section (4/26). Identified 12 cross-doc gaps with DOC24 / DOC72 R5.73. Decision: invariant carve-outs for sealed-signal partitioning per §23.8.
## wc_smith_v_acme — Smith v. Acme
Active 2026-04-18 → 2026-04-23 (2 sessions).
Motion practice — opposition to motion to compel. Briefer engagement than other matters this period.
## wc_modular_synth_exploration — Modular Synth Exploration
Active 2026-04-19 (weekend, 1 session).
Eurorack exploration — Mutable Marbles + Plaits combos. No durable artifacts produced.
```
**Why segmented per work-context:** CSA R2 §6.2 specifies that Tier 2 injection excludes the current Tier 1 work context. The renderer at injection time filters out the segment matching the active work_context_id. Per-context segmentation makes this filtering trivial (drop the matching `## wc_*` section).
### 2.3 Generation triggers
Three cadences, three rolling windows:
| Cadence | Window | Storage |
|---|---|---|
| Nightly | Last 14 days | `ELNOR_MEMORY/rollup/recent_activity.md` (overwritten nightly) |
| Weekly | Last 30 days | `ELNOR_MEMORY/rollup/weekly_recent_activity.md` (overwritten weekly, e.g., Sundays) |
| Monthly | Last 90 days | `ELNOR_MEMORY/rollup/monthly_recent_activity.md` (overwritten monthly, e.g., 1st of month) |
The DAILY rollup is the canonical Tier 2 source for fresh-surface injection. Weekly and monthly rollups are auxiliary — used for deeper "what have I been doing" queries (e.g., via CSA §7 cross-surface semantic query) and for DOC73 PBE consolidation feedback (see §3.4 below).
### 2.4 Inputs
The Mechanism 4 generation job consumes:
1. **DOC73 §6.3 session summaries** for sessions in the rolling window. Primary narrative input.
2. **CSA continuity log entries** (`ELNOR_MEMORY/continuity/{wc_id}.jsonl`) for sessions in the window. Source for open_questions, key_decisions, work_phase_changes — gives the narrative more substance than session summaries alone.
3. **DOC72 R5.73 weekly_digest** (graph-pattern summary, §42A absorbed-GIE NP22) — used as signal for "which work contexts were hot this period" but NOT as narrative content. Just helps prioritize which contexts get more text in the rollup.
4. **DOC73 §6.4 Mechanism 3 cross-session topic consolidations** if any were generated during the window — these are higher-quality narrative for specific topics and can be referenced rather than re-summarized.
The job does NOT consume raw session transcripts. That work was already done by §6.3 to produce the session summaries; Mechanism 4 reuses §6.3's output.
### 2.5 Generation logic
Single LLM pass per cadence:
```
You are reviewing the user's recent work activity to produce a brief narrative
rollup for cross-context awareness. Below are session summaries and continuity
log entries from the past {N} days, organized by work context.
Produce a markdown rollup with one section per work context that had activity
in this window. For each work context:
- 1-2 sentences capturing what the user has been doing in this context
- Mention key decisions (if any) with date
- Mention open questions (if any) but only ones that remain open at end of window
- Activity intensity signal (sessions count, days active)
Be concrete. Reference entities, decisions, and outcomes. Avoid generic
"the user worked on X" — instead say what was actually done.
Do NOT include the active session's content — fresh-surface injection
filters by current work context, so each rollup section must stand alone.
Format: per-work-context markdown sections under H2 headings. Front matter
header with metadata. Total length: 300-600 tokens for nightly (14-day
window), 500-900 for weekly, 700-1200 for monthly.
Inputs:
[Session summaries by work context]
{enumerate session summaries grouped by wc_id}
[Continuity log highlights by work context]
{enumerate non-resolved open_questions, latest work_phase, key_decisions}
[Graph activity signal by work context]
{wc_id, session_count, days_active, top_entities}
```
**Model:** Configurable via `dreaming.model` knob OR a new DOC73-specific knob `rollup_synthesis_model` (preferred — separates concerns from DOC73 §6.3 model choice). Recommended default: same cheap model used for §6.3 session summarization (Kimi or local Ollama).
**Cost:** Single LLM pass per cadence. Inputs ~3,000-5,000 tokens (session summaries from a 14-30 day window). Outputs ~600-1200 tokens. At Kimi pricing (~$0.50/M input), nightly cost ~$0.002. Weekly + monthly together ~$0.005. Total: <$0.01/day. Local Ollama: $0.
**Hot path:** Off. Runs as a nightly background job (or weekly/monthly per cadence). Does not block any user-facing operation.
### 2.6 Schema (Zod TypeScript)
```ts
export const RecentActivityRollupSchema = z.object({
generated_at: z.string().datetime(),
window_days: z.number().int().positive(),
window_start: z.string().datetime(),
window_end: z.string().datetime(),
synthesis_model: z.string().max(120),
schema_version: z.literal(1),
work_contexts_included: z.array(z.string().max(120)),
segments: z.array(z.object({
work_context_id: z.string().max(120),
work_context_display_name: z.string().max(200),
active_period_start: z.string().datetime(),
active_period_end: z.string().datetime(),
session_count: z.number().int().nonnegative(),
days_active: z.number().int().nonnegative(),
narrative: z.string().max(600), // The actual rendered text
primary_entity_ids: z.array(z.string().max(120)).max(5),
})),
});
```
The **markdown file is the canonical artifact** (consumed directly by DOC24 packet assembly). The Zod schema represents an in-memory parsed view used by the generator and any downstream tools.
The markdown front matter encodes the metadata; the body sections are the narrative segments. Generators MUST produce both views consistently — the parsed structure must round-trip with the markdown text.
### 2.7 DOC24 R3 consumption (cross-doc obligation)
CSA R2 §6.2 specifies how DOC24 consumes this file:
```ts
// In DOC24 R3 packet assembly, when assembling the `recent_activity` card:
function renderRecentActivityCard(
rollupFile: string, // Path to recent_activity.md
currentWorkContextId: string | null, // Tier 1's work_context_id, if Tier 1 fires
budget: number, // Default 200 tokens
): CompactEntityCard {
const parsed = parseRollupMarkdown(rollupFile);
const filteredSegments = parsed.segments.filter(
s => s.work_context_id !== currentWorkContextId
);
const text = filteredSegments
.map(s => `## ${s.work_context_display_name}\n${s.narrative}`)
.join("\n\n");
return {
node_kind: "rollup_recent_activity",
tag: "recent_activity",
content: truncateToTokens(text, budget),
droppable: true,
droppable_priority: "high", // Drop first under budget pressure
};
}
```
Mechanism 4's responsibility ends at writing the markdown file. DOC24 owns the rendering and budget enforcement.
---
## 3. Considerations and design rationale
### 3.1 Why a single nightly file, not on-demand?
Two alternatives were considered:
- **On-demand generation per fresh-surface boot.** Pro: always fresh. Con: adds LLM call to every fresh-surface boot, which adds latency to the moment that matters most (user starting a new chat). Hot-path LLM call.
- **Pre-generated nightly file.** Pro: zero hot-path latency, single LLM call/day, file just gets read and rendered. Con: stale up to 24 hours.
Chose pre-generated. The 24-hour staleness is acceptable for "what's been going on lately" — the rollup intentionally does not include "what just happened" (that's Tier 1's job). Hot-path zero-cost is more important than recency.
### 3.2 Why per-work-context segmented rather than one flowing narrative?
Tier 2's anti-duplication rule (CSA R2 §6.2) requires excluding the current Tier 1 work context. Excluding from a single flowing narrative is brittle (which sentence references which context?). Excluding a labeled segment is trivial.
Also: per-segment rendering means the consumer can choose how to display (e.g., show all segments in Q's status panel, or only the non-current ones in fresh-surface injection). Optionality without re-generation.
### 3.3 Why three cadences (daily / weekly / monthly)?
The daily rollup is the Tier 2 source. The weekly and monthly rollups serve different purposes:
- **Weekly rollup:** Used by §7 cross-surface semantic query for queries with longer time windows ("what have I been doing this month?"). Refreshed less often, so consistent for repeat queries. Also useful for human review (a Q UI panel showing "your week").
- **Monthly rollup:** Feedback signal to DOC73 PBE consolidation (§3.4 below).
Building all three is cheap (~$0.005/day total). Skipping them and re-generating from sources on demand would be more expensive over time.
### 3.4 Feedback loop to DOC73 PBE living memory
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 (Tier 3 stable facts).
Example: if "Will is heavily focused on ELNOR architecture" appears in 3 consecutive monthly rollups, that becomes a stable fact in PBE rather than a "recent activity" entry. The rollup mechanism degrades naturally — once the fact stabilizes, it leaves the rollup and lives in PBE.
This is OPTIONAL. The basic mechanism works without this feedback loop. The loop is an enhancement.
### 3.5 Why not OpenClaw Dreaming?
CSA R2 §10 explicitly disables OpenClaw Dreaming in ELNOR deployments. Reasoning:
- Dreaming runs on raw session transcripts (its native input). DOC73 §6.3 also runs on transcripts. Both consuming the same input is duplicate work.
- Dreaming produces flat-text MEMORY.md / DREAMS.md. ELNOR produces structured DOC72 entity nodes with provenance, significance gating, sealed-signal partitioning. Re-extracting Dreaming's output into ELNOR's pipeline LOSES the structure ELNOR's pipeline produces directly.
- Configuration overhead, conflicting state risk, unclear canonical truth.
Mechanism 4 is the ELNOR-native equivalent of (the narrative-summary part of) Dreaming. It runs entirely within DOC73's governed consolidation pipeline.
### 3.6 Token efficiency analysis
Per fresh-surface boot, the three-tier injection delivers:
- Tier 1 (`resume`): up to 120 tokens
- Tier 2 (`recent_activity`): up to 200 tokens
- Tier 3 (`living_memory`): up to 100 tokens
- **Total: up to 420 tokens**
DOC24 R3 chat surface profile budget for context layers is 250-350 tokens. With Lane 1 borrowing, ~400 tokens. The three-tier model fits within budget when at least one of Tier 1 or Tier 2 takes a partial allocation.
In practice:
- Most fresh-surface boots have Tier 1 firing at modest size (60-100 tokens), leaving room for Tier 2 (150-200 tokens) and Tier 3 (50-100 tokens). Total 260-400.
- When Tier 1 doesn't fire (no active work-context match), Tier 2 can use full 200 tokens. Total 250-300.
- Tier 3 is non-droppable; under extreme budget pressure, Tier 2 drops first, then Tier 1 trims.
Mechanism 4's nightly cost (<$0.01/day) is well below the cost of the alternative (running on-demand LLM calls per fresh-surface boot, which would cost significantly more on every chat start).
### 3.7 Anti-duplication with §6.4 Mechanism 3
§6.4 Mechanism 3 already produces topic-scoped state-of-play summaries on-demand ("Across your 7 most relevant recent sessions on scienter, you've focused on…"). Mechanism 4 is cross-context and cadence-driven. They serve different consumers:
- Mechanism 3: triggered by topic-scoped query (e.g., agent asks "summarize what I've done on scienter"). On-demand. Topic-scoped.
- Mechanism 4: pre-generated. Cross-context. Time-window-scoped.
They can share the underlying §6.3 session summaries as input. They produce different output artifacts for different consumers.
If Mechanism 3 has produced a recent topic consolidation, Mechanism 4's narrative for that work context can REFERENCE the Mechanism 3 output rather than re-summarize:
```markdown
## wc_henderson_appeal — Henderson Appeal
Active 2026-04-22 → 2026-04-28 (5 sessions). See topic consolidation
"scienter formulation" (2026-04-26) for details.
```
This saves tokens in both inputs and outputs and keeps the two mechanisms' outputs coherent.
---
## 4. Cross-doc obligations introduced by this proposal
### 4.1 DOC24 R3
Already covered in CSA R2 §A.1. New tag `recent_activity` and corresponding card rendering template + budget allocation in the waterfall (§19.1A).
### 4.2 EC Core (Addendum A V3.3+)
Already covered in CSA R2 §A.6:
- Provision `ELNOR_MEMORY/rollup/recent_activity.md` infrastructure (and weekly + monthly variants).
- Register the nightly + weekly + monthly background jobs that invoke Mechanism 4.
### 4.3 DOC73 R-next (this proposal's home)
- Add §6.4 Mechanism 4 specification per §2 above.
- Specify the schema (§2.6).
- Specify the inputs (§2.4) including dependency on DOC73 §6.3 session summaries.
- Specify generation logic and prompt (§2.5).
- Specify the relationship to Mechanism 3 (§3.7).
- Define the `rollup_synthesis_model` configuration knob (or alias to `dreaming.model` if DOC73 prefers a unified model knob).
### 4.4 DOC8
Optional: track Mechanism 4 utility (rollup card injection counts, agent reference rate to rollup content) as a feedback signal. Default off; can be enabled if the team wants empirical tuning of rollup quality vs. cost.
---
## 5. Open questions for the receiving session
These are points where DOC73's authority should make the final call. CSA R2 has assumptions that DOC73 R-next can override:
### Q1. Is the canonical artifact a markdown file or a DOC73 manifest entry?
CSA R2 assumes a markdown file at `ELNOR_MEMORY/rollup/recent_activity.md` (CSA R2 Appendix B). If DOC73 R-next prefers to store this in a different format (e.g., as a session-manifest-adjacent JSON), DOC24 R3's renderer would need to adapt. Markdown was chosen because:
- DOC24 R3's existing card rendering can pass markdown through with minimal transformation.
- Human-inspectable.
- Can be opened in Q UI as a recent-activity panel.
DOC73 R-next can override.
### Q2. What's the relationship to DOC73 §6.3 session manifest storage paths?
DOC73 V1.5.1 §6.4 has a cross-doc obligation to DOC24 for manifest persistence ("DOC24 must persist these manifests"), but the actual file paths are unspecified. CSA R2 references `linked_doc73_session_summary_id` in continuity log entries. DOC73 R-next should resolve the storage paths for both session manifests AND the rollup artifacts in a coordinated way.
### Q3. Is the nightly cadence the right default?
CSA R2 assumes nightly. Alternatives:
- Twice-daily (e.g., 6am + 6pm) for users with heavy weekend activity.
- Per-session-close (rebuild the rollup whenever §6.3 produces a new session summary). More expensive, fresher.
Nightly was chosen as a baseline. DOC73 R-next can override or make it Category C user-configurable.
### Q4. Should Mechanism 4 inputs include DOC73 PBE living memory contents?
Currently §2.4 lists session summaries, continuity log, weekly_digest, and Mechanism 3 outputs. NOT listed: PBE living memory contents.
Argument for including: PBE has high-confidence stable facts; including them grounds the narrative.
Argument against: Tier 3 already injects PBE; including PBE in Tier 2 risks duplication.
CSA R2 chose against. DOC73 R-next can override. If included, the unified-prompt should explicitly de-duplicate against Tier 3 content.
### Q5. Should the unified-prompt model from CSA R2 §5.4 (DOC73 §6.3 + CSA structured extras in one pass) extend to Mechanism 4?
Currently §6.3 handles per-session synthesis with CSA-extracted structured extras. Mechanism 4 is a SEPARATE LLM pass that consumes §6.3's outputs. They could be merged (one massive call that produces both per-session and rollup), but that complicates retry / partial-failure logic.
CSA R2 chose to keep them separate. DOC73 R-next can override if it sees a benefit.
### Q6. How does Mechanism 4 interact with the post-absorption versioning rule (Architectural Invariant #24)?
If Mechanism 4 evolves significantly post-promotion to operative, version it as DOC73 R-next-2 / R-next-3 (per the rule). This proposal is V1; future improvements (e.g., better feedback loops, smarter input weighting) would require new minor revisions.
---
## 6. Suggested next steps for the receiving session
1. **Review §2** (the actual specification) and adjust schemas, file paths, and triggers as DOC73 R-next sees fit.
2. **Resolve open questions in §5.** Some of these might already be answered by other DOC73 work the receiving session is doing.
3. **Coordinate with the CSA R2 author** (Will, in this same workspace) to align on:
- The markdown file format and front matter content (§2.2).
- The DOC24 cross-doc obligation language (CSA R2 §A.1).
- The DOC73 → CSA `linked_doc73_session_summary_id` field naming.
4. **Promote Mechanism 4 with the next DOC73 revision** (R-next, version TBD). Once promoted, CSA R2 §A.4's CRITICAL obligation downgrades to MET.
If significant changes to this proposal are needed (e.g., different output format, different cadence model), the CSA R2 author should be looped in so CSA R2 §6.2 can be patched in step.
---
## 7. Cross-references to CSA R2
For the receiving session, these CSA R2 sections are most relevant for understanding how Mechanism 4 plugs in:
- **CSA R2 §6.2** — Tier 2 recent_activity card. Specifies how DOC24 consumes the rollup file.
- **CSA R2 §A.4** — DOC73 R-next CRITICAL obligation (which this proposal addresses).
- **CSA R2 §10** — OpenClaw Dreaming disabled. Explains why Mechanism 4 is the ELNOR-native answer.
- **CSA R2 §5.4** — DOC73 §6.3 unified-prompt model. Explains how CSA depends on §6.3.
- **CSA R2 Appendix B** — Storage paths.
CSA R2 file: `/Users/OpenClaw1/Documents/Elnor Docs Folder/Q and EC Build Working/ECQ Development/CURRENT SPECS AND BUILD DOCS/Addenda Proposals & In Progress/DOC72 Addenda and Proposals/DOC72_PROPOSAL_CONTINUITY_SYNTHESIS_ARCHITECTURE_R2.md`
---
## 8. Summary
**The gap:** DOC73 V1.5.1 §6.4 Mechanism 4 ("weekly/monthly rollup summaries") is named but undefined. CSA R2's three-tier fresh-surface injection has Tier 2 (cross-context recent-activity narrative) that depends on this mechanism producing a usable artifact.
**The fix:** Specify Mechanism 4 as a nightly (+ weekly + monthly) LLM-driven synthesis job that produces a per-work-context segmented markdown rollup at `ELNOR_MEMORY/rollup/recent_activity.md`. Single LLM pass per cadence on a configurable cheap model. <$0.01/day cost. Off the hot path. Consumed by DOC24 R3's `recent_activity` card at fresh-surface boot.
**The dependencies:** None blocking. Inputs (DOC73 §6.3 session summaries, CSA continuity log entries, DOC72 weekly_digest) all exist or are coming online with CSA R2.
**The cross-doc obligations:** DOC24 R3 (new tag + card rendering), EC Core (provision infrastructure + register nightly job), DOC73 R-next (this proposal's home — promote Mechanism 4 to specified status).
**The decision needed:** Does DOC73 R-next adopt this specification (with whatever modifications the receiving session prefers per §5 open questions)?
If yes: CSA R2 §A.4 CRITICAL obligation downgrades to MET. Tier 2 fresh-surface injection becomes implementable. The full three-tier model lands.
If no, or if the receiving session has a different vision: please coordinate with the CSA R2 author so CSA R2 §6.2 can be patched accordingly. Tier 2 can be redesigned around a different DOC73 mechanism, or deferred — but the gap should not be left open in DOC73 R-next.
---
*End of DOC73 Proposal — §6.4 Mechanism 4 Specification: Recent-Activity Rollup V1*