X2 for AI: The Real-Time Data Plane Behind the Model

At 14:03, Alice taps her card at a pharmacy. The fraud model has milliseconds to make a decision. It needs Alice’s current account state and the recent events that led to this payment.

Thirty days later, one of Alice’s payments becomes a chargeback. Training must learn from that outcome, but the decision at 14:03 must not use it. One payment now creates four data operations. The system ingests an event, updates current state, serves a size-limited model input, and later reconstructs that input at an exact point in history.

What did the system know when it approved the payment?

The model does not perform these data operations. It waits for its data plane.

Real-time AI and ML run in a continuing loop

Real-time AI and ML systems receive events and make decisions again and again. A payment changes risk state, a click changes recommendation context, and a new order changes a demand forecast. Each decision also produces an event. A decline, ranking, alert, or forecast becomes part of the next input, while a later outcome can confirm the decision or show that it was wrong.

The model can be a decision tree, a transformer, a rules engine, or an agent. The surrounding data loop has the same form in every case. An event arrives, application state changes, and the model reads a new context. A feature that updates tomorrow cannot help a decision today, and a sequence that takes seconds to assemble cannot fit inside a request measured in milliseconds.

Many models read a feature vector. Feature engineering compresses past events into selected values such as payment count, average amount, and current account status. Sequence modeling keeps those events distinct and reads them in their defined order. Each event remains a separate step instead of disappearing inside one summary value.

An event can become one model representation or several tokens. That representation belongs to the model. The data plane keeps the ordered structured events from which the model input is made.

A sequence model usually reads the history of one entity. The entity can be a customer, card, account, device, patient, or market instrument. Its context window contains the latest eligible events before a boundary. During training, the model can predict the next event or recover an event hidden from its input. These tasks are called next-event prediction and masked-event prediction. The model can also rank possible outcomes or learn vectors that represent entities with similar histories.

Longer and fresher histories can give the model more useful context. The data system decides how much history can reach the model and how quickly it arrives. It must fill this window during real-time inference and rebuild the same window at past decision boundaries.

Alice’s decision has a boundary

The phrase “recent history” needs an exact meaning. A live service can ask for the latest data, but the word “latest” cannot reproduce a past decision. The system therefore records an exact boundary for each source stream. A later read can stop at the same boundary.

The model input therefore needs a boundary that states which facts were available. The chargeback becomes useful after it arrives because it can change future risk state and supply a training label. It cannot enter the input for the earlier payment decision. The data plane must record the boundary in stable coordinates that a later reader can use again.

An X2 address survives every storage tier

X2 records each fact as a message on a stream. A stream is a dense append-only sequence, and each message receives a position. After X2 makes that position durable and final, it permanently identifies the same message.

Recent messages can be served from memory, while retained messages remain readable from local storage. Older retained ranges can move to object storage. Their stream addresses stay stable, and applications use the same read contract across storage tiers.

Stable addresses let applications refer to facts without naming their storage locations. The address identifies the data, while the storage tier only changes the cost of the read. A stateful application can read those streams, write derived streams or keyed values, and save a checkpoint with the input positions it covers.

After a restart, the application loads the checkpoint and replays the later messages. The source history stays outside the compute process, so the process can be replaced without becoming the owner of that history.

Event time and durable log order answer different questions

Alice’s chargeback shows why one timestamp is not enough. Event time records when the producer says an event happened. If that value is absent, ingestion time can serve as a fallback. In that case, the timestamp records arrival rather than the business event. Alice’s payment can carry the time 14:03, while the chargeback refers to it thirty days later.

X2 also records the order in which events become part of durable history. The payment receives one permanent position, while the later chargeback receives another and refers to the payment. X2 does not rewrite the original fact. Corrections, reversals, and labels become new facts with their own permanent addresses.

An X2 cut maps each source stream to its exclusive next-read position. Messages below that boundary were available to the computation. Messages at or above it were not. The cut for Alice’s decision excludes the later chargeback, while a current cut includes it and can follow its reference to the payment. Event time answers when an event happened, and the cut answers what the system knew.

Sequence features preserve per-entity event history

Online models often consume sequence features. Each feature contains the latest eligible events for one entity in their defined order. An application can express that read as:

events(entity, cut, length)

The application resolves the entity to an ordered list of stable X2 message addresses. The cut selects the available prefix, while the length limits the number of events returned to the model. For Alice, the entity can be her card, and the operation returns its latest eligible events before the recorded decision cut.

A versioned sequence definition decides which events belong to that history. It also defines their order and how corrections affect later reads. The real-time path can keep the latest N events materialized near the model. Each new event advances this cached sequence and removes its oldest member.

This cache optimizes current access, but it does not replace the retained event history. Training uses point-in-time reconstruction to recover sequence features at many historical cuts. A new model may also request a deeper window than the cache retains. Older and longer reads therefore use retained source ranges under the same versioned sequence definition.

Current and historical reads remain two access modes for one logical history. The system can add customers, cards, devices, and accounts without adding one infrastructure object for every entity.

Current state is a materialized projection

Sequences preserve detail, but many decisions also need compact current state. A fraud model can read recent spend, login velocity, a risk score, or the latest account status. An application derives each value from ordered events and updates it under the entity key when a new event arrives.

X2 makes the current value directly addressable. It also records every update on a stream, so the update history remains available. This stored result is a materialized projection: current state derived from history and kept ready to read. It makes a common read fast without replacing the events that define it.

Some shortcuts lose detail by design. A counter keeps a total but not the purchases that produced it. An embedding keeps a learned summary but not the exact interaction sequence. This loss is useful when the model wants a compact current row, but it is the wrong operation when the model needs the events themselves.

A feature store can combine current-state projections, sequence features, retained history, and embeddings behind one interface. X2 supplies the data-plane primitives, while the application defines the features and their read contract.

Serving and training read the same coordinates differently

Serving and training need the same logical data, but they use it at different scales. Online serving reads one entity under a latency limit. The model usually needs a current-state projection, the latest N events, or both. Training reads many entities at many past cuts, so its main limit is the number of contexts reconstructed each second.

A common architecture builds these contexts along two separate paths. The online path sends events through a broker and a stream processor, which updates an online store for serving. The training path lands events in object storage, where batch jobs join, filter, order, and repack them into examples.

Both paths must decide which events belong to Alice, which order is authoritative, how corrections apply, and where the context ends. When each path implements those rules independently, they can select different inputs even when they share a schema. Teams then monitor freshness and compare values after the divergence has already happened.

Each model input can instead name its entity, input-definition version, cut, requested length, and transformation version. These coordinates define the source context. Serving can use a current-state projection or cached sequence, while training scans retained ranges and rebuilds many contexts in bulk.

Each path can use a physical layout that matches its workload. Both still apply the same history definition and agree about entity membership, event order, corrections, and the facts available at the cut. This shared definition removes one source of training-serving skew. Training-only operations such as masking can still differ by design.

Hot and cold storage hold one history

The latest context and the complete history need different physical layouts. Current-state projections and the latest N events stay on the hot request path. They are small, change often, and must be read within a tight latency limit. Deep history is colder and much larger, so training, historical recomputation, and audit read it in long sequential ranges.

Hot storage makes current reads fast, while cold storage keeps deep history at a lower cost. A logical read can cross this boundary without changing its meaning. The same sequence definition controls entity membership and order in memory, local storage, and an object-storage archive.

Live reads and historical reads also need separate cache capacity. A deep replay must not evict the messages that serve current traffic. Consumers can advance at different rates, so a slow training reader does not set the pace for real-time inference. Hot and cold storage can specialize because both still hold one logical history.

Every decision records its input coordinates

The model decision becomes another durable event. Its record can include the entity, cut, input-definition version, transformation version, model version, output, and request identifier. These coordinates bind the decision to its source context, so a later reader can rebuild the input after the serving cache has expired.

A later outcome refers to the decision without changing it. Alice’s chargeback can refer to the earlier approval and provide its training label. The training pipeline starts from the recorded decision coordinates, rebuilds the context at that cut, and then applies the later label rule. The outcome supplies the label but cannot become part of the earlier input.

The training example metadata can also include the requested length and an input digest. These values help a later run verify the reconstructed sample. Historical recomputation reads an older retained range and writes a new derived version, while the source events keep their original positions.

The same decision record supports fraud review, risk backtesting, recommendation experiments, and model debugging. Each use starts from stable data coordinates instead of process logs or an expired serving cache.

The ML stack starts where X2 stops

X2 supplies ordered ranges, current values keyed by entity, cuts, and application outputs. It does not own the model or the meaning of its inputs. The application defines entity membership, feature formulas, correction policy, sequence length, token budget, and input transformation.

A stateful stream-processing application can run beside X2 or connect as a client. It can maintain state, save checkpoints, and write derived data. Tokens, embeddings, masks, and tensors remain model-specific representations, so the application records its transformation version with the X2 input coordinates.

The ML platform manages model artifacts, training jobs, serving runtimes, accelerators, scaling, and model lifecycle. A training framework can sample, shard, and pack tensors for its GPUs. These systems use X2 data, but their deployment and scaling remain separate from the data plane.

The same X2 primitives support several application shapes:

Semantic retrieval can join this plane as another application view. Embeddings and vector indexes add an access pattern while retaining lineage back to ordered source events.

The progression can start with online feature and sequence serving. Point-in-time reconstruction, training sample generation, decision audit, profiles, and agent memory then reuse the same capture, computation, state, and replay primitives. This boundary keeps the platform useful across model types, so fraud models, recommenders, forecasting systems, and agents can share one data plane.

Return to Alice

At 14:03, Alice’s payment receives a permanent stream address. An application updates her current-state projection and latest N events. The fraud model reads both at a recorded cut, and the decision event stores that cut with the input-definition, transformation, and model versions.

Thirty days later, the chargeback receives a new stream address. It changes future state and links to the earlier decision as an outcome. During training, the pipeline returns to the recorded cut and rebuilds the events and state that were available at 14:03. The reconstructed input excludes the chargeback, while the label rule attaches it as the later outcome.

The system can now answer the opening question. At 14:03, the model knew exactly the facts named by the decision cut. Serving and training use different physical reads, but both resolve Alice’s history from the same coordinates.

X2 gives real-time AI one ordered history for current state, sequence features, point-in-time training data, and decision audit.

Learn why Everything is a Stream, explore append-only storage, or contact us.