DOC23_ADDB_SUBSYS_TASK_FORUM_RUN_BOARD_V1_0_1.md
Current Specs/DOC23/DOC23 Addenda B/DOC23_ADDB_SUBSYS_TASK_FORUM_RUN_BOARD_V1_0_1.md
# DOC23 Addenda B Sub-addendum — Task Forum + Run Board V1.0.1
**Document type:** Topical sub-addendum to DOC23 Addenda B Core R0.7.
**Subject:** Specification for the passive Task Run Board, the active Task Forum module (`system.task_forum`), Module Assistance Requests, Board Digests, TaskRunContextPacket, moderator modes, and the user-facing Forum/Board UI surfaces.
**Status:** V1.0.1 — clean replacement for V1.0; reference/topology cleanup only; initial draft incorporating R0.6.5 proposal §§19-22, §27, §31, integrated with V3.3 §14.9 plan review forum 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, Source Workspace 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 Addenda B / Source Workspace V1.0.1; DOC23 Addenda B / Feedback Delivery V1.0.1; DOC23 Evaluation Common Contracts V1.1.1; DOC23 Addenda A R4.1 V3; DOC23 R3.1; DOC12 (Forum room kinds); DOC24 (capability/context routing); DOC20 (UI surfaces); EC Core Addendum A V3.3; OP-A V3.7+.
---
## §0 How to read this sub-addendum
### §0.1 Scope
This sub-addendum specifies two distinct but related primitives:
- **Task Run Board** — a passive chronological audit feed for every task run. Records module starts/completions, artifacts created, deliveries, errors/retries, gate decisions, evaluator findings, repair instructions, source updates, user comments, Task Agent recommendations, cost/duration updates, and key task-run events. Does not alter execution.
- **Task Forum** — an optional active module (`system.task_forum`) that enables controlled cross-module communication, posting, reading, requests, mentions, digests, and user/Task Agent interaction. Shaped like other DOC23 modules: typed inputs, typed outputs, declared participants, configurable behavior.
It also specifies:
- **Module Assistance Requests** — typed module-to-module communication primitive (operates with or without the Forum)
- **Board Digests** — role-specific, token-capped board summaries delivered to modules that need awareness
- **TaskRunContextPacket** — broader context packet assembled by DOC24 for scoped contextual injection
- **Moderator modes** — five distinct modes (none, deterministic router, Task Agent advisory, domain moderator, human moderator)
- **UI surfaces** — passive board view, active forum view, config panel
### §0.2 What this sub-addendum does NOT cover
- **Evaluator output emission and routing** — Feedback Delivery V1.0.1 (sibling sub-addendum). Forum is one of four delivery channels per Feedback Delivery V1.0.1 §7.
- **Source Workspace mechanics** — Source Workspace V1.0.1 (sibling). Forum can read/write source-related posts; the workspace owns the source substrate.
- **Outcome evaluation** — V3.3.
- **Task Agent core mechanics** — Core R0.7.1 §4. Forum interacts with Task Agent (advisory moderator mode); Task Agent's own internals live in Core R0.7.
- **DOC12 Forum room kinds** — DOC12 owns canonical room registrations (e.g., `RoomKind.plan_review` per V3.3 §14.9). This sub-addendum specifies the Forum module that DOC12's room kinds may instantiate.
### §0.3 Boundary with V3.3 §14.9
V3.3 §14.9 specifies the **plan review forum** — a Forum instantiation where the V3.3.1 Revisor publishes RevisionPlans for sub-agent review and user approval before execution. The plan review forum uses this sub-addendum's primitives (forum module, posts, digests) with `RoomKind.plan_review` (DOC12-registered).
This sub-addendum is the generic substrate; V3.3 §14.9 is one specialized application.
### §0.4 Reading order
- §1 — Passive Task Run Board
- §2 — Active Task Forum module
- §3 — Forum module ports and config
- §4 — Forum moderator modes
- §5 — Task Run Board Posts
- §6 — Board Digest and TaskRunContextPacket
- §7 — Module Assistance Requests
- §8 — UI surfaces
- §9 — Substantive gap vs. process gap (Task Agent boundary)
- §10 — Cross-doc obligations
---
## §1 Passive Task Run Board
### §1.1 Always-on
Every task run has a passive Run Board. It is the chronological audit feed of the run. It records what happened, when, by what module, to what artifact. It does not require user opt-in or configuration. It does not alter execution.
The Run Board is the foundation for:
- The user-facing run-inspector UI (per Core R0.7.1 §20)
- Audit and replay (Core R0.7.1 §12 telemetry spine)
- Post-run learning signals (events feed BDSM via the standard telemetry path)
- Task Agent diagnosis (when the user asks "what happened in this run?", the agent reads the board)
### §1.2 Recorded events
The Run Board records:
- Module starts and completions
- Artifacts created or updated
- Deliveries (artifact-out, side effects per V3.3 §11.18 RevisionSideEffectPolicy)
- Errors and retries
- Gate decisions (Outcome Gate, Quality Gate per V3.3)
- Evaluator findings (anchored to feedback bundles per Feedback Delivery V1.0.1)
- Repair instructions (created, dispatched, consumed)
- Source updates (workspace tier changes, verification results, staleness flags)
- User comments (when the user posts mid-run)
- Task Agent recommendations
- Cost and duration accruals
- Key task-run lifecycle events (start, pause, resume, completion, abort)
### §1.3 Passive vs. active distinction
The Run Board is **passive** — events are recorded as side effects of normal execution. No module needs to be wired to "post to the board." Every system event auto-publishes.
The Forum (§2) is **active** — modules participate by wiring ports. The Forum is opt-in per task and provides cross-module communication beyond passive recording.
A task without a Forum module still has a Run Board.
---
## §2 Active Task Forum module
### §2.1 Module type
```
system.task_forum
```
### §2.2 Purpose
The Forum enables controlled cross-module communication. It is module-shaped: typed inputs, typed outputs, declared participants, configurable behavior. Tasks that benefit from cross-module visibility (multi-agent research, multi-stage drafting with quality gates, complex pipelines with conditional routing) wire a Forum module; simpler tasks don't.
### §2.3 When to use
The Task Agent suggests adding a Forum module when:
- Task complexity is medium or complex (per Core R0.7.1 §2.13)
- Multiple modules need to coordinate (e.g., research module + drafting module + evaluator module)
- Cross-module awareness improves outcomes (e.g., one module's source verification result is useful to another)
- The user wants visibility into the cross-module workflow
A simple single-module task does not need a Forum.
---
## §3 Forum module ports and config
### §3.1 Ports
```
Inputs:
post_in // generic post intake
artifact_in // artifact reference posts
source_update_in // source workspace update posts
repair_instruction_in // repair instruction posts
evaluation_result_in // evaluation envelope/feedback bundle posts
research_need_in // research need posts
question_in // module question posts
user_guidance_in // user-authored guidance posts
context_packet_in // assembled TaskRunContextPacket for forum context
Outputs:
digest_out // BoardDigest for downstream consumers
post_out // generic post stream
research_need_out // routed research needs
assistance_request_out // ModuleAssistanceRequest routing
repair_broadcast_out // broadcast repair instructions
user_guidance_out // active user guidance
decision_out // forum decisions (e.g., approved/rejected plans)
signal_out // learning signals
error_out
```
### §3.2 Module config
```ts
TaskForumModuleConfig {
forum_name: string // e.g., "Plan Review Forum"
mode:
| "passive_board_only" // passive recording only
| "structured_forum" // typed posts, declared participants
| "moderated_forum" // structured + moderator agent
participant_policies: Record<string, ForumParticipantPolicy>
board_digest_policy: BoardDigestPolicy
moderator_policy?: ForumModeratorPolicy
source_workspace_sync_policy?: SourceWorkspaceSyncPolicy
user_participation_policy?: UserForumParticipationPolicy
// DOC12 room kind binding (V3.3 §14.9 coordination)
room_kind?: string // e.g., "plan_review", "research_coordination"
// resolves to DOC12-registered RoomKind
schema_version: "1.0"
}
ForumParticipantPolicy {
module_id: string
// Capabilities
can_read: boolean
can_post: boolean
can_ask_questions: boolean
can_answer_questions: boolean
can_create_research_needs: boolean
can_create_repair_instructions: boolean
can_tag_modules: boolean
// Reading
read_scope:
| "none"
| "mentions_only"
| "segment_only"
| "all_relevant_posts"
| "full_board"
notification_mode:
| "never"
| "on_mention"
| "on_segment_post"
| "on_blocking_post"
| "all_posts"
check_frequency:
| "never"
| "before_run"
| "after_each_iteration"
| "on_mention"
| "periodic_if_long_running"
allowed_post_kinds: TaskRunBoardPostKind[]
schema_version: "1.0"
}
BoardDigestPolicy {
include_open_research_needs: boolean
include_unresolved_repairs: boolean
include_current_run_guidance: boolean
include_user_comments: boolean
include_source_warnings: boolean
max_digest_tokens: number // typical default 1200
refresh_policy:
| "before_each_consumer_read"
| "periodic"
| "on_change"
schema_version: "1.0"
}
UserForumParticipationPolicy {
can_post: boolean
can_comment_on_posts: boolean
can_approve_guidance: boolean
can_contest_findings: boolean
notification_subscription:
| "all_posts"
| "blocking_only"
| "mentions_only"
| "summary_only"
| "none"
schema_version: "1.0"
}
SourceWorkspaceSyncPolicy {
auto_publish_source_updates: boolean
auto_publish_workspace_warnings: boolean
source_workspace_refs: string[] // which workspaces sync to this forum
schema_version: "1.0"
}
```
### §3.3 Mode behaviors
**`passive_board_only`** — Forum module exists but does not actively coordinate. Posts are recorded; no moderator, no routing, no digest assembly. Functionally equivalent to the always-on passive Run Board with explicit forum scoping.
**`structured_forum`** — Default for non-trivial tasks. Modules participate per their `ForumParticipantPolicy`. Digests are assembled per `BoardDigestPolicy`. No moderator agent.
**`moderated_forum`** — Adds a moderator agent per `ForumModeratorPolicy` (§4). The moderator can route requests, summarize, propose changes (with user approval for graph patches).
---
## §4 Forum moderator modes
Five moderator modes, in plain English:
### §4.1 No moderator (`none`)
The board is a feed. Modules post and read according to their `ForumParticipantPolicy`. No agent routes anything. Used when the task is small enough that participation rules are sufficient.
### §4.2 Deterministic router (`deterministic_router`)
The system uses simple rules to route requests. Example: a module posts "need source support" → the system routes it to the configured source-research module's `research_need_in` port. No LLM judgment; just rule-based dispatch.
Rules are defined in the forum config (e.g., `{ "source_lookup" → "step.source_research", "format_question" → "step.format_checker" }`).
### §4.3 Task Agent advisory moderator (`task_agent_advisory`)
The Task Agent watches the forum for process problems and suggests graph/process changes. It does NOT make substantive judgments and does NOT change the graph without user approval.
Example: repeated evaluator failures show no repair route exists in the current graph → Task Agent posts "I'd suggest adding a repair module here" with a proposed graph patch; user approves or declines.
### §4.4 Domain/substantive moderator (`domain_moderator`)
A configured domain/reviewer agent makes substantive observations. This is NOT the default Task Agent role; it requires its own context, instructions, and evaluation criteria.
Example: in a legal-drafting task, a "legal_reviewer" agent monitors the forum for substantive issues (incorrect citation forms, missing arguments) and posts findings. The legal_reviewer is configured separately with its own outcome bindings.
### §4.5 Human moderator (`human_moderator`)
The user (or another designated human reviewer) moderates the board. The forum surfaces all posts to the human via notification; the human responds, routes, or approves. Used for high-stakes tasks where human judgment is required at coordination points.
### §4.6 ForumModeratorPolicy schema
```ts
ForumModeratorPolicy {
mode:
| "none"
| "deterministic_router"
| "task_agent_advisory"
| "domain_moderator"
| "human_moderator"
moderator_agent_ref?: string // required if mode != "none" && "human_moderator"
// Capabilities
may_route_requests: boolean
may_summarize_board: boolean
may_create_research_needs: boolean
may_create_repair_instructions: boolean
may_propose_graph_patches: boolean
may_pause_run_for_human: boolean
// Gating
require_user_approval_for_graph_changes: boolean // default true
schema_version: "1.0"
}
```
---
## §5 Task Run Board Posts
### §5.1 Post kinds
```ts
TaskRunBoardPostKind =
| "status_update"
| "source_added"
| "research_need"
| "research_answer"
| "evaluation_finding"
| "repair_instruction"
| "quality_gate_decision"
| "question_to_module"
| "answer_from_module"
| "user_guidance"
| "artifact_reference"
| "score_summary"
| "delivery_receipt"
| "error_or_retry"
| "decision"
| "process_gap"
| "task_agent_proposal"
```
### §5.2 Post schema
```ts
TaskRunBoardPost {
post_id: string
task_id: string
run_id: string
forum_module_id?: string // null for passive-board-only posts
// Authorship
author_kind:
| "module"
| "subagent"
| "outcome_evaluator"
| "task_agent"
| "user"
| "system"
author_ref: string
post_kind: TaskRunBoardPostKind
// Scoping
segment_id?: string
module_id?: string
activation_seq?: number
target_module_id?: string
target_segment_id?: string
// Content references
content_ref: StorageRef // post body
artifact_refs: StorageRef[]
source_workspace_refs: string[] // Source Workspace V1.0.1 §2
repair_instruction_refs: StorageRef[] // Feedback Delivery V1.0.1 §5
outcome_result_refs: StorageRef[] // EvaluationResultEnvelope ids
feedback_bundle_refs: StorageRef[] // Feedback Delivery V1.0.1 §2
// Visibility
visibility:
| "all_task_modules"
| "selected_modules"
| "segment_only"
| "user_only"
| "task_agent_only"
// Governance
privileged?: boolean
matter_id?: string
created_at: ISO8601
schema_version: "1.0"
}
```
### §5.3 Post creation discipline
- Passive Run Board posts are created by the system automatically as events occur (module starts, artifacts created, etc.)
- Forum posts are created explicitly by participants via the Forum module's input ports
- Post creation is append-only; posts MUST NOT be modified after creation (audit invariant)
- Posts MAY be marked superseded by later posts; the original remains visible with a supersession indicator
### §5.4 Post visibility resolution
`visibility` field governs who can read the post:
- `all_task_modules` — every module in the task can read (via digest or direct query)
- `selected_modules` — only explicitly listed modules (via `target_module_id` and `target_segment_id`)
- `segment_only` — modules within the same task segment
- `user_only` — visible to the user (via UI); modules cannot consume
- `task_agent_only` — visible only to the Task Agent; surfaced in agent's diagnosis
---
## §6 Board Digest and TaskRunContextPacket
### §6.1 Purpose
Modules should NOT receive the entire board. They should receive role-specific, token-capped digests. The digest is what the module reads; the full board is what the user/Task Agent sees.
V3.3 §14.9 plan review forum uses `OutcomeEvaluationPacket` as a specialization of the broader `TaskRunContextPacket` for plan-review-specific context. Other forums use their own specializations or the generic packet.
### §6.2 BoardDigest schema
```ts
BoardDigest {
digest_id: string
task_id: string
run_id: string
segment_id?: string
module_id?: string // digest scoped to this module
// Included content
included_post_ids: string[]
open_research_needs: ResearchNeed[] // Source Workspace V1.0.1 §6
unresolved_repair_instruction_refs: StorageRef[] // Feedback Delivery V1.0.1 §5
source_warnings: string[] // from Source Workspace V1.0.1
user_guidance_summary: string
latest_quality_gate_states: Record<string, OutcomeEvaluationState>
current_run_guidance_ids: string[] // Feedback Delivery V1.0.1 §4
// Audience
generated_for:
| "drafting_module"
| "source_research_module"
| "outcome_evaluator"
| "task_agent"
| "human_reviewer"
| "custom"
// Cost
token_count: number
generated_at: ISO8601
schema_version: "1.0"
}
```
### §6.3 TaskRunContextPacket schema
```ts
TaskRunContextPacket {
packet_id: string
task_id: string
run_id: string
audience:
| "outcome_evaluator"
| "authoring_module"
| "source_research_module"
| "style_revision_module"
| "format_checker"
| "task_agent"
| "human_reviewer"
| "custom"
segment_id?: string
module_id?: string
// Content sources
current_plan_summary_ref?: StorageRef // task design summary
board_digest_ref?: StorageRef
source_workspace_snapshot_ref?: StorageRef
// Open items
open_research_needs: ResearchNeed[]
unresolved_repair_instruction_refs: StorageRef[]
current_run_guidance_ids: string[]
user_guidance_refs: StorageRef[]
prior_failed_gate_refs: StorageRef[]
// Relevant references
relevant_artifact_refs: StorageRef[]
relevant_source_refs: StorageRef[]
// Cost
max_tokens: number
generated_at: ISO8601
schema_version: "1.0"
}
```
### §6.4 Assembly rule
`TaskRunContextPacket`s are assembled by **DOC24** when used as contextual injection (i.e., when the consuming module didn't have explicit wired feedback input). Direct wired inputs do NOT require DOC24 packet assembly — feedback flows through the wired port per Feedback Delivery V1.0.1 §7.2.
The DOC24 packet assembly path:
1. DOC24 receives a request for context for a specific module's activation
2. DOC24 reads the audience role, applies selection rules (per its own routing), and produces a packet
3. Packet includes board digest (per `BoardDigestPolicy` of any forum the module participates in), workspace snapshot (per Source Workspace V1.0.1), active guidance, and other audience-appropriate context
4. DOC24 applies permissioning (matter/privilege firewall per EC Core)
5. DOC24 caps the packet at `max_tokens`
6. The packet is rendered into the module's prompt via DOC15/CIL
### §6.5 Digest vs. packet boundary
- **BoardDigest** is the forum's view of run state; produced by the Forum module
- **TaskRunContextPacket** is the broader DOC24-assembled context for a module activation; may include a BoardDigest among other sources
A module may receive a BoardDigest via direct port wiring (`Forum.digest_out` → `Module.context_in`) without DOC24 involvement, OR via DOC24-assembled TaskRunContextPacket that includes the digest by reference. Both flows are valid; the choice depends on whether the module needs the broader context or just the forum view.
---
## §7 Module Assistance Requests
### §7.1 Purpose
Modules may need help from shared resources, source workspaces, research modules, evaluators, Task Agent, humans, or the forum. This communication MUST be typed and optional — free-form module-to-module chat is NOT the default.
### §7.2 Schema
```ts
ModuleAssistanceRequest {
request_id: string
task_id: string
run_id: string
from_module_id: string
from_activation_seq: number
// Target
target:
| "source_workspace"
| "source_research_module"
| "outcome_evaluator"
| "task_agent"
| "specific_module"
| "human"
| "task_forum"
target_module_id?: string // required when target = "specific_module"
// Request
request_kind:
| "source_lookup"
| "more_research"
| "verify_reference"
| "clarify_prior_output"
| "format_rule_lookup"
| "style_guidance"
| "repair_instruction"
| "human_question"
| "custom"
question: string
priority: "low" | "medium" | "high" | "blocking"
// Response policy
response_policy:
| "post_to_board"
| "route_to_instruction_in"
| "route_to_context_in"
| "pause_until_answer"
| "continue_with_warning"
response_ref?: StorageRef // populated when answered
created_at: ISO8601
schema_version: "1.0"
}
```
### §7.3 Operates with or without Forum
Module Assistance Requests work with OR without a `system.task_forum` module:
- **With Forum:** Requests flow through the Forum's `assistance_request_out` port. The forum digests requests, routes per moderator policy, surfaces to participants per their `notification_mode`.
- **Without Forum:** Requests flow directly to the target module via the request's `response_policy` (e.g., `route_to_instruction_in` wires the request to a specific module's `instruction_in` port).
The Forum module makes requests visible/configurable but is not required for the primitive to function.
### §7.4 Response handling
When a request is answered, the answering party populates `response_ref` with a reference to the response (typically a Forum post or a direct module output). The requester reads the response via:
- The Forum (if request used `post_to_board`)
- The wired port (if request used `route_to_instruction_in` or `route_to_context_in`)
- Pause-resume mechanism (if request used `pause_until_answer` — the run pauses; the answer triggers resume)
- Standard continuation (if request used `continue_with_warning` — the requester proceeds with a warning record)
---
## §8 UI surfaces
### §8.1 Passive Run Board view
The passive Run Board displays as a forum-like chronological run stream. Available in:
- Task run inspector (per Core R0.7.1 §20)
- Run review UI (post-completion view)
- Task Agent panel (for diagnosis)
- DOC72 task activity memory surface
Filter bar:
```
All | Modules | Sources | Evaluations | Repairs | User | Artifacts | Errors | Deliveries | Task Agent
```
A post expands to show:
- Input refs (what came into the producing module)
- Output refs (what the module produced)
- Source refs (sources consulted)
- Module activation details (config, capabilities used)
- Cost and duration
- Evaluator result (if an evaluation happened in this step)
- Repair instructions (if any were created)
- Open actions (user-actionable items)
### §8.2 Sample passive board view
```
Run Board — Paramount MTD Opposition Brief (run 47)
─────────────────────────────────────────────────────
[All filter selected]
10:14 — step.outline_drafter (activation 1)
Status: completed (4.2s, $0.18)
Produced: outline_v1.md
[Open artifact] [Show input/output]
10:15 — step.source_research (activation 2)
Status: completed (47.3s, $1.20)
Sources added: 12 (3 cards, 9 references)
Workspace updated: MTD Source Workspace
[Open workspace]
10:23 — step.brief_drafter (activation 3)
Status: completed (62.1s, $1.85)
Produced: brief_draft_v1.md
[Open artifact]
10:32 — step.evaluator (activation 4)
Status: completed (12.4s, $0.42)
Verdict: failed
Findings: 8 (2 blocking, 4 major, 2 minor)
Routing: send_to_revision_module + post_blockers_to_forum
[Open findings] [Open feedback bundle]
10:33 — Forum
Posted: 2 blocking findings from step.evaluator
[Open forum]
10:33 — step.revisor (activation 5)
Status: in progress
Consuming: repair_instructions from step.evaluator
[Live status]
10:44 — Source Verifier
Blocking issue: Source X does not support proposition Y
[Open evidence] [Mark wrong]
```
### §8.3 Active forum view
When `system.task_forum` is present, the UI adds:
- Participant list (with capabilities and read scope per module)
- Per-module permission view
- Mentions stream (@module-id syntax)
- Open requests queue
- Board digest settings (collapsed by default)
- Moderator mode indicator
- Post filters (kind, author, segment, target)
- User comments thread
- Task Agent side-panel context
### §8.4 Forum config panel
The module detail panel for `system.task_forum`:
```
Task Forum: Paramount MTD Coordination
─────────────────────────────────────────
Mode: Structured forum
Moderator: Deterministic router
Room kind: research_coordination (DOC12-registered)
Participants
step.source_research read/write, answers source requests
step.brief_drafter read digest, may ask source questions
step.outcome_evaluator posts findings + repairs
user can comment, approve guidance
Task Agent advisory process monitor
Digest policy
☑ Include open source needs
☑ Include unresolved repairs
☑ Include accepted/current guidance
☑ Include user comments
Max digest tokens: [1200]
Refresh: [Before each consumer read ▾]
User participation
☑ Can post
☑ Can comment on posts
☑ Can approve guidance
☑ Can contest findings
Notifications: [Blocking posts only ▾]
Moderator policy (deterministic router)
Routing rules:
source_lookup → step.source_research
format_question → step.format_checker
repair_instruction → step.revisor
☑ May route requests
☑ May summarize board
☐ May propose graph patches (require approval)
```
### §8.5 Plan review forum specialization
When the Forum is instantiated as the V3.3 plan review forum (per V3.3 §14.9), the UI shows:
- Pending plans awaiting review (from V3.3.1 Revisor)
- Per-plan vote summary (sub-agent votes + user vote)
- Annotation tools (per-step approve/modify/reject)
- "Approve and execute" or "Reject and replan" actions
The plan review forum uses `RoomKind.plan_review` (DOC12-registered) and the standard Forum module mechanics; specialization is in the UI rendering, not the underlying primitives.
---
## §9 Substantive gap vs. process gap (Task Agent boundary)
### §9.1 Two kinds of gaps
The Forum and Run Board surface two distinct gap categories:
**Substantive gap** — about the work product itself.
> *Example: "The draft does not address the Safe Harbor argument."*
Detected by:
- V3.3.1 Outcome Evaluator (Addenda B)
- Addenda A Judge
- Agent Review gates
- Red Team modules
- Source Research module (when verifying claims)
- Human reviewer
- Domain/substantive moderator agent
Surfaced via: evaluator findings, repair instructions, forum posts of kind `evaluation_finding` or `repair_instruction`.
**Process gap** — about the task graph or workflow.
> *Example: "The graph has no route for a `needs_more_sources` evaluator output."*
Detected by:
- Task Agent (Core R0.7.1 §4)
- Task Assessment (Core R0.7.1 §16)
- Telemetry analysis (Core R0.7.1 §12)
- Repeated feedback failures (Feedback Delivery V1.0.1 §6.4)
Surfaced via: `TaskProcessGapSignal` (Core R0.7.1 §9.0.3), forum posts of kind `process_gap` or `task_agent_proposal`.
### §9.2 Why the distinction matters
Confusing the two leads to misrouting:
- A substantive gap routed to the Task Agent results in the agent producing suggestions outside its competence (the Task Agent is the operational task-system expert, NOT a domain reviewer)
- A process gap routed to a domain reviewer results in the reviewer flagging "missing argument" when the actual issue is "no module exists to research that argument"
The Forum keeps the boundary clean: substantive gaps stay with substantive evaluators; process gaps go to the Task Agent (which can propose graph patches with user approval).
### §9.3 Task Agent role (recap from Core R0.7.1 §4)
The Task Agent may:
- Design tasks
- Explain graphs
- Inspect runs
- Retrieve outputs
- Assess task design
- Consume evaluator findings (for diagnosis, NOT for substantive re-evaluation)
- Detect process gaps
- Propose graph patches
- Propose new modules/segments/gates
- Propose template updates
- Explain why feedback did or did not reach downstream modules
The Task Agent MUST NOT be the default substantive evaluator. Substantive judgment lives in evaluator modules with proper outcome bindings, criteria, and assurance basis.
---
## §10 Cross-doc obligations
### §10.1 OP-A rows owned by this sub-addendum
```
OBL-ADDB-TFB-V1-RUN-BOARD-01
Owner: Addenda B Sub-addendum Task Forum + Run Board V1.0.1 (this doc)
Consumer: DOC23 R3.1 telemetry spine, Core R0.7.1 run inspector UI,
Task Agent (diagnosis), DOC72 task activity memory
Description: Passive Task Run Board — always-on chronological audit feed
recording module events, artifacts, evaluations, repairs, sources,
user actions, agent recommendations
Status: specified_in_owner
OBL-ADDB-TFB-V1-FORUM-MODULE-01
Owner: Addenda B Sub-addendum Task Forum + Run Board V1.0.1
Consumer: DOC23 R3.1 module type registry, DOC12 Forum room kinds, V3.3 §14.9
plan review forum specialization
Description: system.task_forum module type with config schema, port surface,
participant policies, digest policy, moderator policy,
source workspace sync policy, user participation policy
Status: specified_in_owner
OBL-ADDB-TFB-V1-DIGEST-PACKET-01
Owner: Addenda B Sub-addendum Task Forum + Run Board V1.0.1
Consumer: DOC24 context packet assembly, downstream modules consuming digests
Description: BoardDigest schema and TaskRunContextPacket schema; assembly rule
(DOC24 owns context packet assembly when consumer didn't wire input directly)
Status: specified_in_owner
OBL-ADDB-TFB-V1-ASSISTANCE-REQUEST-01
Owner: Addenda B Sub-addendum Task Forum + Run Board V1.0.1
Consumer: Any module needing typed module-to-module communication
Description: ModuleAssistanceRequest schema; operates with or without Forum module
Status: specified_in_owner
OBL-ADDB-TFB-V1-MODERATOR-MODES-01
Owner: Addenda B Sub-addendum Task Forum + Run Board V1.0.1
Consumer: Forum module configs, Task Agent, domain agents, DOC20 UI
Description: Five moderator modes (none / deterministic_router / task_agent_advisory /
domain_moderator / human_moderator); capability gating;
user-approval requirement for graph changes
Status: specified_in_owner
OBL-ADDB-TFB-V1-UI-01
Owner: Addenda B Sub-addendum Task Forum + Run Board V1.0.1
Consumer: DOC20 UI surfaces
Description: Passive Run Board view, active forum view, config panel,
plan review forum specialization view
Status: specified_in_owner
```
### §10.2 Consumed obligations from other docs
- **OBL-DOC12-FORUM-01** (DOC12) — DOC12 registers `RoomKind.plan_review` and other canonical room kinds that this sub-addendum's Forum module instantiates per `room_kind` config field
- **OBL-XDOC-EVAL-ENV-01** (Common Contracts) — forum posts may reference `EvaluationResultEnvelope` ids
- **OBL-ADDB-FD-V1-CHANNELS-01** (Feedback Delivery V1.0.1) — forum is one of four delivery channels; ports defined there reference this sub-addendum's Forum module
- **OBL-ADDB-SW-V12-WORKSPACE-API-01** (Source Workspace V1.0.1) — Source Workspace sync policy reads from workspace
- **OBL-XDOC-EC-POLICY-SIGNALS-01** (EC Core) — forum posts inherit privilege/matter governance per the same envelope rules as signals
### §10.3 Consuming-doc inserts
**[XDOC-INSERT: DOC23 R3.1 next revision]**
```
1. Register system.task_forum as a canonical module type in the module registry,
with config schema, port surface, and operational contract per
Task Forum + Run Board V1.0.1 §3.
2. Add post_in, artifact_in, source_update_in, repair_instruction_in,
evaluation_result_in, research_need_in, question_in, user_guidance_in,
context_packet_in to the canonical input port registry.
3. Add digest_out, post_out, research_need_out, assistance_request_out,
repair_broadcast_out, user_guidance_out, decision_out to the canonical
output port registry.
4. Document the passive Run Board as a baseline telemetry feature (no opt-in).
5. Cross-reference OBL-ADDB-TFB-V1-FORUM-MODULE-01 and
OBL-ADDB-TFB-V1-RUN-BOARD-01 in DOC23's OP-A list.
```
**[XDOC-INSERT: DOC12 next revision]**
```
1. Register canonical RoomKind values for Forum module instantiation:
- "plan_review" (V3.3 §14.9 plan review forum)
- "research_coordination" (multi-module research tasks)
- "drafting_coordination" (multi-stage drafting with quality gates)
- "custom" (user-defined)
2. Each RoomKind declares: default participants, default digest policy,
default moderator mode, default user participation policy.
3. Forum module config's room_kind field resolves to the DOC12-registered
RoomKind; resolved RoomKind contributes defaults that the config may override.
4. Cross-reference OBL-DOC12-FORUM-01 in DOC12's OP-A list.
```
**[XDOC-INSERT: DOC24 next revision]**
```
1. DOC24 context packet assembly produces TaskRunContextPacket records per
Task Forum + Run Board V1.0.1 §6.3 when modules request context.
2. Packet content includes BoardDigest (from active Forum if present),
Source Workspace snapshot, active RunGuidance, open ResearchNeeds,
unresolved RepairInstructions, prior failed gate refs.
3. Packet assembly respects matter/privilege firewall and token budget per
audience role.
4. Cross-reference OBL-ADDB-TFB-V1-DIGEST-PACKET-01 in DOC24's OP-A list.
```
**[XDOC-INSERT: DOC20 next revision]**
```
1. Render passive Run Board UI per §8.1-§8.2:
- Chronological run stream with filter bar
- Per-post expansion (inputs, outputs, sources, cost, duration, evaluator
result, repair instructions, open actions)
- Integration with task run inspector
2. Render active Forum UI per §8.3:
- Participant list with capabilities
- Mentions stream
- Open requests queue
- Board digest settings panel
- Moderator mode indicator
- Post filters
3. Render Forum config panel per §8.4.
4. Render plan review forum specialization per §8.5 (V3.3 §14.9):
- Pending plans queue
- Per-plan vote summary
- Annotation tools
- Approve/reject actions
5. Cross-reference OBL-ADDB-TFB-V1-UI-01 in DOC20's OP-A list.
```
### §10.4 Coding-agent instructions
[CODING-AGENT-NOTE: cross-doc obligations pass]
When implementing Task Forum + Run Board 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 TASK FORUM + RUN BOARD V1
**Document:** DOC23 Addenda B Sub-addendum — Task Forum + Run Board V1.0.1
**Status:** Build-ready
**Date:** 2026-05-17
**Total sections:** 10
**Total OP-A rows owned:** 6
**Total cross-doc inserts:** 4 (DOC23 R3.1, DOC12, DOC24, DOC20)
**Self-contained:** Yes
**Sibling docs:** Core R0.7.1, V3.3.1 Outcome Evaluator+Revisor, Common Contracts V1.1.1, Source Workspace V1.0.1, Feedback Delivery V1.0.1
---