Application Overview

What the Isolation & Permit to Work app models, and the ideas behind it

Core Operating Chain

WorkRequest
  → IsolationRequest            (class: PERSONAL / GROUP / OPERATIONAL / COMPLEX / TEST_EMERGENCY)
    → EnergySource              (per asset: electrical, mechanical, gravitational, hydraulic…)
      → IsolationPoint          (method + verification method + sequence)
        → IsolationStep         (apply → lock/tag → dissipate → verify)
          → LockApplication     (personal / group master / equipment locks + tags)
          → IsolationVerification (zero-energy proof, independent where required)
    → GroupIsolationBoard → BoardParticipant   (one personal lock per worker)
    → Permit → PermitControl / PermitWorker / WorkExecution / PermitHandover
    → TestRelease              (temporary, named points, then reapply + reverify)
    → RestorationChecklist     (blocked until permits closed and locks removed)
IsolationEvent / AuditFinding → CorrectiveAction

Key Concepts

The isolation record is the controlling safety record. Twenty-three relationships hang off IsolationRequest. A work order or a permit cannot independently release plant — the permit references the isolation, not the other way around, and restoration is gated on the isolation's own checklist.

Energy is enumerated before it is isolated. An asset's EnergySource rows are the hazard inventory: type, normal magnitude, whether stored energy is possible, and critically whether it can re-accumulate. Each source resolves to one or more IsolationPoint records carrying the isolation method (rack out, blank/blind, double block and bleed, lower to ground…) and the verification method (test for dead, try start, gauge zero, earth applied…). Missing an energy source is the failure mode the model is built to prevent.

Isolation is a sequence, not a state. IsolationStep records the whole life of one point in order: applied → dissipated → verified → (test released) → restored, each with its own person and timestamp, plus a separate restoration_sequence so plant is restored in a deliberate order rather than the reverse of however it was applied.

Verification is evidence, and it can fail. IsolationVerification records the method, the instrument and its calibration due date, the observed value, and an outcome of PASS / FAIL / NOT_POSSIBLE / NOT_REQUIRED. A FAIL is a first-class record — it holds the isolation and marks the step EXCEPTION rather than being quietly overwritten.

Personal locks belong to people. A Lock of type PERSONAL has an owner, and a BoardParticipant row ties one worker to one personal lock on one group board, with an explicit acknowledgement of the boundary and scope. Removing someone else's lock requires forced_removal = true plus a linked Approval — the demo data carries the dual-approval case.

Testing is a declared state, not a bypass. TestRelease names the exact isolation steps being released, requires a test authority and an approver, requires persons-clear confirmation and temporary controls, and is not complete until reverification_completed is set after the points are reapplied.

Restoration is blocked, not assumed. RestorationChecklist is a set of explicit confirmations — work complete, permits closed, all persons signed off, all personal locks removed, guards restored, tools removed, persons notified, area inspected — before an area owner authorises return to service.

Approved safety evidence is immutable. Attachment carries an immutable flag and a sha256; corrections are made by superseding records rather than destructive edits, which is why approvals, verifications and lock applications are all separate append-only tables rather than fields on the isolation.