Document validation architecture and renderer faithfulness findings

- document Entity Registry and Meeting Context V2 architecture
- preserve meeting_context.yaml as the authoritative meeting-specific input
- define immutable authoritative metadata across all pipeline stages
- restrict Constraint Repair to deterministic structured-data operations
- record BUG-003 root cause and deferred entity-verification resolution
- document BUG-005 attendance-consistency design
- add BUG-006 renderer faithfulness root-cause analysis
- distinguish Engineering Readiness from Practical Usability
- update the persistent regression bug tracker

docs/architecture.md

@@ -99,6 +99,8 @@ The analyzer gradually transforms an unstructured discussion into structured kno
 
 # High-Level Pipeline
 
+Current implemented and intended analysis flow:
+
 ```text
 Transcript
     ↓
@@ -123,6 +125,24 @@ Output View Rendering
 Working Protocol / Distribution Protocol / Knowledge Objects
 ```
 
+Accepted future Meeting Context V2 preparation flow:
+
+```text
+Whisper
+    ↓
+Entity Detection
+    ↓
+User Confirmation
+    ↓
+Entity Registry Update
+    ↓
+Meeting Context Builder
+    ↓
+meeting_context.yaml
+    ↓
+Extraction Pipeline
+```
+
 Each stage solves one clearly defined problem.
 
 No module should perform multiple semantic tasks simultaneously.
@@ -204,6 +224,32 @@ The context can help prevent non-participants from being interpreted as
 attendees and can normalize known aliases for extraction. It must not infer
 roles, departments, responsibilities or decisions.
 
+Accepted future direction:
+
+Meeting Context V2 should be generated or assisted from an interactive entity
+confirmation workflow and a persistent Entity Registry. The Entity Registry is
+the persistent cross-meeting knowledge source for confirmed people,
+organizations, departments, products, projects, locations, aliases and
+organizational metadata under stable internal IDs. Display names may change,
+but internal IDs remain stable. Aliases are first-class data.
+
+The registry never learns automatically. It may propose matches and aliases,
+including spelling variants, Whisper transcription variants, umlaut variants
+and OCR-like mistakes, but only explicit user confirmation updates registry
+state. Unknown names should be presented to the user as meeting participant,
+mentioned person, external person, transcription error or ignore.
+
+In this architecture, `meeting_context.yaml` remains the authoritative
+meeting-specific Point of Truth and reproducible input artifact consumed by the
+extraction pipeline. It is a meeting-specific snapshot built from the Entity
+Registry, user confirmations and meeting metadata. The Registry must not
+override explicit meeting-specific confirmations, and Registry changes after a
+meeting run must not silently change the historical Meeting Context used for
+that run.
+
+Status: Accepted Architecture; implementation deferred. See
+`docs/adr-meeting-context-v2-entity-registry.md`.
+
 ---
 
 ## consolidation/