Site constraints
What the site forbids before you write a line of code
Hazardous-area certification and operational technology change the hardware before they change the software.
Each entry is a physical or regulatory constraint, why it exists, and what it removes from the design.
Written as engineering and regulatory reality, not as a claim of past oil and gas delivery.
Hazardous area classification
Why it exists: In some zones a standard phone or tablet cannot legally be carried at all. Ignition risk and zone rules decide which hardware may enter.
What it removes: Consumer device assumptions. The software has to run on certified hardware with a different screen, different input and different capability set.
Intrinsically safe devices set the performance floor
Why it exists: Certified handsets are slower, smaller and older than consumer hardware. That is the device class permitted on site, not a temporary limitation.
What it removes: Flagship-only performance budgets, dense animation and interfaces that assume current consumer CPU, memory and display density.
Gloves and PPE remove precise touch input
Why it exists: Protective equipment is mandatory in many work areas. Operators cannot use fine multi-touch gestures the way a desk worker can.
What it removes: Tiny tap targets, swipe-only paths and flows that need precise finger placement to complete a critical step.
No connectivity offshore or at remote sites
Why it exists: Platforms, well sites and pipelines can sit without usable network for hours or days. That is an operating condition, not an edge case.
What it removes: Online-only writes for core capture. Offline behaviour and sync strategy have to be decided during scoping, before design locks in.
Cameras may be restricted or prohibited
Why it exists: Security, IP and safety rules can ban or limit photography in parts of a facility.
What it removes: Photo-as-the-only evidence path. Capture must work when the camera is unavailable, with alternative structured input.
Personal devices may not be permitted on site
Why it exists: BYOD policies and hazardous-area rules often forbid personal phones inside the fence line.
What it removes: Designs that assume crews install from a personal app store mid-shift. Provisioning has to match issued hardware and IT policy.
Shift patterns break task ownership
Why it exists: The person who started a task is often not the person who finishes it. Handover is the normal path, not an exception.
What it removes: Single-user task models and history that disappears when a shift ends. Records and open work must transfer cleanly between people.
OT networks are deliberately separated from IT
Why it exists: Operational technology networks are isolated to protect plant safety and availability. Crossing that boundary is a security decision, not a plumbing one.
What it removes: Casual API assumptions into control or historian systems. Integration scope has to name the boundary, approvals and what never crosses.
Regulatory records must survive audit years later
Why it exists: Regulators expect durable records in an acceptable form long after the crew that captured them has moved on.
What it removes: Ephemeral chat-style notes as the system of record. Retention, identity of who recorded what, and exportable evidence belong in the design.
Unavailable safety-critical systems stop work
Why it exists: When a required system is down, operations pause. Downtime cost is measured in halted work, not in frustrated app users.
What it removes: Fragile single points of failure treated as acceptable for field-critical flows. Availability and degraded-mode behaviour are product requirements.
