Evidence provenance, explained

The four provenance fields

Every evidence_items row in your dispute carries:

• source_api — which integration produced this value: stripe, shopify, zendesk, tenant_settings, or victava-llm (only for the small narrative carve-out).
• source_endpoint — the exact API endpoint hit. Example: /v1/charges/ch_… or /admin/api/2024-01/orders/123.json.
• source_field_path — the JSONPath into the API response. Example: payment_method_details.card.checks.cvc_check.
• source_retrieved_at — the timestamp the value was read. ISO-8601 with milliseconds.

Why all four

With all four, every cell on every dispute is auditable. If the win-probability score depends on Radar’s risk_level, you can click the field and see exactly which Stripe API call produced it, when, and where in the response. This is the difference between trusting the model and trusting the data.

The “Never Generate, Only Retrieve” rule

Victava has a non-negotiable design rule: the AI never fabricates factual data. Tracking numbers, dates, amounts, IPs, addresses — all of these come from your connected accounts, each tagged with where it came from. The AI is only allowed to author text in three narrative fields — the cancellation, duplicate-charge, and refund-refusal rebuttals — and even those are clearly marked as AI-written so you can see them at a glance.

This is strictly enforced — if any field has AI-authored content outside that small, allowed set, the dispute errors out and does not submit.

How to read provenance in the UI

On the dispute detail page, every evidence item card has a provenance summary line: stripe · /v1/charges/ch_… · 15:51:46Z. Hovering opens a modal with the full path and the raw value. The Stripe evidence payload preview (what gets shipped to Stripe on submit) renders the same way — every cell is hover-traceable to its source.