Elnor Repo Reader

# DOC23 Addenda B Sub-addendum — Feedback Delivery V1.0.1

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

**Subject:** Specification for in-run feedback delivery from evaluators (V3.3.1 Outcome Evaluator, Addenda A Judge, agent review gates) to downstream consumers (modules, sub-agents, Task Agent, user). Defines the `EvaluationFeedbackBundle`, defeasible findings, Run Guidance, Repair Instructions, Feedback Routing Policy, four delivery channels, and Feedback Consumption Receipts.

**Status:** V1.0.1 — clean replacement for V1.0; reference/topology cleanup only; initial draft incorporating R0.6.5 proposal §§8-15, integrated with V3.3.1 Outcome Evaluator+Revisor §14 (post-run learning signals) 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 Task Forum + Run Board 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. Substantive Feedback Delivery compatibility updates remain scheduled for Feedback Delivery V1.1.

**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 B / Source Workspace V1.0.1; DOC23 Addenda B / Task Forum + Run Board V1.0.1; DOC23 Addenda A R4.1 V3; DOC23 R3.1; DOC15 (CIL/runtime prompt assembly); DOC24 (capability/context routing); 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 **in-run feedback delivery pipeline**. It defines how evaluator output (findings, recommendations, source needs, process gaps) reaches the modules, sub-agents, and surfaces that can act on it during a running task.

It covers:

- `EvaluationFeedbackBundle` — the unified output shape that evaluators emit alongside the `EvaluationResultEnvelope`
- Defeasible findings — findings carry lifecycle state and authority basis; they are not eternal truth
- Run Guidance — finding-derived guidance scoped to the current run
- Repair Instructions — actionable directives for repair-capable consumers
- Feedback Routing Policy — declarative policy for what happens on each evaluation outcome
- Four delivery channels — control flow, direct wiring, forum/board publication, process-gap signal
- Feedback Consumption Receipts — confirmation that feedback reached and was acted on
- DOC23 / DOC15 / DOC24 boundary — which doc owns which feedback motion

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

- **Post-run learning signals** — that lives in Core R0.7.1 §9.0 (the five Core-owned signal payloads wrapped in `EvaluationLearningSignalEnvelope`). Post-run signals feed BDSM/DOC72 for durable learning; in-run feedback is about the current run.
- **The evaluator module surface itself** — V3.3 owns the Outcome Evaluator module and its ports.
- **The Judge module surface** — Addenda A R4.1 V3 owns it.
- **Forum and Run Board mechanics** — Task Forum + Run Board V1.0.1. Feedback delivery channels reference forum/board posts; the forum's own schemas live there.
- **Source Workspace** — Source Workspace V1.0.1 owns it. Research needs that originate from feedback may route to a Source Research module via the workspace.

### §0.3 Boundary with V3.3 §14 (post-run learning)

V3.3 §14 specifies the eight Phase 1 post-run learning signals (per Core R0.7.1 §9.0 enumeration). Those signals are emitted at outermost cycle closure for durable learning. This sub-addendum specifies the in-run feedback that flows during execution before the cycle closes. The two are complementary:

- **In-run feedback** (this sub-addendum): During a running task, evaluator emits findings/repair instructions/needs; downstream modules consume them; the run proceeds
- **Post-run learning signals** (Core R0.7.1 §9.0): At cycle closure, signals are emitted to BDSM/DOC72 for cross-run pattern learning

Both can fire during the same task; the in-run pipeline operates as the run executes, the learning pipeline operates at well-defined emission points.

### §0.4 Reading order

- §1 — Substrate role
- §2 — EvaluationFeedbackBundle
- §3 — Defeasible findings
- §4 — Run Guidance
- §5 — Repair Instructions
- §6 — Feedback Routing Policy
- §7 — Four delivery channels
- §8 — DOC23 / DOC15 / DOC24 boundary
- §9 — Feedback Consumption Receipts
- §10 — Cross-doc obligations

---

## §1 Substrate role

### §1.1 The problem

Evaluators answer "did this pass?" The next question is "what now?" An evaluator that emits only a binary verdict pushes the burden of interpretation onto every downstream consumer, leading to inconsistent repair workflows, lost findings, and duplicated work. The system needs a structured shape for "what failed, why, what to do, who should act."

`EvaluationFeedbackBundle` is that shape. It travels alongside the `EvaluationResultEnvelope` and carries the actionable layer.

### §1.2 Relationship to EvaluationResultEnvelope

- **`EvaluationResultEnvelope`** (Common Contracts §3) carries the verdict, slices, and lineage — what the evaluator concluded
- **`EvaluationFeedbackBundle`** (this sub-addendum §2) carries the actionable derivatives — what the system should do about the conclusion

Both are emitted by every evaluator producer. The envelope is universal across all evaluation producers (Judge, Outcome Evaluator, agent review gates, deterministic scorers, human review). The feedback bundle is the Outcome Evaluator's primary output shape; other producers may emit a minimal feedback bundle or skip it (e.g., a pure Judge scoring run with no repair pipeline downstream emits an envelope but may emit an empty feedback bundle).

### §1.3 Findings are defeasible

A finding is a proposition the evaluator emitted; it is not truth. Subsequent evidence (verification, user input, source updates) can supersede a finding. Run Guidance derived from findings carries the same defeasibility. The system MUST NOT treat findings as eternal — that would create stale-guidance pollution and frustrate the user.

---

## §2 EvaluationFeedbackBundle

### §2.1 Schema

```ts
EvaluationFeedbackBundle {
  feedback_bundle_id: string
  task_id: string
  run_id: string
  
  evaluator_module_id: string
  evaluator_activation_seq: number
  
  // Links to the parallel envelope (Common Contracts §3)
  evaluation_result_envelope_ref: string       // EvaluationResultEnvelope.result_id
  evaluation_snapshot_ref: StorageRef          // immutable snapshot the bundle is keyed to
  
  evaluated_target: EvaluatedTarget
  evaluation_basis: EvaluationBasis
  decision: EvaluationDecision
  
  findings: EvaluationFinding[]                // §3
  repair_instructions: OutcomeRepairInstruction[]  // §5
  research_needs: ResearchNeed[]               // Source Workspace V1.0.1 §6
  proposed_run_guidance: RunGuidanceCandidate[]  // §4
  
  routing_recommendation: FeedbackRoutingRecommendation  // §6
  
  created_at: ISO8601
  schema_version: "1.0"
}

EvaluatedTarget {
  target_kind:
    | "module_output"
    | "task_segment"
    | "draft_artifact"
    | "research_bundle"
    | "source_workspace"
    | "final_output"
    | "prompt_candidate"
    | "experiment_variant"
    | "custom"
  target_module_id?: string
  target_activation_seq?: number
  target_artifact_ref?: StorageRef
  target_version_ref?: StorageRef
  target_segment_id?: string
  target_scope_ref?: ArtifactScopeRef          // Common Contracts §7
                                               // when feedback scopes to sub-document
  schema_version: "1.0"
}

EvaluationBasis {
  outcome_spec_ref?: string                    // EvaluationOutcomeDefinition reference
  criteria_refs: string[]                      // Criterion.criterion_id values
  rubric_text_ref?: StorageRef
  source_workspace_snapshot_ref?: StorageRef   // workspace state at evaluation time
  board_digest_ref?: StorageRef                // forum digest at evaluation time
  input_artifact_refs: StorageRef[]
  evaluated_at: ISO8601
  schema_version: "1.0"
}

EvaluationDecision {
  state: OutcomeEvaluationState                // V3.1 §0.4 (14 values)
  verdict: "passed" | "failed" | "indeterminate" | "not_applicable"  // mirrors envelope
  aggregate_score?: number
  pass: boolean
  blocks_downstream: boolean
  schema_version: "1.0"
}
```

### §2.2 Bundle invariants

- `evaluation_result_envelope_ref` MUST resolve to a valid `EvaluationResultEnvelope`. Bundles without an envelope link fire `validation.feedback_bundle_unanchored`.
- `evaluation_snapshot_ref` MUST match the envelope's `evaluation_snapshot_ref`. Mismatch fires `validation.feedback_bundle_snapshot_drift`.
- `decision.verdict` MUST match envelope's `evaluation_verdict`. Mismatch fires `validation.feedback_bundle_verdict_inconsistent`.
- `findings[i].based_on_artifact_version_ref` MUST resolve to a version present in the snapshot. Findings keyed to stale artifact versions fire `validation.finding_stale_artifact_ref`.

### §2.3 When the bundle is emitted

Outcome Evaluator (V3.3) emits the bundle on every evaluation completion. Other producers may emit per their own rules:

- Judge (Addenda A) may emit a feedback bundle when scoring against a criterion-based outcome (Pattern A or C wiring) but typically emits a minimal bundle since Judge's primary output is scoring
- Agent review gates emit bundles when they observe issues that warrant downstream repair
- Deterministic scorers emit bundles only when they detect failure (pass case emits envelope only)
- Human review records may include a manual bundle (the human articulates findings and repair guidance)

---

## §3 Defeasible findings

### §3.1 Finding lifecycle

Findings carry lifecycle state that evolves as evidence accumulates:

```ts
EvaluationFindingLifecycleState =
  | "proposed"                                 // evaluator emitted it; not yet validated
  | "accepted"                                 // accepted into the run's working set
                                               // (e.g., feedback router admitted it)
  | "user_approved"                            // user explicitly confirmed
  | "tool_verified"                            // a deterministic tool confirmed
  | "contested"                                // user, tool, or sub-agent disputed it
  | "superseded"                               // a later finding replaced it
  | "expired"                                  // time/version-based expiration
```

### §3.2 Authority basis

A finding declares its authority. The Outcome Compiler and Revisor (V3.3) use authority basis to gate which findings can block downstream execution.

```ts
EvaluationAuthorityBasis =
  | "deterministic_check"                      // rule/tool gave a hard answer
  | "source_reference"                         // a cited source supports the finding
  | "tool_verification"                        // external tool ran and produced result
  | "rubric_criterion"                         // structured rubric-based judgment
  | "user_instruction"                         // user said so
  | "saved_criteria"                           // saved task's criteria triggered
  | "human_label"                              // human labeled this
  | "multi_reviewer_consensus"                 // multiple reviewers agreed
  | "model_judgment_only"                      // LLM judgment without external anchor
```

### §3.3 EvaluationFinding schema

```ts
EvaluationFinding {
  finding_id: string
  
  finding_kind:
    | "criterion_failed"
    | "missing_requirement"
    | "unsupported_assertion"
    | "source_mismatch"
    | "format_violation"
    | "style_violation"
    | "incomplete_coverage"
    | "research_gap"
    | "subjective_quality_issue"
    | "tool_verified_failure"
    | "process_observation"                    // about the task design itself
    | "custom"
  
  severity: "low" | "medium" | "high" | "blocking"
  authority_basis: EvaluationAuthorityBasis[]
  
  explanation: string
  evidence_refs: StorageRef[]
  affected_artifact_refs: StorageRef[]
  affected_claim_refs?: string[]               // extracted claim ids (Addenda A registry)
  confidence: number                           // 0-1
  
  // Criterion linkage (Common Contracts §6)
  target_criterion_id?: string                 // Criterion.criterion_id
  target_scope_ref?: ArtifactScopeRef          // Common Contracts §7
  
  // Provenance keying
  based_on_artifact_version_ref?: StorageRef
  based_on_source_workspace_snapshot_ref?: StorageRef
  based_on_board_digest_ref?: StorageRef
  
  // Lifecycle
  lifecycle_state: EvaluationFindingLifecycleState
  superseded_by_finding_id?: string
  expires_at?: ISO8601
  
  schema_version: "1.0"
}
```

### §3.4 Normative rules

1. **A finding is not truth merely because an evaluator emitted it.** Findings represent the evaluator's view at evaluation time; downstream consumers treat them as defeasible.

2. **Hard blockers require backed authority.** A finding with `severity = "blocking"` MUST have at least one of: `deterministic_check`, `source_reference`, `tool_verification`, `user_instruction`, `saved_criteria`. A `model_judgment_only` finding MUST NOT be a hard blocker unless the EvaluationOutcomeDefinition explicitly permits subjective blocking (per V3.3 §5.1.1 `pass_semantics` and `Criterion.scoring_basis`).

3. **Stale-version findings demote.** Findings based on old artifact versions or old source snapshots transition to `superseded` when the underlying target changes materially. The Outcome Compiler tracks this via V3.3 §5.16 EvaluationSnapshot mechanics.

4. **Source updates can supersede findings.** A finding about an unsupported assertion is superseded when a later Source Research module activation produces a supporting source.

5. **User approval promotes a finding.** When a user clicks "confirm" in the UI, lifecycle transitions to `user_approved`. This unlocks more aggressive repair routing.

6. **Tool verification promotes a finding.** When a deterministic tool confirms the finding, lifecycle transitions to `tool_verified`.

7. **Contesting demotes findings.** User dispute, sub-agent challenge, or tool contradiction transitions the finding to `contested`. Contested findings do NOT block execution by default; they surface to user for resolution.

### §3.5 Defeasibility in Pattern primitive learning

Per V3.3 §13 Pattern primitive, learning systems consume only `accepted`, `user_approved`, or `tool_verified` findings as positive signal. `proposed` findings that never promote are excluded — they represent transient noise. `contested` and `superseded` findings feed negative learning (the system learns to avoid emitting similar findings in similar contexts).

---

## §4 Run Guidance

### §4.1 Purpose

Some findings become run-level guidance for later modules. Run Guidance is scoped, lifecycled, and defeasible — it is NOT eternal accepted truth. A finding "source A is stale" might generate guidance "do not cite source A in this run"; the guidance ends when the run ends or when a refresh supersedes it.

### §4.2 Schemas

```ts
RunGuidanceCandidate {
  candidate_id: string
  source_finding_id: string
  statement: string
  proposed_scope:
    | "entire_run"
    | "segment"                                // task segment / sub-graph
    | "selected_modules"
    | "source_workspace"
    | "final_output"
  proposed_target_refs: string[]
  rationale: string
  schema_version: "1.0"
}

RunGuidanceItem {
  guidance_id: string
  task_id: string
  run_id: string
  
  guidance_kind:
    | "source_warning"
    | "do_not_use"
    | "must_include"
    | "style_rule"
    | "format_rule"
    | "research_gap"
    | "strategic_guidance"
    | "user_instruction"
    | "custom"
  
  statement: string
  source_finding_refs: string[]                // findings that generated this guidance
  source_refs: StorageRef[]                    // supporting sources
  
  lifecycle_state:
    | "proposed"
    | "active"
    | "user_approved"
    | "tool_verified"
    | "contested"
    | "superseded"
    | "expired"
  
  applies_to:
    | "entire_run"
    | "segment"
    | "selected_modules"
    | "source_workspace"
    | "final_output"
  target_refs: string[]
  
  based_on_artifact_version_ref?: StorageRef
  based_on_source_workspace_snapshot_ref?: StorageRef
  created_by_ref: string                       // module/agent/user that promoted candidate
  created_at: ISO8601
  superseded_by_guidance_id?: string
  
  schema_version: "1.0"
}
```

### §4.3 Candidate → Item promotion

`RunGuidanceCandidate` is what the feedback bundle proposes. `RunGuidanceItem` is what the run actually carries. Promotion from candidate to item happens via:

- Auto-promotion when finding lifecycle is `tool_verified` or `user_approved` and routing policy permits
- User confirmation in the UI
- Task Agent recommendation

Auto-promotion of `model_judgment_only` candidates is gated; default is human-in-the-loop for those.

### §4.4 Anti-drift rule

Downstream modules receive **current, scoped** Run Guidance via direct wiring or DOC24-assembled context packets. They MUST NOT receive superseded or expired guidance unless specifically requested for audit/debug. The CIL/DOC15 prompt assembly path filters guidance by lifecycle state when assembling context.

### §4.5 Scope semantics

`applies_to = "segment"` means the guidance applies to all modules within a named task segment. The Task Agent and DOC23 graph mechanics define segments. Segment-scoped guidance does not leak to other segments.

`applies_to = "selected_modules"` means the guidance applies only to explicitly enumerated modules. Used when guidance is specific to one downstream stage (e.g., format guidance applies to the final formatter, not to the intermediate drafter).

`applies_to = "source_workspace"` means the guidance affects the Source Workspace (e.g., "exclude source X"). Source Workspace V1.0.1 reads this guidance when filtering sources for downstream consumption.

---

## §5 Repair Instructions

### §5.1 Purpose

Findings say what is wrong. Repair Instructions say what to do. A repair instruction names the target, summarizes the failure, lists required changes, and recommends a route.

### §5.2 Schema

```ts
OutcomeRepairInstruction {
  repair_id: string
  
  target_scope:
    | "module"
    | "segment"
    | "artifact"
    | "source_workspace"
    | "final_output"
  
  target_ref: string                           // module_id, segment_id, artifact_ref, etc.
  failure_summary: string                      // 1-3 sentence overview
  required_changes: string[]                   // bullet list of changes
  
  // Optional structured guidance (for plan compilation; V3.3.1 Revisor reads this)
  target_scope_refs?: ArtifactScopeRef[]       // Common Contracts §7
                                               // specific scopes within target to modify
  source_findings: string[]                    // finding_ids that motivate this instruction
  preservation_constraints?: PreservationConstraintKind[]  // V3.1 §0.4
  
  suggested_route:
    | "send_to_prior_module"                   // route back to upstream module
    | "continue_original_session"              // resume the originating module session
    | "start_followup_from_module_context"     // new module activation with prior context
    | "route_to_source_research"
    | "route_to_format_checker"
    | "route_to_human_review"
    | "post_to_forum"
    | "continue_with_warning"
    | "ask_task_agent_for_process_patch"
  
  evidence_refs: StorageRef[]
  priority: "low" | "medium" | "high" | "blocking"
  
  schema_version: "1.0"
}
```

### §5.3 Consumer: V3.3.1 Revisor

V3.3.1 Revisor consumes `OutcomeRepairInstruction` via the `revision_in` port contract (V3.3 §9). The Revisor compiles instructions into a `RevisionPlan` typed in V3.1 schemas. Repair Instruction is the human-readable summary; the Revisor's compiled plan is the machine-actionable form.

The Revisor MAY reject a Repair Instruction (e.g., if the required changes would violate preservation constraints, or if the suggested route conflicts with the user's `AutonomousModePolicy`). Rejection produces a `HardRevisionCall` per V3.3 §7.9.

### §5.4 Consumer: Other modules

Modules other than the Revisor may receive Repair Instructions directly via wired ports. A `step.format_checker` module receiving a `OutcomeRepairInstruction` with `target_scope = "artifact"` and `suggested_route = "route_to_format_checker"` interprets the `required_changes` as input and applies formatting fixes. The module MUST emit a Feedback Consumption Receipt (§9) confirming consumption.

### §5.5 Priority semantics

- `low` — fix when convenient; doesn't block
- `medium` — fix before final output
- `high` — fix before downstream modules that depend on this output
- `blocking` — execution halts until repaired

---

## §6 Feedback Routing Policy

### §6.1 Purpose

Evaluator modules need a consistent way to declare what happens when evaluation passes, fails, needs more sources, needs verification, or repeatedly fails. The policy is declarative and lives in the evaluator's module config; the feedback router reads the policy when emitting the feedback bundle.

### §6.2 Schema

```ts
FeedbackRoutingPolicy {
  on_satisfied:
    | "continue"
    | "post_summary"
    | "score_only"
  
  on_needs_revision:
    | "emit_repair_instruction"
    | "route_to_prior_module"
    | "route_to_revision_module"
    | "post_to_forum"
    | "pause_for_human"
  
  on_needs_more_sources:
    | "emit_research_need"
    | "route_to_source_research"
    | "post_to_forum"
    | "pause_for_human"
  
  on_needs_source_verification:
    | "route_to_source_verifier"
    | "emit_repair_instruction"
    | "post_to_forum"
  
  on_needs_format_repair:
    | "route_to_format_checker"
    | "emit_repair_instruction"
    | "post_to_forum"
  
  on_repeated_failure:
    | "ask_task_agent_for_process_assessment"
    | "pause_for_human"
    | "fork_from_checkpoint"
    | "none"
  
  broadcast_policy:
    | "none"
    | "post_blockers_only"
    | "post_all_findings"
    | "post_summary_only"
  
  downstream_visibility:
    | "none"
    | "same_segment"
    | "selected_modules"
    | "all_future_modules"
  
  schema_version: "1.0"
}

FeedbackRoutingRecommendation {
  applied_policy_ref: string                   // FeedbackRoutingPolicy reference
  primary_route: string                        // chosen route per policy + decision
  routing_rationale: string
  schema_version: "1.0"
}
```

### §6.3 Policy resolution

The router evaluates the policy in order:

1. Read `EvaluationDecision.state` (one of V3.1's 14 values, or coordination V3's 4-value verdict)
2. Map to the appropriate policy branch (`on_satisfied`, `on_needs_revision`, etc.)
3. Apply the policy action
4. Set `FeedbackRoutingRecommendation.primary_route`

Multiple branches may fire (e.g., `on_needs_revision` AND `on_needs_more_sources` both apply). The router emits separate Repair Instructions / Research Needs for each branch.

### §6.4 Repeated-failure detection

`on_repeated_failure` is invoked when the same finding (matched by criterion_id + finding_kind + affected_artifact_refs) recurs N times within a run. Default threshold N = 3. The "repeated_failure" condition is computed by the run executor; the policy specifies the action.

### §6.5 Broadcast and visibility

- `broadcast_policy` governs what gets published to the Task Forum (when wired)
- `downstream_visibility` governs what becomes visible to later modules via DOC24 context packets

These are independent: a finding can be "post_blockers_only" to the forum AND "all_future_modules" via DOC24 context.

### §6.6 UI rendering

The Outcome Evaluator's config panel renders the policy as plain controls:

```
If this review passes:
  ◉ Continue   ○ Post summary only   ○ Score only

If this review fails:
  ☑ Send repair instructions to revision module
  ☐ Post blockers to Task Forum
  ☐ Pause for human review

If more sources are needed:
  ☑ Send source need to Source Research module
  ☑ Post to Task Forum

If source verification needed:
  ☑ Route to source verifier

If the same failure repeats (3+ times):
  ☑ Ask Task Agent to assess process design
  ☐ Pause for human

Broadcast to forum:
  ◉ Blockers only   ○ All findings   ○ Summary only   ○ None

Downstream visibility:
  ◉ Same segment   ○ Selected modules   ○ All future modules   ○ None
```

---

## §7 Four delivery channels

Evaluator feedback flows through four distinct channels. Each has a purpose; consumers wire whichever channels are needed.

### §7.1 Channel 1 — Control flow

The evaluator's output ports control the graph:

```
approved_out
failed_out
needs_revision_out
needs_more_sources_out
needs_source_verification_out
needs_format_repair_out
needs_human_review_out
default_out
```

**Owner:** DOC23 (port enumeration in module registry)

**Use:** Graph-level routing. Downstream modules wire to the appropriate port. The evaluator's compiled control-flow decision determines which port fires.

### §7.2 Channel 2 — Direct repair wiring

Feedback travels directly to the module that can fix it:

```
repair_instruction_out → DraftRevision.instruction_in
research_need_out      → SourceResearch.data_in
format_repair_out      → FormatChecker.data_in
feedback_bundle_out    → RevisionModule.context_in
```

**Owner:** DOC23 (port wiring); module configs declare which inputs they accept

**Use:** Repair-by-wiring. The evaluator's repair output is wired explicitly to the consuming module's input. DOC24 is NOT required for this; the data flows by ordinary graph wiring. The DOC15/CIL runtime prompt assembly renders the wired input into the receiving module's prompt context.

### §7.3 Channel 3 — Board/forum publication

Feedback becomes visible to the run via the Forum:

```
feedback_bundle_out      → TaskForum.post_in
repair_instruction_out   → TaskForum.repair_instruction_in
research_need_out        → TaskForum.research_need_in
```

**Owner:** DOC23 (port wiring); Task Forum + Run Board V1.0.1 (forum module config)

**Use:** Shared awareness. Multiple downstream consumers may read forum posts. The forum digest becomes part of the run's shared context, accessible via DOC24 when scoped.

### §7.4 Channel 4 — Process improvement signal

Feedback tells the Task Agent that the task graph itself may be insufficient:

```
process_gap_out → Task Agent assessment queue
```

**Owner:** DOC23 emits via the evaluator's `process_gap_out` port; Task Agent (Core R0.7.1 §4) consumes

**Use:** Task-design-level feedback. When the evaluator detects that the task is failing due to missing modules, missing capabilities, missing verification stages — i.e., the graph design is wrong rather than a specific module's output — it emits a `TaskProcessGapSignal` (Core R0.7.1 §9.0.3). The Task Agent collects these and surfaces suggested graph patches to the user.

### §7.5 Channel selection rule

- **Use direct wiring (Channel 2) for repair.** The fastest path; explicit and deterministic.
- **Use forum (Channel 3) for shared awareness.** When multiple modules need visibility, or when the user benefits from seeing the post stream.
- **Use Task Agent (Channel 4) for process design gaps.** When the issue isn't fixable within the current run's graph topology.
- **Use DOC24 (separately) only for scoped contextual reuse.** Not a feedback channel per se; DOC24 selects/summarizes/permissions feedback as scoped context per §8.

---

## §8 DOC23 / DOC15 / DOC24 boundary

### §8.1 Direct wired feedback (DOC23 owns)

When evaluator feedback is explicitly wired from one module to another, DOC24 is NOT required:

```
OutcomeEvaluator.repair_instruction_out → DraftRevision.instruction_in
```

DOC23 routes the payload via the standard graph mechanics. DOC15/CIL/runtime prompt assembly renders the wired input into the receiving module's prompt at execution time.

### §8.2 Scoped contextual feedback (DOC24 participates)

DOC24 participates when feedback becomes **selected contextual guidance** rather than explicit wired input. Examples:

- Current Run Guidance (active items)
- Unresolved Repair Instructions (those not yet consumed)
- Relevant board/forum digest entries
- Source Workspace warnings (e.g., "source A stale")
- Accepted user guidance
- Open ResearchNeeds (when a module's job is unclear due to open needs)
- Tool/capability context created by evaluator feedback

DOC24 reads these, selects relevant subsets, summarizes/permissions them, and renders them as scoped context for a module that didn't have explicit wired feedback input.

### §8.3 Correct phrasing

**Do not say:**

> "DOC24 injects evaluator feedback into downstream modules."

**Say:**

> "Evaluator feedback travels by ordinary DOC23 graph wiring when explicitly connected. DOC24 participates only when evaluator findings, repair instructions, forum posts, Source Workspace updates, or active Run Guidance must be selected, summarized, permissioned, and rendered as scoped contextual material for a module. Final prompt assembly remains through the existing DOC15/CIL runtime path."

This phrasing keeps the ownership clear: DOC23 owns wiring, DOC15 owns prompt assembly, DOC24 owns scoped contextual selection.

### §8.4 Future input ports (optional)

Existing ports carry feedback today:

- `instruction_in` — Repair Instructions and structured directives
- `context_in` — Feedback bundle as context
- `data_in` — Research needs as input data

For clarity, future revisions MAY add typed ports:

- `feedback_in` — typed for EvaluationFeedbackBundle
- `repair_instruction_in` — typed for OutcomeRepairInstruction
- `run_guidance_in` — typed for RunGuidanceItem
- `source_need_in` — typed for ResearchNeed

These are NOT required for V1. Existing ports work; typed ports are an ergonomics improvement.

---

## §9 Feedback Consumption Receipts

### §9.1 Purpose

The system needs to know whether feedback actually reached and improved downstream work. Consumption Receipts close the loop: the consumer confirms what was used, how it was used, and what artifact resulted.

### §9.2 Schema

```ts
FeedbackConsumptionReceipt {
  receipt_id: string
  task_id: string
  run_id: string
  
  consuming_module_id: string
  consuming_activation_seq: number
  
  // What was consumed
  feedback_bundle_ids: string[]
  finding_ids: string[]
  repair_instruction_ids: string[]
  run_guidance_ids: string[]
  
  // How it was used
  consumption_mode:
    | "used_as_instruction"
    | "used_as_context"
    | "used_as_source_query"
    | "ignored_by_policy"                      // policy excluded this feedback
    | "not_applicable"                         // didn't apply to this consumer
    | "conflicted_with_newer_guidance"         // superseded before consumption
  
  // What resulted
  produced_artifact_refs: StorageRef[]
  notes?: string
  
  // Linkage to V3.3 RevisionOperationReceipt (when consumer is the Revisor)
  revision_operation_receipt_ref?: StorageRef  // V3.3 §11.6
  
  created_at: ISO8601
  schema_version: "1.0"
}
```

### §9.3 Uses

Consumption Receipts support:

- **Audit** — reconstruct the feedback → consumption → artifact chain
- **Task Agent diagnosis** — when something fails, the agent traces back through consumption receipts to see if feedback was received
- **Repeated-failure detection** — if feedback is consumed but the same finding recurs, that's a different signal than feedback that never reached
- **DOC8/BDSM learning** — receipts contribute to learning about which feedback shapes are effective
- **Template improvement proposals** — when feedback consistently doesn't reach (or is ignored by policy), Task Agent proposes template improvements
- **Evaluator false-positive/false-negative detection** — if findings are consistently consumed and produce no improvement, the evaluator may be generating noise; if findings are consistently NOT consumed and the same failures recur, the evaluator may be missing the actual problem

### §9.4 Receipt emission discipline

Every module that consumes a feedback bundle, finding, repair instruction, or run guidance item MUST emit a consumption receipt. Modules that explicitly ignore feedback (per policy or applicability) emit a receipt with `consumption_mode = "ignored_by_policy"` or `"not_applicable"`. Silent ignoring (no receipt) fires `validation.feedback_consumed_without_receipt` at run audit time.

### §9.5 Receipt to learning signal

Consumption Receipts feed BDSM/DOC8 indirectly via the `RepairCycleSignal` (Core R0.7.1 §9.0.2). When the Revisor consumes a Repair Instruction and emits a `RevisionOperationReceipt` linking to the Repair Instruction, the receipt linkage flows into the `RepairCycleSignal.revisor_actions[].revision_operation_receipt_ref` field at cycle closure.

---

## §10 Cross-doc obligations

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

```
OBL-ADDB-FD-V1-BUNDLE-CONTRACT-01
  Owner: Addenda B Sub-addendum Feedback Delivery V1.0.1 (this doc)
  Consumer: V3.3.1 Outcome Evaluator+Revisor, Addenda A Judge (when emits bundle),
            agent review gates, downstream modules
  Description: EvaluationFeedbackBundle schema and emission discipline
  Status: specified_in_owner

OBL-ADDB-FD-V1-DEFEASIBLE-FINDINGS-01
  Owner: Addenda B Sub-addendum Feedback Delivery V1.0.1
  Consumer: V3.3.1 Outcome Compiler, V3.3.1 Revisor, Task Agent (Core R0.7.1), DOC72 Pattern
  Description: Defeasible finding lifecycle, authority basis, hard-blocker authority
              gating, supersession semantics
  Status: specified_in_owner

OBL-ADDB-FD-V1-ROUTING-POLICY-01
  Owner: Addenda B Sub-addendum Feedback Delivery V1.0.1
  Consumer: Evaluator module configs, feedback routers, DOC20 UI
  Description: FeedbackRoutingPolicy schema, resolution rules, repeated-failure
              detection threshold, UI rendering
  Status: specified_in_owner

OBL-ADDB-FD-V1-CHANNELS-01
  Owner: Addenda B Sub-addendum Feedback Delivery V1.0.1
  Consumer: DOC23 R3.1 port registry, Task Forum + Run Board V1.0.1, Task Agent,
            DOC24 context routing
  Description: Four delivery channels (control flow, direct wiring, forum, process gap)
              with port names, owners, and selection rules
  Status: specified_in_owner

OBL-ADDB-FD-V1-RECEIPTS-01
  Owner: Addenda B Sub-addendum Feedback Delivery V1.0.1
  Consumer: All feedback consumers (Revisor, format checker, source research, etc.),
            DOC8/BDSM, Task Agent
  Description: FeedbackConsumptionReceipt emission discipline; linkage to
              V3.3 RevisionOperationReceipt
  Status: specified_in_owner
```

### §10.2 Consumed obligations from other docs

- **OBL-XDOC-EVAL-ENV-01** (Common Contracts) — feedback bundle anchors to `EvaluationResultEnvelope.result_id`
- **OBL-XDOC-SCOPE-PRIMITIVES-01** (Common Contracts) — `ArtifactScopeRef` used in `EvaluatedTarget.target_scope_ref` and `OutcomeRepairInstruction.target_scope_refs`
- **OBL-XDOC-EVALUATOR-CLAIMS-IN-01** (V3.3) — Evaluator's claims_in input affects what findings reference via `affected_claim_refs`
- **OBL-XDOC-EVAL-SIGNAL-OWNERSHIP-01** (Core R0.7.1) — consumption receipts feed into RepairCycleSignal at cycle closure

### §10.3 Consuming-doc inserts

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

```
1. Add the eight evaluator output port types to the canonical port registry per §7.1:
   approved_out, failed_out, needs_revision_out, needs_more_sources_out,
   needs_source_verification_out, needs_format_repair_out, needs_human_review_out,
   default_out.

2. Add direct-repair port types per §7.2:
   repair_instruction_out, research_need_out, format_repair_out, feedback_bundle_out.

3. Add process_gap_out port type per §7.4.

4. Cross-reference OBL-ADDB-FD-V1-CHANNELS-01 in DOC23's OP-A list.
```

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

```
1. CIL/runtime prompt assembly reads wired feedback input (instruction_in,
   context_in, data_in, and future feedback_in / repair_instruction_in /
   run_guidance_in / source_need_in) and renders it into the receiving
   module's prompt at execution time.

2. CIL filters Run Guidance by lifecycle state — only "active", "user_approved",
   and "tool_verified" guidance items are rendered. Superseded, expired,
   and contested items are excluded unless explicitly requested for audit.

3. Cross-reference Feedback Delivery V1.0.1 §8 boundary statement in DOC15's OP-A list.
```

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

```
1. DOC24 context packet assembly may include feedback-derived material when
   the consuming module didn't have explicit wired feedback input:
   - Active RunGuidanceItems matching the module's scope
   - Unresolved OutcomeRepairInstructions with target_scope matching module
   - Forum digest (when forum wired) filtered to recent + relevant
   - Source Workspace warnings (e.g., stale sources) when module reads sources
   - Accepted user guidance for the current run/segment

2. DOC24 selection respects lifecycle state — same filter as DOC15 (§above).

3. DOC24 permissioning respects matter/privilege firewall.

4. Cross-reference Feedback Delivery V1.0.1 §8 boundary statement in DOC24's OP-A list.
```

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

```
1. Render FeedbackRoutingPolicy as plain controls per §6.6 layout.

2. Render EvaluationFinding lifecycle in UI: badges for "proposed",
   "accepted", "user_approved", "tool_verified", "contested", "superseded",
   "expired". User-approval action available on "proposed" findings; contest
   action available on any finding except "superseded"/"expired".

3. Render RunGuidanceItem stream in run inspector. Allow user to confirm,
   contest, scope-edit, or expire individual items.

4. Render FeedbackConsumptionReceipt chain in audit view — show the path
   from finding → repair instruction → consumer → produced artifact.

5. Cross-reference Feedback Delivery V1.0.1 §10.1 OP-A rows in DOC20's OP-A list.
```

### §10.4 Coding-agent instructions

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

When implementing Feedback Delivery 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 FEEDBACK DELIVERY V1

**Document:** DOC23 Addenda B Sub-addendum — Feedback Delivery V1.0.1
**Status:** Build-ready
**Date:** 2026-05-17
**Total sections:** 10
**Total OP-A rows owned:** 5
**Total cross-doc inserts:** 4 (DOC23 R3.1, DOC15, 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, Task Forum + Run Board V1.0.1

---