Enforce explicit responsibility attribution

- document responsibility attribution as a project-wide invariant
- prevent inferred ownership in protocol rendering
- add negative gold regression for false responsibility assignment
- document future responsibility evidence and attribution model
- record the real-life benchmark finding

docs/architecture.md

@@ -47,6 +47,20 @@ Every processing step should be understandable.
 
 Intermediate results should remain inspectable throughout the pipeline.
 
+## Responsibility Attribution Integrity
+
+Responsibility, ownership, organizational roles and action-item assignments may
+be recorded only when meeting evidence explicitly assigns, accepts or confirms
+them.
+
+The system must not infer responsibility from thematic proximity,
+participation in a discussion, mentioning a task, commenting on another
+department, organizational assumptions, likely job roles, speaker adjacency or
+model world knowledge.
+
+When evidence is incomplete or ambiguous, the responsible person remains unset
+or unclear and the supporting evidence is preserved.
+
 ## Reproducible Experiments
 
 Experiments must be repeatable.

docs/data-models.md

@@ -272,6 +272,27 @@ Each item contains at least:
 Action items also preserve deterministic fields such as `responsible` and
 `deadline` when present.
 
+Responsibility attribution is stricter than mention or participation. A
+`responsible` value may be kept only when source evidence explicitly assigns,
+accepts or confirms responsibility. If evidence is incomplete, ambiguous or
+only based on a suggestion, objection, topic expertise or department mention,
+the field remains `null` or unset and the evidence is preserved.
+
+Do not collapse these concepts into one field:
+
+- `speaker`: person who uttered the evidence.
+- `mentioned_person`: person named in the evidence.
+- `participant`: person present in the meeting.
+- `responsible_person`: person explicitly assigned to or accepting an action.
+- `department`: organizational unit discussed or represented.
+- `owner`: durable ownership of a process, system or knowledge object.
+- `assignee`: operational person or team assigned to a concrete task.
+
+Future compatible fields may include:
+
+- `responsibility_status`: `explicit`, `accepted`, `proposed` or `unclear`.
+- `attribution_evidence`: source evidence supporting the assignment status.
+
 Example:
 
 ```json

docs/experiments.md

@@ -1169,3 +1169,65 @@ Evidence:
 - `samples/benchmarks/semantic_consolidator_v0/report.md`
 - `samples/benchmarks/semantic_consolidator_v0/consolidated_extractions.json`
 - Local diagnostic only: `samples/benchmarks/semantic_consolidator_v0/raw_model_response.txt`
+
+## EXP-0023 - Responsibility attribution integrity
+
+Status: Running
+
+Date or period: 2026-07-31
+
+Hypothesis:
+
+Protocol generation is operationally unsafe if responsibility, ownership or
+departmental role attribution is inferred from discussion context rather than
+explicit meeting evidence.
+
+Setup:
+
+The real-life Working Protocol Renderer V2 benchmark was inspected against the
+consolidated input. A false assignment connected a Marketing participant to
+Business Development criteria work even though the participant's contribution
+was critical or reluctant and did not establish acceptance of that task.
+
+Inputs:
+
+- `samples/benchmarks/working_protocol_renderer_v2/working_protocol.md`
+- `samples/benchmarks/semantic_consolidator_v0/consolidated_extractions.json`
+- `samples/benchmarks/canonicalizer_v1/canonicalized_extractions.json`
+
+Model / configuration:
+
+- Not rerun for this finding.
+- Finding is based on existing benchmark artifacts.
+
+Result:
+
+The false responsibility attribution is visible in the structured input before
+rendering, so the issue is not merely stylistic renderer wording. The root
+cause may originate earlier in extraction and then be preserved by
+canonicalization and consolidation. Renderer guardrails are still required so
+output views do not strengthen ambiguous ownership.
+
+Decision:
+
+Responsibility attribution is now treated as a critical project-wide
+invariant. A person, team or department may be recorded as responsible only
+when the evidence explicitly assigns, accepts or confirms that responsibility.
+Discussion, expertise, objection, suggestion, thematic proximity, speaker
+adjacency, organizational assumptions and likely job roles do not establish
+ownership.
+
+Lessons learned:
+
+This class of error affects operational correctness, not only style. The
+pipeline needs traceable attribution evidence and future schema support for
+responsibility status such as explicit, accepted, proposed or unclear.
+
+Evidence:
+
+- `AGENTS.md`
+- `PROJECT_KNOWLEDGE.md`
+- `docs/data-models.md`
+- `docs/output-views.md`
+- `prompts/working_protocol.md`
+- `tests/gold/responsibility_attribution_negative/`

docs/output-views.md

@@ -78,6 +78,13 @@ Rendered protocol language should normally match the dominant language of the
 source transcript or consolidated meeting knowledge unless an explicit output
 language is requested.
 
+Responsibility attribution is a cross-cutting invariant for every Output View.
+A renderer may name a person, team or department as responsible only when the
+input explicitly contains that assignment or acceptance. Discussion,
+expertise, objection, suggestion, speaker adjacency, organizational
+assumptions and department mentions do not establish ownership. If
+responsibility is unclear, render it as open rather than guessing.
+
 ## Working Protocol
 
 Suggested filename: `working_protocol.md`

docs/pipeline.md

@@ -10,6 +10,22 @@ The guiding principle is simple:
 
 > **Each processing stage has exactly one responsibility.**
 
+Cross-cutting invariant:
+
+> **Responsibility attribution requires explicit evidence.**
+
+A person, team or department may be recorded as responsible only when the
+source material explicitly assigns, accepts or confirms that responsibility.
+The pipeline must not infer ownership from thematic proximity, discussion
+participation, mentioning a task, commenting on another department,
+organizational assumptions, likely job roles, speaker adjacency or model world
+knowledge.
+
+When support is incomplete or ambiguous, leave the responsible person unset,
+mark the item as unclear where supported, and preserve the attribution
+evidence. This applies to extraction, canonicalization, semantic consolidation,
+Canonical Meeting Knowledge and every Output View renderer.
+
 ---
 
 # Pipeline Overview