Line vision and inline analyzers
Fill level, seam and cap, label and OCR, foreign body, clarity and container defects at line speed; gravity, CO2, dissolved oxygen, turbidity, pH, temperature and pressure fused from inline analyzers.
Features
Everything a plant needs to trust software that acts.
Autonomy in a beverage plant is a set of features that make action safe: cited reasoning, graduated control, bounded writes, an immutable audit log, batch genealogy and a twin that rehearses the batch first. This page lists them one by one.
Illustrative scenario: Plant run · one lager batch from brewhouse to can · brewhouse, cellar, filler, tunnel pasteurizer. Not a measured run.
Core
The features that make autonomy safe
Each of these exists because a beverage plant is food-safety-critical, high-speed and continuous.
Prognostics with lead time
Attenuation and finish time per tank, stuck or runaway ferments, filter loading, filler and seamer drift, spoilage and contamination risk, predicted early enough to act.
Adaptive setpoints and recipes
Closed loops on blend, fermentation ramps, carbonation dosing and fill valves, inside documented limits, at the autonomy stage you set.
The plan before the run
Cuvera ranks candidate plans on gravity margin, finish time, CO2 target, PU margin, takt and CO2 and energy, and discards any that thin the pasteurization margin.
Cited reasoning
Every recommendation carries a citation to the recipe, spec, HACCP plan or CIP procedure it relied on, through tenant-isolated retrieval.
Audit log and genealogy
Every reading, recommendation, write, approval and release in an append-only log, assembled into the batch genealogy for release.
Craft capture
Per-plant yield-and-quality history and per-brewer and per-operator corrections, versioned and scoped per tenant, so the next batch starts from what the last one taught.
Defect to cause
Each inspection reject is attributed to the filler valve, seamer or upstream state that caused it, closing the loop across the line.
Yield, water, energy, takt
cuOpt sequences brews, tanks, changeovers and CIP cycles under water, energy and sanitation constraints and rebalances the line when the plant is disrupted.
Run timeline
One scenario run, step by step
Every Brewira run is an ordered, inspectable sequence. This is run_scn_01, an illustrative scenario: Plant run · one lager batch from brewhouse to can · brewhouse, cellar, filler, tunnel pasteurizer. Scenario complete · batch inside spec · one human approval at the pasteurizer.
run_scn_01
scenario · not measured
SUCCEEDED
-
01
order.receive
SUCCEEDED
0.8 s
Plant Orchestrator · Pulled the recipe, the package spec, the HACCP plan with its pasteurization critical control point, the yeast lot record and the standing CIP window from the beverage MES and the lab system; locked the target envelope for the run.
-
02
twin.simulate
SUCCEEDED
38 s
Plant Orchestrator · Simulated 24 candidate brew, fermentation and carbonation plans on the Cuvera as-produced twin; ranked them on gravity margin, predicted finish time, CO2 target, PU margin, takt and CO2 and energy use, and discarded every candidate that thinned the pasteurization margin.
-
03
brew.blend
SUCCEEDED
2 m 40 s
Brew-and-Blend · Held wort gravity to recipe from the inline gravity analyzer and the brewhouse PLC, trimming the blend and utilization setpoints inside the recipe window rather than correcting after a spot lab check.
-
04
ferment.control
SUCCEEDED
5 d 06 h
Ferment-and-Yeast · Predicted the attenuation curve and finish time for the tank from inline gravity, dissolved oxygen and CO2, pH and temperature; held the temperature ramp and timed the crash inside the brewmaster-approved window; no stuck or runaway fermentation was flagged.
-
05
carbonate.dose
SUCCEEDED
3 m 15 s
Filter-and-Carbonate · Fused inline CO2, dissolved oxygen, turbidity, temperature and pressure; held carbonation to the package target with the minimum CO2 and timed the filter backwash from the predicted loading instead of a fixed schedule.
-
06
fill.seal
SUCCEEDED
continuous
Fill-and-Seal · Adjusted fill valves toward the target level inside the approved window using drift feedback from inspection, and ran seam checks on the seamer; the filler corrected upstream instead of rejecting downstream.
-
07
inspect.line
SUCCEEDED
continuous
Defect-and-Inspect · 16 camera streams at the line edge: fill level, seam and cap, label and date code, foreign body and container checks on every can; three low-fill rejects were attributed to one filler valve and Fill-and-Seal corrected it.
-
08
pasteurize.verify
SUCCEEDED
continuous
Pasteurize-and-CIP · Held the tunnel pasteurizer on the validated PU profile at the lowest zone energy inside the envelope; every critical control point reading was written to the audit log against the HACCP plan and the CIP release checks were armed.
-
09
approve.human
APPROVAL
1 m 52 s
Plant Orchestrator · The lowest-energy candidate wanted to move the pasteurizer CIP into a window that overlapped the next brand's start. Held for the shift quality manager, who kept the validated PU profile untouched and approved the CIP move with a tighter release check.
-
10
release.genealogy
SUCCEEDED
1 m 05 s
Quality-and-Conformance · Batch released: gravity and attenuation curves, yeast lot, CO2 and clarity, fill and seal outcomes, inspection rejects, PU readings, CIP release and every human decision written to the batch genealogy and checked against spec.
Tool calls
The agent shows its work
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:50:02mes.read_order({ batch: "L-0931", brand: "LAGER-33", package: "CAN-330" })
- 04:50:02ok recipe locked · HACCP plan v6 · CCP: tunnel PU 15–20
- 04:50:03lab.read_results({ yeast_lot: "Y-2207", test: "viability" })
- 04:50:03ok viability inside window · lot accepted for pitching
- 04:50:04twin.simulate({ candidates: 24, horizon: "batch" })
- 04:50:42ok best plan #7 · PU margin held · lowest CO2 and energy per hl
- 04:50:43policy.evaluate({ plan: 7, stage: "bounded" })
- 04:50:43ok 7 writes permitted · 1 write requires human approval
- 04:50:44plc.write_setpoint({ tag: "BH1.BLEND_RATIO", basis: "gravity+recipe" })
- 04:53:24ok wort gravity on recipe · utilization held
- 05:10:00ferment.predict_curve({ tank: "FV-12", lot: "Y-2207" })
- 05:10:00ok attenuation curve predicted · finish day 5 · crash timed
- 05:10:01plc.write_setpoint({ tag: "FV12.TEMP_RAMP", window: "brewmaster_approved" })
- 05:10:01ok ramp applied · no stuck or runaway ferment flagged
- 06:02:10plc.write_setpoint({ tag: "CARB1.CO2_DOSE", basis: "co2+do+turbidity" })
- 06:05:25ok CO2 on package target · clarity inside spec · backwash timed
- 06:05:26vision.stream({ cameras: 16, models: ["fill_level", "seam_cap", "label_ocr", "foreign_body"] })
- 06:31:48reject: low fill · can 20417 · attributed to filler valve 14 drift
- 06:31:49defect.attribute({ event: "low_fill", cause: "filler.valve_14" })
- 06:31:49ok fill_seal notified · valve 14 trimmed inside window · two more rejects, then clean
- 06:31:50plc.verify_pu({ tag: "TUN1.ZONES", profile: "validated" })
- 06:31:50ok PU inside profile · readings → audit log
- 06:31:52approval.request({ action: "cip.window", reason: "overlaps next brand start" })
- 06:33:44ok approved by the shift quality manager · PU profile untouched · tighter release check
- 09:12:30mes.release_batch({ batch: "L-0931", genealogy: "full" })
- 09:13:35ok batch released · scenario complete
Reasoning trace
Goal, plan, thought, action, observation, exactly as the orchestrator would record it.
GoalBrew batch L-0931 to recipe gravity, ferment it to target atte…
Brew batch L-0931 to recipe gravity, ferment it to target attenuation, carbonate and fill it to spec at line speed, pasteurize it on the validated PU profile and release it with full genealogy.
PlanSimulate the whole batch on the twin first. Lead with gravity …
Simulate the whole batch on the twin first. Lead with gravity so the cellar gets the right wort and the filler gets the right CO2. Verify the pasteurization critical control point continuously. Let the filler chase target level only inside the approved window; hold anything beyond the envelope for a human.
ThoughtThe standing practice over-fills to avoid low fills and over-g…
The standing practice over-fills to avoid low fills and over-gasses to avoid flat product. With continuous fill-level estimation and inline CO2 the filler and the carbonator can sit at target. The saving is giveaway, not safety margin: the pasteurization CCP is never a candidate for optimization.
Actiontwin.simulate(candidates=24) → plan #7: gravity on recipe, fin…
twin.simulate(candidates=24) → plan #7: gravity on recipe, finish day 5, CO2 at package target, PU margin unchanged, lowest predicted CO2 and energy per hectoliter.
ObservationPlan #7 wants the pasteurizer CIP in a window that overlaps th…
Plan #7 wants the pasteurizer CIP in a window that overlaps the next brand's start. The policy engine routes that single move to the shift quality manager and permits the other seven writes.
ActionExecute plan #7 at the bounded stage: brewhouse blend, tank ra…
Execute plan #7 at the bounded stage: brewhouse blend, tank ramp, CO2 dosing and fill-valve writes proceed; PU is verified continuously; the CIP move waits.
ObservationApproval granted at 06:33:44 with the PU profile untouched and…
Approval granted at 06:33:44 with the PU profile untouched and a tighter CIP release check. Three low-fill rejects were attributed to filler valve 14 and corrected by Fill-and-Seal inside the approved window.
OutcomeScenario complete. The batch is released with gravity and atte…
Scenario complete. The batch is released with gravity and attenuation curves, yeast lot, CO2 and clarity, fill and seal outcomes, PU readings, CIP release and the human decision in the genealogy. No measured plant result is claimed; this is the run the platform is designed to execute.
In depth
Three features worth the detail
Latency
Decisions at the line, not in the cloud
A reject decision is only useful if it arrives before the container leaves the station, and a drift alert is only useful if it arrives before the filler has over-filled a pallet. The design targets are under 100 ms and under 250 ms respectively, on line-edge GPUs, with the cloud used for training and simulation.
| Decision | Design target |
|---|---|
| Reject decision | <100 ms |
| Drift alert to fill-and-seal | <250 ms |
| Camera feeds per line | 8–24 at 60–240 FPS |
Evidence
Nothing is recommended without a citation
The orchestrator retrieves over recipes, brew, fermentation and carbonation specs, food-safety standards (HACCP, FSMA, FSSC 22000, BRCGS) and quality, genealogy and CIP procedures. Retrieval is multi-tenant isolated and permission-aware, and every output is traceable to a source.
- Citation and grounding checks on every output
- Schema and safety guardrails
- Golden datasets and model-as-judge evaluation in CI
- Immutable, assurance-grade food-safety audit log for every action
Rehearsal
The twin discards what the plant should never try
Cuvera simulates the batch as it will actually be produced, across fermentation kinetics, carbonation mass transfer, mixing, pasteurization heat and line flow. Candidates that save energy or CO2 but thin the pasteurization margin never reach the agents.
- Multi-objective ranking: gravity, finish time, CO2, PU margin, takt, energy
- Safe control envelopes handed to the agents
- Twin-versus-actual calibration every batch
- Validated synthetic rare defects for training
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: tunnel pasteurizer belt speed
-
01yield_takt.request(belt +5%) SUCCEEDED0.2 s
Yield-and-Takt wants more belt speed through the tunnel pasteurizer so the filler is not held back and the shift meets takt.
-
02pasteurize_cip.request(belt hold) SUCCEEDED0.2 s
Pasteurize-and-CIP requires the belt speed that keeps every container inside the validated PU profile. 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 pulling the next changeover earlier and shifting the CIP window instead. Takt is met without touching the CCP.
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 optimization variable. An under-pasteurized or contaminated batch 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 human rather than resolving by timeout.
Autonomy
Four stages, set per loop
A plant does not go from manual to bounded control in one step. Brewira makes the stage explicit per loop, auditable and reversible at any time, and some decisions never leave the person.
| Stage | What the agent does | What the person does | When |
|---|---|---|---|
| Shadow | Predicts gravity, attenuation, carbonation, fill and seal faults, contamination and takt; writes nothing | Runs the plant as today; compares predictions to lab, QA and PLC outcomes | First phase with every design partner |
| Assist | Recommends bounded brew, fermentation, carbonation, fill and seal, pasteurization and CIP moves with the evidence | A brewmaster, process engineer or quality manager approves or rejects each one | After accuracy is proven against the baseline |
| Bounded | Writes low-risk filling, carbonation and inspection setpoints inside documented recipe, quality, food-safety, equipment and rollback limits | Approves anything above the limits; reviews the shift record | 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 |
How it works
A goal becomes a plan becomes a run
Nothing about a Brewira run is implicit. The goal is declared, the plan is rehearsed on the twin, each step is typed, and the outcome is written to the batch genealogy.
The orchestrator plans, the agents act
A run starts as a goal, becomes a plan, and executes as a graph of typed steps. The active path is always visible, always logged, always reversible.
RUNNING APPROVAL SUCCEEDED
Autonomy is a dial, not a switch
Shadow, assist, bounded, exceptions. Each plant sets the stage per loop, and anything above the threshold, every critical control point and every release decision waits for a named person.
Design targets
Feature design targets
The numbers Brewira is engineered against, from the GPU utilization plan.
<100 ms
edge inference for a reject decision at line speed
<250 ms
drift alert to the fill-and-seal agent
8–24
camera feeds per high-speed filling or packaging line
60–240 FPS
aggregate frames processed per line, depending on container speed
20–60
deployed model versions per enterprise tenant, with canary rollout and rollback
100k–1M
labeled synthetic rare-defect variants per design-partner phase
Design targets from the GPU utilization plan, all marked aspirational in the architecture. Nothing on this page is a measured plant result; measurements start when the first design-partner line runs in shadow mode.
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, inline analyzers, lab systems, MES, cameras and meters, with declared allow-lists and limits
- An autonomy policy per loop: stage, 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 batch genealogy to your quality system
// one write, as the audit log would hold it
{
"run": "run_scn_01",
"step": "fill.seal",
"agent": "agent.fill_seal",
"stage": "bounded",
"action": { "tool": "plc.write_setpoint", "tag": "FIL1.VALVE_14" },
"limits": { "max_step": "declared per tag", "per": "declared per tag" },
"evidence": ["vision.stream", "filler.read_telemetry"],
"citation": "spec:CAN-330 fill-level v3 §2",
"policy": "permitted",
"models": { "fill_level": "versioned", "policy": "versioned" },
"human": null,
"outcome": "on target level · inside approved window"
}
From the plant floor
Who this is built for
The three people in a beverage plant whose week changes when the process runs itself, and what each of them needs from Brewira.
Plant or Operations Director
Owns production rate, quality, loss, giveaway and yield, water and energy, and food safety. Wants a plant that holds spec at higher rate with fewer interventions, and a number that justifies the spend.
Brewmaster or Process Engineer
Owns recipes, brewhouse and blend, fermentation and carbonation process windows and yield. Approves and corrects the agents in assist mode; those corrections train the models.
Quality or Food-Safety Manager
Owns product quality and safety under HACCP, FSMA, FSSC 22000 and BRCGS, contamination and fill and seal conformance, and batch 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
Brewira 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 brewhouse, blending and syrup systems, fermentation tanks and yeast handling
Setpoint reads, guarded writes, interlocks untouched
Filtration and carbonation skids and their inline CO2, dissolved-oxygen and turbidity analyzers
Continuous carbonation and clarity state
High-speed filler, seamer and capper controls
Telemetry in; fill-valve and seam settings inside approved windows
Tunnel and flash pasteurizers, CIP skids and hygiene sensors
PU readings verified and logged; CIP release checks
Multi-camera stations for fill level, seal and cap, label, foreign body and container defects
Frames, defect events, reject commands
Orders, recipes, product specs, batch genealogy, LIMS results
Targets in, release records out
Plant and asset meters; Isaac-driven pack, case and palletizing cells
Hard constraints for scheduling; bounded handling
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
Brewira 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 stage the plant has set.
- Critical control points are read, never written. Pasteurization units, CIP release checks and batch release decisions stay with the HACCP plan and the people who own it.
- Policy engine before every write. Autonomy stage, interlock state, product, 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, FSSC 22000 and BRCGS record-keeping.
- Hard fallback. If the edge node, the network or a model stops, the plant keeps running on its existing PLC and SCADA control and interlocks.
- Tenant and IP isolation. Recipes, supplier data 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 · FSSC 22000 · BRCGS | 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 producers | RUNNING Design option |
Brewira supports your food-safety records. It is not a certification and it does not replace your HACCP plan.
Enterprise
Standardize autonomy across the group
One policy model, one audit trail and one set of yield, loss, giveaway, water and energy benchmarks across every plant 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, brewmasters and quality managers ask in the first meeting.
Only at the autonomy stage your plant has set, and only to an explicit allow-list of low-risk loops inside documented limits. Every design partner starts in shadow mode, where Brewira predicts and writes nothing. Assist mode follows, where a brewmaster or process engineer approves each recommendation. Bounded autonomy on filling, carbonation and inspection loops comes after the food-safety and ROI gates agreed up front.
Critical control points are not optimization variables. The pasteurization PU profile, the CIP release checks and the batch release decision stay with your HACCP plan and your people. Brewira verifies readings, writes them to an immutable audit log and attaches them to the batch genealogy. It is grounded in HACCP, FSMA, FSSC 22000 and BRCGS procedures; it is not a certification and does not replace your plan.
Brewira sits above your existing automation as a supervisory layer. If it stops, the plant keeps running on its current PLC and SCADA control and the interlocks it already has. A Brewira outage degrades the plant to the way it runs today, not to a stop.
The first phase is shadow mode on one line: Brewira reads your analyzers, PLC history, lab results and MES while you run the plant as usual, and we measure its predictions against your lab, QA and PLC outcomes. Recommendations start when accuracy is proven against that baseline, and improve as plant-specific history and brewmaster corrections accumulate.
Recipes, product specs, tolerance models and supplier data are tenant-scoped and never used to train another customer's models. Retrieval is multi-tenant isolated and permission-aware. Cross-plant learning, where a customer opts in, is federated and IP-isolated. On-prem deployment is available for producers protecting sensitive recipes.
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: fill giveaway and low-fill rejects, leaker and seal faults, attenuation variance and tank time, CO2 use and clarity rejects, or water and energy on pasteurization and CIP. We instrument the line in shadow mode, measure the baseline, move to assist mode when accuracy is proven, and expand only when the number holds.
Full multi-module autonomy across the whole plant, 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 assurance-grade food-safety audit log.
Get started
See these features on your line
Shadow mode shows the perception, prediction and evidence features before any control feature is enabled.