docs/AlarmTracking.md

@@ -456,9 +456,15 @@ from the scripted `AlarmCommandRouter`:
    carrying the authored `FullName` as the `ConditionId` and the
    authenticated `OperatorUser`. The driver forwards this to the Galaxy
    gateway → AVEVA via `GatewayGalaxyAlarmAcknowledger`.
-   **Fire-and-forget** — a failed upstream ack is not surfaced back to the
+   The Galaxy adapter awaits the correlated `AcknowledgeAlarmAsync` RPC:
-   OPC UA client (mirrors the Galaxy write-outcome limitation; the local
+   gateway protocol failures throw, while a non-zero native return code is
-   `AlarmConditionState` SDK update already committed at step 1).
+   warning-logged. **The actor route back to OPC UA is fire-and-forget** —
+   `DriverInstanceActor` logs and drops failures without replying to the
+   OPC UA client, whose local `AlarmConditionState` SDK update already
+   committed at step 1. This is a native-ack routing limitation; Galaxy
+   value writes have a separate correlated write-outcome path. An awaited
+   ack RPC does not prove the ack reached AVEVA event history: the H6 live
+   verification remains [operator-gated](plans/2026-06-15-stillpending-phase-3-opcua-standards-design.md).
 
 Only the **Acknowledge** is routed to the driver. **A native condition
 supports Acknowledge and AddComment only** (Gitea #587 review): `Confirm`,

docs/ScriptedAlarms.md

@@ -325,8 +325,10 @@ routes through a separate `NativeAlarmAckRouter` seam (instead of the scripted
 FullName)` inverse map, Primary-gated) → the owning driver's
 `IAlarmSource.AcknowledgeAsync` → Galaxy gateway → AVEVA. The call carries the
 authenticated operator's display name via the `AlarmAcknowledgeRequest.OperatorUser`
-field. This is fire-and-forget — a failed upstream ack is not surfaced back to the
+field. The actor route back to OPC UA is fire-and-forget — a failed upstream ack
-OPC UA client (mirrors the Galaxy write-outcome limitation). See [AlarmTracking.md
+is logged rather than surfaced back to the OPC UA client. The Galaxy adapter
+awaits its correlated RPC; this does not establish delivery to AVEVA event history.
+Galaxy value writes use a separate correlated write-outcome path. See [AlarmTracking.md
 §Native alarm acknowledge → AVEVA](AlarmTracking.md#native-alarm-acknowledge--aveva)
 for the full routing diagram.
 

docs/plans/2026-06-15-stillpending-phase-3-opcua-standards-design.md

@@ -120,7 +120,9 @@ OPC UA client Acknowledge on a NATIVE condition
   under Lock, like `AlarmCommandRouter`).
 - **Driver faulted / reconnecting** → `AcknowledgeAsync` fails or no-ops per the driver; the local condition
   state still reflects the SDK-applied ack (the OPC UA client sees Good). Surfacing a *failed* upstream ack
-  back to the client is out of scope (mirrors the Galaxy write-outcome fire-and-forget limitation).
+  back to the client is out of scope for this native-ack actor route. **Current clarification
+  (2026-10-13):** the Galaxy adapter awaits a correlated ack RPC, but the actor route does not
+  return its outcome to OPC UA; Galaxy value writes have a separate correlated write-outcome path.
 - **H4 native Enable/Disable** → `BadNotSupported` (decision #2).
 - **H2-bit:** no runtime behavior change for existing grants except closing the HistoryRead⇒HistoryUpdate
   authorization hole; the service itself stays rejected.