Oil and gas permit software: evaluate record controls and failure handling

Topics: oil and gas permit to work software; permit record controls; role permissions; software failure handling.

A permit-software demonstration moves smoothly from request to approval. Every user has the expected role and the network remains available. The purchasing team sees a clean workflow, but has learned little about what the product will display when an acknowledgement is lost or an approver's authority changes.

Oil and gas permit to work software should be evaluated as a record and authority system within the approved site process. The essential questions concern what users can rely on, what the application records and how uncertainty is handled. This is a software-evaluation guide, not a permit or hazardous-work procedure.

Translate the approved process into a demonstration script

Qualified work-control and safety authorities should identify the applicable roles, decision stages, evidence and contingency requirements. IT then verifies how the product represents and protects those records. Do not let the vendor's default workflow become the process by convenience.

OISD's catalogue lists STD-105, Work Permit System, with an August 2023 edition. The full applicable source set and site procedures require qualified review. A catalogue match or product claim does not establish conformity. OISD standards catalogue

The script should identify the record being created, its revision, the actor's role, the intended transition and the evidence the next user will see. Include separate cases for authorised, unauthorised and no-longer-authorised users. A role name in a menu is insufficient; demonstrate the actual permission checks.

Examine what the signature binds together

For each approval or acknowledgement, inspect the user identity, authority at the time, timestamp, record revision and scope of the action. Confirm what happens if a relevant field changes afterwards. The application should preserve the earlier decision and represent the new state according to the approved process.

Separate a device's capture time from the server's receipt time and display the timezone. An offline action received later should not acquire a misleading earlier server-confirmation time. For delegated authority, demonstrate the start and end of the delegation, the action performed under it and the treatment of a subsequent attempt after it ends. Keep historical attribution while enforcing the permissions that apply to a new request.

Ask the vendor to show the history to an ordinary authorised reviewer, not only a database administrator. The reviewer should be able to tell which version was considered and which subsequent changes occurred. Test exports as well as the screen; a PDF that drops qualifications or revision details can misrepresent the record.

Evidence of tampering or unauthorised edits should be detectable through the system's controls and audit history. A promise that logs are “immutable” needs a demonstration of administrator privileges, retention, export and integrity controls. Avoid accepting a marketing label as the test result.

The lost-acknowledgement demonstration

Illustrative example. A user submits an acknowledgement for record P-62 revision 4. Connectivity fails before the device receives a server response. The example concerns only record state; it provides no permission to carry out work.

A reassuring “submitted” banner is inadequate if the next user interprets it as confirmed approval. Equally, an automatic retry should not apply an acknowledgement to revision 5 when the user saw revision 4. The demonstration must preserve what was actually presented and decided.

Follow the same event into a supervisor's dashboard and any connected system. A careful pending message on the submitting device is of little value if another screen shows a confirmed state. Capture screenshots and audit records from both sides of the interruption, then repeat the demonstration after recovery. The requirement is consistent, traceable record status across those views.

Inspect offline behaviour as a separate capability

Offline capture, offline viewing and offline authority are different claims. Ask exactly which records are cached, how their age is shown, when permissions are refreshed and how revocation works. The site's qualified owners decide whether and how any offline function fits the approved process.

Test two devices holding different revisions, an expired session, a revoked user, a device with an incorrect clock and a server unavailable during synchronisation. Confirm that the system exposes uncertainty and follows the approved contingency. This article intentionally does not prescribe how work should proceed during any of those conditions.

Information exported or cached to a device remains part of the access design. Verify logout, device loss and data-retention behaviour with IT and security. NIST SP 800-82 provides OT security context for architecture decisions where the system touches operational environments. NIST guidance

Keep integrations from creating implied authority

The maintenance system may supply planning information, the identity system may supply user roles and the document repository may supply controlled references. None of those inputs should silently become a permit decision. Define each interface's direction, freshness and failure state.

Demonstrate a changed work-order scope and a superseded reference. The qualified process owner determines the resulting review; the integration should surface the change and preserve prior evidence. If a feed fails, the UI must show the last confirmed state rather than imply that nothing changed.

If a vendor proposes document summarisation, test whether it omits qualifications or mixes revisions, and keep the original controlled record available. A summary must remain recognisable as a summary, with a link to the exact source; it cannot stand in for the required decision evidence.

Record the procurement decision by demonstrated requirement

Use a requirement table with owner, source, test case, result, evidence and unresolved gap. Treat critical authority or record-integrity failures as explicit decision blockers under the purchaser's evaluation method; do not average them away with attractive interface features.

The procurement outcome should state what was demonstrated, what requires configuration and what remains unsupported. It should not promise reduced incidents or regulatory compliance from a software demonstration. Those are different claims requiring different evidence.

Summary and next actions

The strongest permit-software evaluation concentrates on authority and uncertainty: who decided, which record they saw and what the application shows when confirmation is missing. That evidence allows qualified owners to judge fit with the approved site process.

1. Have the work-control authority define the required record states and permissions.
2. Turn them into demonstrations covering unauthorised access, revisions and lost acknowledgements.
3. Verify offline, export and integration behaviour with IT and security.
4. Record gaps and required remediation before making the procurement decision.

A software-fit assessment can turn the approved record requirements into a vendor demonstration script, including the interruption tests above. Bring the work-control owner and IT reviewer so each unresolved requirement has a decision maker before procurement proceeds.