What proves what the AI actually did: PostgreSQL and the transactional evidence layer

An AI agent receives a refund request, retrieves the order, evaluates the rules, decides the refund is permitted, and calls the appropriate service. From the AI system's point of view, the flow succeeded: the trace shows that a decision was made and a tool was invoked. Except the payment system tells a different story. The operation failed, the transaction was rolled back, and no refund was actually committed.

This scene opens Vibhor Kumar's article published on Planet PostgreSQL, and it captures the problem that matters to anyone putting AI automation into production: the fact that an agent called a tool and the fact that a business transaction was committed are two different facts. Conflating the two is the shortest path to an impossible audit six months later.

Observability tells you what the AI did, not what changed

During the generative AI era, attention has been on what models produce: accuracy, latency, token consumption, trace quality. That makes sense when the interaction ends in a response. It isn't enough when it ends in a business action.

Kumar is direct about the distinction. An execution trace can establish that an agent invoked approve_claim() at 10:42:17. Only the authoritative claims system can establish whether claim 84721 actually moved from pending to approved. The first describes execution; the second describes business state. A trustworthy architecture needs to connect the two, and the problem is that these records usually live in different systems, with different identifiers, retention policies, and notions of success.

This is where things break down in practice. A timeout can make the agent repeat an action that had already succeeded on the first attempt. A downstream system can reject an operation after the AI flow has already considered the task complete. In each case, the execution record says something true, but doesn't tell the whole story.

The evidence layer: questions that must remain answerable

Kumar calls this connective tissue an evidence layer: durable, correlated information that ties an AI decision or action to the authoritative business state that resulted from it. It isn't another log repository, nor an obligation to capture every intermediate event. It's a focused set of questions that must remain answerable:

• What was the AI trying to do?
• Which execution produced the action?
• Which business entity was affected?
• Which policy applied?
• Was the transaction committed?
• What state resulted?

The criterion he proposes is honest: can you answer that without pulling three teams together to reconcile disconnected logs six months later? If the answer requires a war room, the organization has observability data, but it doesn't yet have an evidence architecture.

Where PostgreSQL comes in (and where it shouldn't)

It's worth underscoring the DBA's judgment here, because Kumar is right to resist the obvious temptation. PostgreSQL should not become an AI observability platform. Storing every prompt, every token event, and every distributed trace in a transactional database would be the wrong instinct, both from a modeling and a cost standpoint.

The database's role is a different one. In many enterprise systems, PostgreSQL already sits exactly at the boundary where business state becomes durable, which makes it the natural place to anchor evidence of what an AI action actually changed. The execution carries a correlation identifier, an execution_id, throughout the flow. When the business transaction happens, that identifier is associated with the entity and the state transition the action produced.

The article's example, simplified, is elegant precisely because the trick isn't in the evidence table, it's in the transactional boundary:

BEGIN;

WITH approved_refund AS (
  UPDATE customer_refund
     SET status = 'approved',
         approved_at = CURRENT_TIMESTAMP
   WHERE refund_id = :refund_id
     AND status = 'pending'
  RETURNING refund_id
)
INSERT INTO ai_action_evidence (
  execution_id, entity_type, entity_id, action, model_ref, policy_ref
)
SELECT :execution_id, 'refund', refund_id, 'approve', :model_ref, :policy_ref
  FROM approved_refund;

COMMIT;

The crucial point: the evidence is tied to the state transition, not to the agent's request. If the refund is no longer pending, the UPDATE changes nothing, the RETURNING returns no row, and no evidence record claiming approval is inserted. If the transition happens, business change and evidence become durable together. If the transaction rolls back, neither one falsely represents a committed outcome. It's the right design solving the problem before any application layer has to handle an exception.

The rollback is part of the story too

There's a subtlety that separates those who understand integrity from those who just want one more log. If the refund transaction rolls back, we don't want durable business evidence claiming the refund was approved. But that doesn't mean forgetting that the AI tried.

Execution evidence says what the AI attempted. Transactional evidence says what the business accepted. A rollback shouldn't erase the fact that the AI tried something, only prevent durable evidence from falsely claiming the change was committed.

-- Vibhor Kumar

The two records answer different questions, and that's exactly why they need to remain distinguishable and correlated, rather than collapsed into one. The execution trace holds the attempt and the failure; the transactional evidence holds the consequence.

When it doesn't fit in a single transaction

Kumar is careful to acknowledge the limit: real flows rarely stay within a single database transaction. If PostgreSQL records the refund request but an external payment provider is the one who moves the money, the local transaction can't prove that leg completed. The database doesn't create atomicity across systems that don't share a transactional boundary, and the architecture shouldn't pretend that it does.

It's the classic transactional outbox scenario: a PostgreSQL transaction atomically commits local business state and an event describing what needs to happen next; another process reliably publishes that event downstream; and the same execution_id and entity identifiers cross the boundary. Logical decoding and CDC propagate the relevant changes forward, for analytics or long-term retention. The goal isn't a giant audit database, it's a durable chain of correlated evidence across systems that don't share a transaction.

Evidence isn't logging

Treating this as a logging problem underestimates it. Logs are optimized to understand system behavior: high volume, operational scope, retention for troubleshooting. Business evidence is different. It needs to survive longer, correlate with authoritative business identifiers, carry stronger integrity guarantees, and often answer regulatory or contractual retention requirements. There's no need to store every intermediate token the agent generated while deciding, but it may be necessary to prove that a specific execution led to a specific refund, that the applicable policy was evaluated, that the transaction was committed, and that the customer received the money.

Why this becomes a business problem

Kumar ties the argument together with an angle that the Brazilian developer doing integration work should have on their radar: AI economics is shifting from cost per token to cost per task, and in some cases, cost per successful business outcome. He proposes a concrete scenario: the vendor reports that the AI resolved 10,000 requests; the company's systems show 9,300 completed under the contractual definition of success. Which number goes on the invoice?

From there, it stops being an observability problem. Both parties need to agree on what counts as an outcome, how it's attributed, and what evidence proves it happened. And transactional evidence, quietly, becomes part of AI's commercial architecture.

What to take back to your own project

Readers don't need to wait for outcome-based pricing to test their own architecture against three questions Kumar leaves us with: can you correlate an AI action with the business transaction it caused? Can you distinguish what the AI attempted from what was actually committed? And can you reconstruct that evidence six months from now without assembling a task force? If answering all three requires logs from four teams and assumptions about timing, the design isn't yet ready to give an agent authority to act. The more authority you hand to AI, the more that durable boundary between intent and consequence matters, and PostgreSQL, when it owns the authoritative state, is a solid place to anchor it.