Authority architecture
Authority and Safety Boundary Brief
A concise technical model for deciding who and what may observe, acknowledge, coordinate, administer, command and protect across facility, network, security, compute and operating-workflow systems.
- Access
- Open access
- Resource type
- Authority and safety architecture brief
- Primary audience
- Owners, engineers, operators, cybersecurity, controls, safety, compliance and commissioning teams
- Product scope
- All PrecisionDCOS components and integrated systems
Visibility does not equal authority
A system may be readable, writable and still not be safe or authorized to command.
Critical-infrastructure integration often fails at the boundary between technical capability and operating authority. A protocol exposes a writable register. A BMC exposes a power action. A VMS exposes a door-control integration. A monitoring platform can send an API request. None of those facts establishes that the action is safe, contractually permitted, procedurally approved or owned by the caller.
PrecisionDCOS separates observation, workflow coordination, administration, equipment-changing command and local protection. Each authority is documented by system, action, role, state, location, time, approval, feedback and failure behavior.
Monitor broadly. Command narrowly. Keep protection local.
Each authority is documented by system, action, role, state, location, time, approval, feedback and failure behavior.
Separate the layers
Use the architecture diagram to prevent hidden authority.
Observation — Read authority
Coordination — Workflow approval
Bounded command — Separately engineered
Local protection — Independent
Layer 1 — Observation
Acquire approved values, states, events, health, quality, time and source references. Observation may be broad, but it remains limited by identity, tenant, privacy, security and source-system policy.
Layer 2 — Coordination
Normalize alarms, correlate dependencies, open incidents, notify, escalate, assign work, request approval, preserve communications and verify closure. Coordination manages the response without silently changing the equipment.
Layer 3 — Bounded command
Execute a separately engineered equipment-changing action only through a published command definition, explicit owner, permitted role, local state validation, interlocks, expiration, feedback, audit and accepted test.
Layer 4 — Local protection
Protective relays, fire alarm, gas emergency shutdown, equipment-local safeties, hardwired permissives, emergency egress and other required protective functions remain local and independent of Cloud, NOC or general monitoring availability.
The layers can exchange state and evidence, but they must not be collapsed. A remote workflow can request a local action. A local protective system can report its state. Neither relationship transfers the underlying authority unless the approved design expressly does so.
Apply the model by domain
The same words can mean different consequences in different systems.
Electrical protection
Observe: breaker, relay, metering, trip and alarm state. Coordinate: incident, utility or OEM communication, field dispatch and evidence. Command: a separately engineered breaker or scheme action, if expressly included. Protect: protective relay and local trip circuit. Boundary: PrecisionDCOS monitoring does not replace protection and must not block a trip.
Gas monitoring and shutdown
Observe: detector, warning, alarm, trouble, shutdown and valve feedback. Coordinate: alarm workflow, evacuation or site response, maintenance and evidence. Command: no force-open, remote reset, bypass or trip clear in the baseline. Protect: listed or approved gas controller, hardwired relay chain and final element. Boundary: protective action remains functional without PrecisionDCOS, network or Cloud.
Fire alarm and egress
Observe: approved alarm, supervisory, trouble and interface status. Coordinate: notification, incident, vendor and restoration workflow. Command: only through the fire-system and code-approved authority, if any. Protect: fire-alarm control unit, releasing logic, local notification and egress interfaces. Boundary: PrecisionDCOS does not become the fire-alarm system.
Mechanical and cooling
Observe: temperature, pressure, flow, valve, pump, fan, alarm and controller state. Coordinate: dependency impact, incident, OEM, maintenance and capacity response. Command: bounded setpoint, enable, reset or sequence action only if separately engineered. Protect: equipment-local safeties, pressure and temperature limits, freeze protection and OEM controls. Boundary: a readable BACnet or Modbus object does not establish command authority.
Server and BMC
Observe: inventory, power, temperature, fan, PSU, memory, storage, firmware and event state. Coordinate: incident, customer approval, vendor support, maintenance and RMA. Command: power-cycle, virtual media, firmware or configuration action only by approved role and workflow. Protect: hardware and firmware protections. Boundary: NOC visibility does not imply customer workload authority.
Physical security
Observe: door, reader, video, intrusion, visitor, intercom and device health. Coordinate: assessment, dispatch, escalation, evidence and restoration. Command: unlock, lockdown, arm, disarm or export only within approved platform authority. Protect: local access, egress, fire interface, intrusion and emergency behavior. Boundary: portal access does not silently grant door-control authority.
Network and connectivity
Observe: interface, optical, route, tunnel, wireless, firewall, circuit and performance state. Coordinate: incident, carrier ticket, change, maintenance and customer communication. Command: configuration, isolation, route or failover action only through named administrative and change authority. Protect: local device safeguards, control-plane protections and provider boundaries. Boundary: monitoring reachability is not administrative privilege.
A command is a published control function
Do not enable writes as an implementation shortcut.
- 01
Command name and purpose
The exact action and operational objective
- 02
Target and source system
Equipment, interface, object and authoritative controller
- 03
Owner
The accountable organization and system owner
- 04
Permitted roles
Named roles, tenant, location and access method
- 05
Preconditions
Required local state, mode, maintenance condition and dependencies
- 06
Interlocks
Hardware, software, procedural and human controls that must be satisfied
- 07
Approval
Whether one-person, two-person, customer, site or change approval is required
- 08
Expiration
Time limit for the authorization, request and any temporary state
- 09
Execution semantics
Idempotency, retry, timeout, duplicate prevention and partial failure
- 10
Feedback
Authoritative confirmation that the requested state was achieved
- 11
Failure and safe state
Behavior on loss of communication, disagreement, timeout or rejection
- 12
Rollback or recovery
Accepted method to return to a known state
- 13
Audit and evidence
Requester, approver, time, before and after state, result and related record
- 14
Test and acceptance
FAT, SAT, commissioning, periodic proof and change-retest requirements
- 15
Disablement
How the command is administratively and technically disabled when not authorized
If the command cannot be described, interlocked, feedback-confirmed, failed safely, audited and tested, it is not ready to be enabled.
Keep the consequence-limiting function local
Protection must survive loss of the operating platform.
Required local protection includes the systems and functions that must act within their engineered time and safety envelope even when PrecisionDCOS, the facility network, the WAN, the hosted service, central identity or the NOC is unavailable.
- Electrical protective relays and trip circuits
- Generator, turbine, reciprocating-engine and BESS equipment protections
- Gas detection, emergency shutdown and hardwired permissives
- Fire alarm, suppression-release and emergency notification
- Emergency egress and code-required door release
- Equipment overtemperature, overpressure, overspeed and other OEM safeties
- UPS, switchgear, cooling and process equipment local protection
- Emergency-stop circuits
- Listed or approved safety controllers
- Local manual controls required for safe operation
- Any function designated local by code, hazard analysis, OEM or approved Basis of Design
PrecisionDCOS may observe, correlate, notify, dispatch, preserve evidence and support restoration around these systems. It does not become the protective device merely because it can see the state.
Authority during impairment
State what remains possible when dependencies fail.
Scroll horizontally to see the full table.
| Impairment | Authority behavior |
|---|---|
| WAN or tunnel loss | Local protection and local source systems continue; hosted commands are unavailable unless an independently approved path exists; collectors buffer within accepted limits; Cloud marks stale |
| Hosted-service loss | Local systems remain authoritative; local or alternate operational procedures apply; no required protection depends on hosted recovery |
| Identity-service loss | Existing sessions and local emergency access follow policy; new privileged actions may be restricted; break-glass remains controlled and audited |
| Monitoring database impairment | Active critical state and incident integrity are protected according to profile; command paths do not infer normal state from missing data |
| Source-system loss | PrecisionDCOS reports quality and source failure; it does not fabricate current state or execute a command against an unknown condition |
| Feedback loss | Equipment-changing action is inhibited, failed or escalated according to the command definition; requested state is not assumed achieved |
| Authority conflict | Competing owners or command paths are inhibited and alarmed; a documented resolution procedure controls restoration |
| Primary NOC unavailable | Backup NOC, continuity team or site authority follows the accepted access, communication and command schedule |
| Emergency condition | Local protective systems act first; central coordination supports response without delaying or overriding the protective action |
Automation inherits the same authority rules
A machine caller is not exempt from accountability.
APIs, scripts, orchestration, analytics and AI operate through the same identity, role, state, interlock, expiration, feedback, audit and acceptance model as a human operator.
The standard Data Fabric and API posture is read-oriented. Workflow interfaces may create or update records within role. Command APIs are disabled by default. AI and analytics are advisory by default.
Advisory analytics
Predict a likely cooling or capacity issue and create a recommendation or incident candidate. A qualified operator or approved workflow evaluates the result.
Workflow automation
Enrich an alarm, open a ticket, notify a vendor, request approval or gather evidence without changing equipment state.
Bounded operational automation
Execute a separately approved command only when the command definition, state, role, interlocks, feedback and accepted automation logic are satisfied.
Do not represent an AI assistant as an autonomous controller of critical infrastructure.
Authority must have one owner. The authority schedule identifies the responsible owner for each system, information class and action. PrecisionX may own the monitoring and operational workflow while a customer, OEM, carrier, security provider, licensed contractor, utility, commissioning authority or local operator retains administration, command or protection. Conflicting or overlapping authority is treated as a design defect. Shared workflow is acceptable; ambiguous equipment authority is not.
The Authority and Safety Boundary Brief includes
- Visibility-versus-authority principle
- Four-layer operating model
- Authority-class definitions
- Domain examples
- Authority schedule fields
- Command-definition requirements
- Local protection boundaries
- Read, workflow, administrative and command API distinctions
- GMS, fire, protection and equipment-safety examples
- Identity, approval and two-person controls
- Feedback, timeout and safe-state behavior
- WAN, Cloud, identity and source failure modes
- AI and automation governance
- Acceptance and periodic proof requirements
- Shared responsibility and conflict resolution
Frequently asked
Questions and answers
- Does monitor-only mean operators cannot acknowledge alarms or manage incidents?
- No. Monitor-only refers to equipment-changing authority. Operators may still acknowledge monitoring events, manage incidents, communicate, dispatch, create work and preserve evidence within their workflow roles.
- Can PrecisionDCOS ever issue equipment commands?
- A separately engineered bounded command may be included when the use case, authority, local state, interlocks, expiration, feedback, audit, failure behavior and acceptance are explicit. It is not enabled merely because the protocol or API supports a write.
- Why must local protection remain independent?
- Protective functions must act within their required time and consequence envelope despite loss of general monitoring, WAN, Cloud, central identity or NOC reachability. Making them dependent on those services would introduce inappropriate common modes and delay.
- Does acknowledging an alarm reset the source device?
- Not by default. Monitoring acknowledgment records that an operator has seen the event. Source acknowledgment, reset, clear or return to service is a separate action governed by the native system and approved authority.
- Can AI approve or execute a command?
- AI is advisory by default. Any automated action must pass through a separately approved workflow and command design with accountable ownership, state validation, interlocks, limits, feedback and evidence. The model output itself is not authority.
Related resources
IO and GMS Overview
See the distinction between Field interfaces and independent gas-safety action.
Read resourceData and APIsData Fabric and API Guide
Separate read-oriented data access from workflow and command interfaces.
Read resourceEngineering and AcceptanceFAT, SAT and Operational Readiness Guide
Test authority, interlocks, failure behavior and local protection before service.
Read resourcePublish the authority model
Resolve who can act before integrating the systems.
Bring the system list, desired remote functions, customer and OEM responsibilities and safety boundaries. PrecisionX will help produce an authority schedule and the engineering actions required for any bounded command path.