Data State: The Missing Object in Enterprise AI
Your stack versions your code, your models, and your infrastructure. It does not version the one thing your AI actually runs on: the data state. Naming that object is the foundation reproducibility, audit, and ownership all depend on.
Two engineers get different answers from the same AI system and set out to find why. They check the code: same commit. The model: same version. The prompt: same template. The configuration: identical. Everything their tooling can name matches, and the outputs still differ.
The thing that differed has no name in their stack. It is the data the system actually ran on: the specific records, values, and context that one execution resolved and consumed. That object decided the output, and nothing in the toolchain treats it as something you can point to.
Call it the data state. It is the object that most directly determines an AI output, and the one your stack was never built to name.
What a data state is
A data state is the exact, complete set of inputs a single AI run resolved at the moment it ran. Not the database, not the pipeline, not the query. The result of all of them, frozen for one execution.
Concretely, it is the source records the run actually read, the feature values as computed at that instant, the documents retrieved, the schema in force, and the context assembled and handed to the model. A query describes what you asked for. A data state is what you got, on that run, at that time. Run the same query an hour later and the query is unchanged while the data state may not be.
This is the object that determines an output. Two runs with identical code, model, and prompt produce the same result only if they shared a data state. When they diverge, the data state is usually where they diverged.
Why the stack never named it
The gap is not an oversight. Enterprise data systems were built to serve people and applications, where data is a present-tense resource. You ask for current data, you get current values, and everyone understands those values are a moving target. Nothing in that design needs to freeze and label the exact inputs behind one past result, because a dashboard viewer never asks to reconstruct the dashboard as it stood at 2:14 last Tuesday.
Get BG Yoo’s stories in your inbox
Join Medium for free to get updates from this writer.
AI changed what the data is for, without changing how the stack records it. Code has commits. Models have versions. Infrastructure has configuration under source control. The data state has none of these. It is assembled at run time and discarded when the run ends, treated as a transient byproduct rather than a durable object.
Existing tools each version one slice and stop there. Git versions the code. A registry versions the model. A table format versions one table’s history. None of them captures the assembled state a specific run consumed across all its sources, and none lets you replay a run against it. The object exists in reality and is absent from the toolchain, which is why the engineers above had nothing to point to.
What changes when you treat it as an object
Give the data state what every other important artifact already has, a name, an address, and a version, and the hard problems of production AI turn mechanical.
Reproducing an output becomes replaying a run against its stored state, instead of rebuilding it by hand. Explaining or auditing a decision becomes inspecting the exact inputs it was built on, instead of guessing. Trusting and reusing a result becomes possible, because another team can reconstruct the state behind it. The recurring cost of unrepeatable AI, and the question of who is accountable for a decision months later, both trace back to the same root: the object at the center was never something anyone could hold.
None of this asks for a new kind of data. It asks for an existing thing to be treated as first-class. The object already exists. The architecture never promoted it to something durable.
Making the object real
Treating the data state as an object is an architectural choice, not a logging feature bolted onto what you already run. The state has to be captured as it is consumed, versioned so later changes do not overwrite it, and replayable so a past run can be reconstructed exactly.
That is what we build at CUBIG. Syntitan captures, versions, and replays the data state behind every run, turning it from a transient byproduct into a durable object that the rest of your systems, and your teams, can rely on.
The object was never missing
The data state was always there. It produced every output your AI has ever generated. What was missing was never the object. It was a name for it, an address to find it, and a decision to treat it as something that lasts.
Your stack versions everything the AI was built with. The data state is the one thing it ran on. Name it, and enterprise AI finally gets the foundation it has been running without.
