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/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/`