Runbooks manifest the playbook inside the system

LabelAllowedValue.ParentLabelAllowedValueId already lets values nest. The AI classifies at the leaf; the parent is a grouping affordance for the review UI.

Data Category (LabelDefinition)
Financial Data
  Bank Statements
  Tax Records
  Investment Docs
Health Data
  Medical Records
  Insurance Claims
Employment Data
Communications Data

Author the taxonomy once; the model navigates it. “Show me all Financial items” expands the tree in the review UI.

The current model creates one LabelApplied row per value, so multi-value is technically possible. The gap is that nothing tells the AI or backend whether to pick one or many.

public enum LabelCardinalityMode
{
    PickOne  = 0, // Exactly one value. AI picks the single best match.
    PickBest = 1, // Same as PickOne for AI, but UI shows confidence + override.
    PickMany = 2  // AI tags all that apply. Multiple LabelApplied rows.
}

The label configuration drives the prompt. There is no separate AI instruction system; the user authors the contract and the pipeline materialises it.

Each label gets two thresholds, per LabelDefinition, not global. Sensitivity might run hot at 80/60; Topic might run loose at 60/30.

When the runbook reaches an enrich node, six things happen in order.

1. Create a Query on the case, scoped to the upstream view node’s filter.
2. Create LabelDefinitions from the enrich config: cardinality, thresholds, allowed values and hierarchy.
3. Build the classification prompt from the LabelDefinitions.
4. Run the existing classification pipeline: AI, Detections, LabelsApplied.
5. Validate responses against cardinality constraints. Reject or truncate non-conforming responses and log warnings.
6. Apply confidence thresholds: auto-apply, review or skip.

The enrich node reuses the existing pipeline. The new work is cardinality enum, thresholds and prompt-injection logic that reads label configuration.