Developers

How the platform reaches the systems your operation already runs, and what your own team configures once the data is in it.

The Singularity connects to the systems already running in your operation through one Foundational Module, the Integration Hub. Everything your own team shapes inside the platform, meaning screens, forms, workflows, and the model of the operation, is configuration, and each piece has its own module.

The Integration Hub does not replace existing systems. It makes the data inside them usable.

How connections work

The Integration Hub creates and maintains live, structured connections between the Singularity and every external system already in place. It reads from each source, normalizes what that source produces, tags every signal with where it came from, and makes the result available to every other module on the platform. Writes back to source are handled where the workflow needs them.

The systems it reaches:

The main business software for orders, inventory, and finance (ERP)
The system that monitors and controls equipment across a plant (SCADA)
The small computers that control individual machines (PLCs)
Internet-connected sensors and devices
Quality platforms, scheduling tools, and third-party cloud apps

Connecting

Connecting a siteThe path a signal takes from a machine on your floor into the Singularity, the Ignition setup that publishes it, the topic it lands on, and what the documentation does not specify.ProtocolsWhat the Integration Hub speaks to source systems, which layer of your estate each protocol reaches, and what happens to a signal after it arrives.Asset modelHow an operation gets addressed and modelled before anything on it can report, and why the naming agreed in that work outlives every module built on top of it.Data modelsThe ISA-95 tag taxonomy the Singularity expects from a site: the hierarchy, the tags, their engineering units, and the four tags that are genuinely mandatory.Connection healthWhat the platform does when a connection degrades, what it does not do, and how a site works back from a flag to the break that caused it.

Building

Configuring the platformThe modules your own team configures: what people see, what they capture, how work moves, and how the platform answers a question, all without a release cycle.

Working together

Site readinessA pre-flight for the engineer who will own the connection: what gets assessed before configuration starts, what your own team has to decide, and what actually holds a plant up.Division of responsibilitiesWhat your team owns, what mode40 owns, and the choices worth settling before an implementation starts.

Nothing you already depend on gets ripped out. One customer runs the Integration Hub across 19 facilities on a single platform, without replacing the ERPs or machine infrastructure already in place.

Reference: Integration Hub and what it connects to.

Protocols

The Integration Hub speaks the common technical languages systems use to talk to each other:

REST
SOAP
OPC-UA
MQTT
File-based protocols

These terms are not needed to understand what the Hub does. They matter when a specific connection gets scoped, because the protocol a source system already speaks decides how that connection is built.

Connection health

Every signal that flows through the Integration Hub is schema-normalized and source-tagged, so every module downstream works from the same values with the same provenance.

Connection health monitoring watches each connection continuously. When one drops, it is flagged before it causes a downstream error, so a module never works from stale or missing data without anyone knowing.

What your team configures

The parts of the platform that change most often are the parts your own team configures. Screens, forms, workflows, and the model of the operation are configuration, so the people who run the work can change them without waiting on a development cycle.

Screens: What appears on a screen, which roles see it, and how it lays out. A line operator, a supervisor, and a plant manager look at the same operation and need almost none of the same things on screen.
Forms: The capture the work actually needs: checks, readings, inspections, sign-offs. Submissions land in the platform as structured data, available to every other module the moment they are entered.
Workflows: The steps, the order, who or what does each one, and what has to be true before the next step starts. The state of every running workflow is visible while it is running.
The model: A working model of the operation, read from assets, capacity, workflows, and history, that a what-if question can be put to before a decision is made.

The modules your team configures

Each has its own reference page.

Screen ConfiguratorConfigure what each role sees, without a release.Form BuilderBuild the capture forms the work actually needs.Workflow EngineProcesses that run, with every step and handoff in flight.Data Model EngineA working model of the operation for what-if questions.Model RouterEvery AI call routed to the model built for it.Retrieval EngineSearch and exploration across everything the platform holds.

Every module is listed in the module reference.

Scoping custom work

Where an off-the-shelf module does not fit the operation, mode40 builds the piece that does. What gets built, and in what order, is a scoping conversation before anything is committed.

Integration work already done in-house stays in place. The Integration Hub is the wiring layer going forward, and what it connects to is scoped connection by connection.

How custom integration work gets scoped, or talk to us about a specific system.