We shipped twelve modules in three months. Each one solves a real problem on its own — training tracking, document control, incident management, inspections, PPE. But a collection of modules is not a platform. A platform is what happens when the modules start sharing data in ways that make each one more valuable than it would be alone.
That’s what the multi-tier interoperability layer does. It’s the connective tissue between modules.
Three tiers of interop
We designed the interop layer in three tiers, each connecting a different cluster of modules through shared data structures and cross-module references.
Tier 1: Safety Operations — Incidents, Inspections, and PPE & Assets. When an inspection finding escalates to an incident, the inspection record becomes linked evidence. When an incident involves equipment, the PPE module surfaces the asset’s pre-start gate status and maintenance history. A near-miss flagged during a pre-start check flows directly into the incident register. These three modules form a closed loop: inspect, detect, investigate.
Tier 2: Compliance Lifecycle — Document Control, Psychosocial Health, and Inductions. A document review that reveals a psychosocial hazard triggers a risk assessment in the psych health module. Induction completion status flows into the competency snapshot when an incident involves a new starter. Return-to-work inductions link back to incident records and document acknowledgements.
Tier 3: Intelligence Network — Benchmarking, Self-Service Portal, Working Groups, and Provider Directory. Benchmarking metrics now include cross-module indicators — not just training compliance, but inspection coverage, incident rates, and document health. The self-service portal surfaces an employee’s full picture: training, incidents they were involved in, inspections of their equipment, PPE assignments. Working group threads track which module generated the discussion. Provider demand signals attribute training requests to their source module.
Why not just build APIs?
Every module already has API endpoints. The interop layer is not about APIs — it’s about shared schema. When the incident module captures a competency snapshot, it needs to understand the training matrix schema, the induction schema, and the PPE assignment schema. When benchmarking calculates a cross-module score, it needs to aggregate data from six different modules with consistent definitions.
We solved this with foreign key bridges at the database level. Schema migrations 057 through 059 added the cross-module references — incident-inspection bridges, induction-competency fields, benchmarking metric columns, demand signal attribution. The interop lives in the schema, not in middleware.
What this enables
The practical result is that every module gets richer as the platform grows. The incident management module becomes more valuable when it can pull in inspection history and PPE status. The inspections module becomes more valuable when findings can escalate into incidents with full context. PPE & asset management becomes more valuable when pre-start gate data feeds into incident investigations.
This compounding effect is the moat. A competitor can build a training matrix. They can build an inspection app. What they can’t easily replicate is twelve modules sharing data across three interoperability tiers, all connected through a training matrix backbone, stored under Australian data sovereignty guarantees.