Operational safety compliance for the energy sector — built sovereign, deployed on-premise, with AI that never leaves the building.
The Problem
Lockout/tagout (LOTO) compliance in the energy sector is not optional. OSHA 29 CFR 1910.147 mandates specific procedures for controlling hazardous energy during equipment servicing and maintenance. In the UK and Ireland, PUWER regulations and HSE guidance impose equivalent requirements. A failure is not a fine — it is a worker in danger.
The existing compliance landscape for energy operators is fragmented. Paper-based procedures, spreadsheet tracking, disconnected training records, and audit processes that rely on manual evidence collection. When an auditor arrives — or worse, when an incident occurs — the question is always the same: can you prove that the right procedure was followed, by the right person, at the right time?
For most operators, the honest answer is: not quickly, not confidently, and not without significant manual effort.
Why It Mattered
The compliance overhead for energy operators is not just regulatory exposure — it is operational drag. Engineers spend time on paperwork instead of maintenance. Safety officers chase documentation instead of observing conditions. The administrative burden of compliance competes directly with the operational work compliance is supposed to protect.
Cloud-hosted solutions exist but introduce their own problems in this sector. Operational safety data — who has access to what equipment, which procedures are active, which workers are certified for which energy isolation points — is sensitive. Hosting it on US-controlled cloud infrastructure creates CLOUD Act exposure. For operators subject to NIS2 as essential entities, that exposure is a supply chain risk that must be assessed and documented.
The requirement was specific: a compliance platform that runs entirely within the operator's own infrastructure, with no external cloud dependency, no data leaving the building, and AI-assisted workflows that work without an API call to a third-party model provider.
What We Built
SafeOps365 is a lockout/tagout compliance platform designed for energy sector operators. It manages equipment inventories, energy isolation procedures, worker certifications, and audit evidence — with AI-assisted compliance workflows running entirely on-premise.
The core capabilities:
- Equipment and procedure management — every piece of equipment with its associated energy sources, isolation points, and LOTO procedures. Procedures are versioned and auditable.
- Worker certification tracking — who is certified to perform which procedures, when certifications expire, automated notifications for renewal.
- Compliance evidence capture — digital records of every LOTO application and release, timestamped, with the worker identity, equipment identity, and procedure version linked.
- AI-assisted procedure generation — given an equipment profile and energy source inventory, the system generates draft LOTO procedures using local ONNX inference. The safety officer reviews and approves. The AI accelerates the documentation; the human owns the judgment.
- Audit-ready reporting — when the auditor arrives, the evidence is already structured. Compliance reports generate from live data, not from someone spending a week assembling spreadsheets.
How We Built It
Architecture
- Language Go — single static binary, no runtime dependencies
- Data Per-tenant SQLite via sqliteproxy — complete data isolation per operator
- AI ONNX Runtime — local inference, no cloud API, no data egress
- Deployment Single binary from scratch container — no shell, no package manager
- Auth JWT with per-tenant claims — standard HTTP middleware
- Migrations Automatic per-tenant via sqliteproxy — no migration runner, no coordination window
The architecture is deliberately minimal. A single Go binary that contains the entire application — HTTP server, business logic, data access, AI inference, migration management. No external database server. No message queue. No cache layer. The binary is the service.
This is not minimalism for its own sake. Every component removed is an attack surface eliminated, a dependency that cannot break, a piece of infrastructure that does not need to be operated. For a platform handling safety-critical data in a regulated environment, the simplest architecture is the most defensible one.
Per-tenant SQLite isolation means each operator's data exists in a separate database file. There is no row-level security to audit, no shared tables, no possibility of cross-tenant data access. When an operator asks "is our data isolated?" the answer is the filesystem. When a regulator asks for evidence of data isolation, the answer is the same.
The Outcome
The platform replaces a fragmented paper-and-spreadsheet compliance process with a single system that captures, structures, and reports compliance evidence as a natural byproduct of the work itself. The safety officer's job shifts from chasing documentation to reviewing AI-assisted drafts and monitoring compliance status in real time.
Related Reading
- How We Build: Single-Binary Multi-Tenant Services with Per-Tenant SQLite — the architecture pattern behind SafeOps365
- The Convergence — why sovereign AI infrastructure is becoming an inevitability for regulated industries
- How We Work — our outcome-driven engagement process
SafeOps365 demonstrates what happens when the architecture serves the compliance requirement rather than the other way around. The platform is sovereign by design, not by policy. The AI is local by architecture, not by configuration. The data isolation is structural, not logical.
If you're building for a regulated environment and need a team that understands what "sovereign" actually means at the infrastructure level — we should talk.