> ## 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 WISMO system before full exception handling, approvals, and proactive automation

Start with one autonomous WISMO loop that can identify the order, gather live context, detect a small set of common conditions, reply safely, and save a follow-up commitment.

This proves the core value without starting with every supplier, warehouse, carrier, and replacement/refund edge case.

<Info>
  The MVP is one intake path, one canonical order context, one routing workflow, three specialist handlers, one customer communications agent, and one follow-up monitor.
</Info>

## MVP Goal

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

* Which customer, order, shipment, and support case is this?
* What does the OMS, WMS, carrier, and support history say right now?
* Is the order normal, split, delayed in fulfillment, or stalled in carrier tracking?
* What can Duckie safely tell the customer without overpromising?
* Should Duckie answer, monitor, ask for more information, or escalate?
* When did Duckie promise the next update, and what event should trigger it?

## Minimal Flow

```mermaid theme={null}
flowchart TD
  Message["Customer WISMO message"]
  Message --> Intake["WISMO intake deployment"]
  Intake --> Identify["Identify customer, order, shipment, and case"]
  Identify --> Context["Build order context"]
  Context --> Route["Condition routing workflow"]

  Route -->|Normal ETA| Standard["Standard status agent"]
  Route -->|Multiple shipments| Split["Split shipment agent"]
  Route -->|No scan or no movement| Carrier["Carrier exception agent"]
  Route -->|Low confidence or restricted state| Escalate["Escalate to human review"]

  Standard --> Reply["Customer communications agent"]
  Split --> Reply
  Carrier --> Reply
  Reply --> Followup["Save follow-up commitment"]
  Escalate --> Internal["Internal note or Slack review"]
```

## Build First

| Piece                         | What to build                                                                                     | Done when                                                                    |
| ----------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Intake deployment             | Trigger from a WISMO tag, chat intent, email rule, or helpdesk group.                             | Duckie creates or finds a stable WISMO case ID.                              |
| Order lookup                  | Find the order from requester email, authenticated customer ID, ticket metadata, or order number. | Duckie asks for order ID only when identity or order selection is ambiguous. |
| Order context workflow        | Pull canonical OMS, WMS, carrier, and support-history fields.                                     | Downstream agents receive one structured context object.                     |
| Condition routing workflow    | Route normal status, partial shipment, carrier stall, low-confidence, and restricted cases.       | The branch label is saved as a WISMO condition.                              |
| Standard status agent         | Explain normal processing, in-transit status, delivered status, and customer-safe ETA.            | Replies include status, source, next action, and follow-up only when needed. |
| Split shipment agent          | Itemize shipped, delivered, and pending items.                                                    | Customers can see which component maps to which shipment.                    |
| Carrier exception agent       | Explain label-created-no-scan, no movement, delivery attempt, and tracking-resumed cases.         | Duckie starts allowed traces or escalates when action is not allowed.        |
| Customer communications agent | Draft and send customer replies using approved tone and facts.                                    | Responses never invent ETAs or generic windows.                              |
| Follow-up state               | Save `next_follow_up_due_at`, `last_status_sent`, and `follow_up_reason`.                         | Promised follow-ups can be audited and retriggered.                          |

## Defer Until the MVP Works

Add these after the first loop is trusted:

* Supplier allocation and backorder investigation
* Warehouse short-pick, quarantine, or cycle-count exceptions
* Delivered-not-received review
* Replacement, refund, cancellation, and address-change write actions
* Broad proactive outbound messaging for every backend event
* Advanced customer segmentation, VIP paths, or SKU-specific rules
* Automated alternate component recommendations

## Required Human Handoffs

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

| Condition                                                   | Handoff                                                                      |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Order value exceeds replacement/refund threshold            | Route to the owner with order value, shipment facts, and recommended action. |
| Fraud, payment, or address hold is present                  | Route without exposing restricted risk signals to the customer.              |
| Data conflicts across OMS, WMS, carrier, or support history | Route with the conflict called out clearly.                                  |
| Same customer contacted support 2+ times for the same order | Route as priority review with prior replies summarized.                      |
| Duckie cannot identify one clear order                      | Ask the customer for verification or route to manual review.                 |

<Warning>
  Do not use the MVP to automate high-impact write actions. Duckie can prepare drafts and recommendations, but replacement, refund, cancellation, and address-change actions should remain gated until the policy and approval path are tested.
</Warning>

## When to Expand

Move beyond the MVP when:

* Order identification works reliably for the selected channel
* The canonical context object is stable
* Normal, split-shipment, and carrier-stall replies pass QA
* Low-confidence and restricted cases escalate cleanly
* Follow-up commitments are saved and retriggered reliably
* Historical WISMO tickets pass replay and batch tests

## Next Pages

After the MVP:

1. Read the [system map](/examples/wismo-order-status/system-map) to see the full architecture.
2. Build [intake and order context](/examples/wismo-order-status/intake-and-order-context).
3. Add [condition routing and agents](/examples/wismo-order-status/condition-routing-and-agents).
4. Use the [rollout plan](/examples/wismo-order-status/rollout-plan) before expanding live scope.