Define queue labels with examples and an unknown outcome
Different agents use Billing and Payments interchangeably, so routing reports cannot be compared. Define stable queue IDs with concise boundaries and ambiguous examples.
- Focused work estimate
- 1h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Domain modeling · Classification design · Product specification
Estimated field mix
- Applied AI100%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional software vendor receives billing, account-access, bug, and security reports. A prototype silently moves tickets based on vague model confidence. Replace it with bounded suggestions, deterministic safety rules, and an auditable review flow.
Setup prerequisites
- Create a synthetic support-ticket corpus with no real customer messages.
- Implement a deterministic local classifier double with success, malformed-output, and timeout modes.
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Every queue has a stable ID, description, included examples, and excluded examples.
- UNKNOWN and NEEDS_REVIEW are explicit outcomes rather than invented queue names.
- Changing a label definition creates a new taxonomy version.
Implementation constraints
- Use fictional support topics and avoid demographic categories.
Verification to include
- Map a duplicate-charge example and an account-reset example to distinct documented queues.
- Validate that a mixed billing/security example can remain NEEDS_REVIEW.
Deliverables
- Versioned queue taxonomy and labeled examples
Rollout and recovery
Use the taxonomy in suggestion-only mode; retain previous versions for historical reports.
Value of the work
For the engineer: Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs.
For the team: Review whether automation saves triage effort while preserving queue ownership and safe escalation.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.