Industrial software is defined as much by what it prevents as by what it enables.
Producing a number is easy. Refusing to produce one when the method, evidence or authority is insufficient requires deliberate engineering governance. That principle shapes how Zemerc applications are designed.
6 steps, each with a defined output.
A step is complete only when its required artefact exists and the next decision can be made from it.
- 01
Start from the record
The first artefact is not a schema. It is the register, the sheet or the log the team already maintains, and the rules they already apply to it; who may change it, what makes it valid, what must never be lost.
Produces: The record model the application is built around - 02
Build one application
Each application is developed, released and operated independently. It must provide complete value on its own before any integration with another application is considered.
Produces: An independently operable application - 03
Enforce the rules in the system
Segregation of duties, immutability and effective dating are implemented in the application rather than written in a procedure. A rule a user can work around is not a control.
Produces: Controls the database itself upholds - 04
Derive, never declare
Where a status can be read from the record, the application reads it: gate readiness from the registers, control effectiveness from the findings, compliance from the evidence held. Typed totals are treated as a defect.
Produces: Figures with a traceable basis - 05
Decide what not to compute
Some numbers should not exist. Where there is no approved engineering method, the application refuses the figure and says why, because on a major-hazard site a refusal is worth more than a plausible number.
Produces: A stated boundary on every claim - 06
Prove it on real work
An application is run on a live project or asset with the team that owns the record before it is offered more widely. What it computes is checked against what that team knows to be true.
Produces: Evidence behind every claim made here
Every principle is visible in a delivered application.
These are implemented behaviours, not design intentions. Each is demonstrated in the application named.
- PSMStates that no certified engineering method exists for its enterprise indices, and reports the components instead of a scorePSM: Process Safety Management System
- AIRMSComputes no integrity, health or readiness index; thickness readings and approved assessment revisions are immutableAIRMS: Asset Integrity & Reliability Management System
- FAMSKeeps a draft invisible downstream, and refuses to let the author of an engineering record approve itFAMS: Flow Assurance Management System
- HAMSHolds readings immutably with governed substitution, and re-runs a closed period on the method that was in force thenHAMS: Hydrocarbon Accounting Management System
- EAMSSeparates completing a work order from closing it, with independent verification enforced as configurationEAMS: Enterprise Asset Management System
- LGMSPrevents double allocation in the database itself, and reports an unstated limit as not checkable rather than as a passLGMS: Logistics Management System
- OPEPShows a figure it cannot derive as not measurable, and holds cannot-be-determined apart from not-readyOPEP: Offshore Projects Execution Platform
- OMSTreats unknown as a real lifecycle answer, never as active, and counts only verified eventsOMS: Obsolescence Management System
PSM: Process Safety Management System
The enterprise process-safety indices make this principle explicit. Where no certified engineering method is configured, the application does not manufacture a composite score.
Instead, the contributing measures are presented individually so the recorded position remains transparent and technically defensible.
Controls that preserve the record throughout its lifecycle.
Long-term defensibility depends on how the record is controlled after creation: who may change it, how revisions are approved, how supersession is handled and how the audit trail is preserved.
- Office and field on one record; What the desk reads and what the field enters is the same record. Field capture works on the device the work actually happens on, and offline where the work happens offshore.
- Identity is the control surface; Roles, tenancy and approval rights are enforced on identity, which is why segregation of duties survives a busy week rather than depending on people remembering the rule.
- Approved records are superseded, never edited; An approved engineering record stays as it was. Supersession requires the dependent records to be reassessed rather than silently cascading through the system.
- The audit trail is append-only; Every controlled change leaves a record of who, when and what; which is the only reason a closed period can be explained two years later.
Why the portfolio is structured this way.
Developing applications independently is an engineering and commercial design decision. The philosophy page explains the consequences of that model for clients and for the portfolio.
Ask what the application is designed to refuse.
For industrial software, the controls around invalid, unsupported or unauthorised outcomes are as important as the capabilities themselves. Bring one of your records and we will show both.