Mark corrections-doc E2 (Aveva System Platform IO pattern verification) as RESOLVED with GREEN-YELLOW verdict — the OtOpcUa team completed the research, published findings at lmxopcua/docs/v2/aveva-system-platform-io-research.md, and added a Phase 1 acceptance test (Task E.10, decision #142) to catch AppServer-specific quirks well before the Year 3 tier-3 cutover schedule. AVEVA's OI Gateway is the documented path; multiple non-AVEVA upstream-server integrations exist in published partner walkthroughs; no re-architecting of OtOpcUa needed. Two integrator-burden risks the plan team should track: validation/GxP paperwork (no AVEVA Part 11 blueprint for non-AVEVA upstream servers — engage QA/regulatory in Year 1) and unpublished scale benchmarks (in-house benchmark required in Year 2 before tier-3 cutover scheduling).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

handoffs/otopcua-corrections-2026-04-17.md

@@ -351,11 +351,31 @@ Questions the plan didn't think to ask but should have, surfaced during v2 desig
 
 ---
 
-### E2. Tier 3 (System Platform IO) cutover — Aveva-supported pattern verification
+### E2. Tier 3 (System Platform IO) cutover — Aveva-supported pattern verification — **RESOLVED (GREEN-YELLOW)**
 
 **Question:** Does Aveva System Platform IO support consuming equipment data from another OPC UA server (OtOpcUa) instead of from equipment directly? The handoff §"Downstream Consumer Impact" says this "needs validation against Aveva's supported patterns — System Platform is the most opinionated consumer."
 
-**Recommendation:** plan should commit to a research deliverable in Year 1 or Year 2 (well ahead of Year 3 tier 3 cutover): "Validate with Aveva that System Platform IO drivers support upstream OPC UA-server data sources, including any restrictions on security mode, namespace structure, or session model." If Aveva's pattern requires something OtOpcUa doesn't expose, that's a long-lead-time discovery.
+**Resolution** (lmxopcua decision #141, 2026-04-17): **YES — supported pattern.** AVEVA's OI Gateway communication driver is an OPC UA client that bridges arbitrary upstream OPC UA servers into AppServer via SuiteLink + DI Object. Multiple AVEVA partners (Software Toolbox, InSource) have published end-to-end integrations against four different non-AVEVA upstream servers (TOP Server, OPC Router, OmniServer, Cogent DataHub). No re-architecting of OtOpcUa required.
+
+**Path**: `OPC UA node → OI Gateway (OPC UA client) → SuiteLink → $DDESuiteLinkDIObject → AppServer attribute (IO.SourceAttribute = <SuiteLinkDIObjectName>.<TopicName>.<ItemReference>)`.
+
+**Recommended AppServer floor**: System Platform 2023 R2 Patch 01 (best OPC UA client maturity, script-level method calls, External Providers UI in Tag Dictionary).
+
+**Documented OtOpcUa-side requirements** (already met or trivially met by v2):
+- `Basic256Sha256` security policy + `SignAndEncrypt` message mode (OtOpcUa Phase 1 transport security covers this)
+- Username/password user token over encrypted channel (LDAP-bound per `Security.md`, no change needed)
+- Reject-and-trust certificate workflow on OtOpcUa side (standard OPC UA, no change needed)
+- Endpoint URL of form `opc.tcp://{host}:{port}` — must NOT include a `/discovery` suffix (forum-documented failure mode)
+- Hostname-stable certificates (per OtOpcUa decision #86 — `ApplicationUri` is auto-suggested but never auto-rewritten because clients pin trust to it; this case is exactly that)
+- OI Gateway service must NOT run under SYSTEM (known AVEVA issue) — deployment-guide concern, not OtOpcUa-side
+
+**Two integrator-burden risks** the plan team should track:
+1. **Validation/GxP paperwork**: AVEVA has no published blueprint for Part 11 deployments where a non-AVEVA OPC UA server sits between equipment and AppServer. Budget IQ/OQ work for OtOpcUa itself + change-control impact assessment against the existing validated AppServer deployment. Engage QA / regulatory **early in Year 1** so paperwork doesn't gate the Year 3 cutover.
+2. **Scale benchmarks**: AVEVA does not publish per-topic item limits or throughput numbers for OI Gateway's OPC UA client. **Stand up a non-production AppServer + OtOpcUa pairing in Year 2** to benchmark at target item count + publishing interval + `SignAndEncrypt` security mode before tier 3 cutover scheduling.
+
+**Phase 1 acceptance test added** (lmxopcua decision #142, Task E.10 in `phase-1-configuration-and-admin-scaffold.md`): end-to-end AppServer-via-OI-Gateway smoke test against a Phase 1 OtOpcUa instance. Catches the AppServer-specific quirks (cert exchange, endpoint URL, service account, security mode combo) at Phase 1, well before Year 3 cutover. Non-blocking for Phase 1 exit if it surfaces only documentation-level fixes; blocking if it surfaces architectural incompatibility.
+
+Full research write-up: `lmxopcua/docs/v2/aveva-system-platform-io-research.md`.
 
 ---
 
@@ -437,7 +457,7 @@ Neither of these affects the handoff or this corrections doc directly.
 | B. Missing constraints | 3 | ACLs, schemas-repo dependencies, certificate trust pre-cutover |
 | C. Architectural decisions to revisit | 6 | Driver list pre-survey, stability tiers, Polly resilience, multi-identifier model (now refined per addendum), missing cutover plan, per-building cluster interactions |
 | D. Resolved TBDs | 4 | Pilot class, schemas repo format, ACL location, **D4 enterprise shortname = `zb` RESOLVED 2026-04-17** |
-| E. New TBDs | 4 | UUID-gen authority, Aveva validation, multi-cluster site addressing, cluster-endpoint mental model |
+| E. New TBDs | 4 | UUID-gen authority, **E2 Aveva validation = GREEN-YELLOW RESOLVED 2026-04-17**, multi-cluster site addressing, cluster-endpoint mental model |
 | **Addendum hardening fixes** | **4** | EquipmentId system-generated; ExternalIdReservation table; same-cluster namespace binding; Namespace generation-versioned |
 
 The hardening fixes are committed in `lmxopcua` branch `v2` at commit `a59ad2e` (2026-04-17). Decisions #122–125 in `lmxopcua/docs/v2/plan.md` carry the rationale.
@@ -466,7 +486,7 @@ After the plan team integrated the original 19 corrections + 4 hardening fixes,
 | B. Missing constraints | 3 | B1 ACLs **CLOSED** (#129–132); B2 schemas-repo **PARTIALLY CLOSED** (seed contributed; owner-team + dedicated-repo TBD); B3 cert-distribution remains operational concern |
 | C. Architectural decisions to revisit | 6 | C1 driver list **CLOSED** (#128); C5 cutover scope **CLOSED** (#136 — out of v2 scope); others still flagged |
 | D. Resolved TBDs | 4 | Pilot class, schemas repo format, ACL location, **D4 enterprise shortname = `zb` RESOLVED 2026-04-17** |
-| E. New TBDs | 4 | UUID-gen authority, Aveva validation, multi-cluster site addressing, cluster-endpoint mental model |
+| E. New TBDs | 4 | UUID-gen authority, **E2 Aveva validation = GREEN-YELLOW RESOLVED 2026-04-17**, multi-cluster site addressing, cluster-endpoint mental model |
 | **Addendum hardening fixes** | **4** | EquipmentId system-generated; ExternalIdReservation table; same-cluster namespace binding; Namespace generation-versioned |
 | **Round 3 additions** | **4** | ACL design (#129–132); dev-environment two-tier (#133–137); cutover scope removal (#136); `_base` template + OPC 40010 columns (#138–139) |