Deployment & integrations
Jemba runs on the IT/OT infrastructure the plant already has. No new sensor, no intervention on the machines, and no integration project standing between you and the first number.
Any source or format — a rough CSV export, machine and sensor feeds, historians, a live MES or SCADA API. Ingested, cleaned and shaped by us.
No new sensor and no intervention on the machines. One lightweight score per machine every ten minutes — no GPU, no external service.
From a named line to a reviewed result, on a plant-level scope. The long pole in most projects is integration, and there isn’t one here.
Works with the landscape you already run.
Brownfield or greenfield, with no standardisation of your stack required. Both client cases ran on exports the plant was already producing.
| What reaches us | What that looks like in practice | Proven on |
|---|---|---|
| Machine event log | Run/stop records only — no sensors, no process data | 4 machines |
| CSV or spreadsheet export | One file, no schema imposed — process, quality and material columns together | 336 runs |
| Historian | Time-series tags, pulled on a schedule | supported |
| MES / SCADA | Live API, read-only | supported |
| Custom or in-house system | Whatever the plant already exposes | supported |
Factories have spent more than a decade instrumenting. The data exists and it dies in storage — which means there is nothing left to deploy in the plant before value can be extracted. “We only have a CSV” is a starting point, not a blocker.
Where Jemba sits next to what you already run.
Jemba is not a historian and not an MES. It reads what those systems already hold, and computes the layer neither of them does.
| Capability | Historian | MES | Jemba |
|---|---|---|---|
| Machine data collection — states, tags, alarms | yes | — | reads it |
| Time-series data storage | yes | — | reads it |
| OEE and KPI calculation | — | yes | reads it |
| Production order execution | — | yes | — |
| Per-machine adaptive anomaly thresholds | — | — | only Jemba |
| Flags traced back to the variables behind them | — | — | only Jemba |
| Automatic variable selection, hundreds down to ten | — | — | only Jemba |
| Optimal operating regions as setpoint ranges | — | — | only Jemba |
| Trustability check before a result is shown | — | — | only Jemba |
| One-click retraining by your own team | — | — | only Jemba |
The full requirement list, in five lines.
Taken from the aerospace and defence deployment, in a regulated environment.
- Data
- The event log already collected. Nothing new to gather.
- Hardware
- None added. No new sensor, and no intervention on the line.
- Compute
- One lightweight score per machine every 10 minutes. No GPU, no external service.
- Upkeep
- Periodic threshold recalibration, automatable on a monthly cadence.
- Client effort
- No man-days. Neither client case asked for data preparation or engineering time.
Where your data is held, who can see it, and what happens to it afterwards is covered on Security.
What actually runs on the line.
No streaming pipeline, no GPU, no agent installed on the machines. The loop below is the whole of it.
Tell us the transport you already use.
Name one line and one target variable. We read the export you already produce and tell you within a week whether it carries the levers.
