From aa1e21f53c379b8945946251856512439c32e6b2 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Mon, 15 Jun 2026 05:15:50 -0400 Subject: [PATCH] docs(historian): clarify modified-value history is infra-gated (no backend modified-read path) --- docs/Historian.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/Historian.md b/docs/Historian.md index 71072c65..74f01acf 100644 --- a/docs/Historian.md +++ b/docs/Historian.md @@ -163,7 +163,12 @@ data. read and there is no "full page ⇒ maybe more" signal to page on. Returning the full result with no continuation point is spec-conformant. - **No modified-value history** (`HistoryReadModified`). Requests for modified values return - `BadHistoryOperationUnsupported`. This is a follow-up. + `BadHistoryOperationUnsupported`. This is **infra-gated, not a server-code gap**: the AVEVA + Wonderware historian backend (`IHistorianDataSource`, the TCP sidecar client) exposes only a + current-value read path — there is no modified/edited-history surface to source the data from. The + server-side override is in place (it cleanly rejects modified reads per node) and `IsReadModified` + is honoured; serving real modified-value history is unblocked only once the historian client/sidecar + grows a modified-read RPC. Until then, rejecting is the correct, spec-conformant behaviour. ### Redundancy and authorization