> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duckie.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# MVP

> The smallest useful autonomous dispute operations system before full submission, escalation, reporting, and feedback loops

Start with an autonomous case-handling loop. Duckie should receive a dispute case, normalize required fields, classify the reason, gather approved evidence, choose the next path from deterministic policy, and submit or record only the actions your policy allows without human approval.

This proves the system without putting every case through a reviewer or starting with full external submission automation.

<Info>
  The MVP is one case record, one validation workflow, one reason classifier, one decision policy workflow, one evidence packet, and one required-approval path for cases that cannot continue autonomously.
</Info>

## MVP Goal

By the end of the MVP, Duckie should reliably answer:

* What case was opened, and what deadline applies?
* Which transaction, account, order, processor, and communication records matter?
* What is the likely dispute reason and recommended path?
* Is the case allowed to continue autonomously under policy?
* What evidence is required, present, missing, or weak?
* Should Duckie submit, record a decision, request account information, or route a required approval?

## Minimal Flow

```mermaid theme={null}
flowchart TD
  Event["Dispute case or ticket"]
  Event --> Intake["Dispute intake deployment"]
  Intake --> Validate["Normalize and validate case"]
  Validate --> Classify["Classify reason and deadline risk"]
  Classify --> Policy["Apply decision policy"]

  Policy -->|Accept or close allowed| Record["Record decision"]
  Policy -->|Need account info| Account["Ask for missing account information"]
  Account --> Validate

  Policy -->|Prepare response| Evidence["Collect approved evidence"]
  Evidence --> Draft["Draft evidence packet"]
  Draft --> Gate{"Approval required by policy?"}

  Gate -->|No| Submit["Submit or record response"]
  Gate -->|Yes| RequiredApproval["Route required approval"]
  Submit --> Outcome["Track outcome"]
  Record --> Outcome
  RequiredApproval --> Outcome
```

## Build First

| Piece                  | What to build                                                                                             | Done when                                                                                    |
| ---------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Intake deployment      | Trigger from ticketing, custom webhook, or payment processor event.                                       | Duckie creates or finds a stable case record.                                                |
| Case validation        | Normalize case ID, processor ID, transaction ID, account ID, amount, currency, deadline, and reason text. | Downstream agents always receive a structured case object.                                   |
| Reason classifier      | Classify reason category, confidence, deadline risk, and recommended path.                                | Messy processor text becomes structured workflow input.                                      |
| Decision policy        | Apply deterministic accept, close, counter, request-info, submit, and approval-required rules.            | The workflow decides whether the case can continue autonomously.                             |
| Evidence packet        | Collect approved evidence and draft the response narrative.                                               | Evidence uses auditable sources tied to the case, account, transaction, or published policy. |
| Required approval path | Route only cases that policy requires to an internal approval or escalation channel.                      | High-risk cases leave the autonomous path with a clear packet and reason.                    |
| Outcome tracking       | Record submitted, accepted, countered, won, lost, missed, or closed outcomes.                             | Each case can be audited from intake through outcome.                                        |

## Defer Until the MVP Works

Add these after the first autonomous loop is trusted:

* Full external submission automation for every processor
* Broad multi-processor routing
* Complex appeal or second-presentment flows
* Automatic handling for high-value cases
* Legal, regulatory, or policy-exception automation
* Daily reporting and feedback agents
* Large evidence source catalogs that are not yet audited

## Required Human Handoffs

Keep humans in the loop only when policy, risk, or missing authority requires it:

| Condition                                        | Handoff                                                                |
| ------------------------------------------------ | ---------------------------------------------------------------------- |
| External submission requires approval            | Route the final packet and submission summary to the approved owner.   |
| Case value is above threshold                    | Route to the finance, operations, or risk owner.                       |
| Evidence is weak or contradictory                | Route the packet with the missing or conflicting facts called out.     |
| Legal, regulatory, or policy exception appears   | Route to the team that owns that decision.                             |
| Deadline or tool failure makes automation unsafe | Route to the manual handling queue with current state and next action. |

<Warning>
  Do not remove required approval gates. The autonomous path should handle allowed cases end to end and hand off only the cases where policy, risk, or external submission rules require a person.
</Warning>

## When to Expand

Move beyond the MVP when:

* Case validation is reliable across live sources
* Reason classification is consistently correct for common categories
* Decision policy branches match operations rules
* Evidence packets are complete and sourced from auditable systems
* Required approval handoffs are specific and actionable
* Outcomes are tracked cleanly enough to improve the workflow

## Next Pages

After the MVP:

1. Read the [system map](/examples/disputes-and-chargebacks/system-map) to see the full architecture.
2. Build [intake and triage](/examples/disputes-and-chargebacks/intake-and-triage).
3. Add the [dispute handling workflow](/examples/disputes-and-chargebacks/dispute-handling-workflow).
4. Use the [rollout plan](/examples/disputes-and-chargebacks/rollout-plan) before expanding live scope.