A Signed Decision Is Not an Execution Outcome
A signature proves who issued a record and whether it changed. It does not prove that the approved action executed, settled, or produced the intended result.
Four Facts Belong in the Evidence Chain
- Verification decision. Was this transaction authorized for this agent and principal under the evidence and rules evaluated?
- Invocation decision. Was this exact tool version, assignment, argument set, and policy state allowed on the governed path?
- Execution outcome. Did the allowed invocation succeed, fail, remain unexecuted, or end in an unknown state?
- Payment or fulfillment outcome. Did value settle, did the seller deliver, and was the commercial result later refunded, disputed, or accepted?
One event can inform the next. None of the four should be silently treated as proof of another.
What a Signature Proves
A valid signature can establish the issuing key and detect changes to the signed bytes after issuance. The record can also state which evidence, policy version, decision, and time the issuer observed.
The signature does not make every input true. It does not prove that the caller enforced the decision, that a tool executed, that a payment settled, that fulfillment occurred, or that the principal intended an outcome beyond the authority represented in the record.
Use Explicit Outcome States
An execution record should say what is known rather than convert missing evidence into success. Useful states include success, failed, not_executed, unknown, and missing.
Not_executed means the system has affirmative evidence that no execution occurred, such as a BLOCK before launch. Unknown means execution may have occurred but the outcome was not resolved. Missing means the expected outcome record is absent. Those distinctions matter in incident response and audit review.
Link Records Without Collapsing Them
Use shared identifiers for the transaction, verification record, invocation, Agent Passport, Tool Passport, exact digest, policy version, payment receipt, and fulfillment event. That creates a traversable evidence chain while preserving which system observed each fact.
The record order can vary by workflow. The semantic boundary should not. A later outcome may refer back to an earlier decision, but it should not rewrite the decision that was made with the evidence available at the time.
ALLOW and STEP-UP Can Coexist
Suppose an agent requests a $0.01 x402 purchase through an approved adapter. Command may return ALLOW because the adapter's exact digest, assignment, and invocation policy pass. Verify may return STEP-UP because the transaction lacks current principal authority or another required proof.
The tool decision and transaction decision are not contradictory. The adapter is approved to run, but the purchase is not yet approved to proceed. The integrating caller must honor the stricter condition and withhold the consequential action until the requested evidence produces a fresh decision.
Where FLINT Fits Today
FLINT Verify issues signed transaction authority decisions. FLINT Command can issue a separate signed invocation decision and execution outcome for supported calls that pass through the managed design-partner pilot.
The current Command boundary is one scoped Linux workflow. The caller is responsible for routing the supported call through Command, enforcing the decision, and linking payment or fulfillment evidence produced by other systems.
Common Questions
Does a signed ALLOW prove the action ran?
No. It proves the issuer signed an ALLOW decision. Execution requires separate outcome evidence.
Does success prove the action was authorized?
No. A system can execute an unauthorized action successfully. Preserve the authority decision and execution result separately.
Why distinguish unknown from missing?
Unknown records unresolved execution. Missing records the absence of expected evidence. They drive different investigations.
Who enforces a FLINT decision?
The integrating wallet, API, gateway, or fulfillment system enforces the decision.
Sign each fact, link the chain, and keep the claims narrow enough that an auditor can tell what was decided, what ran, and what happened next.
Primary Sources
Related Academy Briefs
Get in touch
If you are building on agentic payment rails and want to talk through how FLINT fits your stack, reach out directly.
contact@flint.network