Glossary

The Composition Impossibility Theorem states that no composition of independently advancing data systems can guarantee decision coherence: a decision that reads its context from multiple systems — each ingesting, deriving, and serving state on its own timeline — cannot be guaranteed one consistent view of reality, regardless of how fast or well-tuned each system is. Coherence lost at the seams between systems cannot be recovered by improving the systems themselves.

A context gap is the difference between the state of the world an automated decision acts on and the actual state of the world at the moment the decision commits. It arises when the context a decision reads — balances, counters, session state, derived signals — lags behind or diverges from the events that have already happened. When the gap exceeds the decision's validity window, the system approves, blocks, prices, or routes based on a version of reality that no longer exists.

Context infrastructure is the data layer beneath AI applications and agent frameworks responsible for the context they consume being accurate: fresh within the decision's validity window, internally coherent across its inputs, and served reliably under concurrent load. It is the systems counterpart to context engineering — engineering shapes what goes into a prompt or plan; infrastructure determines whether what goes in is true of the world at the moment it's used.

A Context Lake is real-time, multi-modal data infrastructure that gives AI agents and automated decision systems fresh, internally coherent context at the moment a decision runs. It unifies structured state, continuously maintained derived signals, and semantic retrieval in one layer, so every concurrent reader sees the same version of reality — rather than assembling context from separate databases, caches, and indexes that each lag events differently.

Decision coherence is the property that concurrent automated decisions about the same entity act on the same version of shared state. In a coherent system, two services evaluating one account at the same moment reach conclusions that could both be true of a single world. Systems lose decision coherence when each service reads its own copy of state — a cache, a projection, a feature snapshot — sitting at a different propagation stage, so simultaneous decisions are made against different versions of reality.

Decision-time analytics is the pattern in which analytical query results directly drive automated decisions — an aggregate, scan, or score is computed and immediately determines an action: block this transaction, set this price, route this request. It contrasts with traditional analytics, where results terminate at a dashboard for humans to review and eventually act on. When analytics drives automated action inside a tight validity window, any propagation lag in the analytical layer means decisions run against state that no longer exists.

Derived context is state computed from raw events rather than stored directly: aggregates, velocity counts, running exposures, session summaries, ML features, embeddings. It is the form in which automated decisions actually consume the world — a fraud model reads transactions-per-minute, not individual transactions. Because derivation requires computation, derived context always trails the events it summarizes, and where that computation runs determines how far.

The divergence problem is the failure mode in which multiple services each maintain their own pipeline over the same underlying events — fraud with its stream consumer and cache, authorization with another, limits with a third — and each pipeline advances at its own pace, so the services' views of shared state disagree with each other, not just with reality. Two services, or two agents, can simultaneously hold conflicting beliefs about the same account, and both can act on them.

A freshness budget is the maximum staleness a decision can tolerate in the context it reads, treated as an engineering budget to be measured and allocated rather than an assumption. Its defining arithmetic is unforgiving: because a decision consumes all its inputs together, its effective freshness equals the worst of its components — one fast signal does not help if the decision also reads a slow one.

Live context is decision context that is maintained continuously as events arrive: derived state — aggregates, counters, features, views — updates incrementally and converges in sub-second time, rather than being recomputed on a pipeline schedule or refreshed on a timer. A decision reading live context reads the world approximately as it is now, not as it was at the last batch run or cache refresh.

Semantic context is the meaning-bearing layer of decision context: signals computed from raw events — aggregations, vector similarity, LLM-derived classifications, relationships — that tell a decision or agent what the data means, not just what happened. It can be pre-computed, computed on demand at query time, or both; the defining requirement is that all of it derives from the same set of ingested events, so the signals a decision reads agree with each other.

Shared context is the property that every service and agent in a decision system reads from one context layer under a single, internally coherent snapshot — so all concurrent readers see the same version of state at the same moment. It is the alternative to the default architecture in which each service maintains its own cache, projection, or feature pipeline, each sitting at a different propagation stage and each holding a slightly different version of reality.

State velocity is the rate at which the state a decision depends on changes — how frequently events mutate the balances, counters, positions, and sessions that decisions read. Together with the decision's validity window, state velocity determines whether any copied or derived view of that state can remain a valid basis for action: high velocity means context ages materially in milliseconds, so anything cached, batched, or pipelined is already describing a previous world.

A validity window is the interval within which the context an automated decision reads remains an accurate basis for that action. If the state a decision depends on can change materially within, say, 500 milliseconds, then context older than 500 milliseconds is not merely stale — it is invalid for that decision, regardless of how fresh it is by pipeline standards. For high-velocity automated decisions the window typically spans roughly 10 milliseconds to 1 second.

ACID transactions are database transactions that provide four guarantees — atomicity, consistency, isolation, and durability. A transaction groups multiple reads and writes into a single unit that either commits completely or leaves no trace, behaves as if it ran alone even under concurrent load, and, once committed, survives crashes and power loss.

Cache coherence is the property that all cached copies of a shared piece of data reflect writes to that data in a single agreed order, so no reader observes a value that contradicts what another reader sees. The term originates in multiprocessor CPU design, where hardware protocols keep per-core caches synchronized; by extension, it names the same problem in distributed systems, where multiple services hold independent caches of the same source data.

Cache invalidation is the process of removing or updating entries in a cache when the underlying source data changes, so that readers stop receiving stale values. Because a cache is a copy of data held closer to the reader, every change at the source opens a window in which the copy is out of date; an invalidation strategy determines how long that window lasts and what it costs to close it.

Eventual consistency is a consistency model for distributed systems which guarantees that, if no new updates are made to a data item, all reads of that item will eventually return the last written value. It trades immediate agreement between replicas for availability and low latency: during the convergence window, different nodes may return different values for the same item. The model bounds what replicas converge to, not when they converge.

Idempotency is the property of an operation that can be applied multiple times without changing the result beyond the initial application. In mathematics, a function f is idempotent when f(f(x)) = f(x). In distributed systems and APIs, an idempotent operation produces the same effect on the system whether it runs once or several times, which makes it safe to retry after a timeout or network failure.

Isolation levels are database transaction settings that define how and when changes made by one transaction become visible to other concurrently running transactions. The ANSI SQL standard specifies four levels — READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE — each defined by which read anomalies (dirty reads, non-repeatable reads, phantom reads) it forbids. Higher isolation gives stronger correctness guarantees at the cost of reduced concurrency or more transaction retries.

Multi-Version Concurrency Control (MVCC) is a database concurrency-control method in which the system keeps multiple versions of each data item rather than overwriting it in place. Each transaction reads from a consistent snapshot assembled from committed versions, so readers never block writers and writers never block readers. MVCC is the concurrency foundation of PostgreSQL, MySQL's InnoDB engine, Oracle, and most modern transactional systems.

A race condition is a defect in which a system's correctness depends on the relative timing or ordering of concurrent operations. It arises when two or more processes read and modify shared state without sufficient coordination, so that certain interleavings produce a result no correct serial execution would produce. Race conditions occur at every layer of computing — between CPU threads, between database transactions, and between services in a distributed system.

The dual-write problem occurs when an application writes the same logical change to two or more independent systems — for example, a database and a message broker, cache, or search index — without a transaction spanning them. Because each write commits or fails on its own, a crash, timeout, or error between the writes leaves the systems holding contradictory versions of the data. The inconsistency is typically silent: neither system knows the other missed the update.

Event sourcing is a data persistence pattern in which every change to application state is recorded as an immutable event in an append-only log, rather than overwriting current state in place. The event log is the system of record; current state is derived by replaying the events in order. Because events are never modified or deleted, the log provides a complete, auditable history from which state can be reconstructed as of any point in time.

The outbox pattern (transactional outbox) is a technique for reliably publishing events from a service that updates a database. Instead of writing to the database and the message broker as two separate operations, the service inserts the event into an outbox table within the same local transaction as the business data. A separate relay process then reads the outbox and publishes the events to the broker — guaranteeing an event is published if, and only if, the business change committed.

The saga pattern manages a transaction that spans multiple services or databases by breaking it into a sequence of local transactions. Each step commits independently in its own system; if a later step fails, the saga runs compensating transactions that semantically undo the completed steps, in reverse order. Sagas trade the atomicity and isolation of a single distributed transaction for availability and loose coupling.

Backpressure is a flow-control mechanism in which a component that cannot keep up with its input signals upstream producers to slow down, rather than letting unprocessed work accumulate without bound. It appears throughout data systems — TCP flow control, reactive streams, message brokers, and stream processors — and its purpose is to keep an overloaded system stable instead of letting it fail through memory exhaustion or runaway queues.

Change data capture (CDC) is a set of techniques for identifying row-level changes — inserts, updates, and deletes — made to a database and delivering them to downstream systems as an ordered stream of change events. Instead of repeatedly re-extracting entire tables, consumers receive only what changed, typically within seconds of the source commit. CDC is a foundational pattern for replication, cache updates, search indexing, analytics feeds, and event-driven integration.

A columnar database stores table data column by column rather than row by row, so all values of a single column are laid out contiguously on disk and in memory. This layout lets analytical queries read only the columns they reference, and it compresses well because values within a column share a data type and often repeat. Columnar storage is the standard design for analytical (OLAP) workloads, in contrast to the row-oriented storage used by transactional (OLTP) systems.

Sharding is a database architecture technique that horizontally partitions a dataset across multiple independent servers, called shards, so that each shard holds only a subset of the rows. Each shard operates as a self-contained database with its own storage and compute, and a routing layer directs every query to the shard that owns the relevant data based on a shard key. Sharding allows a system to scale storage and throughput beyond the limits of a single machine.

Semantic operators are composable, AI-based operations that integrate large language models directly into a SQL query engine. They let developers express semantic criteria declaratively — filter rows by meaning, classify free-form text, extract structured fields from unstructured data, and aggregate records using natural-language expressions — as first-class query operators alongside joins, filters, and aggregations, rather than as external model-pipeline steps.