Category

What an AI manufacturing app builder actually is

The term is new enough that it means different things to different vendors. Here is a precise definition, then what SubAssembly AI does against it, including the limits.

Definition

An AI manufacturing app builder is software that produces a working application for a plant from a plain-English description or an existing spreadsheet, without a developer writing code. It differs from a general app builder in one way that matters: it knows what a plant is. Lines, machines, stations, parts, routings, shifts, reason codes, operators and serialized units are first-class things, with the rules the plant knows about them, so an app for 'downtime by shift' is built against the real shifts and real reason codes rather than a blank table.

What it should be able to do

  • Build the standard plant applications — OEE and downtime tracking, hourly plan-vs-actual, CMMS, MRP, inventory control, quality/SPC — from a description, and change them from a description.
  • Take a spreadsheet the plant already runs on and keep its numbers while adding the forms, boards and alerts it never had.
  • Compute KPIs by the plant's own definitions (what counts as planned downtime, the ideal cycle time, first-pass yield), so every app, report and spoken answer agrees.
  • Know the plant's rules — 'line 2 can't take material over 2 mm', 'this part needs a 1500-ton tandem line' — and enforce them in scheduling and assignment screens with the reason and the person who recorded the rule.
  • Say plainly when data isn't recorded, rather than showing zero.
  • Explain every number: which records, which definition, which file it came from.

What SubAssembly AI does today

All of the above, on a plant model you set up once (a wizard, or a file) and keep in one place: the hierarchy, custom objects such as tooling and gauges, the part master, BOMs, routings as reusable processes, the plant's knowledge and constraints, and the metric definitions in a Metrics Studio. Five starter kits ship complete. Apps are built by a frontier model, checked by a Build Advisor and a Deep Build audit, and opened in a builder where changes are described in English.

The same plant model answers the phone: the plant line is a number a production manager calls to ask anything the model knows, read-only, every call transcribed. And it answers typed questions on an Ask-the-Plant screen that shows exactly how each answer was built.

OEE by machine from a built app
A built app: OEE by machine on the demo plant.

Where it stops

  • It does not control machines or write to your ERP. It reads exports and files; it is a layer over your data, not a controller.
  • It does not replace an MES in a regulated, validated environment. It can hold traceability data (per-serial events, parameters, holds, EOL results) and answer questions on it, but it is not a validated system of record.
  • It does not invent names. If a file says 'Press 7' and the plant has no Press 7, that is reported, not guessed.
  • Builds are drafts to review. The AI can mis-read a spreadsheet or make an assumption; assumption receipts and the Build Advisor are there to make those visible, not to claim they never happen.
  • Data connectors are files, email and watched folders today. Live database and lake connectors are on the roadmap; there is no 'connect your ERP' button.

How it compares

Against low-code platforms: those give a plant a blank canvas and a drag-and-drop editor; the plant still has to model itself and compute its own OEE in every app. An AI manufacturing app builder starts from the plant model and the definitions, so the modeling is done once.

Against an ERP or MES module: those are complete and rigid; the gap between what the module does and what the plant needs is filled with spreadsheets. The app builder is for that gap — the workbook that became a system.

Questions

Is this low-code?

No code at all is written by the user. The difference from low-code is that the plant model, the metric definitions and the rules exist before the first app, so apps are built against them rather than from scratch.

Can it build any app?

Any plant-floor application over tabular data: tracking, boards, forms, schedules, analysis. It will not build a PLC program, a CAD tool or a consumer app.

Does it need an IT project?

No. The hierarchy is set up in a wizard; data arrives as a CSV, by email or from a folder. IT is involved when a plant wants SSO or a direct data feed.