Glossary

Agent context is everything an AI agent reads before it takes a step: the instructions and conversation in the model's prompt, the results of tool calls, retrieved documents and memories, and the operational state the step depends on, such as balances, permissions, limits and actions other agents have already taken. Some of it is placed in the model's context window. The rest is read by tools and by the code around the model. An agent step is only as correct as the agent context it read at the moment it ran.

Authorization-time context is everything a decision to authorize a payment or purchase has to read at the moment it authorizes: the mandate or instruction and its current status, the budget remaining net of commitments still in flight, per-agent and per-period limits, the policy in force, and recent activity by the same agent or account. It is accurate only if it includes every commitment made before the decision, by any agent, channel or worker, and if all of it describes the same moment. When it lags, a check can pass against a budget that has already been spent.

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.

Context lag is the delay between the moment a fact changes at its source and the moment the system an automated decision reads from reflects that change. A value with context lag is returned successfully and looks valid; it is simply out of date when the decision reads it. Context lag is also called stale context. It becomes a failure only when it exceeds the time the decision can tolerate, and it grows with every copy, cache or pipeline between the source and the reader.

A Context Lake is real-time, multi-modal context infrastructure that gives AI agents and automated decision systems fresh, internally coherent context at the moment a decision runs. It unifies structured state, incrementally 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 context is the complete set of state an automated decision depends on at the moment it executes: the source records it reads, the signals derived from them, anything it retrieves by search or similarity, and the outputs of earlier decisions it must respect, such as holds, limits, verdicts and actions already taken. Decision context is correct only if all of it describes the same moment and that moment is recent enough for the decision's validity window. Every decision's output becomes part of the decision context for the next one.

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 fleet control loop is the automated feedback cycle a platform uses to steer many running AI agents at once. It observes the fleet, derives state such as spend to date, error rates, model quality, latency and abuse signals, adjusts a policy, budget or route, and the agents that are still running act on the adjusted setting. The loop's defining property is how long running agents keep acting on a superseded policy after it changes. Every moment of that interval is spent against the old policy.

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 kept close to the current state of the world. Reads run against the latest committed data, and derived state — aggregates, counters, features, views — is refreshed incrementally, each refresh applying only what changed, on a schedule typically every few seconds, rather than recomputed from scratch by a batch job. 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.

Multi-writer contention is the condition in which two or more independent actors, such as services, AI agents or people, read and write the same mutable state within the same short window, so that each write can invalidate what another writer just read. It is distinct from multi-tenancy and partitioning, where many actors each write their own isolated state. Partitioning is a scaling problem. Contention is a correctness problem: it decides whether concurrent decisions can trust what they read.

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.

Unmergeable state is shared, mutable state whose concurrent updates cannot be combined after the fact without breaking a rule the state must obey. Two writers that each acted correctly on the same earlier version can produce a combined result that is invalid, such as a balance below zero or a budget spent twice. Money, budgets, quotas, spending mandates, velocity counters and database schemas are typical examples. Correct concurrent use of unmergeable state requires coordination before the write, not a merge after it.

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.

Cognitive serializability is a correctness condition for writes that an AI agent derives by reasoning over inputs that can change while it reasons. A set of committed agent writes is cognitively serializable if the writes can be placed in a serial order and, for each one, there is a single logical point at which every value the agent was shown (database rows, retrieved evidence, policy and delegated authority) was still unchanged. It extends database serializability, which orders the transaction an agent submits but does not check whether the inputs behind it still hold.

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.

The single-writer principle is a concurrency design rule: each item of mutable state has exactly one owner, such as one thread, process, service or agent, that performs every write to it. Others may read the state or send the owner requests to change it, but never write it directly. Because only one writer mutates the state, writes need no locks or compare-and-swap retries, and the owner puts conflicting requests in order instead of letting them collide.

Agent-ready data is data an AI agent can find, interpret and act on correctly at the moment it acts. It is reachable through an interface the agent can call, described well enough that a model can use it without guessing at meanings or units, scoped to what the agent and the person it acts for are allowed to see, and current enough for the action it supports. Readiness is judged per use: the same dataset can be ready for an agent that summarizes last month and not ready for one that approves a refund.

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.

An agent handoff is the transfer of an in-progress task from one AI agent to another, after which the receiving agent carries the work forward instead of the sender. Three things have to move with it: the conversation or task history, the current state of the task (what is settled and what remains open), and the authority to act on the user's behalf. A handoff that drops or misstates any of them leaves the receiving agent working from an incomplete or outdated picture.

Agent hijacking is an attack that redirects an AI agent to carry out an attacker's goals instead of its user's, through instructions planted in content the agent reads while working, such as a web page, email, document or tool response. That route, indirect prompt injection, is how NIST defines the term. Stolen keys or tokens reach the same outcome by another route: whoever holds them acts as the agent. Either way, the actions carry the agent's legitimate identity and permissions, so they look authorized to every system that checks only who is asking.

An agent mandate is a signed, verifiable record of what a person has authorized an AI agent to buy or pay for. It either approves one specific purchase or sets constraints, such as a budget, allowed merchants, an amount range and an expiry, within which the agent may complete purchases on its own. Merchants, payment networks and credential providers check each purchase against the mandate, and the mandate later serves as evidence if the purchase is disputed.

Agent overreach is a descriptive name for an action by an AI agent that goes beyond the authority its user or operator delegated: buying a different item or quantity, paying more than a per-purchase or total limit allows, paying a merchant or payee outside the approved set, or acting after the mandate expired or was revoked. In an overreach dispute, the user's complaint that the agent exceeded its instructions is true. That is what separates overreach from mandate repudiation, where the agent stayed within its authority and the user disputes the purchase anyway.

Agent spend limits are caps on how much money or metered resource an AI agent may commit, set per transaction, per period, per agent or across a group of agents, and checked before each spend. Also called per-agent budgets, they apply both to payments an agent makes on someone's behalf and to the agent's own running costs, such as model tokens and paid tool calls. A spend limit is only as accurate as the spend total it is checked against. If that total lags recent commitments, or several agents draw on it at once, the limit can be exceeded without any single check failing.

An agent wallet is an account or credential that lets an AI agent hold or spend money on its own, within limits set by the person or company it acts for. Many agent wallets are onchain wallets the agent uses through an API while the keys stay in an isolated enclave the agent cannot reach, with caps per transaction or per session. The term is also used for setups where the agent holds a tokenized card credential instead of keys. A wallet's own checks cover only that wallet; a budget shared by several agents has to be tracked by whoever runs them.

Agentic memory is the set of mechanisms that let an AI agent keep information from its own work and use it in later steps, sessions or tasks, because the language model underneath retains nothing between calls. The term is used in two ways. Broadly, it means any memory an agent uses, usually divided into working, episodic, semantic and procedural memory. Narrowly, it means memory the agent manages itself, deciding what to store, link, update or discard.

An agentic mesh is an architecture for operating many AI agents, built by different teams or vendors, as one governed network. Agents register their capabilities, discover one another, delegate tasks and share context through common services for identity, access control, observability and policy, rather than through point-to-point integrations. The term names an organizing pattern for an agent ecosystem, not a single product or protocol.

Agentic tokens are card-network payment tokens issued for use by a specific AI agent. A registered agent presents the token in place of the card number to pay on a cardholder's behalf, and merchants, networks and issuers can recognize the payment as agent-initiated. Agentic Tokens is the name Mastercard uses for the credentials in Mastercard Agent Pay; Visa issues tokenized credentials for agents under Visa Intelligent Commerce, and Stripe calls both "agentic network tokens." A token carries the agent's identity and per-transaction controls, while totals across many purchases are tracked separately.

The blackboard pattern is an architecture in which independent specialist components, called knowledge sources, cooperate on a problem by reading from and writing to one shared data structure, the blackboard, instead of messaging each other directly. A control component watches the blackboard and decides which knowledge source acts next, based on its current contents. The solution builds up incrementally on the blackboard as each specialist contributes a partial result.

Context isolation is the practice of splitting an AI agent's work so that separate parts run in separate context windows, or of holding information where the model cannot see it until a step needs it. The most common form gives each sub-agent its own window and returns only a condensed result to a coordinating agent. Isolation limits what each model call sees. It does not isolate the external data those calls read and write.

Context offloading is the practice of moving information out of a language model's context window into external storage, such as a file, a scratchpad, a runtime state object or a database, and bringing it back only when a later step needs it. The window keeps a short reference or preview in place of the full content. Offloading controls what a prompt carries; it does not make the stored information more correct or more current.

Episodic memory, in AI agents, is a store of the agent's own past experiences: specific interactions, actions and their outcomes, each kept with when and in what context it happened. Agents retrieve episodes to reuse what worked, avoid repeating what failed and reconstruct what happened before a decision. The term comes from cognitive psychology, where it names memory for personally experienced events, as distinct from semantic memory for general knowledge.

Mandate repudiation is a descriptive name for a dispute in which a person denies a purchase that an AI agent made inside the authority they gave it, either by claiming the agent acted on its own or by denying they granted that authority at all. The purchase fell within the mandate; the claim says it did not. The claim can come from regret, a forgotten standing instruction or bad faith. It looks identical to a genuine case of agent error or overreach, and only evidence of the mandate, its status at the time of purchase and what the agent did against it tells the two apart.

Mastercard Verifiable Intent is an open specification, maintained by Mastercard and co-developed with Google, for proving what a person authorized an AI agent to buy. It chains signed credentials from the card's credential provider to the user to the agent, binds the user's constraints (such as an amount range, approved merchants or a total budget) into them, and lets the merchant, the payment network and later a dispute investigator check a purchase against those constraints. It gives cryptographic evidence that an agent stayed inside the authority it was given; it does not judge how the agent behaved within it.

Procedural memory is the part of an AI agent's long-term memory that holds how to act rather than what is true: the rules, code, instructions and skills that determine its behavior. In the CoALA framework for language agents, it takes two forms, implicit knowledge in the language model's weights and explicit knowledge in the agent's code. In practice it also includes system prompts and reusable skill libraries. The term comes from cognitive science, where it names memory for skills and procedures, "knowing how" as distinct from "knowing that."

Semantic memory is long-term memory for general knowledge: facts, concepts and the relationships between them, held without a record of when or where they were learned. In AI agents, it is the store of facts an agent keeps about the world, its users and itself, such as a customer's preferred language or a product's return policy, which it retrieves into its working context when a task calls for them. It is distinct from episodic memory, which records specific past events, and from procedural memory, which holds how to act.

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.

A state footprint is the full set of state an agent task reads and writes while it runs: its own context and local files, the orchestrator's plan and task status, and external systems such as code repositories, databases and APIs. Two tasks conflict when one writes an item the other reads or writes. Recording footprints lets a multi-agent orchestrator order conflicting tasks, undo only what a failed task touched, and tell which earlier results are still valid.

Stateful governance is the control of AI agent actions by policies that depend on mutable state, such as a team's spend so far, remaining inventory, pending approvals or current risk signals, rather than only on the request being made. Because that state can change between the policy decision and the action's effect, stateful governance has to keep the decision valid through commit: an action takes effect only if it is still allowed against the state immediately before it lands.

Tool calling, also called function calling, is the mechanism by which a language model asks the application around it to run an external function, such as a database query, an API request or a calculation, and then uses the result. The model does not execute anything itself. It emits a structured request naming a tool and its arguments, the application or the model provider runs it, and the output goes back to the model as input to its next step.

The Visa Trusted Agent Protocol (TAP) is a framework Visa introduced in October 2025 that lets an AI agent prove to a merchant, with a cryptographic signature on each request, that it is a recognized agent and whether it is browsing or paying. Built on HTTP Message Signatures (RFC 9421), each signature covers the merchant's domain and page path and carries timestamps and a nonce, so the merchant can reject requests that were altered, expired or replayed. Signed objects in the request body can also carry consumer recognition data and payment information.

Context clash is the failure in which information gathered into a language model's context conflicts with other information in the same context, and the model's answer is pulled toward the wrong part. It typically builds up in multi-turn conversations and agent loops, where early guesses, superseded tool outputs and sources that disagree all stay in the prompt. Unlike context confusion, the conflicting content is relevant; it just disagrees with something else the model can see.

Context compression is the practice of reducing the number of tokens in a language model's context while keeping the information the current task needs. Common forms are summarizing earlier turns, pruning irrelevant passages, trimming old messages by rule and token-level prompt compression. It is a technique, not a failure: it trades fidelity for room and focus, and an aggressive compressor can drop a detail the task later depends on.

Context confusion is the failure in which superfluous content in a language model's context, such as irrelevant documents or unneeded tool definitions, is used by the model and lowers the quality of its response. The extra content is neither false nor contradictory; the task simply does not need it, and the model attends to it anyway. In agents, a well-documented form is too many tools: offered a long list, the model calls the wrong tool or one that was not needed at all.

Context distraction is the failure in which a language model's context grows so long that the model over-relies on what the context contains, such as its own history of past actions, and neglects what it learned in training. In long-running agents it shows up as repetition: the agent replays earlier moves instead of forming new plans. It is a length effect that can begin well before the context window is full, and it is separate from irrelevant content misleading the model or from parts of the context contradicting each other.

Context poisoning is the failure in which a hallucination or other error enters a language model's context and is then referenced again on later turns, so the mistake compounds instead of fading. It does the most damage in agents that carry goals, plans or summaries forward, because every step reads the false claim as settled fact. In security writing, the same name describes an attacker deliberately planting instructions or preferences in an agent's memory or conversation thread.

Embedding drift is a change over time in the distribution of the embedding vectors a system produces, measured against a reference set. It has two causes: the input data shifts, so new items and queries land in regions of the vector space the reference barely covered, or the embedding function changes, through a new model, a new model version or different preprocessing. Similarity queries keep returning results with plausible scores when either happens, so drift can degrade retrieval and downstream models with no obvious failure. It is distinct from stale embeddings, where the model is unchanged but stored vectors were not recomputed after their source data changed.

Filtered vector search is nearest-neighbor search restricted to items that satisfy structured predicates, such as category = 'shoes' AND in_stock, so that the result is the k most similar items among those that match, not the k most similar overall. Engines implement it by filtering before the search (pre-filtering), after it (post-filtering), or during the traversal of the vector index. The strategy decides whether a query returns k correct results, fewer than k, or results that miss closer matches.

Lost in the middle is the tendency of large language models to use information placed at the beginning or end of a long input context more reliably than the same information placed in the middle. Accuracy plotted against the position of the relevant passage forms a U-shaped curve. The effect is about where content sits inside a single prompt, not about whether that content is correct or current.

Memory supersession is how an AI agent's long-term memory handles facts that change: when a newer value replaces an older one (a user moves, a price changes, a plan is revised), the agent must answer from the current value and stop asserting the superseded one. Memory systems implement it by overwriting or deleting the old entry, or by marking it invalid from a point in time and keeping it as history. The hard part is noticing that a new statement supersedes an old one, because real updates are rarely phrased as updates.

Operational AI is artificial intelligence that runs inside a business's live processes and makes or directly triggers decisions while the work is happening: approving a payment, routing an order, pricing a ride, resolving a support ticket. It is usually contrasted with analytical AI, which produces forecasts and reports that people act on later, and with generative AI used only to draft content. Because its outputs act on the business directly, operational AI carries production requirements: low latency, high availability, current input data, monitoring and an audit trail.

Point-in-time correctness is the property of a machine learning training dataset in which every feature value attached to a labeled example is the value that was known at that example's timestamp, never a later one. It is produced by point-in-time joins, also called as-of joins, which match each label to the most recent feature value at or before the label's time. Without it, training data leaks information from the future, and offline metrics overstate how the model will perform in production.

A real-time feature store is a feature store that serves machine learning features reflecting events from the last few seconds, not only the last batch run, fast enough for an online prediction. It adds two paths to a batch feature store: streaming or push ingestion that updates feature values in the online store shortly after events occur, and request-time transformations computed when the prediction is requested. An offline store keeps feature history so that models train on the same feature definitions they are served.

Stale embeddings are stored vectors that no longer represent their source data because the source changed, through an edited document, an updated row or a deleted record, and the embedding was not recomputed. The embedding model is unchanged; the input moved. A similarity search over stale embeddings ranks items by what they used to say, and an index that is not updated on delete can return items that no longer exist. The fix is re-embedding what changed, which is why staleness is a pipeline problem rather than a model problem.

Temporal RAG is retrieval-augmented generation that accounts for when facts were true. Each retrievable fact or passage carries time information, such as the period it was valid or the date it was recorded, and retrieval filters or ranks by how well that time matches the question. A model asked about last quarter, or about right now, then receives evidence from that moment instead of the most similar text from any moment. Temporal RAG matters most when a corpus holds several versions of the same fact.

A token budget is a limit on how many tokens a language model call, or a whole multi-step agent task, may use. The term covers three related limits: how a fixed context window is divided among the parts of a prompt and the reserved output, a cap on generated tokens including hidden reasoning, and a ceiling on total tokens across an agent's run for cost or latency control. A token budget governs how much goes into and comes out of a model, not whether that content is accurate.

Training-serving skew is a difference between a machine learning model's performance during training and its performance during serving, often because the model receives different inputs in production than it was trained on. Common causes are feature logic implemented twice, once for batch training and once for online serving; data that changes between training and serving; and feedback loops between the model and the system around it. Skew rarely raises an error. The model keeps returning predictions that look normal and are measurably worse.

Closed-loop decisioning is a way of running automated decisions in which each decision's output is fed back as input to later decisions. In the fast loop, every verdict, score, hold, limit or action is written to the state the next decision reads, often seconds later. In the slow loop, observed outcomes such as chargebacks, defaults or conversions flow back into the rules and models. An open-loop system decides and moves on: nothing it decided changes what it reads next.

A decision ledger is an append-only record of the decisions an automated system makes, kept as first-class data rather than as log lines. Each entry records what was decided, the inputs the decision read, the policy and authority it acted under, the action taken, and what changed as a result. Like a financial ledger, entries are never edited in place; corrections are new entries. A decision ledger serves two readers: auditors reconstructing why something happened, and later decisions that must respect what earlier ones committed.

Decision traces are durable records of how individual decisions were made: the inputs gathered, the policy applied, any exception or precedent invoked, who or what approved it, and what changed as a result. Where a rule says what should happen in general, a decision trace records what happened in one specific case. Accumulated over time, decision traces become searchable precedent for audits, debugging and later decisions, including decisions made by AI agents. A trace can be checked later only if it records what the decision read, and as of when.

Velocity checks are fraud and risk rules that measure how often, or how much, something happens per key within a time window, and act when a threshold is crossed. The key is an identifier such as a card, device, IP address, email or account; the measure is a count, a sum of amounts or a count of distinct values; and the action is to decline, send to review or ask for step-up authentication. For example, a rule might decline a card after five authorization attempts in ten minutes. A velocity check is only as accurate as the count it reads at the moment the transaction is evaluated.