Build Brief

Item This lesson
Decision Specify the smallest useful product, its evidence contract, and the tests required before implementation.
Primary audience operations manager, technical product manager, builder
Estimated time 25 minutes
Output A baseline routing specification and reproducible evidence record.
Practice data Use your own safely redacted workflow or the Harborline Services running case.

Learning outcomes

By the end of the lesson, you should be able to:

  • explain the operating decision in plain business language;
  • identify the evidence, ownership, and failure boundaries that matter;
  • produce the stated output well enough for another person to review or implement.

This lab makes routing logic inspectable before model performance complicates the diagnosis. It is a deterministic baseline, not an LLM demonstration.

Run the Lab

Open the lab in a full page

Manual Fallback Lab

The exercise below remains usable even when the embedded application is unavailable.

Label and routing policy

Label Queue Default priority Mandatory review trigger
access_issue IT access Normal Security language or privileged account
billing_dispute Accounts receivable High Payment suspension, contract dispute, or material amount
vendor_change Finance controls High Bank, beneficiary, tax, or identity change
policy_question HR service Normal Personal entitlement or conflicting source
uncertain Intake review Normal Missing context or more than one plausible label

Fixed evidence set

Use records H-001 through H-006 in the Harborline Services case. For each record, complete:

Case Label Priority Route Review? Evidence Reason
H-001
H-002
H-003
H-004
H-005
H-006

Baseline checks

  • H-003 must enter finance verification; no automated bank-detail change is permitted.
  • H-004 must surface the source conflict rather than answering from the stale FAQ.
  • H-005 should use uncertain unless the workflow has enough evidence for a safer classification.
  • Every route must name an operational owner, not merely a topic.

Record disagreements between reviewers. Those disagreements indicate taxonomy or policy work that must happen before model optimization.

What to Record

  • which labels and queues reflect the real operating workflow;
  • which phrases produce ambiguous matches;
  • which cases require human review;
  • which metrics a model-based version must beat;
  • which failure would make automatic routing unacceptable.

Completion Evidence

Run the fixed evidence set, save the observed routes, and document one proposed rule or taxonomy change. A model is justified only when it improves on this baseline using representative business examples.

Example Output Contract

A production workflow needs an explicit contract, not only a prompt. Adapt this starting point to the domain and validate every field against representative examples.

{
  "label": "operational_category",
  "priority": "normal|high|urgent",
  "confidence": 0.0,
  "evidence": ["short source excerpt"],
  "route_to": "named_queue",
  "human_review_required": true,
  "reason": "brief operational justification"
}

The contract should be versioned. Changes to labels, required fields, confidence behavior, or approval logic should be reviewed like changes to business rules.

Practice: Write the Build Specification

Write a build-ready v1 specification and produce A baseline routing specification and reproducible evidence record. The specification should allow an engineer and a process owner to reach the same interpretation.

Specification field What to include
Label design Define mutually useful labels, boundary examples, and an explicit other/uncertain path.
Routing decision Name the destination owner, priority rule, service level, and escalation trigger.
Review design Define the risk tier, review trigger, evidence shown, reviewer authority, and correction record.
Operating evidence Choose quality, volume, latency, override, and incident indicators with thresholds and owners.

Definition of done

  • input and output contracts are unambiguous;
  • the test set includes normal, ambiguous, and prohibited cases;
  • failure behavior and maintenance ownership are defined.

Learning Ladder

Classification and Routing — stage 6 of 8. Previous: Specify the classifier · Next: Evaluate the prototype

Sources and Further Reading