Pragmatos · Build with Helios

Build what's missing. Build it on Helios.

For the process that still lives in Excel, on paper or in someone's head, or in a legacy system that no longer fits the modern digital highway. AI agents that already know the Helios codebase draft your application from the process map; our engineers review and test it, and you see working screens before the build is finished. Low-code, on the same foundation Flow runs on.

Show us what's missingSee the scenarios

From Excel, paper or a legacy system to an application built on Helios, on the same foundation as the loop Left: where the process lives today, an Excel sheet, a paper form with a signature, a legacy system that no longer fits the digital highway, someone's head. Centre: your new application, built on Helios, for example customer claims and 8D steps, with screens for the quality lead, shift lead, plant manager and a read-only auditor view, an approve button, and working screens before the build is finished. Right: the systems already linked to the loop, ERP, PLM, CAQ, CMMS, which the new system reads through a published interface, and the loop itself: Loom, Live, Pulse, Orbis, Flow, Decisions. Everything stands on one foundation: one data model, screens for each role, workflows and approvals, your calendars, your sign-in with your directory. It runs on your own servers or in your cloud. Loom reads the machine; nothing writes to it. Today it lives in An Excel sheet one per plant, one per person A paper form and a signature in a folder A legacy system off the modern digital highway Someone's head the one person who knows the steps Your new application, built on Helios Customer claims and 8D steps, for example Screens for each role Quality lead Shift lead Plant manager Auditor, read-only one data model: the claim, its steps, its sign-off Approve Working screens before the build is finished Already linked to the loop ERP part master, orders PLM parts, documents CAQ findings, measures CMMS work orders Published interface: the new system reads the ERP part master, it is not re-typed Loom Live Pulse Orbis Flow Decisions The loop on your machines The loop, already running on the same foundation One foundation the same one the loop and Flow run on no second data model, no second sign-in One data model Screens for each role Workflows and approvals Your calendars Your sign-in, your directory Runs on prem, in your own cloud, or both, with your directory for sign-in. Loom reads the machine; nothing here writes to it. From Excel, paper or a legacy system to an application built on Helios, on the same foundation as the loop Stacked version of the hero diagram: where the process lives today, your new application with screens for each role, the systems already linked (ERP, PLM, CAQ, CMMS) read through a published interface, the loop, and the one foundation under all of it: one data model, screens for each role, workflows and approvals, your calendars, your sign-in. Runs on your own servers or in your cloud. Today it lives in An Excel sheet A paper form A legacy system Someone's head Your new application, built on Helios Customer claims and 8D steps Screens for each role Quality lead Shift lead Plant manager Auditor, read-only one data model: claim, steps, sign-off Approve Working screens before the build is finished Already linked to the loop ERP part master, orders PLM parts, documents CAQ findings, measures CMMS work orders published interface: the new system reads the ERP part master Loom Live Pulse Orbis Flow Decisions The loop on your machines The loop, already running on the same foundation One foundation the same one the loop and Flow run on One data model Screens for each role Workflows and approvals Your calendars Your sign-in, your directory Runs on prem, in your own cloud, or both. Loom reads the machine; nothing here writes to it.
Left to right: where the process lives today, the application it becomes, the systems and the loop already beside it. All of it on one foundation, on prem, in your own cloud, or both.

For the process with no system yet, or a system that no longer fits

Build

Some of your work has no system at all: it lives in Excel, on paper or in someone's head. Some of it lives in a legacy system that no longer fits the modern digital highway. Either way, we build it on Helios, low-code, on the same foundation Flow runs on, and the new application joins the loop below.

  1. Connect: LoomYour machines, old and new.
  2. See: Pragmatos LiveThe plant on one screen, as it runs.
  3. Analyze: PulseWhat changed, machine by machine.
  4. Decide: OrbisOrbis proposes, a person approves.
  5. Act: FlowThe decision becomes work.
  6. Prove: DecisionsEvery decision on the record.

Which route each system takes

Which route each system takes, and where it landsRoute diagram in three columns. What you have today, the route it takes, where it lands. Machines and sensors: connect with Loom, which reads the machine; nothing writes back. An ERP with a Fabric connector (SAP Business One, Microsoft Dynamics, Odoo): configure it in Fabric from the Platform's screens. A system you already own (ERP, PLM, CAQ, CMMS): integrate with Mateos; we build the link, or your partner does. A process with no system yet (Excel, paper, someone's head): build it on Helios, low-code, drafted by AI agents and reviewed by our engineers. A legacy system that no longer fits the modern digital highway: build it on Helios and migrate with Albatross, so the old records move into the new application. All five routes land on one foundation: the loop (Loom, Live, Pulse, Orbis, Flow, Decisions), your applications built on Helios, one data model and one sign-in, on prem, in your own cloud, or both.WHAT YOU HAVE TODAYTHE ROUTEWHERE IT LANDSMachines and sensorsold and new, on the shop floorConnect with Loomreads the machine; nothing writes back→An ERP with a Fabric connectorSAP Business One, Microsoft Dynamics, OdooConfigure in Fabricfrom the Platform's screensA system you already ownERP, PLM, CAQ, CMMSIntegrate with Mateoswe build the link, or your partner does→A process with no system yetExcel, paper, someone's headBuild it on Helioslow-code; AI-drafted, engineer-reviewed→A legacy systemthat no longer fits the digital highwayBuild it on Heliosand migrate with Albatross: old records move in→One foundationThe loop: Loom, Live, Pulse,Orbis, Flow, DecisionsYour applications, built on HeliosOne data model, one sign-inOn prem, your own cloud, or bothAct on all of it in FlowWhich route each system takes, and where it landsRoute diagram in three columns. What you have today, the route it takes, where it lands. Machines and sensors: connect with Loom, which reads the machine; nothing writes back. An ERP with a Fabric connector (SAP Business One, Microsoft Dynamics, Odoo): configure it in Fabric from the Platform's screens. A system you already own (ERP, PLM, CAQ, CMMS): integrate with Mateos; we build the link, or your partner does. A process with no system yet (Excel, paper, someone's head): build it on Helios, low-code, drafted by AI agents and reviewed by our engineers. A legacy system that no longer fits the modern digital highway: build it on Helios and migrate with Albatross, so the old records move into the new application. All five routes land on one foundation: the loop (Loom, Live, Pulse, Orbis, Flow, Decisions), your applications built on Helios, one data model and one sign-in, on prem, in your own cloud, or both.1 · WHAT YOU HAVEMachines and sensorsold and new, on the shop floorConnect with Loomreads the machine; nothing writes back→2 · WHAT YOU HAVEAn ERP with a Fabric connectorSAP Business One, Microsoft Dynamics, OdooConfigure in Fabricfrom the Platform's screens3 · WHAT YOU HAVEA system you already ownERP, PLM, CAQ, CMMSIntegrate with Mateoswe build the link, or your partner does→4 · WHAT YOU HAVEA process with no system yetExcel, paper, someone's headBuild it on Helioslow-code; AI-drafted, engineer-reviewed→5 · WHAT YOU HAVEA legacy systemthat no longer fits the digital highwayBuild it on Heliosand migrate with Albatross: old records move in→WHERE EVERY ROUTE LANDSOne foundationThe loop: Loom, Live, Pulse,Orbis, Flow, DecisionsYour applications, built on HeliosOne data model, one sign-inOn prem, your own cloud, or bothAct on all of it in Flow
Five starting points, three verbs: integrate with Mateos, build it on Helios, migrate with Albatross. Every route lands on the same foundation, and Flow acts on all of it.
  • Flow, extended. Flow is the action module: tasks and workflows, standalone if needed, configured from screens. When you need more than Flow, build it on Helios: a new application with its own data model and screens, on the same foundation. Flow
  • Integrate, build, migrate. Integrate with Mateos links the systems you already own; build it on Helios creates the system you do not have. When the old system goes, migrate with Albatross brings its records into the new one. Mateos · Albatross

How a build runs

Build

From the first conversation to the working application: nine stations, three phases. Nothing is built before the walk. Once the map is agreed, AI agents that know the Helios codebase draft the application, low-code, and our engineers review and test it before you see it. Nothing is handed over without the guide to run it.

How a build runs, from the first conversation to the working application A rail with nine stations in three phases. Walk: you bring one process and the person who runs it; we walk it on the floor end to end, we or your partner; we mark where it stops, in Excel, an e-mail hand-off, paper, a legacy system or the number typed twice; you keep the map, and if the fix is a setting in a system you own we say so. Build: AI agents draft it on Helios and our engineers review and test it, one data model, screens per role, workflows, calendars; you see working screens before the build is finished. Run: handover with the operating guide and a backup and restore procedure; your admin runs settings, users, roles, fields and lists; the new system joins the estate through a published interface, and anything beyond that is a written change request. Walk Build Run You bring one process and the person who runs it 1 We walk it on the floor, end to end; we, or your partner 2 We mark where it stops Excel, paper, a legacy system, a number typed twice 3 You keep the map if the fix is a setting in a system you own, we say so 4 We build agents draft it on Helios; engineers review and test it 5 You see working screens before the build is finished 6 Handover operating guide, backup and restore procedure 7 Your admin runs it settings, users, roles, fields and lists 8 It joins the estate published interface; more by written change request 9 One process, one person who runs it, one map; then the application, its handover and its admin. The same steps on every build. How a build runs, from the first conversation to the working application Stacked version: nine stations in three phases, Walk, Build and Run, from you bring one process to the new system joining the estate. Walk Build Run 1 You bring one process and the person who runs it 2 We walk it on the floor, end to end; we, or your partner 3 We mark where it stops Excel, paper, a legacy system, the number typed twice 4 You keep the map if the fix is a setting in a system you own, we say so 5 We build AI agents draft it on Helios; our engineers review and test it 6 You see working screens before the build is finished 7 Handover operating guide, backup and restore procedure 8 Your admin runs it settings, users, roles, fields and lists 9 It joins the estate published interface; more by written change request
Walk first, then build, then run it yourselves. Where a station names your integration partner, they can take it instead of us.

Walk

You bring one process and the person who runs it. We walk it on the floor, end to end, and mark where it leaves a system. You keep the map; if the fix is a setting in a system you already own, we say so. Station 3, close up

Build

AI agents draft the application on Helios from your map, low-code: one data model, screens for each role, workflows and approvals, your calendars, your sign-in. Our engineers review and test it, and you see working screens before the build is finished. Old records move in with Albatross. The foundation · Albatross

Run

Every handover includes the operating guide and a backup and restore procedure. Settings, users, roles, fields and lists: your admin. The new system joins the estate through a published interface; anything beyond that is a written change request. FAQ

3Station 3, close up: find where the work gets stuck

Before anything is built, we walk one process with you end to end and mark every place it leaves a system:

  • the step that lives in Excel
  • the hand-off that goes by e-mail
  • the signature on paper
  • the number typed twice
  • the legacy system that no longer fits
  • The map is yours. Whatever you do with it. If the fix is a setting in a system you already own, we say so.
  • Who walks it. We, or your integration partner.

Partner? Start here. Sell and deliver Pragmatos with us

What you get from the build, wherever you sit

Build

Your operations team gets its process back in one system it can see. Your IT team gets an application it can run like the rest of the estate. Your works council sees exactly what is recorded.

For operations

Plant and operations, quality, and the person who owns the process.

Plant / operations managerThe claim sits in an inbox until someone remembers it.

Every customer claim becomes a record with its 8D steps and a status everyone can see. Plant scenarios

Quality leadA deviation needs a sign-off I can show the auditor, not a signature in a folder.

Deviations, sign-offs and work-instruction revisions in one place, and the monthly quality report comes from the same records. Approvals in practice

Process ownerI know every step. It lives in my Excel and in my head.

You walk the process with us and keep the map. The screens follow your steps, and you see them working before the build is finished. Where the work gets stuck

For IT

“Another application means another server, another login, another backup.” It does not have to.

Hosting
On prem, your own cloud, or both: your own VM or Kubernetes, one PostgreSQL database. Hosting
Sign-in and roles
Your company directory over OpenID Connect, with SAML 2.0 and LDAP where needed; roles and row-level permissions. Security
Interfaces
REST interfaces described in OpenAPI. For the systems you already own, integrate with Mateos. Interfaces · Mateos
Old data
Records from the legacy system move into the new application: migrate with Albatross. Albatross
Handover
Every handover includes the operating guide and a backup and restore procedure.
Admin / key user
Settings, users, roles, fields and lists stay with your admin. Anything beyond that: a written change request to us or your integration partner. FAQ

For the works council. “Which names does the system record, and who decided that?” Roles by default; names only when a works agreement is recorded, and every change of that setting is kept. Roles and access

Plant scenarios

Build

What you can build on Helios, as it shows up in a plant. Each one is a new application with its own data model and screens.

A customer claim

A claim arrives. The 8D steps, the containment actions and the person who signs each step run in one system, and everyone sees what is still open.

Workflows and approvals

A work instruction changes

The new revision is reviewed, approved and released to the line. The old one is withdrawn, and the change history stays with the document.

Document management

Drawings and test reports

Drawings, test reports and certificates sit with the part they belong to, checked out while someone edits, with every revision kept.

Data model and storage

A deviation waits for sign-off

Quality and production approve in turn. A request that waits past its deadline on your shift calendar escalates to the next person.

Calendars and shifts

A ramp-up project

Tasks, owners, due dates and status on one dashboard, from the same records the team updates.

Helios gallery

Each desk sees its own

The operator sees their tasks, the quality engineer the open claims, the plant manager the dashboard. Roles decide who reads and who changes.

Security and roles

A monthly quality report

The report comes from the same records, printed or exported to a spreadsheet, in the reader's language.

Reports and languages

The new system joins the estate

When the new system needs your ERP part master, it reads it through a published interface.

Interfaces

It runs where you decide

On your own servers or in your cloud, with your directory for sign-in.

Hosting and handover

Your old records come with it

When the process lived in a legacy system, its records move into the new application: extracted, fitted to the new data model and loaded. Migrate with Albatross.

Albatross: load

What the foundation gives a build

Build

Flow runs on this foundation today, and Flow can be extended into your own system. Build it on Helios, and your application gets everything underneath from day one: the same data model, the same sign-in, the same technical base.

Layer 1What you use
FlowThe action module: tasks and workflows, running on this foundation today. Flow
Your own system, built on HeliosA customer claim and its 8D steps, a deviation sign-off, a ramp-up project: your data model and your screens, next to Flow. Plant scenarios
Layer 2One foundation

One data modelScreens for each roleWorkflows and approvalsYour calendarsYour sign-in, your directoryPublished interfaces

Layer 3Technical foundation
Data model and storageDescribe the data model once; list, detail and edit screens are generated from it. PostgreSQL, other major databases supported; files kept with their record.DocumentsSearch and browse by metadata, check-out while someone edits, revisions and history, fine-grained access.Security and auditOpenID Connect, SAML 2.0 and LDAP. Roles and row-level permissions. Every change recorded: who, when, what.WorkflowsBPMN 2.0 processes your own people can read and change; task lists, escalation, Kanban boards and maps.Calendars and schedulesFederal-state holidays, shift patterns, scheduled jobs, deadlines that follow your working calendar.Reports and languagesReports from the same data model, printed or exported to a spreadsheet. The interface runs in more than one language.InterfacesREST interfaces described in OpenAPI that other systems can read and write.Hosting and handoverYour own VM or Kubernetes, or your cloud; one PostgreSQL database. Operating guide plus backup and restore with every handover.

Flow and the application you build on Helios share layers 2 and 3: one data model, one sign-in, one database. No second platform to run.

Each block, in full, on the Helios page. Technical foundation

Bring one process. We'll show you where it gets stuck and what the system to fix it looks like.

You bring one process and the person who runs it; we walk it on the floor and leave you the map.

Show us what's missing

Where to go next

Get new articles by email

One shop-floor problem at a time.

Questions plant and IT leads ask

Yes: on your own VM or Kubernetes, or in your cloud; one PostgreSQL database, your directory for sign-in. Or hosted by your IT partner.
Through Fabric where Pragmatos ships the connector: you configure it. Where it doesn't, we build the link: integrate with Mateos.
Settings, users, roles, fields, lists: your admin. Anything beyond that: a written change request to us or your integration partner.
Every handover includes the operating guide and a backup and restore procedure.
Each company sets it: roles by default; names only when a works agreement is recorded, and every change of that setting is kept.
Yes, by a written change request to us or your integration partner.
Yes. Records from the spreadsheet or the legacy system move into the new application: migrate with Albatross.
Both. AI agents that know the Helios codebase draft the application from your process map; our engineers review and test it before you see it, and again before handover.