Arcturus cannot reach a datapoint on your BMS unless it has been explicitly exposed and explicitly tagged readable or writable. Two layers of approval — one on your side and one on ours — gate every read and every write.

Layer 1 — your BMS exposes a datapoint

A datapoint exists for Arcturus only if your BMS vendor has put it on the address list they ship for the site (the CSV uploaded in Step 3 of the wizard). Any point not on that list is invisible to us — not just write-protected, but unreachable. Adding a new datapoint requires the BMS vendor to re-issue an updated address list.

Layer 2 — read vs write is per-row in the address list

Inside the address list, every row carries a read/write attribute. Rows marked Read are pulled into our database. Rows marked Write are the only points Arcturus can ever write to — there is no path in our code for Arcturus to write to a Read-only row. Changing a row from Read to Write requires the BMS vendor (and you) to deliberately re-issue it.

IWMAC adds a third gate — watchdog registration

For IWMAC sites, there is one more layer: even a Write-marked datapoint will not actually accept writes from us until IWMAC has registered it as a watchdog tag (the Step 7 handshake). This is IWMAC's own protection, not ours. The practical effect is that you, your IWMAC contact, and Arcturus all have to deliberately consent to a setpoint becoming writable — there is no way for the platform to self-extend to new setpoints after onboarding.

Sensor providers are read-only by code

Airthings and Disruptive Technologies clients in our codebase have no method that writes back to the sensor vendor — they push received readings into our internal time-series database, but never call back out to Airthings or DT to change anything. There is no setpoint or actuation path to those sensors.