Security

This page is written for whoever has to approve the connection. It describes architectural properties, and it is explicit about the difference between a design decision and an audited attestation.

Sessions

Sessions are server-side. The browser holds only an opaque token, and the server re-establishes who the caller is on every request.

The consequence that matters operationally: revoking an account takes effect on the next request, not whenever a cached claim would have expired. Suspending a departing contractor’s access is immediate rather than eventually consistent.

The access model

Access is bounded by explicit company grants. Nothing is visible by default.

Boundary	Behaviour
Company grant	Bounds which wells, facilities and tanks are reachable at all
Visibility	What a user can see within those grants
Control authority	Separate grant, scoped per device group

Scoping applies to every surface — the main interface, exports, the API, and the mobile experience. A pumper’s phone only ever holds the assets that pumper is granted.

Identity separation

Identity lives in a separate database from operational data, and no query joins across the two.

This is structural rather than a convention the application is trusted to follow. Account data and well data are not co-resident.

Control authority and audit

Seeing an asset and commanding it are distinct permissions. Authority is granted per device group, so there is no global “can control” right.

Every command:

• requires an explicit confirmation showing prior and commanded values
• captures the device’s own acknowledgment
• writes an append-only audit entry recording author, grant, device, action, prior value, commanded value, origin and time

Audit entries cannot be edited or removed. See control.

The production accounting connection

A least-privilege, SELECT-only connection to approved fields.

• The platform does not write to your system of record.
• The credential does not require write rights and should not be granted them.
• The set of readable fields is explicit, not “whatever the schema exposes”.

Field input recorded in the platform — gauges, hauls, corrections — is stored in the platform’s own database and is never pushed into your books. The accurate claim is read-only to your system of record, not that the software accepts no input at all.

Fail-closed behaviour

A failed connection, schema, permission or query returns an error describing what failed.

The platform does not substitute sample data, does not relabel a stale value as current, and does not interpolate across a gap. This is relevant to security review because it means a permission failure is visible rather than silently degrading into a page that looks normal.

Deployment

Cloud — hosted; no infrastructure for you to run.

Customer-hosted — the platform runs inside your network and operational data does not leave it.

Both run the same build and the same feature set. The deployment choice does not put capability behind a tier.

What this platform does not claim

It does not display certifications it does not hold. There is no SOC 2, ISO 27001, IEC 62443 or NERC CIP badge on this site, because presenting one would be an assertion about an audit rather than about the software.

Everything above is a design decision, and design decisions are checkable. You are welcome to ask how sessions are validated, what the accounting credential is permitted to do, and what a control command produces in the audit log. Those questions have specific answers.

If a formal attestation is a requirement in your procurement process, raise it directly and we will tell you exactly where things stand rather than implying an answer here.