Skip to content
scsiwyg
sign insign up
get startedmcpcommunityapiplaygroundswaggersign insign up
Ai26.10 — AI-Enabled Autonomous Fermentation Control·The Technology — Atomic47 AI Stack26 Apr 2026David Olsson
Ai26.10 — AI-Enabled Autonomous Fermentation Control

The Technology — Atomic47 AI Stack

#tech#a47#ai#architecture#reference

David OlssonDavid Olsson

Kelowna, BC · Platform-first systems integrator · CAISIC member

Atomic47 designs and deploys AI systems for environments where it actually has to work — regulated, safety-relevant, capital-intensive, with operators who will switch the system off if it gives them bad information. Our delivery for Ai26.10 is a complete supervisory control stack sitting over CDI's existing PLC/SCADA, plus the SaaS packaging that lets us deploy the same stack to other fermentation operators afterwards.

Intelligence Network Architecture

The full Ai26.10 cluster — sensors on CDI's fermenters, edge gateway, inference and control plane, operators and (eventually) external SaaS tenants. Solid arrows show data flow; dashed arrows show the control / setpoint return path.

What we will build (and what becomes technically novel)

Data infrastructure for industrial fermentation

A defensible, secure, OT-network-compliant data path from CDI's fermenters to a centralized time-series store, with a feature store on top. Designed for the realities of the production floor — intermittent connectivity, sensor drift, recipe changes — not a clean lab. Deliverables: M02 edge gateway + ingestion pipeline · TSDB + feature store · OT/IT segmentation, audit trail.

Soft-sensor neural networks

Deep models that infer expensive lab-measured quantities (biomass, key metabolites, off-gas composition) from cheap routine sensors. Trained on historical and DOE data, validated against wet chem, deployed with explicit confidence bounds. Deliverables: M05 soft-sensor models · Confidence-bound inference · Drift detection + retraining triggers.

Hybrid digital twin

A first-principles fermentation model coupled with ML residual learning. Predicts the trajectory of any in-flight batch under current conditions and proposed setpoint changes. The MPC and operators both query it. Deliverables: M05 digital twin model · Sub-batch trajectory simulation · Confidence-aware extrapolation outside training envelope.

Model-predictive control with constraint awareness

A supervisory MPC controller that uses the digital twin to compute setpoint changes maximizing yield/quality/cycle-time subject to safety and operational constraints. Always advisory first; auto-execute only after operator validation gates. Deliverables: M07 MPC controller integrated with PLC/SCADA · Constraint-respecting optimization solver · Operator override and audit trail.

Real-time anomaly detection

Multivariate models that flag batch-failure precursors and quality excursions early enough that the operator can intervene. Tuned for low false-positive rates, because operators stop trusting noisy alarms within a week. Deliverables: Multivariate anomaly model · Operator-tuned alerting · Documented true/false positive rates.

SaaS packaging for replication

The whole stack packaged so it can be deployed to other fermentation operators after CDI's industrial demo. Tenant isolation, data sovereignty, configurable model retraining cadence, and a multi-customer operations playbook. Deliverables: M11 multi-tenant SaaS package · Customer onboarding runbook · Pricing and licensing model.

Agentic project-state operating system

The platform that drives the team site itself. Codifies the PIC PM Guide and our MPA into Claude skills that handle weekly reports, claim packages, SC meetings, IP disclosures, decision logging — anything recurring. The reusable artifact that outlasts Ai26.10. Deliverables: 20+ Claude skills covering project lifecycle · Reusable across PIC and grant-funded projects · Open architecture, documented schema.

Why this stack, and not an off-the-shelf option

Off-the-shelf MES, APC, or general-purpose anomaly-detection platforms exist, but three things are missing for fermentation specifically: (1) the soft-sensor models have to be trained on each plant's actual feedstock and microbial dynamics — generic models are a false economy; (2) the digital twin needs to be a hybrid of first-principles biology and ML residuals to be both physically meaningful and accurate; (3) deployment has to fit OT/IT realities of a working fermenter without a year-long integration project. Building the stack ourselves lets us tune every layer to the actual problem and re-deploy it to other operators afterwards.

See also

  • The Science — the fermentation domain this technology serves.
  • The Collaboration — how the technology team pairs with the science team to validate every model against real fermentation reality.
  • Glossary — definitions for AI / TWIN / MPC / SYS / ANO terms used here.
Share
𝕏 Post