Every evidence field traces back to its source

Every evidence item attached to a Victava dispute carries four things alongside its value:

• Source system — which of your connected accounts it came from (Stripe, Shopify, your helpdesk, or a carrier).
• Exact lookup — the specific request used to retrieve it.
• Field — the precise field the value was read from, such as a shipment's tracking number.
• Retrieved-at timestamp — when it was pulled.

Any evidence item missing complete provenance is rejected before it can be attached to a dispute, and a rebuttal can never be submitted to Stripe if that check fails.

1. Hallucinated facts in AI-drafted rebuttals. LLMs cheerfully invent “the customer logged in on 2026-04-12 from IP 192.168.x.x” when the actual access log shows no such event. With provenance, the LLM can't emit a value unless the value comes attached with a real API endpoint and timestamp the value actually came from. The rebuttal builderretrieves, the LLM narrates — never the other way around.
2. Stale data across long pipelines. A dispute lands today, but the evidence-gathering ran at midnight, and the Shopify fulfillment was updated at 6am. With retrievedAt, the merchant can see exactly when each field was pulled — and we can re-pull anything older than the dispute creation timestamp before submission.
3. Cross-API joins that silently break. We pull a Stripe charge, look up the Shopify order by Stripe payment_intent metadata, and join a FedEx delivery event by tracking_number. If the Stripe → Shopify join fails (metadata stripped, custom-field changed), provenance makes the failure visible — the merchant sees the missing source endpoint and can tell us “use my custom shopify_order_id field instead.”
4. Audit-readiness. If a dispute is lost and the merchant asks “why,” we walk through the submitted evidence row by row. If a regulator, insurer, or processor asks for chain-of-custody, the same audit trail answers them. No reconstruction; no “our AI thought it” opacity.

Every dispute detail page shows evidence in a structured table:

• Field name — the Stripe evidence field this maps to (e.g., shipping_tracking_number)
• Value — the actual data being submitted
• Why it matters — a short rationale citing the relevant Visa/Mastercard reason-code requirement
• Source — collapsible: “from Shopify Order #1234, fulfillment line item 2, fulfillments[0].tracking_number, retrieved 2026-04-25 14:32 UTC”

Click any source to expand the raw API response and the field path we extracted from. If the value looks wrong, you can edit before approving — or click Re-fetch to pull the field again from the source API.

The architectural complement to the provenance contract: the LLM is allowed to narrate evidence, never to fabricate it. The pipeline stages are:

1. Retrieval specialists — deterministic code (no LLM) pulls evidence from each source API. Each retrieval emits an EvidenceItem with full provenance attached.
2. Validator — rejects any item without complete provenance. Rejections halt the pipeline and surface a structured error.
3. Evaluator (LLM) — scores the evidence packet. Cannot add or remove items, only score them.
4. Drafter (AI) — composes the narrative explaining why the evidence wins the case. The narrative cites the evidence items by field name; it cannot invent new facts.
5. Submission step — requires a recorded merchant approval before anything is written to Stripe.

This is enforced automatically by the system and its tests, not by careful prompting. We can't accidentally bypass it.

Three reasons, plausibly:

• Speed-to-market. Auto-fill the Stripe evidence object from any source you can find and submit — works for the median case, ships in months not years. Provenance adds engineering overhead that competitors decided wasn't worth it.
• No merchant asks for it explicitly. Provenance is a trust feature, not a feature merchants demo. They ask “what's your win rate?” and competitors answer with point estimates. They rarely ask “can I trace this evidence back to its source API call?” until something goes wrong.
• It exposes weakness. If you can't cite a source, the rebuttal is shaky. Tools that don't implement provenance benefit from leaving that opacity in place.

We made the opposite trade-off: every evidence row is auditable, even (especially) the LLM-suggested ones. If our drafter wants to claim “the customer logged in after the disputed transaction, showing they had access to the account,” the access log entry must exist with a real timestamp and we surface the timestamp inline.