What Is Context Lag?

What is context lag?

Context lag is part of the context-gap vocabulary Tacnode uses to describe why automated decisions act on the wrong state. It names the mechanism: the propagation delay inside each system that serves a fact. The context gap names the result: a decision acting on context that is incomplete, inconsistent or outdated at the moment it executes. Lag in a store that no decision reads at execution time costs nothing. Lag under a decision that must act on current state is a gap.

The term was set against context rot in Context Rot vs. Context Lag. Context rot degrades a correct fact after it enters a model's context window, as the window fills and the model attends to it less reliably. Context lag delivers a fact that was already wrong before it entered the window. Prompt and window techniques address rot. They cannot change what an upstream store returned.

Every derived copy of state carries its own lag:

A documented example: Stripe's Issuing docs say of card spending limits, "Spending aggregation is done on a best-effort basis. You might notice a delay of up to 30 seconds between spend occurrence and spend aggregation" (Stripe Issuing spending controls). A limit check made in that interval reads a total that does not yet include the newest spend.

How context lag works

Lag accumulates hop by hop. An illustrative path for a velocity counter:

1. 1.A payment commits in the source database.
2. 2.Change data capture picks it up and publishes it to a stream.
3. 3.A stream job adds it to a one-minute window and writes the count to a cache.
4. 4.A decision service reads the count from the cache.

The count the service reads is as old as the slowest of those steps, and under a traffic burst each step falls further behind at the same time. When one decision reads several stores, each with its own lag, the values also describe different moments. The decision then sees a combination of state that never existed at once: inconsistent reads, not just old ones.

Lag can only be managed if it is measured. Record the time of the newest change each value reflects and compute its age at read time:

-- as_of = commit time of the newest source change applied to this row
SELECT account_id,
       txn_count_1m,
       as_of,
       now() - as_of AS context_age
FROM   account_velocity
WHERE  account_id = $1;

Compare the tail of context_age under peak load, not the median, against how old the input may be for that decision. A path passes on averages and fails during the bursts that matter.

Why context lag matters in real-time systems

A person reading a slightly old number on a screen usually notices when it looks wrong. A rule or an agent acting inside a tight window does not. Context lag is worst exactly when the decision is most consequential: high event rates are when counters and caches trail furthest behind, and when many decisions act on the same state at once.

Faster pipelines shrink each hop's lag but keep the hops. The structural fix is fewer independent copies under the decision: read source data and derived signals from one place, compute aggregates on demand against the latest committed data, and give each derived value an explicit freshness requirement. In Tacnode, source data arrives from the systems a team already runs by change data capture, decision state such as holds and limits is written directly, most reads run on demand against the latest committed data, and materialized views are refreshed incrementally on a schedule you set in SQL, typically every few seconds. The broader case for treating staleness as structural is in what is stale data.

FAQ