Proofa
Autonomous fermentation and proofing control that hits target rise every batch.
agent.ferment_proof
Products
Buy the stage that hurts. Add the rest when it pays.
Five products, one plant-edge runtime, one audit and genealogy backbone, one data flywheel. Proofa corrects the dough, Gramex portions it to weight, Ovenix bakes it to colour and moisture at minimum energy, Vizra perceives outcomes and feeds each defect back to its cause, and Bakesim simulates the whole line before every run.
Illustrative scenario: Plant run · one bread line, flour-lot change at the silo · shared oven. Not a measured run.
The ecosystem
Five products, one loop
These are one coherent bakery autonomy ecosystem, not separate bets. They share the plant-edge inference infrastructure, the food-safety audit and genealogy backbone, the multi-tenant data plane and one compounding flywheel.
Gramex
Autonomous depositing and portioning control that erases weight giveaway at line speed.
agent.makeup_deposit
Ovenix
Autonomous oven control that holds colour, bake and moisture to spec while cutting energy.
agent.bake_cool
Vizra
Inline vision that catches defects and foreign bodies before they leave the bakery.
agent.defect_inspect
Bakesim
An as-baked product twin that hits target quality, weight and takt before the run starts.
agent.orchestrator
Proofing wedge · agent.ferment_proofProofa
Autonomous fermentation and proofing control that hits target rise every batch.
The problem
Dough is alive. Fermentation and proofing depend on flour lot, hydration, yeast activity, ambient temperature and humidity, all of which drift shift to shift and season to season. Most industrial bakeries still proof on fixed time-and-temperature profiles set by a scarce head baker, then eyeball the rise. When the dough runs fast or slow, the whole downstream line pays: under-proofed loaves bake dense and short, over-proofed dough collapses, weight and volume drift out of spec, and waste, downgrade and giveaway climb.
What Proofa does
Proofa fuses inline dough temperature, humidity, height and CO2 signals with flour-lot and recipe context, predicts the rise curve for the batch in front of it, and controls proofer temperature, humidity and dwell to land target rise, volume and structure rather than a fixed clock. It compensates for flour and ambient variability in real time and hands the corrected dough to the oven ready to bake right the first time.
Key features
- Real-time rise-curve prediction per batch from fused sensor, recipe and flour-lot signals
- Closed-loop control of proofer temperature, humidity and dwell time
- Flour-lot and ambient drift compensation without a baker at the panel
- Graduated autonomy with human-in-the-loop checkpoints and setpoint approval
- Immutable, assurance-grade audit log of every proof decision for food-safety traceability
AI capabilities
| Capability | Status |
|---|---|
| Time-series forecasting of fermentation and proof rise | design scope |
| Multimodal sensor fusion: temperature, humidity, height, CO2 | design scope |
| Closed-loop control policy tuned per product and recipe | bounded level planned |
| Bakery-process reasoning grounded in recipes and food-safety standards | design scope |
NVIDIA stack
Jetson Orin at the proofer for inline fusion and rise prediction; Holoscan for synchronised sensor streams; TensorRT for sub-second edge inference; Triton and NIM for serving across lines and SKUs; NeMo and Guardrails for cited food-safety reasoning; cuOpt for proofer scheduling and dwell allocation; RAPIDS ETL and DGX/HGX training are planned.
- For
- Industrial bread, bun and roll, pizza and flatbread, and cake makers running continuous fermentation and proofing lines, including private-label and co-manufacturers.
- Price
- $13,000 per proofing line per month, expanding to the Plant tier as adjacent agents activate; outcome pricing on measured waste and giveaway reduction for enterprise.
- First release
- Instrument one proofing line, ingest temperature, humidity and height, ship rise prediction and recommended setpoints with human approval, then graduate to closed-loop control after a paid pilot proves rise-consistency and waste targets.
- In the loop
- Hands corrected dough to Gramex and Ovenix, feeds rise outcomes to Vizra and Bakesim, and shares the Doughex orchestrator, edge runtime and data flywheel.
Giveaway wedge · agent.makeup_depositGramex
Autonomous depositing and portioning control that erases weight giveaway at line speed.
The problem
Every gram over target is money given away, silently, millions of times a day. Depositors, dividers and formers portion dough to a weight spec, but they drift with dough rheology, temperature, hydration and machine wear, so bakeries deliberately overshoot the target to avoid ever going underweight and breaking a legal or customer spec. That safety margin, giveaway, quietly bleeds margin at industrial scale, while underweight faults still slip through. Operators correct by hand between checkweigh readings, always chasing the last batch.
What Gramex does
Gramex fuses inline weight and checkweigher data with dough state and depositor feedback, predicts portion weight for the dough flowing now, and trims depositor and divider setpoints in real time to hold target weight at the minimum safe margin, cutting giveaway without risking underweight. It coordinates with forming and shape control so weight, size and shape land together, first pass.
Key features
- Real-time portion-weight prediction from fused weight and dough-state signals
- Closed-loop trim of depositor and divider setpoints to the minimum safe margin
- Underweight-risk guardrail with graduated autonomy and approval
- Giveaway and first-pass-weight analytics with lot genealogy
- Coordination with forming and shape control for weight, size and shape right first time
AI capabilities
| Capability | Status |
|---|---|
| Time-series and regression portion-weight prediction | design scope |
| Sensor fusion: checkweigher, depositor feedback, dough state | design scope |
| Constrained control policy minimising giveaway under an underweight guardrail | recommend first; bounded level planned |
NVIDIA stack
Jetson Orin at the depositor for sub-100 ms weight prediction and trim; Holoscan for synchronised checkweigher, depositor and dough-state streams; TensorRT for real-time edge inference; cuOpt for margin allocation across parallel heads and lines; Triton and NIM for serving across SKUs; NeMo and Guardrails to block unsafe underweight setpoints; RAPIDS ETL and DGX/HGX training are planned.
- For
- High-volume industrial bakeries with depositing, dividing and forming lines: bread, buns, biscuits, cookies, cake, pizza and tortilla, where per-unit value and volume make giveaway a large, addressable cost.
- Price
- $13,000 per depositing line per month with outcome pricing on measured giveaway reduction; one of the cleanest ROI cases in the plant since giveaway is counted in grams and dollars.
- First release
- Instrument one depositing line with checkweigher and depositor feedback, ship weight prediction, recommended trim and a live giveaway dashboard, then graduate to closed-loop trim after a paid pilot proves giveaway reduction.
- In the loop
- Owns the makeup and deposit stage between Proofa and Ovenix, feeds weight outcomes to Vizra and the Bakesim twin, and shares the Doughex orchestrator, edge runtime and data flywheel.
Energy and bake wedge · agent.bake_coolOvenix
Autonomous oven control that holds colour, bake and moisture to spec while cutting energy.
The problem
The oven is where value is won or lost, and it is the most energy-hungry step in the bakery. Continuous ovens run fixed thermal profiles set months ago, while dough entering the oven varies batch to batch from proof, hydration, flour lot and ambient shifts. Fixed profiles cannot compensate, so bakers chase under- and over-bake, colour drift and moisture faults by hand, on lines that never stop. The result is downgraded product, short shelf life, scrap, recall risk and a gas or electricity bill that dwarfs every other line cost.
What Ovenix does
Ovenix senses surface colour, product profile and inline moisture, predicts the as-baked outcome for the product entering the oven, and tunes oven zone temperatures, airflow, humidity and band speed to land target colour, bake and moisture, then optimises the whole profile for minimum energy per unit at spec. It coordinates with cooling to protect texture and shelf life.
Key features
- Inline colour and moisture sensing with as-baked outcome prediction
- Closed-loop control of oven zone temperature, airflow, humidity and band speed
- Energy-per-unit optimisation at a fixed quality spec
- Cooling coordination for texture and shelf-life protection
- Assurance-grade audit log of every bake decision and lot genealogy
AI capabilities
| Capability | Status |
|---|---|
| Vision regression for surface colour and bake state | design scope |
| Inline moisture and thermal sensor fusion with as-baked prediction | design scope |
| Multi-objective control: hit spec at minimum energy | recommend first; bounded level planned |
| GPU-accelerated oven CFD informing the control policy | design scope; compute-heavy |
NVIDIA stack
Jetson Orin/Thor at the oven for colour and moisture inference and zone control; DeepStream and TensorRT for 10 to 60 FPS bake-colour vision; Holoscan for synchronised colour, moisture and thermal streams; Modulus for physics-informed oven thermal and airflow models; cuOpt for oven scheduling, changeover and energy allocation; Triton and NIM for serving across ovens; NeMo and Guardrails for cited bake-spec reasoning; DGX/HGX for training and oven CFD and RTX workstations for calibration are planned.
- For
- Industrial bread, bun, biscuit and cracker, cookie, cake, pizza and tortilla makers running continuous baking ovens, including private-label and co-manufacturers under sustainability and energy mandates.
- Price
- $13,000 per baking line per month with outcome pricing on measured energy and waste or downgrade reduction; the oven's energy bill makes value-based pricing especially strong here.
- First release
- Instrument one oven with colour and moisture sensing, ship as-baked prediction, recommended zone setpoints and an energy dashboard, then graduate to closed-loop control after a paid pilot proves energy-per-unit and downgrade targets.
- In the loop
- Owns the bake and cool stage, takes corrected dough from Proofa, feeds bake outcomes to Vizra and the Bakesim twin, and shares the Doughex orchestrator, edge runtime and data flywheel.
Perception wedge · agent.defect_inspectVizra
Inline vision that catches defects and foreign bodies before they leave the bakery.
The problem
A single foreign body, allergen cross-contact or seal failure can trigger a recall that costs millions and breaks customer trust overnight. Everyday defects, under- and over-bake colour, holes, cracked tops, misshapes, wrong size, blistering, short weight and bad seals, drive downgrade and complaints. Most bakeries inspect with spot checks, a standalone checkweigher or metal detector, and human eyes on a fast-moving line. Rare, dangerous events are exactly the ones people miss, and the images to train on barely exist because failures are rare and sensitive. Inspection also stays read-only: it flags a reject but never tells the line how to stop making the fault.
What Vizra does
Vizra feeds high-speed cameras and inline sensors into edge vision models that detect and predict colour and bake, shape, size, holes, cracks, blistering, foreign bodies and seal or fill faults in real time at line rate. Where real defect images are too rare to collect, Vizra trains on synthetic rare-event libraries generated in simulation. Because it lives in Doughex, Vizra does not just reject: it feeds defect signals back to Proofa, Ovenix and Gramex so the line corrects the root cause.
Key features
- Real-time multi-defect, foreign-body and seal or fill vision at 10 to 60 FPS per station
- Synthetic rare-event training for defects too rare to collect
- Closed-loop feedback to proof, deposit and oven agents to fix the root cause, not just reject
- Permission-aware defect-image retrieval and an assurance-grade audit trail
- Lot genealogy and food-safety traceability on every reject
AI capabilities
| Capability | Status |
|---|---|
| Fine-tuned vision classification and detection for colour, bake, shape, hole, foreign-body and seal | design scope |
| Multimodal fusion with inline weight and moisture | design scope |
| Synthetic-data augmentation for rare defects | design scope via Replicator and Cosmos |
| Defect-cause reasoning grounded in specs and food-safety standards | design scope |
NVIDIA stack
Jetson Orin/Thor for sub-100 ms multi-defect inference at line rate; Metropolis, DeepStream and TensorRT for high-FPS multi-camera pipelines; Holoscan for camera and inline sensor fusion; Cosmos and Omniverse Replicator for synthetic foreign-body, bake and deformation images; Triton and NIM for serving many defect models across stations; NeMo, Retriever and Guardrails for grounded defect and food-safety Q&A; RAPIDS ETL, DGX/HGX training and RTX/OVX synthetic generation are planned.
- For
- All industrial bakeries with food-safety and quality mandates: bread, buns, biscuit and cracker, cookie, cake, pizza, tortilla and cereal, especially private-label and co-manufacturers held to BRCGS, FSMA, HACCP and customer specs.
- Price
- $13,000 per inspection line per month as a low-friction land wedge, expanding to Plant and Enterprise as the same platform adds control modules; outcome pricing on reduced downgrade and complaints.
- First release
- Deploy cameras on one line, ship top-defect and foreign-body detection with reject control and a dashboard, seed training with synthetic rare-event data, then close the loop to the control agents after a paid pilot proves escape-rate and downgrade targets.
- In the loop
- The perception hub: it senses outcomes for the whole line and feeds Proofa, Ovenix, Gramex and the Bakesim twin, sharing the Doughex orchestrator, edge runtime, vector store and data flywheel.
Twin backbone · agent.orchestratorBakesim
An as-baked product twin that hits target quality, weight and takt before the run starts.
The problem
Bakeries prove out new products, recipes and lines the expensive way: physical trial runs that burn ingredients, energy and line time, guided by a scarce process engineer's intuition. Changeovers stall the line while operators dial in proof, deposit and oven settings by trial and error. When a new SKU or a flour-lot change lands, nobody knows the as-baked colour, weight, volume and takt until dough is already scrapped. Simulation exists for single machines, but no one simulates the whole mix, proof, deposit, bake and cool line to predict the finished product before committing the run.
What Bakesim does
Bakesim is the digital-twin engine of the Doughex platform. It builds a physics-informed, GPU-accelerated twin of the bakery line, oven thermal zones and airflow, proofing heat, humidity and CO2, dough rheology and deformation, and robot cells, and simulates the as-baked product against the as-designed target. It optimises proof, deposit and oven profiles to hit target quality, weight and takt before the first loaf, then hands the validated setpoints to Proofa, Ovenix and Gramex to execute. It also generates rare-defect scenarios to train Vizra.
Key features
- Physics-informed line twin: oven CFD, proof dynamics, dough rheology and deformation, robot cells
- As-baked versus as-designed prediction of colour, weight, volume and takt
- Optimisation of proof, deposit and oven profiles before the run
- One-click handoff of validated setpoints to the control agents
- Rare-defect scenario generation to train inspection
AI capabilities
| Capability | Status |
|---|---|
| GPU-accelerated CFD and process simulation | design scope; compute-heavy |
| Surrogate models that speed twin iteration | design scope; per-plant calibration planned |
| Multi-objective optimisation of setpoints for quality, weight, takt and energy | design scope |
| Synthetic scenario generation for rare events | design scope via Omniverse and Cosmos |
NVIDIA stack
DGX/HGX and OVX for oven CFD, process simulation and twin optimisation (planned); Omniverse to build and run the line twin; Modulus for physics-informed oven, proof and rheology models; Cosmos and Omniverse Replicator for rare-defect scenarios; cuOpt for setpoint, changeover and energy optimisation; Isaac Sim for robot cells in the twin; Triton and NIM to serve surrogates; RTX workstations for engineer-side authoring and Jetson for on-line surrogates.
- For
- Industrial bakeries and multi-site bakery groups launching new products and recipes, running frequent changeovers or commissioning new lines, plus their process-engineering and R&D teams.
- Price
- Included in the Plant tier at $85,000 per month and in Enterprise agreements as the twin-to-run capability; also a wedge for R&D and changeover-heavy bakeries, with value-based pricing on saved trial-run ingredients, energy and line time.
- First release
- Build an oven-CFD and proof twin for one product family, validate as-baked colour, weight and takt prediction against real runs, and ship setpoint optimisation with one-click handoff to the control agents on a paid Plant engagement.
- In the loop
- Validates and hands setpoints to Proofa, Ovenix and Gramex, trains Vizra with synthetic defects, and is calibrated by their real outcomes on the shared Doughex platform and data flywheel.
Run timeline
The products in one run
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.
Compare
What is in each plan
Modules are licensed per line on the Line tier and bundled on Plant and Enterprise.
| Capability | Line | Plant | Enterprise |
|---|---|---|---|
| Lines covered | 1 | All on site | All in group |
| Agent modules | 1 of 9 | All 9 | All 9 + custom models |
| Bakesim twin | Not included | Included | Custom twin domains |
| Plant-edge node | Included | Per line | Fleet managed |
| Guarded PLC writes | Scoped tags | All scoped tags | Group policy |
| Lot genealogy | Included | Included | Included + export |
| Autonomy levels | Observe, recommend, approve, bounded | Observe, recommend, approve, bounded | Observe, recommend, approve, bounded |
| Deployment | Plant edge + cloud | Plant edge + cloud | On-prem or private cloud |
| Outcome pricing | On request | Available | Standard |
| Indicative price | $13,000 / mo | $85,000 / mo | $600k – $8M ACV |
Tool calls
One log, every product
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.
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 |
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.
Design targets
Product design targets
The numbers Doughex is engineered against, from the GPU utilisation plan.
<100 ms
reject decisions for inspection at the plant edge
10–60 FPS
vision inference per station, depending on the station
8–24
synchronised cameras per high-speed line
1–5 s
supervisory control interval for proof, bake and deposit loops
50–200
GPU-hours of fine-tuning per product family per release
100k–1M
synthetic rare-event images per defect family, validated before use
Design targets from the GPU utilisation plan. Nothing on this page is a measured plant result; measurements start when the first design-partner line runs in observe mode.
From the plant floor
Who this is built for
The three people in an industrial bakery whose week changes when the line runs itself, and what each of them needs from Doughex.
Plant or Operations Director
Owns production rate, quality, waste, giveaway and yield, energy and food safety. Wants a bakery that holds spec at higher rate with fewer interventions, and a number that justifies the spend.
Bakery or Process Engineer
Owns recipes, dough development, proof and oven profiles, process windows and yield. Approves and corrects the agents in recommend mode; those corrections train the models.
Quality and Food-Safety Manager
Owns HACCP, FSMA, BRCGS, ISO 22000 and allergen conformance, foreign-body and defect conformance, and lot genealogy. Needs every action grounded, cited and written to an immutable record.
IT/OT and sustainability leads approve the deployment. There are no customer quotes on this site yet; design partners will speak for themselves when they choose to.
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.
Enterprise
Standardise autonomy across the group
One policy model, one audit trail and one set of yield, waste, giveaway and energy benchmarks across every bakery in the group, with each site's recipes and tolerance models kept private to that site.
- Multi-site plant-edge fleet with shared model governance
- Custom recipe, product and tolerance models per site
- SSO and role-based access, named approvers (roadmap, 6 to 12 months)
- Model versioning, validation reports and rollback
- On-prem or private-cloud deployment
- SLAs and outcome-based components on the highest-value workflows
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
Pick your first product
Most bakeries start with Gramex on a depositing line, Ovenix on an oven or Vizra at oven exit. Tell us which number you need to move.