Order change request

Work out what a customer wants changed on an order: the address, the items, the delivery timing, or a cancellation.

Problem

Change requests are time-sensitive and each one touches a different system. Reading them by hand delays the change past the point where it's still possible.

Goal

Identify the requested change quickly so code can check whether it is still possible and apply it.

Input / state

The customer's message and the order's current fulfilment status.

message: The customer's message.
fulfilment_status: Current status from your order system, e.g. "not yet picked", "packed", "shipped".

Decision question

ChoiceQuestion key change_type

What change to the order is the customer asking for?

Options

change_addressDeliver to a different address or correct the existing one.
change_itemsAdd, remove or swap items, sizes or variants.
delivery_timingDeliver earlier, later or on a specific date.
cancel_orderCancel the whole order.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

Change addressChoice is change_address and confidence meets your threshold.
Change itemsChoice is change_items and confidence meets your threshold.
Delivery timingChoice is delivery_timing and confidence meets your threshold.
Cancel orderChoice is cancel_order and confidence meets your threshold.
Needs a personConfidence is below your threshold: probability is spread across options.

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

{
  "message": "I just moved, can you send it to 14 Elm Road instead?",
  "fulfilment_status": "packed"
}

Outcome

Illustrative

Change address

Choice is change_address and confidence meets your threshold.

Why

Asks for a different delivery address.

Better together with

Complementary classifiers, and what each one adds here.

Order issue typeChoice
Runs when the issue type says the customer wants a change rather than reporting a problem.
Combined inOrder problem resolution
Address completenessChoice
A new address should be checked for a missing unit or ambiguity before it replaces the old one.

Used in chains

Order problem resolutionStep 3 of 3

Sources

Primary documentation this classifier builds on. Scenarios on this page are illustrative, not taken from production use.

SourcedTypeSafe docs · Documentation
System One
Defines the Choice, Score and Noul primitives and walks through a refund request built from a state, independent questions and deterministic checks in code.
SourcedTypeSafe docs · Documentation
Model jaggedness
Lists known failure modes, including literal reading, arithmetic, date comparison, option order and adversarial content.

Using it well

Whether a change is still possible depends on the fulfilment status and dates. Check that in code; date comparisons are a known weak spot for language models.
Requests with a fallback ("swap it, or cancel if you can't") come back with spread probability. Route them to a person who can handle both.

Request definition

POST https://api.typesafe.ai/v1/systemone

{
  "model": "jev-latest",
  "state": {
    "message": "<message>",
    "fulfilment_status": "<fulfilment_status>"
  },
  "questions": {
    "change_type": {
      "type": "choice",
      "instructions": "What change to the order is the customer asking for?",
      "criteria": {
        "change_address": "Deliver to a different address or correct the existing one.",
        "change_items": "Add, remove or swap items, sizes or variants.",
        "delivery_timing": "Deliver earlier, later or on a specific date.",
        "cancel_order": "Cancel the whole order."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.

Version History

v1Current Versionabout 8 hours ago@f

Initial version