Control rollout OS for cement groups that safely deploy AI setpoint changes across kilns and lock in cost and CO2 gains.

1. Named deployments at Adani Cement, Heidelberg Materials, and Holcim show the market has moved past lab pilots and into live plant operations.
2. Savings of $1 million to $3 million and roughly 30,000 tonnes of CO2 per plant make rollout speed and consistency financially material at the group level.
3. Legacy plant software and manual calibration are still the bottleneck, so the next software winner can own deployment governance rather than invent yet another optimization model.
4. Expansion from cement into steel, glass, and chemicals suggests this is the start of a repeatable control-software category across continuous-process plants.
5. Cost and carbon are now aligned in the same buying motion, giving plant-ops software a stronger internal coalition than a pure sustainability tool would have.

Catalyst. Gigaton's funding, named live deployments, large per-plant savings, and stated expansion into adjacent continuous-process sectors show AI control has moved from concept to rollout, making safe deployment governance newly urgent.

Build a deployment layer that sits between AI control vendors, APC systems, and plant operations teams. The product ingests historian data, recipe changes, quality constraints, and vendor-recommended setpoint adjustments, then runs a preflight check on each rollout against plant-specific operating envelopes before anything hits the control room. It creates approval flows for group process leaders and plant managers, auto-generates shift handover instructions, and records every operator override with root-cause tags. After rollout, it measures whether the new control recipe actually delivered the expected fuel, throughput, and emissions outcomes so the corporate team can decide which playbooks to standardize across the fleet. The initial deployment stays vendor-neutral and API-light by starting with historian, DCS, and spreadsheet exports instead of requiring a rip-and-replace control stack.

What's different. AI control vendors and legacy APC incumbents optimize within a plant, but they usually do not own the cross-site rollout, approval, and operator-trust workflow that determines whether a pilot ever becomes standard practice. This product wins by becoming the vendor-neutral deployment and evidence layer for control changes, with a proprietary dataset on which operating envelopes travel well between plants, where overrides recur, and which rollout patterns deliver durable savings. That makes it complementary to incumbent control stacks while building a moat in the fleet-level operating workflow they leave behind.

Jobs to be done

flowchart LR
  Buyer[Group process leader] --> Pain[Manual rollout of kiln control changes]
  Pain --> Product[Control rollout OS]
  Product --> Outcome[Faster fleetwide savings and CO2 reduction]

Executive takeaways

• The market signal is strongest where AI/APC value is already proven at one plant but fleet rollout still depends on brittle human coordination.
• The proposed startup is best framed as a deployment-governance layer that complements existing control stacks instead of replacing them.
• Alternative fuels, carbon compliance, and multi-site standardization all increase the value of versioned operating playbooks and override analytics.
• Adoption risk is real: OT security, operator trust, and integration caution make read-only historian-first implementation the right initial posture.

Market definition

This is not the broad APC market. The relevant category is fleet-level deployment governance for kiln-control changes: software that versions recipes, runs preflight checks, routes approvals, and measures override behavior after an AI/APC recommendation moves from one plant to the next.

Customer and buyer

Primary users are group process excellence leaders, kiln optimization managers, and plant operations teams at multi-plant cement producers. The buyer is typically the executive who owns manufacturing excellence, energy performance, or group process performance rather than the control-room team alone.

Buying triggers

• A first successful AI/APC pilot creates urgency to copy the new operating recipe to other kilns without losing quality or operator trust. [1][4][21]
• Alternative-fuel adoption raises process variability, making manual rollout and tuning harder to sustain across plants. [2][15][24][25]
• Carbon-cost pressure and decarbonization commitments increase the payoff from standardizing fuel, clinker-factor, and emissions-improving recipes across fleets. [11][12][13][22]

Willingness to pay

Plants already justify control software on value capture: Gigaton cites $1M-$3M annual savings per plant, while ABB says cement APC can pay back in under six months. That supports a separate rollout-governance budget as long as spend is a small fraction of realized energy and carbon savings. [1][4][5]

Category dynamics

Growth signal double-digit adoption pressure, but no authoritative standalone CAGR for rollout-governance software was found

Validation signals

• Named live deployments prove that major cement groups already trust AI control enough to move beyond pilot rhetoric.
• Plant-level economics are large enough that faster fleet rollout could justify a separate software layer.
• Large cement groups are explicitly investing in OT visibility and network segregation, which makes software governance a board-level topic rather than a niche plant concern.
• Alternative-fuel and clinker-reduction programs create recurring moments when producers must change operating envelopes across multiple sites.

Regulatory & technical constraints

• EU ETS and CBAM make emissions performance economically material and increase the need for auditable operating changes.
• U.S. cement kilns face hazardous-air-pollutant limits, so fuel and process changes cannot jeopardize emissions compliance.
• ICS deployments must preserve safety, reliability and security, which raises the burden for any software touching OT-adjacent workflows.
• Alternative-fuel systems can improve economics but also introduce new process variability that must be modeled before rollout.

Incumbents cluster in three layers. First, APC/automation vendors such as ABB, Honeywell, AspenTech, and Siemens optimize the plant itself. Second, data platforms such as AVEVA and Seeq make historian data analyzable. Third, newer AI controllers such as Gigaton push toward autonomous plant control. The open gap is not optimization inside one plant; it is the vendor-neutral workflow for safely promoting a winning operating envelope across a fleet.

Why incumbents do not win by default

• APC vendors. APC incumbents win inside the process loop, but their tooling is centered on controller performance rather than cross-site recipe versioning, approvals, and post-rollout override learning.
• Automation vendors. DCS and automation vendors own plant infrastructure and can slow integrations, yet their product center of gravity remains plant automation, not multi-plant rollout governance.
• Industrial data platforms. Historian and analytics platforms provide the source-of-truth data layer, but they stop short of prescribing or governing how a control change should move between sites.
• Engineering services. System integrators and alternative-fuel project teams can manage one-off transitions, but they do not create a reusable operating-system layer for approvals, handovers, and benchmark learning.

Kiln Control Rollout OS should start as a vendor-neutral deployment-governance layer for multi-plant cement producers that already proved AI or APC value on at least one kiln. The first customer is a regional group with 5-15 clinker lines, one working control pilot, and a corporate process team under pressure to standardize fuel-mix or energy-performance gains before the next planning cycle. Research supports the pain: named deployments at Adani Cement, Heidelberg Materials, and Holcim show plant-level control software is live, while reported savings of $1M-$3M and roughly 30,000 tonnes of CO2 per plant make delayed fleet rollout financially visible. The company should not sell another optimizer; it should sell preflight validation, approval routing, shift handovers, and override analytics that let a group copy a winning recipe without risking quality, uptime, or emissions compliance. The go-to-market system is coherent because the trigger is a proven pilot or alternative-fuel rollout, the buyer is the VP of Manufacturing Excellence or Group Head of Process Performance, the first contract is a paid pilot on one plant, and pricing scales with managed clinker lines. Modeled market size is modest but investable for a focused company—about $96.0M TAM, $27.0M SAM, and $4.5M year-3 SOM—while no authoritative standalone category dataset was found for this specific rollout-governance layer. The company can win if it stays historian-first and read-only at launch, complements incumbents instead of displacing them, and turns override plus realized-outcome data into a proprietary cross-site benchmark. The main reasons to hesitate are concentrated buyers, long OT-driven sales cycles, and the risk that APC vendors bundle enough rollout workflow to collapse the wedge before the startup becomes system of record.

Problem

• Multi-plant cement groups can prove AI or APC value on one kiln, but they still scale new recipes through spreadsheets, historian screenshots, email approvals, and shift handovers that were not built for fleet rollout.
• Alternative-fuel adoption, carbon-cost pressure, and emissions compliance make each control change more valuable and more risky, so slow or inconsistent rollout leaves board-visible savings stranded.

Solution

• Build a read-only rollout OS that versions kiln recipes, ingests historian and spreadsheet exports, runs plant-specific preflight checks, and routes approvals before a new setpoint package reaches the control room.
• After go-live, capture operator overrides, shift notes, and realized fuel, throughput, and CO2 outcomes so the group team can decide which playbooks should become fleet standard and which should be rolled back.

Why we win

• The wedge is downstream of the pilot but upstream of fleet standardization, which is where proven value most often stalls and where incumbent tools are weakest.
• The product is complementary to APC, DCS, and historian vendors, letting the company sell faster by improving project success rather than demanding a control-stack replacement.
• Cross-site transfer data, override causes, and realized-vs-modeled rollout results can compound into a proprietary benchmark moat that plant-level tools do not naturally see.

Milestones

flowchart LR
  Wedge[Beachhead wedge] --> MVP[MVP]
  MVP --> Proof[Proof points]
  Proof --> Expansion[Expansion motion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least half of qualified target groups already run AI or APC on one kiln but still use spreadsheets, email, or manual handovers for cross-site rollout.
• Read-only historian and quality data are sufficient to generate a preflight workflow that operators and plant managers trust for second-plant rollout decisions.
• Buyers will fund a standalone rollout-governance layer from manufacturing-excellence or energy-performance budgets rather than insist it be bundled into APC contracts.
• One successful production deployment expands to at least one additional plant or line within 6 months, proving account-level land-and-expand economics.
• APC and automation incumbents do not ship equivalent vendor-neutral approvals, handovers, and override analytics fast enough to erase the wedge in the first 24 months.

Open diligence questions

• How many multi-plant cement groups already have one live AI/APC kiln but no repeatable fleet rollout workflow?
• Which team actually owns budget when a pilot needs to move from one plant to the next: manufacturing excellence, process engineering, plant operations, or procurement?
• What minimum historian, lab, and quality data are required to make a second-plant preflight trustworthy?
• Why will a customer buy this layer instead of extending APC vendor services or using a systems integrator?
• Which adjacent sector after cement has the closest buying trigger and lowest data-integration burden?

Model sanity

• Revenue engine. Base-case revenue comes from growing from 3 paid accounts at Y1 end to 10 by Q4Y3 while lifting blended ACV from pilot pricing to about $450K as more plants and premium modules expand inside each group.
• Must go right. The company has to standardize historian normalization and approval workflows fast enough that gross margin can climb from the mid-50s in Y2 to 70% by Q4Y3 without slowing deployments.
• Model breaks if. The biggest cash risk is a sales cycle stretching toward 12 months because the sales-cycle sensitivity has the largest combined downside impact on both Y3 revenue and runway.
• Next-round proof. A credible next round is supported if the company exits Q4Y2 with 7 production accounts, one partner-sourced rollout, and visible second-plant expansion before using the six-month cash buffer.

Scenarios

Sensitivity

flowchart LR
  Trigger[Pilot success or fuel-change trigger] --> Accounts[Paying producer-group accounts]
  Accounts --> Lines[Managed lines and plants per account]
  Lines --> Revenue[Subscription + onboarding + benchmark modules]
  Revenue --> GrossProfit[Gross profit after deployment COGS]
  GrossProfit --> Cash[Cash runway after payroll and opex]

Flags: The reachable market is concentrated, so even the base case depends on a small number of multinational or regional cement groups approving standalone budget for a new workflow layer. · The model assumes buyers will pay for a vendor-neutral governance layer instead of forcing the product into APC vendor bundles; if that proves false, pricing and gross margin both drift toward the downside case. · Y1 and Y2 burn stay heavy because OT review, historian normalization, and operator-trust work keep deployments partly services-influenced until playbooks standardize. · Cash roll-forward treats EBITDA as cash and excludes working-capital timing, taxes, and capex, so real quarterly cash movement could be lumpier than shown.

• Incumbent control-stack resistance. APC vendors or DCS integrators may block access if they see the rollout layer as competitive or operationally risky. Mitigation: Position the product as a vendor-neutral deployment and evidence layer, start with read-only historian integrations, and prove it drives more successful vendor rollouts.
• Operator trust gap. Plant teams may reject centrally pushed control changes if the software feels like a black box that ignores local process nuance. Mitigation: Keep operators in the approval loop, surface explainable preflight checks, and make every override part of the learning and benchmarking workflow.
• Beachhead concentration. Cement is a finite starting market, and long enterprise sales cycles could slow early growth. Mitigation: Start in cement for wedge clarity, then expand quickly into steel, glass, and chemicals once the rollout-governance pattern is proven.