A Facility Relationship Graph is a machine-readable model of how facility entities connect. In Permit to Work analysis, that matters because the thing that creates a conflict is often not the permit form itself, but the live relationship between the permit, the equipment, the isolation, the work location, and the facility system that ties them together.
Traditional registers can tell you that a pump exists, or that an MCC exists, but they may not tell you how work on one item affects another. The graph captures those relationships explicitly so a reasoning engine can trace paths instead of guessing from labels.
Why the graph is useful
PTW teams usually need to answer questions like:
- What does this permit depend on?
- What other work shares the same upstream constraint?
- Does this isolation path also affect another job?
Those are graph questions. They are not just form questions.
In that example, a permit on a pump may be connected to an upstream transformer even if the transformer never appears on the permit title. That is the kind of hidden dependency a Facility Relationship Graph is built to expose.
What gets modelled
A practical graph usually combines several relationship domains:
- process connectivity
- electrical supply paths
- spatial adjacency
- isolation points and barriers
- work-control links such as permit-to-equipment mappings
The point is not visual decoration. The point is deterministic analysis with traceable paths. If a finding is generated, the operator should be able to inspect the rule, the entities, and the traversed relationship chain.
Related PERMITA concepts
The graph feeds the deterministic reasoning layer. The reasoning layer produces structured findings. The 3D view shows where the assets are. Together those layers support Operational Insights and Safety Insights without turning the model into a permit approver.
See also: How Graph-Based Reasoning Can Improve SIMOPS Analysis and What Is a Work-Control Semantic Twin?