Arcturus reads operational data from your BMS and sensors, writes back optimised setpoints, and stores both for analysis. This guide explains what is read, what is written, where each data type lands, and why the operational telemetry is not personal data.

What we read

Operational telemetry only — every read is one of: indoor / outdoor / supply / extract air temperatures, CO₂, humidity, fan speeds and airflow, valve and damper positions, equipment on/off and alarm statuses, and energy meter readings where available. The exact list per site is whatever the address-list CSV from your BMS vendor exposes; we do not invent points.

What we write

Setpoints only — temperature setpoints, airflow setpoints, and schedules where the integration supports it. We never write executable code, configuration changes, or anything that re-wires your BMS. The actual regulation (PI loops, equipment staging, alarms) stays where it always was: in the BMS, running locally.

Where it lands on our side

1. Time-series telemetry (every reading and every write) → a time-series database, partitioned per site.
2. Site configuration (which controllers, which datapoints, how zones map) → an operational database alongside the running services.
3. Vendor credentials (the API keys we use to reach IWMAC, Airthings, etc.) → encrypted at rest with AES-256-GCM; the encryption key is held in a cluster secret, not in any database row.

Why this is not personal data

Telemetry from a ventilation system describes the building, not its occupants. CO₂ levels and fan speeds for a meeting room do not identify who was in the room. The personal data Arcturus handles is administrator accounts for the platform itself (sign-in identity for the people who use the dashboard), held separately from the operational telemetry.