Skip to content

PATTERN Cited by 1 source

Evidence library with auto-selection

Pattern

Maintain a persistent merchant-curated document corpus (uploaded once) and auto-select the appropriate subset per case based on multiple orthogonal classification keys. The selection produces a per-case bundle assembled from stored documents without manual operator intervention.

The pattern decomposes a repetitive bundling workflow into:

  • Storage of canonical documents once — terms and conditions, return policies, service agreements, similar boilerplate.
  • Per-case classification along orthogonal keys.
  • Auto-routing from (key tuple) to (document subset).
  • Bundle assembly in the format the consuming system expects.

Canonical wiki instance

systems/stripe-smart-disputes at 2026-05-27 (sources/2026-05-27-stripe-expanding-stripe-radar-to-protect-more-of-your-business):

"With the evidence library, you upload and store these documents once, and Smart Disputes automatically selects and includes them in your evidence packet based on the dispute's reason code, network requirements, and cardholder claims — no manual resubmission needed."

The three orthogonal selection keys:

  1. Reason code — card network's dispute classification.
  2. Network requirements — Visa / Mastercard / Amex etc.'s evidence-format and required-document rules.
  3. Cardholder claims — the specific complaint (non-receipt, not as described, unauthorized).

Generalisable beyond disputes

The pattern applies to any submission-bundle workflow with composable per-case requirements:

  • Compliance-document submission — different jurisdictions require different documents, but the underlying corpus (entity registration certificates, tax IDs, beneficial-ownership disclosures) is stable.
  • Insurance-claim filing — different claim types require different supporting documents from a stable medical-record / policy-document corpus.
  • KYC / KYB verification — different account types and countries require different verification documents.
  • Procurement / vendor-onboarding submission — different customers' onboarding portals require different artefact bundles from a stable vendor document set.

Required substrate

  • Document storage with metadata — each document tagged with applicable scope (which reason codes / networks / claims, or which compliance jurisdictions / claim types / account types).
  • Selection routing — given a (key tuple), produce the document subset. Rule-based / learned / LLM-classified — mechanism is implementation choice.
  • Format-conversion layer — if consuming systems require specific formats, the bundle must be assembled in the required shape.
  • Versioning / freshness — document content changes over time; retain old versions for cases active during their validity period.

Trade-off

  • vs manual evidence assembly — auto-selection scales to thousands of cases at fixed marginal cost; manual scales linearly with operator headcount.
  • vs always-include-everything — including all documents in every bundle is conservative but wastes reviewer attention and may include irrelevant or harmful documents (e.g. refund-policy inclusion when the dispute is about authorisation).
  • vs case-specific evidence supplied by operator — composes: auto-selection handles boilerplate; operator supplies case-specific evidence (tracking numbers, usage logs) on top.

Caveats

  • Selection mechanism not disclosed in the canonical instance. Rule-based? Learned? LLM-classified?
  • Format-conversion handling not described.
  • Versioning / freshness policy not described.
  • Coverage envelope undisclosed beyond the named document types (T&C, return policies, service agreements).

Seen in

Last updated · 542 distilled / 1,571 read