What Is Decision Context?

What is decision context?

The phrase has older meanings. In policy analysis, a decision context is the setting people decide in: "a space in which one or more people must arrive at a decision on some matter" (Phil Ryan, Facts, Values and the Policy World). In automated systems the term is narrower and more mechanical: the data a specific decision reads at runtime, and the record of what it decided.

Tacnode uses decision context as the name for what its system holds, and it is part of the context gap vocabulary Tacnode uses to describe real-time decisioning. The framing is a loop, not a one-way feed. A fraud check, a credit limit, a pricing call or an agent's tool call reads context, produces an output, and writes that output back, where it becomes context for the next decision. Source data usually arrives from the systems a team already runs, by change data capture or streams. Decision state (verdicts, holds, per-agent limits, agent actions) is written by the decisions themselves. The two halves carry different guarantees. For source data owned by another system of record, Tacnode gives the decision accurate, consistent context to read. For decision state Tacnode holds, writes are transactional, so two decisions that conflict over the same budget cannot both commit. The design argument is laid out in the Context Lake paper on arXiv.

Decision context has four parts, and they fail in different ways:

How decision context works

Take a refund agent deciding whether to approve a refund. Its decision context is:

1. 1.The order and payment records (source data).
2. 2.The customer's refund count over the last 30 days (derived signal).
3. 3.The refund policy and three similar past cases (retrieval).
4. 4.How much of today's refund budget other agents have already approved (prior decisions).

If those four inputs come from four systems, each sits at its own propagation stage. The agent can approve a refund against a budget that a second agent spent two seconds earlier, because the budget figure it read had not yet absorbed that approval. Nothing errored. The decision read context that never existed as a whole.

Reading all of it from one store, in one transaction, closes that seam. In PostgreSQL, a Repeatable Read transaction reads every statement from one snapshot:

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT o.amount, o.status FROM orders o WHERE o.id = $1;
SELECT count(*) FROM refunds r
 WHERE r.customer_id = $2 AND r.created_at > now() - interval '30 days';
SELECT spent, cap FROM refund_budget WHERE day = current_date;
-- decide, then record the outcome so the next decision sees it
INSERT INTO refund_decisions (order_id, verdict, amount, decided_at)
VALUES ($1, 'approve', $3, now());
UPDATE refund_budget SET spent = spent + $3 WHERE day = current_date;
COMMIT;

The last two statements are the part most designs leave out. A decision's output is decision context too.

Why decision context matters in real-time systems

When a human reviews a decision, stale or mismatched inputs get caught by judgment and delay. When a model or a rule decides inside a tight window with no review, the quality of its decision context is the quality of the decision. Two forces make that hard: state that changes with every event, and many decisions reading and writing the same state at once. Faster pipelines narrow each input's lag but leave the inputs at different moments. The useful question shifts from "is our data fresh?" to "did this decision read one current, consistent picture, including what other decisions just did?" That question is developed in why AI agents act on the wrong context.

FAQ