Elnor Repo Reader

# DOC23 Addenda B Sub-addendum — Source Workspace V1.0.1

**Document type:** Topical sub-addendum to DOC23 Addenda B Core R0.7.

**Subject:** Specification for the Task Source Workspace, the Source Research / Source Gathering module, and the user-facing Source Workspace UI. Defines the shared source/reference/research substrate that task runs use when modules need to find, verify, retrieve, or update sources.

**Status:** V1.0.1 — clean replacement for V1.0; reference/topology cleanup only; initial draft incorporating R0.6.5 proposal §§16-18 + §28, integrated with V3.3 §12 narrow workspace coverage and Addenda A ↔ Addenda B coordination V3 FINAL outputs.

**Version:** 1.0.1

**Prepared:** 2026-05-17; revised 2026-05-24 (V1.0.1 reference/topology cleanup)

**Family position:** Sub-addendum to Addenda B Core R0.7.1; sibling to V3.3.1 Outcome Evaluator+Revisor, Task Forum + Run Board V1.0.1, and Feedback Delivery V1.0.1.

**V1.0.1 changes from V1.0:** No schema, route, or behavioral changes. This full replacement copy updates stale family references to the current clean operative set.

**Companion docs:** DOC23 Addenda B Core R0.7.1; DOC23 Addenda B / Outcome Evaluator+Revisor V3.3.1; DOC23 Evaluation Common Contracts V1.1.1; DOC23 Addenda A R4.1 V3 (V4.1 Coordination Patch / V5 Mini-Card); DOC23 R3.1; DOC24 R3; DOC72 R5.73; DOC25 V2.0 (universal document ingestion — distinct from this sub-addendum); DOC73 V1.5.1 (libraries — distinct); EC Core Addendum A V3.3; OP-A V3.7+.

---

## §0 How to read this sub-addendum

### §0.1 Scope

This sub-addendum specifies the **Source Workspace** — a task/run-scoped shared substrate for sources, references, and research work product. It addresses the problem that one module finds or verifies sources but later modules cannot see the work and re-do, contradict, or ignore it. The Source Workspace is the shared memory of source work within a task.

It also specifies the **Source Research / Source Gathering module** (`step.source_research`) — a generic module type for finding, retrieving, verifying, updating, and adding sources to the workspace. Not legal-only; generic across domains.

And it specifies the **user-facing Source Workspace UI** surfaces that render the workspace to the user, expose context menus, and integrate with the Task Agent panel.

### §0.2 What this sub-addendum does NOT cover

- **Outcome evaluation against source criteria** — that lives in V3.3 (Outcome Evaluator/Revisor). The Source Workspace provides the substrate; the Evaluator scores against it.
- **In-run feedback delivery from Evaluator to Source Research module** — that lives in Feedback Delivery V1.0.1. The workspace surfaces unresolved needs; the feedback pipeline routes them to the right consumer.
- **Universal document ingestion** — DOC25 owns that. Source Workspace consumes DOC25 ingestion results as one of many source kinds.
- **Library / corpus storage** — DOC73 owns that. Source Workspace may promote workspace entries to DOC73 library candidates per persistence policy.
- **Forum and Run Board** — Task Forum + Run Board V1.0.1. Source workspace can publish to forum and read from it, but the forum mechanics live separately.

### §0.3 V3.3 §12 coordination

V3.3.1 Outcome Evaluator+Revisor §12 has a narrow Workspace section covering three-way ownership (RunWorkspace + SourceWorkspace + ArtifactStore), ownership boundaries, basic Source Workspace API operations, semantic paging, and cost attribution. This sub-addendum extends V3.3 §12 with the user-facing surface, tier-based documentation modes, the Source Research module type, and the rich SourceRecord/SourceCard schemas.

The boundary:
- V3.3 §12 owns the workspace primitive's interaction with the evaluation/revision pipeline
- This sub-addendum owns the workspace primitive's interaction with the rest of the task system (the Task Agent, the user, the Source Research module, other task modules)

The two views consume the same underlying `TaskSourceWorkspace` object (schema in §2 below). When V3.3 §12 and this document overlap on a field, V3.3's specification governs the field's semantics; this document specifies broader workspace behavior.

### §0.4 Reading order

- §1 — Purpose and substrate role
- §2 — TaskSourceWorkspace schema
- §3 — Source documentation tiers
- §4 — SourceRecord, SourceCard, and ApplicabilityScope
- §5 — Domain specialization examples
- §6 — Research / Source Needs
- §7 — Source Research / Source Gathering module (`step.source_research`)
- §8 — Source Workspace UI
- §9 — Persistence and promotion policies
- §10 — Cross-doc obligations

---

## §1 Purpose and substrate role

### §1.1 The problem

In multi-module tasks, source work is often done by an upstream module (research, citation lookup, source verification) and then needed by downstream modules (drafting, evaluator, revisor). Without a shared substrate, the downstream modules either:

- Re-do the source work (wasted cost; risk of divergent results)
- Skip the source work and produce unverified output
- Hallucinate source support
- Pass source state through ad-hoc port wiring that breaks when graph topology changes

The Source Workspace solves this by being a shared, persistent, queryable substrate accessible to all modules in a task run.

### §1.2 Not just DOC25

DOC25 V2.0 owns universal document ingestion and document intelligence. It does NOT own "doing research." Research/source work may use DOC25 ingestion, but it may also use DOC73 libraries, DOC24 capabilities, APIs, connectors, MCP tools, web search, PACER/CourtListener/SEC/financial databases, browser skills, prior task outputs, user uploads, or firm/internal sources.

The Source Workspace records material results from any of those sources. It is a layer above the retrieval mechanisms.

### §1.3 Optional for simple tasks

The Source Workspace is optional. Simple tasks (single-module, self-contained, no external sources) do not need a workspace; configuring one would be overhead. The Task Agent surfaces the workspace concept only when task complexity (per Core R0.7.1 §2.13 Complexity Profiles) suggests it's beneficial.

### §1.4 Scope and lifecycle

A workspace is task-scoped or run-scoped:

- **Task-scoped:** the workspace persists across runs of the same task. Useful for ongoing matters where source work compounds across runs (a long-running litigation; an ongoing M&A diligence).
- **Run-scoped:** the workspace exists only for one run. Useful for one-off research tasks.

The `TaskSourceWorkspace.persistence_policy.run_scoped` boolean (§2) declares which lifecycle applies. Task-scoped workspaces may also save summaries to DOC72 task memory and promote entries to DOC73 libraries per policy.

---

## §2 TaskSourceWorkspace schema

```ts
type SourceDocumentationMode =
  | "none"                                     // no workspace; ephemeral lookups only
  | "lookup_receipt"                           // tier 0 — receipt records only
  | "source_reference"                         // tier 1 — preserve that source was used
  | "source_note"                              // tier 2 — short relevant takeaway
  | "source_cards_for_high_value_sources"      // tier 3 — rich cards for key sources only
  | "full_source_workspace"                    // tier 4 — major source/research task

TaskSourceWorkspace {
  workspace_id: string
  task_id: string
  run_id?: string                              // null when task-scoped
  label: string                                // user-facing name
  
  documentation_mode: SourceDocumentationMode  // governs tier expected of new sources
  
  source_records: SourceRecord[]               // §4
  source_sets: SourceSet[]                     // logical grouping of related sources
  source_query_records: SourceQueryRecord[]    // queries run, results, lineage
  research_need_queue: ResearchNeed[]          // §6
  verification_records: SourceVerificationResult[]
  freshness_records: SourceFreshnessRecord[]
  run_guidance_ids: string[]                   // refs to Run Guidance from
                                               // Feedback Delivery V1.0.1
  
  // Availability policy
  global_availability_policy: {
    available_to_all_future_modules: boolean
    available_to_selected_module_ids: string[]
    default_prompt_mode:
      | "available_listing"                    // list available sources without inlining
      | "compact_summary"                      // inline compact summary of sources
      | "full_context_when_needed"             // inline full source content when relevant
  }
  
  // Persistence
  persistence_policy: {
    run_scoped: boolean
    save_to_doc72_summary: boolean             // task memory summary
    promote_to_doc73_library_candidate: boolean // library promotion candidate
    user_visible: boolean
  }
  
  // V3.3 coordination — taint state for workspace as a whole
  current_taint_class: TaintClass              // V3.3 §0.4
  privileged: boolean                          // matter-scoped privilege flag
  matter_id?: string
  
  created_at: ISO8601
  updated_at: ISO8601
  schema_version: "1.0"
}
```

### §2.1 SourceSet

```ts
SourceSet {
  set_id: string
  label: string
  source_ids: string[]                         // references to SourceRecord.source_id
  purpose: string                              // e.g., "Authority for standing argument"
  schema_version: "1.0"
}
```

A logical grouping of related sources. Used by Source Research module output, by Task Agent suggestions, and by UI rendering.

### §2.2 SourceQueryRecord

```ts
SourceQueryRecord {
  query_id: string
  query_text: string
  query_kind: "freeform" | "structured" | "database_query" | "api_call"
  
  executed_by_module_id: string
  executed_by_activation_seq: number
  executed_at: ISO8601
  
  result_source_ids: string[]                  // SourceRecords produced from query
  result_status: "success" | "empty" | "partial" | "error"
  result_cost: CostEstimate
  
  schema_version: "1.0"
}
```

Records every source query the system runs. Enables audit ("how did we find this source?") and learning ("what queries work?").

### §2.3 SourceFreshnessRecord and SourceVerificationResult

```ts
SourceFreshnessRecord {
  source_id: string
  checked_at: ISO8601
  freshness_state: "fresh" | "stale" | "needs_update" | "unknown"
  next_check_due?: ISO8601
  staleness_reason?: string
  schema_version: "1.0"
}

SourceVerificationResult {
  verification_id: string
  source_id: string
  verification_kind:
    | "source_exists"
    | "quote_supports_proposition"
    | "applicability_to_context"
    | "currentness"
    | "no_overruling_authority"                // legal-specific
    | "regulatory_in_force"                    // regulatory-specific
  verification_state: "verified" | "failed" | "partial"
  evidence_refs: StorageRef[]
  verifier_module_id?: string
  verified_at: ISO8601
  schema_version: "1.0"
}
```

---

## §3 Source documentation tiers

| Tier | Name | Use cases | Storage |
|---|---|---|---|
| 0 | Ephemeral lookup | Low-stakes simple lookup ("check sports score") | Tool receipt only |
| 1 | Source reference | Preserve that a source was found/used ("check pincite") | SourceRecord with tier=1, minimal fields |
| 2 | Source note | Preserve short relevant takeaway | SourceRecord with tier=2 + summary |
| 3 | Source card | Rich structured reusable source record | SourceRecord with tier=3, full fields |
| 4 | Source workspace / research bundle | Major source/research task | Full TaskSourceWorkspace |

### §3.1 Tier selection

The `documentation_mode` field on `TaskSourceWorkspace` governs the default tier for new sources added to that workspace. Module configs may override per source. The Task Agent suggests an initial tier based on task complexity (Core R0.7.1 §2.13) and typical tier-for-task-kind patterns learned over time.

### §3.2 Tier examples

- "Check today's stock price" → tier 0
- "Check that this case citation is accurate" → tier 1 or verification receipt
- "Find restaurants in Philadelphia for client dinner" → tier 1 or 2
- "Research 100 cases on a doctrine for an opening brief" → tier 4 workspace with source index for all + full cards for key sources only
- "Verify factual claims in a complex memo" → tier 3 cards for cited sources + tier 1 references for incidentally mentioned sources

### §3.3 Tier transitions

A source can be promoted in tier (tier 1 reference becomes a tier 3 card when later modules need rich details). Tier transitions are recorded:

```ts
SourceTierTransition {
  source_id: string
  from_tier: number
  to_tier: number
  reason: string
  promoted_by_module_id?: string
  promoted_at: ISO8601
  schema_version: "1.0"
}
```

Tier transitions enable the Task Agent to learn which sources matter enough to promote and to suggest tier policies for future similar tasks.

---

## §4 SourceRecord, SourceCard, and ApplicabilityScope

### §4.1 SourceRecord

```ts
SourceRecord {
  source_id: string
  tier: 0 | 1 | 2 | 3                          // tier 4 = full workspace (not a single record)
  
  source_kind:
    | "document"
    | "web_source"
    | "api_result"
    | "database_record"
    | "email"
    | "file"
    | "prior_task_output"
    | "library_entry"
    | "case_law"
    | "statute"
    | "regulation"
    | "financial_filing"
    | "expert_report"
    | "technical_doc"
    | "custom"
  
  title: string
  source_ref: StorageRef
  citation_or_reference?: string               // canonical citation format
                                               // (legal cite, DOI, URL, etc.)
  
  // Retrieval lineage
  retrieved_at?: ISO8601
  retrieved_by_module_id?: string
  retrieved_by_activation_seq?: number
  
  // Content summary (tier 2+ only)
  summary?: string
  key_points?: string[]
  applicability_scopes?: ApplicabilityScope[]
  
  // State
  freshness_state: "fresh" | "stale" | "needs_update" | "unknown"
  verification_state: "unverified" | "partially_verified" | "verified" | "failed"
  
  // Domain-specific extension (see §5)
  domain_payload?: Record<string, unknown>
  
  // V3.3 coordination — taint inheritance from source
  taint_class: TaintClass                      // inherited from source kind / retrieval method
  privileged: boolean
  matter_id?: string
  
  schema_version: "1.0"
}
```

### §4.2 ApplicabilityScope

```ts
ApplicabilityScope {
  scope_kind:
    | "legal_jurisdiction"
    | "regulatory_domain"
    | "business_unit"
    | "technical_platform"
    | "time_period"
    | "geography"
    | "audience"
    | "matter"
    | "custom"
  scope_value: string                          // e.g., "Ninth Circuit", "SEC Rule 10b-5",
                                               // "California 2020-2024", "internal use only"
  authority_level?: "binding" | "persuasive" | "advisory" | "unknown"
  domain_specific_payload?: Record<string, unknown>
  schema_version: "1.0"
}
```

ApplicabilityScope tells consumers when a source applies. A Ninth Circuit case binding in the Ninth Circuit is persuasive only in the Second; a CFR provision in force from 2020-2024 doesn't apply to 2026 conduct. The Outcome Evaluator (V3.3) and Revisor consume `applicability_scopes` when assessing whether the cited source supports the proposition in the current context.

---

## §5 Domain specialization examples

The `domain_payload` field on SourceRecord allows domain-specific metadata without polluting the core schema. Examples:

### §5.1 Legal

```ts
LegalSourcePayload {
  court?: string                               // e.g., "9th Cir.", "S.D.N.Y."
  jurisdiction?: string                        // e.g., "federal", "California"
  date?: string                                // decision date
  authority_level?:
    | "binding"
    | "persuasive"
    | "distinguishable"
    | "adverse"
  treatment_status?:
    | "current"
    | "negative_treatment"
    | "overruled"
    | "limited"
    | "unknown"
  holdings?: string[]
  useful_propositions?: string[]
  pincite_refs?: StorageRef[]
}
```

### §5.2 Securities / financial filings

```ts
SecuritiesSourcePayload {
  filer_cik?: string
  filing_type?: "10-K" | "10-Q" | "8-K" | "S-1" | "DEF14A" | "other"
  filing_date?: string
  period_covered?: string
  cik_filings_ref?: StorageRef
}
```

### §5.3 Regulatory

```ts
RegulatorySourcePayload {
  agency?: string                              // e.g., "SEC", "FCC", "EPA"
  cfr_title?: string
  cfr_part?: string
  effective_date?: string
  superseded_by?: StorageRef
  preamble_ref?: StorageRef
}
```

Implementations register new `domain_payload` shapes as needed; the workspace schema does not constrain them. The Task Agent may surface domain-aware actions when domain payload is populated.

---

## §6 Research / Source Needs

### §6.1 Purpose

Later modules may discover that they need more sources, updated information, source verification, format rules, or user input. They MUST NOT hallucinate or perform hidden unshared research. Instead, they emit a `ResearchNeed` record into the workspace's research_need_queue. The need is then routed to either a Source Research module activation, a user prompt, or a forum post.

### §6.2 Schema

```ts
ResearchNeed {
  need_id: string
  task_id: string
  run_id: string
  
  created_by_module_id: string
  created_by_activation_seq: number
  
  need_kind:
    | "new_source_needed"
    | "source_currentness_check"
    | "citation_support_needed"
    | "contrary_source_check"
    | "background_document_missing"
    | "format_rule_needed"
    | "domain_rule_needed"
    | "source_gap_from_evaluator"              // emitted by V3.3 Evaluator
    | "clarification_needed"
    | "custom"
  
  question: string
  target_claim_or_section_ref?: StorageRef     // typically ArtifactScopeRef
                                               // (Common Contracts §7)
  priority: "low" | "medium" | "high" | "blocking"
  
  routed_to_module_id?: string                 // populated when routed
  status: "open" | "in_progress" | "answered" | "unresolved" | "human_needed"
  
  answer_ref?: StorageRef                      // ResearchAnswer record
  source_refs: StorageRef[]                    // SourceRecords produced
  created_at: ISO8601
  updated_at: ISO8601
  schema_version: "1.0"
}

ResearchAnswer {
  answer_id: string
  need_id: string
  answer_text: string
  supporting_source_refs: StorageRef[]
  answered_by_module_id: string
  answered_at: ISO8601
  confidence: number                           // 0-1
  schema_version: "1.0"
}
```

### §6.3 Rule for hidden research

If any module performs material research or obtains material source information, it MUST emit one of:

- SourceRecord (tier-appropriate)
- ResearchAnswer
- SourceVerificationResult
- SourceQueryRecord
- Forum post (when wired; Task Forum + Run Board V1.0.1)
- Tool receipt (universal)

Private scratch is allowed only if explicitly configured (via the module's config). Private scratch MUST NOT affect downstream work product claims. The Outcome Evaluator (V3.3) flags work product whose claims depend on un-recorded research as `source_gap_marker` per the 22-unit extractor registry (V3.3 §5.17).

### §6.4 Routing policy

Open ResearchNeeds are routed by the Task Agent or the Source Research module to:

- A Source Research module activation (if one is wired downstream)
- A user prompt (if `priority = "blocking"` and no module can answer)
- A forum post (if a forum is wired and the need is broad)

Routing decisions are recorded as Need lifecycle transitions in the queue.

---

## §7 Source Research / Source Gathering module

### §7.1 Module type

```
step.source_research
```

(also acceptable: `step.source_gathering` — same module type, alternate label for non-legal domains)

### §7.2 Purpose

A generic module for finding, retrieving, verifying, updating, and adding sources to the Task Source Workspace. Not legal-only; usable across domains via the source_kind enum and `domain_payload` extension.

### §7.3 Config

```ts
SourceResearchModuleConfig {
  research_goal: string                        // user-stated research goal
  source_scope: string[]                       // applicability scopes for what's relevant
  
  allowed_source_types: Array<
    | "document_library"
    | "web"
    | "api"
    | "database"
    | "email"
    | "file_system"
    | "browser"
    | "connector"
    | "manual_upload"
    | "prior_task_output"
  >
  
  required_capabilities: CapabilityRef[]
  optional_capabilities: CapabilityRef[]
  
  source_workspace_policy: {
    workspace_ref?: string                     // existing workspace to update
    create_if_missing: boolean
    add_results_to_workspace: boolean
    make_workspace_available_downstream: boolean
    documentation_mode: SourceDocumentationMode
  }
  
  freshness_policy: {
    check_staleness: boolean
    refresh_if_stale: boolean
    max_age_days?: number
  }
  
  verification_policy: {
    verify_source_exists: boolean
    verify_quotes_or_extracts: boolean
    verify_applicability: boolean
    verify_currentness: boolean
  }
  
  // V3.3 coordination
  honor_learning_mode: boolean                 // default true; respects RevisorConfig.learning_mode
                                               // for cheap-model source verification
  
  schema_version: "1.0"
}
```

### §7.4 Ports

```
data_in                    // optional input artifact (e.g., draft to source-check)
instruction_in             // user/task agent instructions
context_in                 // task graph context
research_need_in           // unresolved ResearchNeed records routed here
source_workspace_in        // existing workspace to read/update
source_workspace_out       // updated workspace (or new one if created)
source_record_out          // new SourceRecords (per-record emission)
research_answer_out        // ResearchAnswer records for satisfied needs
unresolved_need_out        // ResearchNeed records the module couldn't satisfy
signal_out                 // learning signals (TaskProcessGapSignal if gap found)
error_out
```

### §7.5 Operational behavior

When activated:

1. Receive research goal, scope, allowed source types, workspace policy
2. Plan source queries based on goal + scope + available capabilities
3. Execute queries (record `SourceQueryRecord` for each)
4. Extract source content per documentation tier; create `SourceRecord` entries
5. Verify per `verification_policy` (create `SourceVerificationResult` records)
6. Add results to workspace
7. Address any open `ResearchNeed` records that match retrieved sources (emit `ResearchAnswer`)
8. Emit `signal_out`:
   - `TaskProcessGapSignal` if a gap was detected (e.g., a needed source type wasn't available)
9. Return updated workspace via `source_workspace_out`

### §7.6 Cost attribution

Per V3.3 §12.5, Source Research module activations attribute cost to:
- The module itself (LLM calls for query planning, summarization, verification)
- The underlying retrieval mechanisms (DOC25 ingestion, DOC73 library queries, API calls, browser session time, etc.)

Cost records flow through the standard task telemetry spine (Core R0.7.1 §12).

---

## §8 Source Workspace UI

### §8.1 Surfaces

The Source Workspace is rendered in:

- **Task graph** — workspace appears as a stored object accessible from the graph view
- **Run board** — workspace state visible during/after runs (when Run Board V1 is produced)
- **Module detail** — modules that read or write the workspace show workspace state in their detail view
- **Task Agent panel** — workspace summary in side panel
- **Artifact and source links** — clicking a citation in an artifact navigates to the SourceRecord
- **Future DOC73 library promotion flow** — workspace entries that promote to library appear in DOC73 UI

### §8.2 Workspace summary view

```
Source Workspace: MTD Opposition Research
─────────────────────────────────────────
Mode: Full source workspace
Availability: all future modules
Freshness: current
Taint: internal_corpus_trusted
Matter: Paramount Contractors v. City of Los Angeles

Open needs (3)
  • Verify source support for proposition X (blocking)
  • Check local court formatting rule (high)
  • Confirm currentness of Smith v. Jones cite (medium)

Sources
  Source refs:  102
  Source notes:  18
  Source cards:  12
  Verification receipts:  44
  
Warnings (2)
  • Source A flagged as stale (2024 case; may be superseded)
  • Source B does not support proposition C

[Open all] [Add source] [Promote to library] [Ask Task Agent]
```

### §8.3 SourceRecord detail view

For tier 3+ records:

```
SourceRecord: Cal. Civ. Code § 3333
─────────────────────────────────────
Type: statute
Citation: Cal. Civ. Code § 3333
Retrieved: 2026-05-15 14:23
Retrieved by: step.source_research (activation 4)

Summary
  General damages provision; "damages may be awarded... 
  for the breach of an obligation not arising from contract"

Key points
  • Distinct from contract-damages provision (§ 3300)
  • Applies to tort actions including conversion, fraud
  • Used in property/sign-permit damages cases

Applicability
  • Jurisdiction: California (binding)
  • Time period: current law (effective 1872, multiple amendments)
  • Domain: tort damages

Verification
  ✓ Source exists
  ✓ Currentness verified (2026-04-15 amendment check)
  ⚠ Applicability to sign-permit context: persuasive (not binding)

Domain
  Statute (California Civil Code)
  Last amendment: 2024
  Treatment status: current

Used by
  Module: step.brief_drafter (activation 7) — cited at section III.B.4
  Module: step.evaluator (activation 9) — verified citation
  
[Open native] [Open in browser] [Add note] [Verify] [Mark stale]
[Add to library] [Link to claim]
```

### §8.4 Context menu actions

On a SourceRecord:
- Open source (in workspace UI)
- Show in browser (if web source or has URL)
- Show in Finder (if local file)
- Open native app (if file with associated application)
- Save As
- Add note (creates tier-2 entry)
- Verify (triggers verification)
- Mark stale (sets freshness_state)
- Add to library (promotes to DOC73 library candidate)
- Link to claim/artifact (creates explicit authority_support_link per Addenda A 22-type registry)

### §8.5 Workspace-level actions

- **Add source** — manual user upload or URL entry
- **Promote to library** — initiates DOC73 library promotion flow (workspace entries → library entries)
- **Ask Task Agent** — opens Task Agent scoped to workspace state; agent can answer questions like "which sources have stale verification?" or "which open needs are blocking?"
- **Export** — exports workspace as a structured bundle (CSV / JSON / formatted report)

### §8.6 Integration with V3.3 Evaluator findings

When V3.3 Evaluator emits a finding with `target_criterion_id` referencing a source-related criterion, and the finding identifies a missing or unverified source, the UI surfaces a deep link from the Evaluator finding directly to the relevant SourceRecord or research_need_queue entry. This is the cross-cutting "finding → source state → repair action" flow.

---

## §9 Persistence and promotion policies

### §9.1 Task-scoped vs run-scoped

`TaskSourceWorkspace.persistence_policy.run_scoped`:
- `false` (default for ongoing matters) — workspace persists across runs of the task
- `true` — workspace exists only for the current run; cleaned up post-run

### §9.2 DOC72 task memory summary

When `persistence_policy.save_to_doc72_summary = true`, the workspace produces a summary record stored in DOC72 task memory at task completion. The summary includes source counts, key findings, unresolved needs, and verification status. Subsequent task runs read this summary as a starting point.

### §9.3 DOC73 library promotion

When `persistence_policy.promote_to_doc73_library_candidate = true`, workspace entries (typically tier 3 source cards) that match library promotion criteria are queued for review. Promotion requires user approval and EC Core policy gate (privileged-matter sources do not auto-promote).

### §9.4 Privacy and matter firewall

Workspace entries inherit the task's `matter_id` and privilege class. Cross-matter retrieval (per V3.3 §13.4) does not surface workspace entries from privileged matters. Cross-task retrieval within the same matter does surface them.

### §9.5 Retention

Workspace retention follows EC Core retention policies (per V3.3 §16.6 matter-specific governance). Default:
- Internal advisory matters: 3 years post-task-completion
- Client-facing matters: 5-7 years per matter class
- Privileged matters: indefinite until matter closure + 7y

---

## §10 Cross-doc obligations

### §10.1 OP-A rows owned by this sub-addendum

```
OBL-ADDB-SW-V12-WORKSPACE-API-01
  Owner: Addenda B Sub-addendum Source Workspace V1.0.1 (this doc)
  Consumer: V3.3.1 Outcome Evaluator+Revisor (§12 narrow workspace coverage),
            Core R0.7.1 (Task Agent panel integration), other task modules
  Description: TaskSourceWorkspace API surface — read, update, add records,
              query needs queue, verify sources, manage tiers
  Status: specified_in_owner

OBL-ADDB-SW-V12-RESEARCH-MODULE-01
  Owner: Addenda B Sub-addendum Source Workspace V1.0.1
  Consumer: DOC23 R3.1 module type registry (for step.source_research)
  Description: step.source_research module type with config schema, ports,
              and operational contract
  Status: specified_in_owner

OBL-ADDB-SW-V12-UI-01
  Owner: Addenda B Sub-addendum Source Workspace V1.0.1
  Consumer: DOC20 UI surfaces
  Description: Source Workspace UI surfaces — summary, detail, context menu actions,
              integration with Task Agent panel, deep links from Evaluator findings
  Status: specified_in_owner
```

### §10.2 Consumed obligations from other docs

This sub-addendum consumes:

- **OBL-XDOC-CLAIM-EXTRACTOR-PUBLIC-01** (Addenda A R4.1 V3) — uses the extractor's `authority_support_link`, `citation_reference`, `record_citation_reference` unit types when linking sources to claims
- **OBL-XDOC-SCOPE-PRIMITIVES-01** (Common Contracts) — uses `ArtifactScopeRef`, `TextAnchor`, `StructuredAnchor` for source-claim linking
- **OBL-XDOC-EC-POLICY-SIGNALS-01** (EC Core) — retention policies, privilege firewall enforcement, library promotion gating

### §10.3 Consuming-doc inserts

**[XDOC-INSERT: DOC23 R3.1 next revision]**

```
1. Register step.source_research as a canonical module type in the module registry,
   with config schema, port surface, and operational contract per Source Workspace V1.0.1 §7.

2. Add source_workspace_in / source_workspace_out as canonical port types in the
   port registry (consumed by step.source_research and by any module that reads
   or writes a workspace).

3. Cross-reference OBL-ADDB-SW-V12-RESEARCH-MODULE-01 in DOC23's OP-A list.
```

**[XDOC-INSERT: DOC25 next revision]**

```
1. Document the boundary between DOC25 universal document ingestion and the
   Source Workspace: DOC25 owns ingestion mechanics; Source Workspace owns the
   task/run-scoped substrate where ingestion results become SourceRecords.

2. The step.source_research module may invoke DOC25 ingestion as one of several
   retrieval mechanisms; ingestion results flow back to Source Workspace as
   SourceRecord entries with source_kind = "document" (or domain-specific kind).

3. No change to DOC25 internal mechanics; this is a cross-doc boundary note only.
```

**[XDOC-INSERT: DOC73 next revision]**

```
1. Document the boundary between Source Workspace (task/run-scoped) and DOC73
   library (persistent corpus). Source Workspace entries may promote to library
   per persistence_policy.promote_to_doc73_library_candidate.

2. Library promotion flow: Source Workspace candidate → user review → EC Core
   policy gate → DOC73 library entry. Privileged-matter source workspace entries
   do NOT auto-promote; explicit user action required.

3. Library entries can also be retrieved INTO a Source Workspace via the
   step.source_research module (allowed_source_types includes "document_library").
```

**[XDOC-INSERT: DOC20 next revision]**

```
1. Render Source Workspace surfaces per §8 of Source Workspace V1.0.1:
   - Workspace summary view
   - SourceRecord detail view
   - Context menu actions (open, verify, mark stale, add to library, etc.)
   - Workspace-level actions (add source, promote, ask Task Agent, export)

2. Deep links from V3.3 Evaluator findings to relevant SourceRecord or
   research_need_queue entries when finding identifies source-related issues.

3. Cross-reference OBL-ADDB-SW-V12-UI-01 in DOC20's OP-A list.
```

### §10.4 Coding-agent instructions

[CODING-AGENT-NOTE: cross-doc obligations pass]

When implementing Source Workspace V1.0.1, scan §10.3 for `[XDOC-INSERT: target_doc]` blocks and apply them when each target doc is next revised. Status updates flow through the OP-A ledger.

---

# END OF SOURCE WORKSPACE V1

**Document:** DOC23 Addenda B Sub-addendum — Source Workspace V1.0.1
**Status:** Build-ready
**Date:** 2026-05-17
**Total sections:** 10
**Total OP-A rows owned:** 3
**Total cross-doc inserts:** 4 (DOC23 R3.1, DOC25, DOC73, DOC20)
**Self-contained:** Yes
**Sibling docs:** Core R0.7.1, V3.3.1 Outcome Evaluator+Revisor, Common Contracts V1.1.1, Task Forum + Run Board V1.0.1, Feedback Delivery V1.0.1

---