Real-Time Data for AI Missions

Every real-time data program begins with a demand for freshness and ends with an invoice. The question that would have made it cheap — how wrong is this particular fact allowed to be before acting on it becomes wrong — almost never gets asked out loud.

Consider an AI Mission asked to do something ordinary: turn a customer's request into a quote the company would be willing to honor. To produce that one document, the Mission has to touch a handful of facts that live in different places and behave in completely different ways. It needs the negotiated discount schedule from a contract signed some quarters ago. It needs to know whether the account is in good standing, which depends on a ledger that closes on its own rhythm. It needs the on-hand quantity of a component that has been on allocation for the better part of a year and moves whenever another region commits a unit. It needs the lead time the supplier last confirmed, the tax treatment for the shipping jurisdiction, and the name of the manager whose signature the quote will eventually require. Six facts, one document, and no two of them aging at the same speed.

What happens next in most organizations is depressingly consistent. Someone in the room says the Mission needs real-time data, everyone nods because no one wants to argue for stale data, and the phrase enters the requirements document undefined. From there it becomes an architecture: a bus, a change-capture layer, a set of pipelines, a project plan measured in quarters. And after all of it, the quote still goes out wrong, because the fact that actually moved was the allocation on the constrained component, and that number lived in a planning system nobody put on the bus — it was not the kind of system that seemed to belong on a real-time roadmap. The program bought freshness everywhere except where freshness was load-bearing, which is what happens when you answer a question you never bothered to state precisely.

Freshness is a property of the fact, not of the pipeline

The useful move is to stop treating freshness as an attribute of a system and start treating it as an attribute of each individual fact. Every fact a Mission consumes has something like a half-life — a period after which the version you hold has drifted meaningfully from the version the world holds. The negotiated discount schedule has a half-life measured in contract cycles, because it changes only when two companies sit down and renegotiate. The tax treatment changes on a legislative calendar that publishes its own changes well in advance. The on-hand quantity of the constrained component has essentially no stable period at all, because any commitment anywhere in the network invalidates it. Reading these three as though they belonged to the same category is the original error, and no amount of infrastructure corrects a category error.

Half-life alone, though, is only half the picture, and the half that gets more attention than it deserves. The other half is the cost of being wrong, and the two multiply rather than add. There are facts that churn constantly and whose staleness costs almost nothing — an engagement score, a rolling sentiment estimate, a count that informs a suggestion rather than a commitment. Streaming those is expensive theater. There are also facts that change very rarely and whose staleness is quietly catastrophic: the identity of the person authorized to approve an exception, which changes perhaps twice a year and, on the day it changes, turns every approval routed to the old name into an unauthorized decision that will look perfectly clean in the audit trail. That fact does not need a stream. It needs to be verified at the instant of use, which is a different mechanism entirely and one that a freshness conversation conducted at the pipeline level will never distinguish.

Once you hold rate of change and consequence of error in the same hand, the phrase "real-time" resolves into something you can actually build against. What the business meant, when it said real-time, was that a small number of facts must be true at the moment of the decision, and that it had no way to say which ones. The engineering organization heard a throughput requirement and priced it accordingly. Both parties were reasoning honestly about a question neither had written down, and the gap between them became a budget line.

One freshness standard is two failures sharing a budget

A uniform standard fails in both directions simultaneously, which is what makes it so hard to see from inside. Applied to the stable majority of facts, it is enormous overspend: contract terms, product hierarchies, jurisdictional rules, org structures, policy documents and approval thresholds pushed through machinery designed for volatility they do not have, at an operating cost that recurs forever. Applied to the volatile minority, it is usually still not enough, because the fact that mattered turns out to live in a system that was out of scope, or behind a batch job, or in the head of a planner who adjusts allocations by hand. The program is simultaneously too expensive for most of the data and too slow for the part that motivated it.

This is one of the quieter reasons that ambitious autonomy programs stall out. When Gartner predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, it named escalating costs and unclear business value among the causes, and undifferentiated data-freshness requirements are an efficient way to manufacture both at once. The cost escalates because freshness is being bought wholesale for facts that did not need it. The value stays unclear because the decisions the Mission makes are still occasionally wrong in the specific way the whole program was supposed to prevent, and nobody can explain why, since the dashboard reports that the data is current.

There is a subtler damage too, and it compounds. When every fact arrives through the same undifferentiated channel, no fact carries a stated guarantee about its own currency, which means the Reasoning Core deciding what to do has no basis for calibrating its own confidence. A system that knows a value is at most a day old and that a day is acceptable here can proceed cleanly. A system that knows a value may be a day old and that a day is not acceptable here can go and check, or escalate through Human-in-the-Loop, or say plainly that it declined to commit. A system handed a number with no expiry attached can do none of those things; it can only act as though the number is true, which is precisely the behavior that makes autonomous systems feel unpredictable. Uniform freshness does not just cost too much. It destroys the information the Mission would need in order to be appropriately careful.

Naming the tolerance is the design work

The exercise that fixes this is unglamorous and takes a couple of afternoons. Walk a Mission end to end, enumerate every fact it consumes on the way to a decision, and for each one write a single sentence in this form: acting on this becomes wrong once it is older than X, because Y. The X is a duration and the Y is a consequence — a promise the company could not keep, a payment misapplied, a decision made by someone no longer entitled to make it. The discipline is entirely in the Y, because as soon as you have to name the consequence, the conversation stops being an argument about architecture and becomes an argument about the business, which is where it belonged from the beginning. Facts whose Y nobody can articulate are facts nobody needed fresh.

What emerges from that exercise is never one posture but several, and the boundaries between them are where the real design lives. A large set of facts turns out to be genuinely slow-moving and belongs in Enterprise Knowledge, refreshed on a schedule that matches how the underlying thing actually changes. A smaller set needs to be fetched from the system of record at the moment of the decision, not because it changes constantly but because being wrong about it is unrecoverable — the approver's identity, the credit hold, the contract's current status. A smaller set still has to arrive as Observations, pushed the moment it changes, because the Mission's obligation is to react rather than to look up: the allocation moving, the shipment failing, the account going on hold between the quote and the countersignature. And there is usually a final handful whose staleness cannot be bounded honestly at all, which is an excellent argument for routing them to a person rather than pretending otherwise.

Platforms make this easier or harder, but none of them make it unnecessary. StudioX draws exactly these lines in its own vocabulary — Enterprise Knowledge for what a Mission carries with it, retrieval for what it should look up, Observations for what should come and find it — and the separation is only worth anything once somebody has decided which facts belong on which side. That assignment is not an infrastructure decision, and it is not one the platform can make on your behalf. It is the same shift in framing that runs through the reporting gathered around the emergence of the autonomous enterprise: the hard part of autonomy is rarely the model or the plumbing, and is almost always the specification work that everyone assumed had already been done.

So the question to retire is whether your data is real-time, because it invites an answer that is either meaningless or unaffordable. The better question, asked of each fact a Mission touches, is what expiry it carries and what should happen after it — whether the Mission should proceed anyway, go and verify, wait to be told, or hand the decision to a human who can accept the risk on the record. Facts with honest expiry dates make a Mission legible; it can explain not just what it decided but what it believed and how sure it was entitled to be. Freshness was never a property your architecture could have. It is a claim attached to a fact, and until somebody writes those claims down, "real-time" is just an expensive way of saying that nobody has yet worked out which parts of the world are allowed to be out of date.