Skip to content
Postcept
Concept

Postcondition verification

A postcondition is a condition that must hold true after an action for that action to count as complete. Postcondition verification is how Postcept turns an agent’s “done” into proof: instead of trusting the claim or the trace, it evaluates each postcondition directly against the system of record.

Why postconditions, not traces

A trace shows what the agent tried to do. A postcondition asks a sharper question: did the world actually end up in the required state? An agent can emit a perfect-looking tool call to issue a refund while the refund silently fails, duplicates, or lands against the wrong charge. Only the system of record can settle it, which is why verification is deterministic, not another model.

The kinds of postconditions

For a high-risk action, Postcept typically evaluates six families of postcondition:

Existence
The action exists in the system of record at all (e.g. a Stripe refund object).
Value match
Amounts, currency, and identifiers match the agent's claim.
Identity match
The customer, account, or subject matches the intended target.
Status
The object is in the expected terminal state (succeeded, solved, cancelled).
Duplicate check
No second action was created by a retry or lost idempotency key.
Policy
Required approvals or verification steps were completed in order.

Worked example: a refund

When a support agent claims refund_customer is done, Postcept evaluates the operation against Stripe and Zendesk. Each postcondition resolves independently to passed, failed, or blocked:

Refund existsverifiedevidence
Amount matchesverifiedevidence
Customer matchesverifiedevidence
Duplicate check passedverifiedevidence
Ticket updatedverifiedevidence

The combined result is sealed into a Postcept Receipt, verified, incomplete, duplicated, mismatched, or policy-failed, and contributes to the agent’s Verified Completion Rate. When a postcondition fails, the operation is routed to review or recovery before the customer is ever notified.

Systems of record Postcept verifies against

The worked example above uses Stripe and Zendesk, but Postcept verifies against a range of payment, commerce, support, and finance systems, read-only, with scoped credentials. Today that includes:

Payments & refunds

Stripe, Adyen, PayPal, Braintree, Square, Shopify, NetSuite, and QuickBooks, checking refund existence, amount, currency, customer, status, and duplicates. Stripe also verifies subscription cancellations.

Support & CRM

Zendesk, Gorgias, Intercom, Front, HubSpot, ServiceNow, and Salesforce, checking ticket, conversation, and case resolution state and requester match.

...and your own internal systems of record via the verification API.

The verification API is live; the full reference and SDKs are coming.

Get started