Configuration

What counts as configuration

The parts of the platform that change most often are the parts your own team configures, without waiting on a development cycle. Screens, forms, workflows, and the model of the operation are each shaped by a Foundational Module, and each of those modules has its own reference page.

Screens

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. A shared screen that suits nobody is a screen nobody reads.

The Screen Configurator defines those layouts, per role and per context. It sets what appears on a screen, which roles see it, and how it lays out for the device it runs on. When a layout is fixed in code it stops matching the work within months, and people build workarounds around it.

Reference: Screen Configurator.

Forms

Every operation captures data by hand somewhere: checks, readings, inspections, sign-offs. If the form does not fit the work, the data does not get captured.

The 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. A form on paper or in a spreadsheet has to be re-entered before anyone can use it, and it is usually re-entered late.

Reference: Form Builder.

Workflows

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. It handles step sequencing and dependencies, triggers between modules, handoffs between people and agents, and the live state of everything in flight. A process that lives in a binder runs differently on every shift.

Reference: Workflow Engine.

The model

The Data Model Engine holds a virtual model of the operation and runs what-if questions against it. It reads the structure of the operation from the platform: assets, capacity, workflows, and history.

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 comparison between two options can all be put to it. Without a model the only way to find out is to try it, and the cost of being wrong lands on the floor.

Reference: Data Model Engine.

Beyond configuration

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.

The developers property covers configuration and connection together for a technical reader, and integration and implementation covers how custom work gets scoped.