Elnor Repo Reader

# Stage 5R3 Pass 2 — BUCKET C (architect-judgment decisions)

**Generated:** 2026-05-28 · Pass 2 mechanical retarget of OP-A V3.18 §6 against the DOC80 family.
**Confidence:** these are the rows Pass 2 **cannot** resolve mechanically — each is a genuine schema-ownership call that needs Will's sign-off. They are **not** retargeted in `OPA_V4_CANDIDATE.md`; they are held as RESERVED placeholders (current V3.18 target retained + `pending_architect_review` flag) until the ADQ is answered.

**Count:** 2 rows (well under the ≤10 cap the commission set). Every other split/ambiguous row resolved into Bucket A or Bucket B without a new architecture decision.

**Why only 2:** the commission flagged "likely-splits ≈ 342" as a keyword overcount. In practice almost all of those rows either stay at their section owner or peel cleanly onto one DOC80 member along a Pass-1-resolved boundary. Only these two hedge their **schema home** in the source text itself, which is the one thing Pass 2 is forbidden to decide.

## Field key
`opa_row_id` · `current_target_doc` · `candidate_targets` · `recommended_default` · `why_architect_judgment_needed` · `blocks_what` · `proposed_ADQ`

---

### 1. `OBL-D72-NEW-PBE-CLUSTER-01`
*(OP-A line 2437 — "PBEClusterDetectionResult schema as superset of PBEClusterDetectionResultMinimum, OR DOC73-side adapter")*

| field | value |
|---|---|
| **current_target_doc** | DOC72 |
| **candidate_targets** | **DOC72** \| DOC73 |
| **recommended_default** | **DOC72** (graph-store owns the read-model superset) |
| **why_architect_judgment_needed** | The source row **hedges its own schema home**: it proposes `PBEClusterDetectionResult` either as a *superset* schema (which would live in DOC72, the graph store) **or** as a DOC73-side *minimum* adapter. Superset-in-DOC72 vs minimum-in-DOC73 is a one-owner (B3) schema-ownership call that Pass 2 must not invent. Whichever doc owns the canonical shape, the other consumes a projection of it. |
| **blocks_what** | E3 (DOC82 knowledge) consumption of the cluster-detection read-model **and** the DOC72 graph-schema freeze. DOC82 cannot bind to the cluster result until its owner + shape are fixed. |
| **proposed_ADQ** | **ADQ-PASS2-01** — "Does `PBEClusterDetectionResult` live in DOC72 as the superset read-model (DOC73 consumes a minimum projection), or in DOC73 as the owner (DOC72 stores a denormalized copy)?" Recommend DOC72-superset unless DOC73 needs write-authority over cluster membership. |

---

### 2. `OBL-D24-CORPUS-LIB-MAP-01`
*(OP-A line 3426 — corpus / `knowledge_corpus` / "library" terminology + identity reconciliation, DOC24 R3.1 gate)*

| field | value |
|---|---|
| **current_target_doc** | DOC24 |
| **candidate_targets** | **DOC24** \| DOC87 \| DOC25 |
| **recommended_default** | **DOC24** (R3.1 gate row originates here) |
| **why_architect_judgment_needed** | Corpus / `corpus_id` / user-facing "library" terminology + **identity reconciliation** spans DOC24 (search), DOC25 (ingestion), and DOC72/DOC73 (graph/corpus) — and post-flatten, DOC87 (E_org membership identity). Choosing the **identity-authority owner** for the corpus↔library mapping is architectural, not mechanical. The row is also flagged as a **dup-pair vs `OBL-D7-NEW-LIBRARY-NAMING-01`** (different source_doc, different current target), so the decision must also resolve whether these are one obligation or two. Ties to **SM-040** + **OPA-032 TopicIdentityContract**. |
| **blocks_what** | E1 (DOC81 scope) corpus/library identity **vocabulary**, and E_org (DOC87) **membership identity**. Both downstream charters need a single authoritative owner for the corpus-identity term before they can define their own surfaces. |
| **proposed_ADQ** | **ADQ-PASS2-02** — "Who owns the canonical corpus↔'library' identity mapping: DOC24 (search/onboarding), DOC87 (E_org membership identity), or DOC25 (ingestion)? And is `OBL-D24-CORPUS-LIB-MAP-01` the same obligation as `OBL-D7-NEW-LIBRARY-NAMING-01` (merge) or distinct (keep both)?" Recommend DOC87 as identity authority **if** the term is primarily a membership/organization concept; otherwise DOC24. |

---

## Handling in OPA_V4_CANDIDATE.md
Both rows are carried in the V4 deck as **RESERVED placeholders**:
- `proposed_target_doc` = current V3.18 target (DOC72 / DOC24 respectively) — i.e. **unchanged** until the ADQ resolves.
- flagged `pending_architect_review: true` with a pointer to this file.
- **not** counted among the 113 family-moves and **not** treated as discharged.

These two ADQs (ADQ-PASS2-01, ADQ-PASS2-02) are **new** and must be added to the Conflict Register / ADQ log by Will — Pass 2 does not write to that external file (HARD CONSTRAINT §5.5). They are surfaced in `PASS_2_WILL_REVIEW_PACKET.md` under "WHAT YOU MUST DECIDE."