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

At 14:03, Alice taps her card at a pharmacy. Before the issuer answers, a fraud model needs her current account state and her recent payment history.

The first input looks like a row. The second is an ordered sequence containing purchases, declines, logins, and account changes.

Thirty days later, one of those purchases becomes a chargeback. That new fact must influence future decisions and supply a label for training. It must never appear in the context reconstructed for the decision made at 14:03.

One payment has created four data workloads. The system must ingest an event, update live state, serve a bounded context, and later reconstruct that context at an exact historical boundary.

The model handles none of them. It waits for its data plane.

Real-time AI is a continuing loop

A real-time AI system receives events continuously and makes decisions repeatedly. Recommendation ranks the next item after every interaction. Advertising responds to a new impression. Security reacts to a login, while operations forecast demand from the orders arriving now.

The model may be a gradient-boosted tree, a transformer, a rules engine, or an agent. The surrounding loop has the same shape in every case.

An event arrives. Application state changes. A model reads the new context and writes a decision. That decision and its later outcome become events for the next iteration.

Model architecture receives most of the attention, but production behavior depends on this loop. A feature that updates tomorrow cannot help a decision today. A recent sequence that takes seconds to assemble does not fit inside a request measured in milliseconds.

Sequence models make the dependency more visible. Personalization systems learn from ordered histories of impressions, clicks, and conversions. Financial risk models use recent transactions and account activity to interpret the current event, while large consumer platforms must assemble long user histories efficiently for training and online serving.

These systems learn from behavior in order. The available context length and freshness are therefore infrastructure properties before they become model parameters.

One context is commonly built twice

The usual architecture has two paths for the same history.

The online path sends events through a broker and a stream processor. The processor updates an operational store, and the serving application reads the latest row or cached tail from that store.

The training path lands events in object storage. A batch job joins, filters, orders, and repacks them into examples that a training framework can consume.

Both paths need to decide which events belong to Alice, how corrections apply, which order is authoritative, and where a context ends. Those rules are implemented once for serving and again for training.

The two results then need reconciliation. Teams monitor freshness, compare feature values, and investigate why a model trained on one representation receives another in production.

This divergence is usually called training-serving skew. Sharing a schema reduces it, but a shared schema does not make two computations identical. The paths must also agree about history membership, order, cutoff, and transformation version.

X2 begins with the retained event

AlgoX2 starts from a smaller set of primitives. A stream is a dense append-only sequence of messages, and a settled position becomes permanent history.

Messages keep the same stream positions across memory, local storage, and object storage. X2 serves cache hits from memory and refills an uncached settled range from the storage tier that still retains it.

Application computation runs as a stateful stream processing application. It reads input streams, maintains or checkpoints its state, and writes derived streams or keyed values.

The application can run as an ordinary X2 client or as a managed process connected over shared memory.

The compute process is replaceable because the source history remains outside it. After a restart, the process loads its last checkpoint and replays the messages above the recorded cut.

This produces a data and state plane rather than a model platform. X2 records and delivers events, current state, historical positions, and application outputs. The application still owns the model and the meaning of its inputs.

Feature state is one view of history

A Feature Store turns event history into current model inputs. It might maintain spend over twenty-four hours, login velocity over ten minutes, a current risk score, a product embedding, or the latest account status.

Each value is a projection of earlier events. As another event arrives, an application updates the projection and publishes the new keyed value.

X2 stores each feature update on a stream and makes the current feature view directly addressable by entity key. The online model receives a direct lookup, while the ordered updates remain available for replay and investigation.

This view is intentionally lossy. A counter preserves a total but not the purchases that produced it. An embedding preserves a learned summary but not the exact interaction sequence.

Loss is useful when the model wants a compact current row. It is the wrong operation when the model wants the events themselves.

A Sequence Store preserves what aggregation removes

A Sequence Store answers a different query. Given an entity, a boundary, and a length, it returns the latest eligible events in their defined order.

For Alice, the query might be written as events(card, C, N). C identifies what the system knew at the decision boundary, while N bounds the context placed in the request path.

The live representation can keep a materialized last-N tail near the model. Maintaining that tail is still stateful computation because each arrival advances the window and evicts its oldest member.

A tail cache alone is not the whole Sequence Store. Training also needs earlier tails at billions of historical boundaries, and a new model may request a deeper window than the live cache retained.

The complete abstraction therefore joins two access modes. Online serving reads the bounded current tail, while historical reconstruction reads the corresponding tail before a recorded cutoff.

A Sequence Store treats each entity history as a logical view over retained events. Adding a customer, card, device, or account does not require provisioning a separate infrastructure object for that entity.

One history has two access modes

Serving and training have different performance goals.

Online serving reads one entity under a latency budget. The model usually needs a current feature row, a bounded sequence tail, or both.

Training reconstructs many entities at many past boundaries. It is limited by contexts reconstructed per second rather than the latency of one lookup.

Different physical paths are appropriate. They still need one logical definition of the history.

A versioned view defines which events belong to an entity, how they are ordered, which corrections apply, and which events are eligible at a cutoff. Online serving and historical training both consume that definition.

An X2 cut is the boundary shared by the source streams. It names the last included position on each source, so a later reader can identify the exact knowledge available to an earlier decision.

Application code performs the model-specific transformation. It converts structured events into tokens, embeddings, masks, or tensors under a recorded transformation version.

These coordinates make the input reproducible. The view identifies the logical history, the cut identifies its available facts, and the transformation version identifies the representation received by the model.

Training-serving skew is prevented at this boundary because neither path defines the input independently. Training-only operations such as masking may still differ deliberately, but the underlying historical context remains the same data product.

Event time and knowledge order answer different questions

Alice’s chargeback shows why a timestamp alone is insufficient.

Event time says when a purchase or chargeback happened in the business domain. The settled stream position says when the platform learned the fact and made it permanent.

The chargeback may refer to a payment from thirty days earlier. It still enters the stream as a new message at today’s position.

A reconstruction at the original decision cut excludes that later message. A reconstruction at today’s cut includes it and can follow its reference to the payment.

The original event is never rewritten. Corrections, reversals, and labels become additional facts with their own permanent addresses.

This gives the application a bitemporal foundation. Domain time orders what happened in the world, while the source cut orders what the system knew.

Near state and far history serve one logical view

The latest context and the complete history have opposing physical needs.

Current keyed values and bounded tails belong near the request path. They are small, frequently updated, and read under a tight latency budget.

Deep history is colder and much larger. Training, historical recomputation, and audit read it in long sequential runs and benefit from layouts designed for bulk throughput.

This is the near-far problem. The near representation optimizes current access, while the far representation preserves depth and economical retention.

The logical read crosses that boundary without changing its meaning. A view still names the same entity membership and order whether its messages are served from the live cache, retained local storage, or an object-storage archive.

The two workloads also advance independently. Live arrivals and records fetched for historical reads use separate cache shares, so a deep replay does not evict the messages serving current traffic. One training consumer can fall behind without setting the pace for inference.

The physical representations may therefore specialize without creating two histories. Near and far are placements of one data product, not separate definitions of it.

Training samples become replayable data products

A training example begins with an entity and a historical decision cut. The training pipeline resolves the entity’s eligible messages, restores their defined order, applies the versioned transformation, and enforces the model’s input budget.

The label comes from a later outcome rule. Alice’s chargeback may label the earlier payment, but it never enters the payment’s earlier input context.

The training example carries enough provenance to be built again. Its metadata can include the view version, source cut, transformation version, model version, requested length, and an input digest.

Historical recomputation reads an older retained source range and writes a new version of the derived result. The source events remain at their original stream positions.

A separate application runs this replay for each new feature or transformation version while the live materializer continues from the stream tail.

The training framework remains outside X2. It can shard, sample, pack, and deliver tensors in the format its accelerators expect. X2 supplies the ordered input and stable coordinates from which those batches are derived.

Decisions belong on the stream

A decision is another durable application fact. It can name the entity, input cut, view version, transformation version, model, output, and request identifier.

A later outcome can refer to that decision without mutating it. Investigators can then reconstruct the input and compare it with the model output and eventual result.

Fraud review is one application of this decision message. The same mechanism supports recommendation experiments, risk backtesting, model debugging, and regulated decision audit.

Logs cannot provide this guarantee after the serving cache expires. A decision stream can, because its provenance names permanent data coordinates rather than the transient memory of the process that decided.

Applications grow from the same primitives

The data plane supports several application shapes without becoming any one of them.

Semantic retrieval can join this plane as another application view. Embeddings and vector indexes add an access pattern, while their source events, versions, and decisions still benefit from ordered provenance.

The progression starts with the request path. Online feature and sequence serving establish fresh context first. Historical reconstruction, training sample generation, decision audit, profiles, and agent memory then reuse the same capture, computation, state, and replay primitives.

Model systems remain above the data plane

X2 does not need to train or serve a model to support AI workloads. Its responsibility ends at the continuously changing data and state beneath the model.

The application defines entity membership, feature formulas, event eligibility, late-event policy, sequence length, token budget, and input transformation. Those choices depend on the business problem and remain application concerns.

Model platforms separately manage model artifacts, training jobs, serving runtimes, accelerators, scaling, and lifecycle. Those systems remain above X2 because their deployment needs differ from the streaming data plane.

X2 supplies the reusable system properties underneath them. Events receive stable stream addresses, current values are indexed by key, historical ranges remain replayable, computations can run beside the streams, and cuts bind derived state to its input.

That division keeps the platform general. A fraud model, recommender, forecasting system, and agent can share one data plane without sharing a model abstraction.

Alice’s payment returns as training data

At 14:03, the payment enters an ordered stream. A stream processing application updates Alice’s keyed features and her sequence view. The model reads the current state and bounded tail, then appends its decision with the input coordinates.

Thirty days later, the chargeback enters as another fact. It changes future state and supplies a later outcome for the earlier decision.

When training runs, the training job returns to the recorded cut. It reconstructs the context available at 14:03, excludes the later chargeback from the input, and attaches that chargeback through the label rule.

Serving and training perform different reads, but they do not invent Alice’s history twice.

That is the role of X2 in AI. It is the real-time data plane that keeps events, changing state, historical context, and decisions in one continuing system.

Read the concise AI product overview, learn why Everything is a Stream, explore append-only storage, or contact us.