Classify an incoming business request

An operations team receives questions about stock and delivery in many different words. Before looking up inventory or checking a deadline, the application needs to know which question the customer is asking. A classifier turns that English into a category software can use.

1. Define the categories#

The application has already selected the order. This example classifies one current assessment request into a fixed set of categories:

The intended value is less manual triage: the application can send a supported question to the right check. The classifier does not decide whether stock is sufficient, select an order from its name, or authorize shipping or payment.

2. See English become a category#

These are actual recorded outputs from the evaluated native model. The table is built from the same downloadable observations as the benchmark; scores are model scores, not guarantees that the category is correct.

The first three examples show the useful distinction. Asking whether an order can ship is a fulfillment assessment. Asking whether it needs a faster courier is an expedite assessment. Telling the system to ship it is an action instruction, outside this classifier's supported task.

The final two show mistakes: the model collapses a two-question request into one category, and rejects a supported colloquial question. Both mistakes have high scores. The five selected examples explain behavior; the full test set scored 221/233 (94.85%) against synthetic labels.

3. Hand a typed result to software#

English question + declared categories
  → neural encoder → vector → finite category scores
  → typed candidate → validation and calibration admission
  → declared assessment OR clarification / human review

The model produces a finite choice and scores. Application code serializes the JSON. Here is the actual record returned by the demo's JSON option for the faster-courier question:

{
  "mode": "recorded_inference",
  "run_date": "2026-10-03",
  "admission_threshold": null,
  "cases": [
    {
      "id": "ontology.test.00.02",
      "text": "Does the extractor order need a faster courier to make the customer's date?",
      "category": "expedite",
      "scores": {
        "fulfillment": 0.0076,
        "expedite": 0.9789,
        "unsupported": 0.0135
      },
      "expected": "expedite",
      "accepted": false
    }
  ]
}

category identifies the proposed assessment. scores contains one value per allowed category. accepted records the separate admission outcome. expected is an evaluation label supplied with this recorded example; a live request does not arrive with its correct answer.

4. Decide when automation is allowed#

A qualified binding could let an admitted fulfillment candidate start the stock check. The runtime would resolve the required facts and apply the reviewed policy; your application would still enforce permissions for any action. unsupported requests and candidates withheld by admission go to clarification or review.

unsupported is a category; an abstention at admission is a separate outcome. Keeping them separate lets a team improve recognition without silently turning uncertain classifications into business actions. Measure routing quality, review workload and time saved on representative requests before claiming an operational benefit.

5. Run the example#

Clone the public demo repository. From its root, use Python 3.11 or 3.12 with no installed packages:

python3 classification/review.py
python3 classification/review.py --case ontology.test.00.02 --json
python3 classification/recompute.py

The first command shows five recorded classifications, including the errors. The second emits the JSON above. The third verifies hashes and recalculates the aggregate scores, calibration result and timings. These commands inspect a recorded model run; they do not classify new text. The classification README explains the source integration, checkpoint, tokenizer, contract and calibration artifacts needed for fresh inference. The public runtime 0.3.1 wheel does not expose this trained classifier.

The labels are synthetic model-authored and model-judged examples, not human-reviewed business ground truth. A trained checkpoint is not distributed here. See prepare a language contract for a new domain, or the shipping policy example to see what a downstream structured-fact check does.

Recorded 2026-10-03 on M5 Max, macOS arm64, Python 3.12.12, 4 CPU threads, batch size 1. Synthetic labels. Provider inference, tokenization and candidate validation; excludes first call, live evidence retrieval, reasoning and business action execution. Evidence and reproduction limits.