What did the agent decide to do?
Log the decision itself, before any action — the record that this specific purchase or transfer was chosen, and why, independent of whether it later succeeds.
Operator pathway · foundation 04
A transaction hash is not a receipt.
The money moving is one event. The thing you paid for actually arriving, correctly, is a separate event — and an agent that only tracks the first one has no way to know when the second one silently failed.
Learning boundary. This lesson teaches an operating model. It is not a certification, security assessment, legal delegation, financial recommendation, or approval to use production funds.
Learning objective
Separate six transaction states.
By the end of this lesson, you should be able to inspect a proposed transaction-tracking implementation, assign evidence-based readiness scores, identify which states are conflated into one, and explain why settlement proof and fulfillment proof have to come from different sources.
Was it actually permitted?
Confirm the mandate and policy checks passed for this specific action — a distinct state from intent, since an agent can intend something its policy then correctly blocks.
Was the request submitted?
Record that the signed instruction left the agent's control and reached the payment rail — this is where "sent" lives, not where "succeeded" lives.
Did the payment clear?
Confirm the funds actually moved and finalized on the payment rail — a transaction hash or confirmation ID belongs here, and nowhere else in the chain.
Did the thing paid for arrive?
Independently verify delivery of the good, data, or service — from a source other than the payment rail, since the payment rail has no visibility into whether the counterparty delivered.
Do settlement and fulfillment agree?
Actively match settlement records against fulfillment records and flag mismatches — silence here means nobody is checking, not that everything matched.
Practice lab · evidence before confidence
Score a transaction-tracking setup.
A data-purchasing agent logs a transaction hash the moment its payment API call returns success and marks the request "complete." The vendor's data delivery arrives via a separate webhook the team built but does not currently monitor. There is no process that compares paid requests against delivered responses.
- Score each dimension from 0: absent, 1: documented, or 2: tested.
- Name every claim that requires evidence before awarding a point.
- Identify the critical gaps that prevent a bounded pilot.
- Write the smallest safe next experiment.
Answer rationale
Settlement earns a 2 — the transaction hash is real, tested proof that payment cleared. Fulfillment is 0, not partial credit: a webhook that exists but isn't monitored provides no evidence delivery is being verified, only that it technically could be. Reconciliation is 0 — nothing compares the two records, so a paid-but-undelivered request is indistinguishable from a paid-and-delivered one in the system's own view. Marking the request "complete" at settlement conflates two states that must stay separate. The appropriate next step is wiring the existing webhook into an active reconciliation check — not adding more payment-side logging.
STOP → RECONCILE