Visualisation: a long row of graphite machining centres in a dark concrete hall, a thin cyan scan line running across them and reflecting in the polished floor.

Promeing ConceptScenario set in Zürich

Operations Intelligence Platform

IndustryPrecision manufacturing

Visualisation

Status
Promeing Concept
Scenario
Zürich
Industry
Precision manufacturing
Capabilities
AI AgentsAI ProductsAI Infrastructure
Sheet
01 / 06

A live graph of a multi-site plant, with drift detection on every machine and a planning agent whose schedule changes a planner approves.

A Promeing Concept: a studio study of a system we would build, set in a realistic scenario. It describes no client, no deployment and no measured result.

Problem

Planning runs on ERP exports, maintenance logs, supplier emails and the memory of a few senior planners. When a spindle starts to drift or a supplier slips, the schedule finds out late, and the reasoning behind each change lives in someone’s head.

Context

The scenario: a multi-site manufacturer of machined components, working to tight tolerances on mixed batches. The machines already report their state, orders live in the ERP, and maintenance history is split between a ticketing system and free-text shift logs. None of it is connected, so every re-plan starts with a spreadsheet and a phone call, and the planners who know which machine to trust are the ones nobody can spare.

Visualisation: inside a machining centre, a cutting tool hangs above a machined aluminium block clamped in its fixture, a thin cyan scan line crossing the block.
VisualisationFig. 01

System

Machine, order and maintenance events stream into a live graph of the plant: machines, tools, work orders, materials and the dependencies between them. Anomaly models watch each machine’s signals for drift against that machine’s own baseline, not a fleet average. When something moves, retrieval brings up the asset’s maintenance history and similar past incidents, and a planning agent drafts a schedule change inside the constraints the planners have written down. A constraint checker rejects anything infeasible before a person sees it. The planner approves, edits or rejects the proposal, and every suggestion carries a “why” trace: the events, records and rules it used.

AI architecture

Events from machines, the ERP and maintenance systems are normalised into one plant graph. Drift models and retrieval feed a planning agent that can only propose; the planner console is where decisions are made, and every decision is written to a log.

AI architecture of Operations Intelligence Platform

Layers

  • Interface: Planner console
  • Agents: Planning agent, Constraint checker
  • Retrieval: Maintenance history search
  • Models: Per-machine drift models, Private language model
  • Data: Event stream, Plant graph
  • Infrastructure: Machine and ERP connectors, Decision log

Connections

  • Machine and ERP connectors → Event stream
  • Event stream → Plant graph
  • Event stream → Per-machine drift models
  • Plant graph → Maintenance history search
  • Per-machine drift models → Planning agent
  • Maintenance history search → Planning agent
  • Private language model → Planning agent
  • Planning agent → Constraint checker
  • Constraint checker → Planner console
  • Planner console → Decision log
ArchitectureWhat people use at the top, what it stands on at the bottom

Interface

The planner console: the live plant on the left, the drafted change in the middle, and on the right the trace that explains it. Nothing reaches the schedule until a planner approves it.

Interface mockSchematic, with sample data

  1. A: The plant as a graph. The machine the drift models are attending to is marked; everything else holds still.
  2. B: The proposal is drafted, checked against written constraints and shown as a change to the schedule, never applied.
  3. C: The why trace: every event, record and rule the agent used, each with its source ID and timestamp.

Numerals appear only in dates, IDs and timestamps. Indicators read — until there is something true to show.

Technology

  • Event streaming (Kafka-compatible)
  • Machine connectors over OPC UA and MQTT
  • Time-series store for machine signals
  • Graph database for the plant model
  • Per-asset anomaly models for drift detection
  • Hybrid vector + keyword search over maintenance logs
  • Constraint solver for schedule feasibility
  • Private language model deployment for drafting and explanation

Expected outcome

Expected

Earlier warning when equipment starts to drift, re-plans that begin from a checked proposal instead of a blank spreadsheet, and planning knowledge that no longer depends on a few people.

Qualitative and unmeasured. A pilot measures it against acceptance criteria agreed at the start.

What we would measure

  1. Schedule adherence
  2. Unplanned downtime
  3. Hours spent re-planning
  4. Lead time from drift alert to plan change
  5. Proposals approved without edits

Metric names only. Values exist once a pilot measures them.

What a pilot would need

  1. Read access to ERP order and routing exports
  2. Signal history for one cell, from the machines or an existing historian
  3. Maintenance tickets and shift logs for the same machines
  4. Two planners to write down the constraints and review every proposal
  5. A clear list of what the agent may draft, and what it may never touch
  6. A private environment inside the plant network or a chosen cloud region

Promeing ConceptScenario set in Zürich

Building something like this?

Bring the problem in its messiest form. We’ll tell you honestly whether AI is the right way to solve it.

Discuss a system like this All work