Skip to content

ADR 0011: The BPCS/SIS boundary is a documentation and PHA-time concern, not an operator-HMI banner

Status: Accepted Date: 2026-06-16 Issue: #596 Related: ADR 0002, ADR 0007, ADR 0010 (these established the BPCS/SIS boundary; this ADR moves where it is stated, not whether it holds)

Context

The Alarm Response view in the gateway HMI rendered a persistent banner on every load — for every site, in every alarm render — reading "BPCS, not SIS. … not rated for SIL 1/2/3/4 … must be implemented in a separate, hardwired safety system downstream." It was added in the #344 interlock formalization work and styled as an advisory note above the alarm list.

Three problems converged on it:

  1. It states the wrong thing in the wrong layer. Cloud-Native DCS is a Basic Process Control System; that it is not a Safety Instrumented System is the industry baseline for any DCS, not a property worth re-announcing to an operator on every screen. The architectural boundary belongs in the engineering and compliance documentation an integrator reads at design time, not in the operator's live annunciation surface at run time.

  2. It pre-empts a risk-assessment decision that is not the product's to make. Under IEC 61511 a BPCS interlock or alarm can be credited as an independent protection layer (Clause 9.2 does not require risk reduction to come from an SIS); whether a given hazard also requires an independent SIS is the outcome of the operator's process hazard analysis / LOPA, decided per process. The banner's blanket "must be implemented in a separate, hardwired safety system" asserts a conclusion the product cannot reach on the operator's behalf, and reads as alarmist where the operator's PHA has legitimately credited CNDCS interlocks as a protection layer.

  3. It is a positioning conflict. The banner ships on buyer-facing surfaces (the alarm screenshot baked into marketing's compliance page) and blocks a clean fermentation-alarm render (cndcs-marketing#39). Marketing's stance is that the affirmative claim — interlocks and alarm actions are real, verified BPCS protection — is what we make, not a recurring self-deprecating disclaimer.

The BPCS/SIS boundary itself is sound and stays. ADR 0002, ADR 0007, and ADR 0010 each rest on it. What is in question is the vehicle: a persistent operator-HMI banner versus documentation an integrator consults at design time.

Decision

Remove the BPCS/SIS disclaimer banner from the Alarm Response operator HMI (and the .bpcs-disclaimer styling that backed it). The BPCS/SIS boundary is asserted where it is actionable — in the engineering and compliance documentation that an integrator reads when assigning protection layers — not on the operator's run-time annunciation surface.

The boundary is unchanged: CNDCS interlocks and alarms are BPCS-layer functions. The documentation reframes from a blanket "must add a separate SIS" disclaimer toward the accurate statement that CNDCS interlocks/alarms can be credited as protection layers and whether an independent SIS is also required is a per-process PHA/LOPA decision. That documentation reframe is tracked as a follow-up to this ADR and is out of scope for the banner-removal change itself.

Alternatives Considered

  • Keep the banner, add a screenshot-only suppression mode (the resolution cndcs-marketing#39 originally requested). Rejected: it treats a product-correctness problem as a rendering problem. If the banner is wrong to show buyers, it is wrong to show operators; a render-mode flag would leave the questionable element live and add a maintenance surface to hide it.
  • Move the banner into a dismissible tooltip / compliance tab. Rejected: softer placement does not fix that the content pre-empts the operator's PHA decision. The boundary is a design-time concern; relocating it within the run-time HMI keeps it in the wrong layer.
  • Strip the BPCS/SIS framing everywhere, including engineering docs. Rejected: the boundary is real and useful to an integrator doing protection- layer analysis. The fix is to state it accurately in documentation, not to erase it.

Consequences

  • Code/UI: internal/gateway/static/js/views/alarms.js no longer emits the banner; the orphaned .bpcs-disclaimer rules are removed from internal/gateway/static/css/components.css. No CRD, API, or behavior change — alarms, phase guards, and interlocks are unaffected.
  • Compliance: the BPCS/SIS boundary is unchanged and still recorded in ADR 0002 / 0007 / 0010 and in docs/compliance/isa88.md, docs/library/alarms-and-interlocks.md, and docs/architecture.md. Those documents' framing is reframed under a follow-up (creditable BPCS protection layer; independent-SIS is a PHA/LOPA decision); this ADR does not alter their decision content.
  • Marketing: unblocks cndcs-marketing#39 — the fermentation alarm render can be captured without the disclaimer. The screenshot swap is coordinated under that issue.
  • Followups: documentation reframe across the docs above; regeneration of the alarm screenshots (hmi-alarm-state-matrix*) so the published images drop the banner.
  • Reversibility: high — the banner was a presentational element; restoring it is a small UI addition. The decision being recorded is where the boundary is stated, which is the durable part.