IBM has moved its Granite time-series foundation models inside Confluent's stream processor. Four of them — PatchTST-FM, FlowState, TTM and TSPulse — are in early access on Confluent Cloud on AWS, callable from Flink SQL through two functions Confluent already ships, AI_FORECAST and AI_DETECT_ANOMALIES. Swapping one model for another is a single parameter change, with no pipeline to rebuild. Confluent Platform, covering local and hybrid environments, gets the same models and capabilities next.
The models themselves are not the new part. IBM says more than 44 million downloads are associated with them, and the weights are open on Hugging Face. What changes is where inference happens: the models are hosted in Confluent Cloud and invoked from Flink, so a forecast or an anomaly score is produced on the stream rather than requested from a service somewhere else and carried back.
That matters because of the economics the two companies are attacking. Building one specialised model per data series took months of expert work, so companies modelled a few hundred series that touched profit directly and covered everything else with safety stock, spare capacity and loose tolerances. The decision arrived after the moment for it had passed, and the cost of that uncertainty came back every cycle.
A time-series foundation model is trained once across a large set of heterogeneous signals and generalises to a series it has never seen. Hand it a window of measurements and it returns a forecast, a deviation score, similar stretches of history, and settings tuned to a stated objective. The intended users are domain people — demand planners, fraud analysts, process engineers — rather than data science teams.
Source: huggingface.co
The illustration IBM uses is a chocolate factory, where temperature, speed and throughput on a tempering line are measured every few seconds and compared against fixed thresholds. A foundation model can forecast output to the end of the evening shift while a planner can still act on a shortfall, compare the current cycle against the line's normal behaviour on dark chocolate and catch a gradual drift before a defect reaches the bar, surface the closest past episodes and how they ended, and account for the settings the shift controls, with optional fine-tuning where the last increment of accuracy is worth paying for. One model deploys across every line in every plant.
Source: huggingface.co
The argument for doing this in the stream rather than in a batch job is that a signal loses value as it ages. Noticing today that a pump has started running unevenly is a maintenance ticket. The same signal a week later is an outage.
Source: huggingface.co
The engineering claim underneath is about state. Forecasting and anomaly detection both need it: the next value only means something against recent history, and an anomaly is defined against a continuously updated idea of normal. Flink keeps that state per series and makes it fault tolerant, so the model gets the history it needs without a separate store and without a database call on every invocation. On top of forecasting and anomaly detection, the same models cover similar-case search, classification, gap filling and optimisation.
Source: huggingface.co
The four models are deliberately not interchangeable, because the questions are not. PatchTST-FM processes a series in patches, the way a language model reads text, with each variable in its own channel so noise in one signal does not drag the others with it; it returns a full probability distribution, which lets a planner set a reorder point at, say, the 90th percentile. FlowState updates a compact representation of the series after each new value, and its continuous dynamics model suits both SCADA data arriving in seconds and market data arriving hourly. TTM replaces attention with small mixing networks running along time and across variables, and at a million parameters can process a hundred thousand series overnight on CPU. TSPulse folds time and frequency representations into one compact multitask model that finds anomalies, classifies events, fills gaps and answers whether something like this has been seen before.
Source: huggingface.co
Keeping the models small was a choice, not a limitation. Inference runs either inside Confluent Cloud or on a customer's own CPUs using the open weights from Hugging Face; not shipping data out to a cloud and back simplifies the architecture and cuts the bill. IBM also routes Granite through its enterprise AI governance platform, including model provenance and licence transparency — the part of the package aimed at buyers who have to explain the system to a regulator.
Source: huggingface.co
The scenarios the companies lead with are demand planning, fraud and process control. In retail, one model covers a whole catalogue, handles a product with two years of history and one with three months in the same job, launches a new SKU off similar SKUs, and prices a hundred thousand SKUs nightly on CPU, publishing a distribution rather than a single line so replenishment, allocation, pricing and markdown all run off the same numbers. In a retail bank, a fraud lead can keep a separate baseline per card and score every payment through one AI_DETECT_ANOMALIES call while the transaction is still in flight: a card used for two years on groceries in the same three postal codes suddenly paying an overseas e-wallet at three in the morning trips the alert before the money moves, while the same customer's genuine trip abroad goes through. On the factory floor, IBM's example is a process engineer named Andrés at a shampoo plant whose mixing line streams temperature, agitator speed, dosing rate and viscosity into Confluent; the forecast doubles as a simulator he can query for energy draw at a given mixing speed or output at a given temperature, and an optimiser searches for a parameter set against his KPI, respects his constraints and explains the recommendation.
All of it rests on embeddings — compact vectors describing the shape of a time and frequency window, so two similar episodes land near each other even at different scale or offset. That is what turns a score into a precedent: the past cycles where a drift developed the same way and what fixed them, the demand curves a new SKU most resembles, the confirmed fraud cases the current session rhymes with.
Two thirds of the way through the pitch, the numbers start doing less work than they look like they are doing. More than 44 million downloads is a repository counter, not a count of production deployments; it says the weights are easy to obtain, which was never the hard part. Throughput up to ten times higher, each additional percentage point of accuracy worth millions, a one percent improvement at a plant with hundreds of millions in revenue coming out as a seven-figure sum — these are IBM's own figures, and the announcement attaches none of them to a named customer, a baseline or a workload. The one claim I do find persuasive is the unglamorous one: that the months went into wiring a model to a live system, not into the model, and that this is what a hosted inference call inside Flink actually removes. Validation with design partners in cement, steel, pulp and paper, food and telecom is the more meaningful signal here, and one food manufacturer starting with a single process behind 400 plants is the more meaningful number.
Notably absent from the announcement is any accuracy comparison against the statistical models and hand-built machine learning pipelines these are meant to displace. The entire case for a foundation model over a per-series model is that it is good enough on a series it has never seen. That is an empirical claim, and it is the one figure nobody published. The fraud scenario sharpens the point: the same material says false alarms sometimes cost more than the crime, then proposes a model that begins with no labelled examples from the bank's own products and scores payments in flight. Who reviews the blocks, what false-positive budget the bank is expected to accept, and what a bad week looks like are questions the launch leaves entirely to the customer.
Confluent has made the model a parameter in a SQL statement. That is the right level of abstraction for adoption and the wrong one for caution: a team that can change forecasting models by editing one argument can also change them without anyone downstream noticing that this morning's reorder point came out of a different model than yesterday's.