Close corrections-doc E2 (Aveva System Platform IO upstream-OPC-UA pattern verification) with GREEN-YELLOW verdict (decision #141) — AVEVA's OI Gateway communication driver is the documented path for AppServer to consume from arbitrary upstream OPC UA servers; 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 → SuiteLink → $DDESuiteLinkDIObject → AppServer attribute. Recommended AppServer floor: System Platform 2023 R2 Patch 01.

OtOpcUa-side requirements all met or trivially met by v2: Basic256Sha256 + SignAndEncrypt + username token (transport security covers this), reject-and-trust cert workflow, endpoint URL must NOT include /discovery suffix (forum-documented failure mode), hostname-stable certs (decision #86 already enforces this since clients pin trust to ApplicationUri), OI Gateway service must NOT run under SYSTEM (deployment-guide concern). Two integrator-burden risks tracked: validation/GxP paperwork (no AVEVA blueprint exists for non-AVEVA upstream servers in Part 11 deployments — engage QA/regulatory in Year 1) and unpublished scale benchmarks (in-house benchmark required in Year 2 before cutover scheduling).

Phase 1 acceptance gains Task E.10 (decision #142): end-to-end AppServer-via-OI-Gateway smoke test against a Phase 1 OtOpcUa instance, catching AppServer-specific quirks (cert exchange, endpoint URL handling, service account, security mode combo) well before the Year 3 tier-3 cutover schedule. Non-blocking for Phase 1 exit if it surfaces only documentation-level fixes; blocking if it surfaces architectural incompatibility.

New file `docs/v2/aveva-system-platform-io-research.md` captures the full research with all source citations (AVEVA docs, Communications Drivers Pack readmes, Software Toolbox / InSource partner walkthroughs, Inductive Automation forum failure-mode reports). Plan.md decision log gains #141 and #142; Reference Documents section links the new doc.

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

docs/v2/implementation/phase-1-configuration-and-admin-scaffold.md

@@ -444,6 +444,32 @@ Per `admin-ui.md` §"Release an external-ID reservation" and §"Merge or rebind
 - After release: same `(Kind, Value)` can be reserved by a different EquipmentUuid in a future publish
 - Merge equipment A → B: draft preview shows tag re-pointing + ID re-reservation; publish executes atomically; A is disabled with `EquipmentMergedAway` audit entry
 
+#### Task E.10 — AppServer-via-OI-Gateway end-to-end smoke test (decision #142)
+
+Per `aveva-system-platform-io-research.md`, the tier-3 (Year 3) cutover redirects AVEVA System Platform's IO layer from direct-equipment connections to consuming OtOpcUa via OI Gateway. Catching AppServer-specific quirks at Phase 1 — well before the cutover schedule — protects the Year 3 timeline and ensures OtOpcUa's transport security model is actually compatible with the most opinionated downstream consumer.
+
+Stand up a non-production AppServer + OtOpcUa pairing and verify:
+
+1. AppServer (System Platform 2023 R2 Patch 01 or later) installed with the matching Communications Drivers Pack
+2. OI Gateway service runs under a dedicated service account (NOT SYSTEM — known issue per AVEVA 2020 R2 readme)
+3. OtOpcUa endpoint exposed as `opc.tcp://{host}:{port}` with **no `/discovery` suffix** (forum-documented failure mode that produces `Bad_SecurityChecksFailed` even after cert trust)
+4. Configure an OPCUA Connection in OI Gateway pointing at OtOpcUa with `Basic256Sha256` + `SignAndEncrypt` + LDAP-username token
+5. OI Gateway client cert appears in OtOpcUa's pending-certs folder; admin moves it to Trusted; OtOpcUa server cert trusted on OI Gateway side
+6. Configure an OPCUAGroup with at least one tag from a published OtOpcUa generation
+7. Configure a SuiteLink DI Object in AppServer pointing at the OI Gateway instance
+8. Create an AppServer attribute with `IO.SourceAttribute = <SuiteLinkDIObjectName>.<TopicName>.<ItemReference>`
+9. Verify the attribute reads end-to-end with quality `0x00C0` (good)
+10. Re-verify after a publish-generation cycle in OtOpcUa (the AppServer attribute must continue reading without manual re-trust)
+11. Capture the full configuration as `docs/deployment/aveva-system-platform-integration.md` for the future tier-3 cutover team
+
+**Acceptance**:
+- All 10 connection steps succeed; AppServer reads at least one tag end-to-end with good quality
+- Reconnect after OtOpcUa publish: no manual intervention required
+- Documentation captured for the cutover team
+- Any failure mode that surfaces during the test is either: (a) fixed in OtOpcUa Phase 1, (b) added to Phase 1 known-limitations + escalated to corrections doc, or (c) confirmed as an AppServer / OI Gateway quirk operators must accept
+
+This is **non-blocking** for Phase 1 exit if the test surfaces only documentation-level fixes. It IS blocking if it surfaces an OtOpcUa-side incompatibility that requires architectural change — that would be a tier-3 cutover risk and should escalate immediately.
+
 #### Task E.9 — ACLs tab + bulk-grant + permission simulator
 
 Per `admin-ui.md` Cluster Detail tab #8 ("ACLs") and `acl-design.md` §"Admin UI":