Establish which payment this refund request refers to
Actual
Payment could not be correlated
Approved refund is issued correctly · business records read Oct 30, 2026, 14:38 UTCDue Oct 30, 2026, 14:40 UTC (business clock)
Evidence limits: Two orders belong to this customer; the request does not identify which payment to refund. Review the request before correlating a payment.
ExpectedCaptured contract v1 · due 2 min after resolution
Original agent message
The agent wrote, Oct 30, 2026, 14:38 UTC
We've refunded $45.00 to your original payment method for order ord_mvv2nedq4sm20o7v. It should appear within 5-10 business days.
No condition was evaluated: the ticket could not be correlated to business records (see below).
When the support agent approves a refund request and resolves the ticket, the payment for the order named in the ticket must carry a succeeded refund for exactly the requested amount, in the requested currency, within two minutes. Refunds on other payments of the same customer do not count.
ObservedSystems of record, read-only · retrieved Oct 30, 2026, 14:38 UTC
Tickettkt_mvv2neek4ub7m582
Status
Resolved
Agent approved
yes
Resolved at
Oct 30, 2026, 14:38 UTC
Order quoted
none
Refund requested
$45.00
Source
Support
Order
Lookup
Not resolved: order id
Payment and refunds
Lookup
No payment for this order
Shipmentno shipment
Shipments for order
0
Other orders, same customer
ord_mvv2nedq4sm20o7v
paid· $80.00 · refunded $45.00 after the ticket
ord_mvv2ned34qw4qdg1
paid· $45.00
Review needed
Recorded with your name; nothing is guessed
Veycera could not tell which order this ticket is about, so it did not judge the outcome. If you can establish the order from the conversation, name it and the instance is re-evaluated under the same contract version. Otherwise dismiss it: the record stays indeterminate and is not counted as a success or a failure.
Customer request in helpdesk ticket tkt_mvv2neek4ub7m582 (refund), asking for $45.00
Authorization
Agent approved the request· required by the captured contract trigger
Trigger
A refund ticket becomes resolved after agent approval
Obligation
0 applicable conditions must hold within 2 min of resolution; due Oct 30, 2026, 14:40 UTC
Instance created by
connector event · ticket.resolved via webhook (processed)
Checks run
1
Correlated identifiers
Only explicit references are used
Ticket
tkt_mvv2neek4ub7m582
Order quoted in the ticket
none quoted
Order resolved
not resolved
Payment
none for the order
Refunds on that payment
none
Shipment
none for the order
Customer
cus_mvv2necn4pl0lnkd
Other orders, same customer
ord_mvv2nedq4sm20o7v, ord_mvv2ned34qw4qdg1
Correlation rule
The order comes only from the ticket's order reference. When it is missing or unknown the verdict is indeterminate, never a guess by email or recency.
Missing or ambiguous evidence
1
Could not resolve order id: the ticket must name the order explicitly; Veycera does not guess by email or recency.
Stored for this verdict: the business snapshot, predicate results and captured contract v1. No application logs, traces, runtime metrics or agent execution history were read or kept.
Contract as evaluated v15 conditions · deadline 2 min
This is the version the verdict was computed under. Editing the contract creates a new version and does not change this record.
{
"trigger": {
"object": "ticket",
"categories": [
"refund"
],
"status": "resolved",
"requiresAgentApproval": true
},
"identifiers": {
"order": {
"source": "ticket.orderRef",
"required": true
}
},
"conditions": [
{
"path": "refunds.succeededMinor",
"op": "eq",
"ref": "ticket.requestedAmountMinor",
"id": "refund_amount_correct",
"description": "Succeeded refunds on the named payment equal the requested amount",
"applicableWhen": [
{
"path": "charge.exists",
"op": "eq",
"value": true
},
{
"path": "ticket.requestedAmountMinor",
"op": "neq",
"value": null
}
]
},
{
"path": "refunds.succeededMinor",
"op": "eq",
"ref": "charge.amountMinor",
"id": "refund_full_when_unspecified",
"description": "Without a requested amount, the payment is refunded in full",
"applicableWhen": [
{
"path": "charge.exists",
"op": "eq",
"value": true
},
{
"path": "ticket.requestedAmountMinor",
"op": "eq",
"value": null
}
]
},
{
"path": "charge.currency",
"op": "eq",
"ref": "ticket.requestedCurrency",
"id": "refund_currency_matches",
"description": "The payment's currency matches the requested currency",
"applicableWhen": [
{
"path": "charge.exists",
"op": "eq",
"value": true
},
{
"path": "ticket.requestedCurrency",
"op": "neq",
"value": null
}
]
},
{
"path": "refunds.count",
"op": "lte",
"value": 1,
"id": "refund_single",
"description": "At most one refund was issued against the payment",
"applicableWhen": [
{
"path": "charge.exists",
"op": "eq",
"value": true
}
]
},
{
"path": "siblingRefunds.sinceTicketMinor",
"op": "eq",
"value": 0,
"id": "no_refund_on_other_payments",
"description": "No other payment of the customer was refunded for this request",
"applicableWhen": []
}
],
"deadlineSeconds": 120,
"instance": {
"eventTypes": [
"ticket.resolved"
],
"initialRetrySeconds": 30,
"maxRetrySeconds": 600,
"maxAgeSeconds": 86400
}
}
Timeline
UTC · clock domain labelled on every event
Ticket createdbusiness / scenarioDemo time · Oct 30, 14:38 UTC
Ticket resolvedbusiness / scenarioDemo time · Oct 30, 14:38 UTCthe clock for the deadline starts here
Event received (webhook)wall-clock ingestionOct 30, 2026, 14:32 UTC· 2 h agoticket.resolved · evt_mvv2neiy4wnwucxq
Event processedwall-clock ingestionOct 30, 2026, 14:32 UTC· 2 h agoprocessed
Records retrievedbusiness / scenarioDemo time · Oct 30, 14:38 UTCSnapshot labelled by the source/simulation clock, not wall-clock ingestion
Evaluatedbusiness / scenarioDemo time · Oct 30, 14:38 UTCcheck 1 of this instance
Deadlinebusiness / scenarioDemo time · Oct 30, 14:40 UTC2 min after resolution
Final verdict reachedwall-clock ingestionOct 30, 2026, 14:32 UTC· 2 h ago
Record identifiers and retention
Execution out_mvv2nemb4yet0q6o · ticket tkt_mvv2neek4ub7m582 · 1 recorded checks.
Stored for this verdict: the business snapshot, predicate results and captured contract v1.
Simulated time · 6 min ahead
Business records and deadlines use scenario time. Ingestion, reviews, and investigation execution use wall time. Timeline events label their clock; both are shown in UTC. Demos advance business time instead of waiting.