Developers
The 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.
The parts of an operational platform that change most often are not the hard parts. They are the screens, the capture forms, the sequence of a process, and the description of the operation those things run against. When those live in code, every change to them is a development cycle, and the operation waits.
Configuration is where they live instead. Screen Configurator, Form Builder, Workflow Engine, Data Model Engine, Model Router and Retrieval Engine each own one of those surfaces. They are configured by the people who run the work rather than by whoever holds the release calendar.
Configure what each screen shows and who sees it, so people get the view their job needs without a development cycle.
Different jobs need different views of the same operation. A line operator, a supervisor and a plant manager are looking at the same data and need almost none of the same things on screen. Screen Configurator is where those views get built and changed. It defines what appears on a screen, which roles see it, how it lays out for the device it runs on, and how quickly it can be changed.
Who uses it. Whoever owns the view for a role, which is usually a supervisor or a plant lead rather than a developer.
What changes without a release. The contents, the layout, and the role a layout belongs to. Role definitions themselves are settled during implementation, alongside the rest of the governance work a site owns.
Reference: Screen Configurator.
Build the forms your operation actually uses, so quality and process data is captured on the floor instead of transcribed later.
Every operation captures data by hand somewhere: checks, readings, inspections, sign-offs. Form Builder is where those forms get defined, changed, and put in front of the person doing the work. Submissions land in the platform as structured data, available to every other module the moment they are entered.
Who uses it. The people who own the check, typically quality and process owners. The person filling the form in is on the floor, which is the point.
What changes without a release. Fields, validation, and which workflow step a form belongs to. A check that turns out to be measuring the wrong thing gets fixed on the shift that discovers it.
Reference: Form Builder.
The orchestration layer for the workflows your operation runs continuously, so each step starts when the one before it finishes.
A process gets defined once: the steps, the order, who or what does each one, and what has to be true before the next step starts. The Workflow Engine then runs it. Steps trigger, approvals route, records get written, and the state of every running workflow is visible while it is running rather than after. It handles step sequencing and dependencies, triggers between modules, handoffs between people and agents, and the live state of everything in flight.
Who uses it. Whoever owns the process. A process that lives in a binder runs differently on every shift, and this is the module that ends that.
What changes without a release. The steps, the order, the conditions between them, and who or what each step is assigned to.
Reference: Workflow Engine.
A working model of your operation, so a change can be tested against the model before it is tried on the floor.
It reads the structure of the operation from the platform: assets, capacity, workflows and history. That structure becomes a model a question can be put to. Move this job, add this constraint, take this line down, and see what the model says before the decision is made. Capacity and sequencing changes, constraint changes, downtime and outage scenarios, and a straight comparison between two options are all questions it takes.
Who uses it. Whoever is about to make the call. The alternative most operations run today is to settle the what-if by argument and then test it in production.
What changes without a release. The scenario. The model itself is read from the platform, so it moves when the operation moves rather than when someone remembers to update a spreadsheet.
The accuracy of this model is downstream of the addressing work in Asset model. A model reading an operation that is only partly described answers for the part that is described.
Reference: Data Model Engine.
Every AI task routed to the model built for it, automatically and invisibly, so nobody on the team is picking models by hand or hardcoding one into an integration.
It is not a tool anyone configures per task. When an agent or workflow module needs an AI task done, whether that is reading a maintenance photo, parsing a shift note, or flagging a statistical deviation, Model Router decides which model is built for that kind of task and sends the request there. The response comes back in a consistent format regardless of what produced it, and the routing record is logged in the Historian. When something better becomes available for a task type, Model Router absorbs the change and the modules depending on it are not touched.
Who uses it. Nobody, directly. It sits under every agent and every AI-enabled workflow module as shared infrastructure, which is the reason it belongs on this page: it is the surface your team would otherwise have to build and maintain itself.
What changes without a release. The routing, as task types and available models change, without the agents and modules above it being rewritten.
Reference: Model Router.
Retrieval and exploration across everything the Singularity holds, so finding the relevant record is a search rather than a project.
It searches and explores across the platform’s data: documents, structured records, historical events and readings, each carrying the context of where it came from. It is what other modules and agents call when they need the relevant material for a question, and what a person uses when they need to go looking themselves. Most operational searching is otherwise done by asking somebody who might remember.
Who uses it. Every module that needs material to answer with, and anyone who needs to find a record without knowing which system it landed in.
What changes without a release. What it reaches, as the platform accumulates records. Nothing has to be re-indexed by hand for a module to be able to search it.
Reference: Retrieval Engine.
Configuration reaches the surfaces above and stops there. Integration credentials and site certificates are issued by mode40 during onboarding, provisioning is manual per site, and there is no self-serve provisioning or administrative console for it.
Where an off-the-shelf module does not fit the operation, mode40 builds the piece that does, and what gets built is a scoping conversation before anything is committed. How custom work gets scoped covers that. Every module, configuration and otherwise, is listed in the module reference.
We use cookies to understand how the site is used and to connect form submissions to earlier visits. No analytics or marketing cookies are set until you choose. Privacy Policy