Connectors
Declared read and write scopes for PLC and SCADA, checkweighers, sensing, QA, MES, cameras and meters.
Developers
Autonomy policy is declared. Review it like code.
There is no public SDK yet. What exists is the integration surface design partners work with: connectors, an autonomy policy per loop, cited recommendations, versioned models and an audit record for every action. This page describes that surface honestly.
Illustrative scenario: Plant run · one bread line, flour-lot change at the silo · shared oven. Not a measured run.
Developers
Every action is a record
There is no SDK to download yet. What design partners get is the integration surface: connectors, an autonomy policy declared per loop, and an audit record for every reading, recommendation, write and approval. This is the shape of one record, illustrative.
What the surface gives you
- Connectors to PLC and SCADA, checkweighers, moisture and colour sensing, MES, cameras and meters, with declared allow-lists and limits
- An autonomy policy per loop: level, tags, rate and magnitude limits, named approvers
- Citations on every recommendation to the recipe, spec or procedure it relied on
- Model versions named in every record, with rollback by version
- Export of the audit log and lot genealogy to your quality system
// one write, as the audit log would hold it
{
"run": "run_scn_01",
"step": "deposit.trim",
"agent": "agent.makeup_deposit",
"level": "bounded",
"action": { "tool": "plc.write_setpoint", "tag": "DIV1.TRIM" },
"limits": { "max_step": "declared per tag", "per": "declared per tag" },
"evidence": ["checkweigher.read", "depositor.read_feedback"],
"citation": "spec:SANDWICH-800 declared weight v3 §2",
"policy": "permitted",
"models": { "weight": "versioned", "policy": "versioned" },
"human": null,
"outcome": "inside spec · minimum safe margin"
}
Capabilities
What the surface gives you
Autonomy policy
Level, tag allow-list, rate and magnitude limits and named approvers per loop, versioned like any other change.
Cited recommendations
Every recommendation names the recipe, spec or procedure it relied on; retrieval is tenant-isolated and permission-aware.
Model router
The best or cheapest model serves each step; high-volume steps move to fine-tuned open models, reasoning steps use frontier models.
Evaluation gates
Golden datasets and model-as-judge evaluations gate model and prompt changes in CI.
Export
Audit log and lot genealogy export to the plant's quality system.
Run timeline
What a run record contains
Every Doughex run is an ordered, inspectable sequence. This is run_scn_01, an illustrative scenario: Plant run · one bread line, flour-lot change at the silo · shared oven. Scenario complete · every stage inside spec · one human approval at the oven.
run_scn_01
scenario · not measured
SUCCEEDED
-
01
order.receive
SUCCEEDED
0.8 s
Plant Orchestrator · Pulled the product spec, the recipe, the HACCP plan with its bake kill-step and metal-detection control points, the allergen status of the line and the new flour lot's certificate from MES and the lab system; locked the target envelope for the run.
-
02
twin.simulate
SUCCEEDED
38 s
Plant Orchestrator · Simulated 24 candidate profiles across mix, proof, deposit and oven on the Bakesim as-baked twin for the new flour lot; ranked them on colour and moisture margin, weight margin, energy per unit and takt, and discarded every candidate that thinned the bake kill-step margin.
-
03
mix.dose
SUCCEEDED
12 m 40 s
Dose-and-Mix · Adjusted hydration and mix energy for the new lot's absorption so dough temperature and development landed on target; dough state was handed to the proofer with its predicted rise curve.
-
04
proof.hold
SUCCEEDED
58 m
Ferment-and-Proof · Predicted the rise curve from inline height, temperature, humidity and CO2, then trimmed proofer humidity and dwell so rise and volume landed on target instead of running fast on the fresher lot.
-
05
deposit.trim
SUCCEEDED
continuous
Makeup-and-Deposit · Fused checkweigher readings with dough state and divider feedback and trimmed the divider in real time so portion weight sat at the minimum safe margin above the declared weight, with the underweight guardrail armed.
-
06
approve.human
APPROVAL
1 m 36 s
Plant Orchestrator · The twin's lowest-energy candidate wanted a zone-three temperature outside the site's bounded envelope. Held for the shift process engineer, who approved the step with a tighter colour alarm.
-
07
bake.zone
SUCCEEDED
continuous
Bake-and-Cool · Ran the oven against the twin's colour and moisture prediction; stepped zone temperatures and band speed toward the minimum-energy profile while predicted crust colour and crumb moisture stayed inside spec and the core-temperature kill step was verified on every reading.
-
08
inspect.line
SUCCEEDED
continuous
Defect-and-Inspect · 12 camera streams at oven exit, cooler exit and packing at the plant edge: colour, shape, holes, cracks, foreign-body and seal checks on every unit; two pale-top rejects were attributed to a draught at zone one and the oven agent was notified.
-
09
handle.pack
SUCCEEDED
continuous
Robot-and-Handling · Robotic depanning, tray transfers and packaging handling paced to the line, with rejected units diverted off the belt and the safe zone around each cell monitored.
-
10
release.genealogy
SUCCEEDED
1 m 05 s
Quality-and-Conformance · Lot released: flour lot, recipe, mix and proof setpoints, portion weights, oven profile, kill-step readings, inspection rejects and every human decision written to the genealogy and checked against spec and the HACCP plan.
Tool calls
Streaming a run
Every tool invocation, argument and result is written to an immutable, human-readable log, and every reasoning step is expandable. Nothing about a run is hidden from the plant. The log below is the scenario run, not a measured one.
- 04:40:02mes.read_order({ line: "BR-2", product: "SANDWICH-800", flour_lot: "F-3312" })
- 04:40:02ok spec locked · HACCP plan v6 · CCPs: bake kill step, metal detection
- 04:40:03lab.read_results({ lot: "F-3312", test: "flour_certificate" })
- 04:40:03ok protein and absorption read · lot accepted at the silo
- 04:40:04twin.simulate({ candidates: 24, horizon: "shift" })
- 04:40:42ok best profile #7 · kill-step margin held · lowest energy per unit
- 04:40:43policy.evaluate({ profile: 7, level: "bounded" })
- 04:40:43ok 8 writes permitted · 1 write requires human approval
- 04:40:44plc.write_setpoint({ tag: "MIX1.ENERGY", basis: "lot absorption + dough temp" })
- 04:53:24ok dough temperature on target · development inside window
- 04:53:25plc.write_setpoint({ tag: "PRF1.DWELL", basis: "rise curve + humidity" })
- 05:51:30ok rise and volume on target · proof not running fast
- 05:51:31plc.write_setpoint({ tag: "DIV1.TRIM", mode: "min_safe_margin" })
- 05:51:31ok portion weight at minimum safe margin · underweight guardrail armed
- 05:51:33approval.request({ action: "oven.zone3", reason: "outside bounded envelope" })
- 05:53:09ok approved by the shift process engineer · tighter colour alarm set
- 05:53:10plc.write_setpoint({ tag: "OVN1.ZONE3_T", mode: "min_energy" })
- 05:53:10ok predicted colour and moisture inside spec · kill step verified
- 05:53:11vision.stream({ cameras: 12, models: ["colour_shape", "foreign_body", "seal"] })
- 06:21:48reject: pale top · unit 2231 · attributed to draught at zone one
- 06:21:49defect.attribute({ event: "pale_top", cause: "oven.zone1_draught" })
- 06:21:49ok oven agent notified · second reject at 06:23:12 · zone one corrected
- 06:21:50robot.execute({ cell: "DEPAN-1", mode: "guarded", pace: "line" })
- 06:21:50ok depanning and tray transfer paced · rejects diverted · safe zone clear
- 08:14:20mes.release_lot({ lot: "BR2-3312", genealogy: "full" })
- 08:15:25ok lot released · scenario complete
Reasoning trace
Goal, plan, thought, action, observation, exactly as the orchestrator would record it.
GoalStart flour lot F-3312 on bread line BR-2, hold development, r…
Start flour lot F-3312 on bread line BR-2, hold development, rise, weight, colour and moisture on target through the change, and release the lot with full genealogy.
PlanSimulate the whole profile on the twin first. Lead with the mi…
Simulate the whole profile on the twin first. Lead with the mixer so the proofer gets dough with a known rise curve and the divider gets dough with a known density. Verify the bake kill step continuously. Let the oven chase minimum energy only inside the bounded envelope; hold anything beyond it for a person.
ThoughtThe standing recipe overshoots portion weight and runs the ove…
The standing recipe overshoots portion weight and runs the oven hot to protect against lot variability. With continuous dough-state, weight and colour estimates the margins can sit at their minimum safe values. The saving is giveaway and energy, not safety margin: the kill step is never a candidate for optimisation.
Actiontwin.simulate(candidates=24) → profile #7: minimum safe weight…
twin.simulate(candidates=24) → profile #7: minimum safe weight margin, kill-step margin unchanged, lowest predicted energy per unit.
ObservationProfile #7's zone-three temperature sits outside the site's bo…
Profile #7's zone-three temperature sits outside the site's bounded envelope. The policy engine routes that single write to the shift process engineer and permits the other eight.
ActionExecute profile #7 at the bounded level: mixer, proofer and di…
Execute profile #7 at the bounded level: mixer, proofer and divider writes proceed; the zone-three write waits.
ObservationApproval granted at 05:53:09 with a tighter colour alarm. Two …
Approval granted at 05:53:09 with a tighter colour alarm. Two pale-top rejects at oven exit were attributed to a draught at zone one and corrected by the oven agent.
OutcomeScenario complete. The lot released with flour lot, setpoints,…
Scenario complete. The lot released with flour lot, setpoints, kill-step readings, inspection events and the human decision in the genealogy. No measured plant result is claimed; this is the run the platform is designed to execute.
Workflow
From idea to a line, safely
- Declare. Tools, tags and limits for the agent, and the autonomy level for the loop.
- Observe. Run against live plant data; compare predictions to the plant's own checks; nothing is written.
- Evaluate. Golden datasets and model-as-judge checks in CI before a model or prompt version is promoted.
- Rehearse. High-impact moves are simulated on Bakesim where a twin domain exists.
- Recommend, then bounded. Writes only after the accuracy and food-safety gates, inside declared limits.
- Record and retrain. Every action and correction is logged; corrections become training events.
Autonomy
Five levels, set per loop
A bakery does not go from manual to bounded control in one step. Doughex makes the level explicit per loop, auditable and reversible at any time, and some decisions never leave the person.
| Level | What the agent does | What the person does | When |
|---|---|---|---|
| Observe | Predicts rise, weight, colour, moisture and defects; writes nothing | Runs the bakery as today; compares predictions to QA checks | First phase with every design partner |
| Recommend | Proposes mix, proof, deposit and oven moves with the evidence behind each | A process engineer or baker approves or corrects each one | After accuracy is proven against the baseline |
| Approve to apply | Prepares the write; applies it only on a named person's approval | Approves per move; reviews the shift record | Once recommendations are trusted |
| Bounded | Writes low-risk oven, depositing and inspection setpoints inside explicit limits | Approves anything above the limits; reviews exceptions | After the food-safety and ROI gates agreed up front |
| Exceptions | Escalates anything outside its envelope, CCP-adjacent moves and release decisions | Always decides these; the agent never does | Permanent |
Multi-agent handoff
Agents negotiate, they do not collide
Two agents will want the same actuator. The orchestrator arbitrates on the run goal, with food safety above everything, and the handoff is logged like any other step.
Contested move: oven band speed
-
01yield_takt.request(band +4%) SUCCEEDED0.2 s
Yield-and-Takt wants a faster band through the oven so the line clears the proofer backlog and the packing hall is not left waiting.
-
02bake_cool.request(band hold) SUCCEEDED0.2 s
Bake-and-Cool requires the band speed that keeps core temperature above the kill-step threshold for the full dwell. That is the HACCP critical control point.
-
03orchestrator.arbitrate SUCCEEDED0.4 s
Food safety outranks takt under every run goal. The critical control point wins the actuator; the request for more speed is logged with its score and the reason it lost.
-
04yield_takt.handoff(resequenced) SUCCEEDED90 s
Yield-and-Takt recovers the schedule by trimming proofer dwell on the next batch within its window and resequencing the changeover. Takt is met without touching the kill step.
Arbitration rules
- Run goal first. Every request is scored against the declared goal, not against the requesting agent's local objective.
- Food safety outranks everything. A critical control point is never an optimisation variable. A kill-step or foreign-body escape is a recall; a takt miss is a schedule.
- Time-boxed ownership. An agent holds a contested actuator for a bounded window, then must re-justify.
- Everything is logged. The losing request, the score and the reason all appear in the run record.
- Deadlocks escalate to a person rather than resolving by timeout.
Accelerated computing
Physical AI, at the plant edge
Dough is alive and the lines never stop, so perception has to be local and fast. Doughex runs GPU inference at the plant edge and keeps training, simulation and optimisation in the cloud, in a private cloud or on-prem. Items marked planned are on the roadmap, not running.
Edge perception
8 to 24 cameras per line plus inline moisture, weight, thermal and metal or X-ray streams. Design target: sub-100 ms reject decisions, 10 to 60 FPS per station, offline-tolerant operation at the plant edge.
Model serving
Bake-prediction, defect, weight, shelf-life and bakery-reasoning models behind one orchestrator, with version routing by product, line and station. Plants run many lines, SKUs and models at once.
Training (planned)
Vision, time-series, multimodal and bakery-process models fine-tuned from batch telemetry, images, engineer corrections and lab outcomes. Initial design target: 50 to 200 GPU-hours per product family per release.
Digital twin (planned)
GPU-accelerated oven CFD, proof heat and humidity dynamics, dough rheology and deformation, and robot cells, run as-baked before the run to find quality-safe, low-energy profiles.
Synthetic data (planned)
Rare foreign-body, under- and over-bake, blistering, cracked-top, hole, deformation and seal or fill scenarios, generated with domain randomisation and validated against real plant events before use.
Optimisation
Oven and changeover scheduling, energy allocation across zones and lines, proof dwell allocation and line balancing, recomputed on the GPU when the line is disrupted.
Robotic handling
Pan loading and unloading, tray transfers, reject diversion and packaging handling, with perception and motion policies built in Isaac Sim before they touch the line.
Integrations
It speaks plant, not cloud
Doughex reads and writes through the systems already on the floor. No parallel historian, no new HMI, no rip-and-replace. Connectors are built against each design partner's stack first; long-tail integrations are out of scope for the first release.
PLC and SCADA of mixers, proofers, dividers and depositors, ovens, coolers and slicers
Setpoint reads, guarded writes, interlocks untouched
Checkweighers, inline moisture and NIR, thermal cameras, dough height, temperature and humidity
Continuous product and process state
Metal detectors and X-ray systems
Read and verified; reject interlocks stay the plant's
Orders, recipes, product specs, lot genealogy, allergen status
Targets in, release records out
Multi-camera stations at oven exit, cooler exit, slicer and packaging
Frames, defect events, reject commands
Plant and oven-level gas and electricity meters
Hard constraints for the oven profile and schedule
Isaac-driven depanning, tray transfer and packaging cells
Perception and motion for pans, trays and packs
SSO and role-based access; SOC 2 on the roadmap
Named approvers, scoped roles
Guardrails
An agent that can move a setpoint needs a leash
Doughex writes to production equipment in a food plant. Every capability is scoped, every write is policy-checked, every output is cited, and every action is written to an append-only audit log the plant owns.
- Bounded action space. Each agent can only write to an explicit tag allow-list, inside per-tag rate and magnitude limits, at the autonomy level the plant has set.
- Critical control points are read, never written. The bake kill step, metal detection and X-ray rejects, allergen changeover and release decisions stay with the HACCP plan and the people who own it.
- Policy engine before every write. Autonomy level, interlock state, product, allergen status, shift and operator presence are evaluated before a setpoint moves.
- Grounded and cited. Every recommendation carries a citation to the recipe, spec or procedure it relied on. Retrieval is tenant-isolated and permission-aware.
- Immutable audit log. Append-only, exportable and retained on the plant's own storage, aligned to HACCP, FSMA, BRCGS and ISO 22000 record-keeping.
- Hard fallback. If the edge node, the network or a model stops, the line keeps running on its existing PLC and SCADA control and interlocks.
- Tenant and IP isolation. Recipes, customer specs and tolerance models never cross a customer boundary. On-prem deployment available.
Assurance posture
| Item | Scope | Status |
|---|---|---|
| SOC 2 Type I | Cloud control plane | QUEUED Roadmap, first 6 months |
| SOC 2 Type II | Cloud control plane | QUEUED Roadmap, 6 to 12 months |
| HACCP · FSMA · BRCGS · ISO 22000 · allergen | Grounding and record-keeping | RUNNING Design basis for retrieval and the audit log |
| Per-tenant isolation | Data, memory, models | RUNNING Design rule |
| On-prem deployment | Recipe-sensitive bakeries | RUNNING Design option |
Doughex supports your food-safety records. It is not a certification and it does not replace your HACCP plan.
FAQ
Straight answers
The questions plant directors, process engineers and quality managers ask in the first meeting.
Only at the autonomy level your plant has set, and only to an explicit allow-list of low-risk loops inside explicit limits. Every design partner starts in observe mode, where Doughex predicts and writes nothing. Recommend mode follows, where a process engineer approves each move. Bounded autonomy on oven, depositing and inspection loops comes after the food-safety and ROI gates agreed up front.
Critical control points are not optimisation variables. The bake kill step, metal detection and X-ray reject interlocks, allergen changeover and release decisions stay with your HACCP plan and your people. Doughex verifies readings, writes them to an immutable audit log and attaches them to the lot genealogy. It supports HACCP, FSMA, BRCGS, ISO 22000 and allergen records; it is not a certification and does not replace your plan.
Doughex sits above your existing automation as a supervisory layer. If it stops, the line keeps running on its current PLC and SCADA control and the interlocks it already has. A Doughex outage degrades the bakery to the way it runs today, not to a stop.
The first phase is observe mode on one line: Doughex reads your sensors, PLC history, QA checks and MES while you run the line as usual, and we measure its predictions against your own checkweigher, colour and moisture checks. Recommendations start when accuracy is proven against that baseline, and improve as plant-specific history and engineer corrections accumulate.
Recipes, product specs, tolerance models and customer specs are tenant-scoped and never used to train another customer's models. Retrieval is multi-tenant isolated and permission-aware. On-prem deployment is available for bakeries protecting sensitive recipes or private-label specs.
You are, the same as with any control strategy. That is why every write is policy-checked, bounded, logged and reversible, every output carries a citation to the recipe or procedure it relied on, and anything above your threshold waits for a named approver. The audit log records the request, the reasoning, the limits applied and the human decision.
As a design partner, on one line, with one hard metric: giveaway in grams per unit, energy per unit through the oven, downgrade and waste from under- or over-bake, or foreign-body and defect escapes. We instrument the line in observe mode, measure the baseline, move to recommend mode when accuracy is proven, and expand only when the number holds.
Full multi-module autonomy across the whole bakery, long-tail integrations beyond the design partners' stacks, and self-serve onboarding. The first release is one wedge workflow, its connectors, the agent loop with human checkpoints, the review console and the food-safety audit log.
Get started
Build on the run engine
Design partners get the integration surface and the people who built it. Tell us what you want to connect.