Skip to content

Decision Tree Update

Selection tool — instantiates Response Repertoire Expansion

Encodes, as an explicit branch structure, which response a case should select from its features — including the branch that says 'none of these fits, escalate.'

A Decision Tree Update is the revision to a branching selection tool that maps a case's observable features to the correct response — made whenever a new option enters the repertoire, so the new option actually gets chosen. Its distinctive job is pure selection logic: not the responses themselves, not the intake queue, but the runtime "if this, then that response" that makes an available option reliably selectable, plus the explicit escalate / none-fits branch. A response nobody selects is not truly available, and this is the mechanism that closes that gap.

Example

A veterinary telehealth service's technicians use a decision tree to route callers: symptoms lead to home-care advice, book-a-visit, or go-to-the-ER-now. The clinic adds a genuinely new response — a same-day medication delivery for a bounded set of chronic-refill cases. But an option no one selects is inert, so the tree must be updated: a new branch keyed to "known patient, chronic med, no red-flag symptoms" routes to the delivery response, and a boundary branch sends any red-flag symptom out to a vet, never to delivery. The new option is now reachable through the same structured questions the techs already ask, and the dangerous cases are explicitly walled out of it.

How it works

The tree is the wiring that connects cases to responses. Adding a response is incomplete until the tree gains a branch that selects it under the right conditions, and a boundary branch that keeps the wrong cases out. Its entire contribution is making the trigger unambiguous at the moment of choice — so a non-expert reaches the correct response by following the branches rather than by knowing the whole repertoire.

Tuning parameters

  • Branch specificity — how finely features discriminate. More branches route precisely but make a tree too large to use; fewer branches are fast but coarse.
  • Default / escalation behavior — what happens when no branch matches: a safe default versus mandatory escalation. This sets the tool's safety posture.
  • Trigger sensitivity — how eagerly a branch fires. Eager routing catches more true cases but misroutes near-misses into a response they don't fit.
  • Update discipline — how a new response earns a branch, and how retired responses are pruned so the tree doesn't route to options that no longer exist.

When it helps, and when it misleads

Its strength is turning "we have a response" into "the response gets chosen," consistently and by non-experts, while the escalate branch makes the repertoire's edge explicit. Its central failure mode is that a tree can only route among responses that exist — it cannot manufacture the variety it lacks, so a genuinely unhandled case needs a new option, not a new branch.[1] Over-branched trees also induce decision fatigue and rote clicking. The classic misuse is bending an existing branch to swallow cases it wasn't built for, to avoid admitting a gap. The discipline is to keep an explicit no-match escalation and feed unrouteable cases to review rather than mis-routing them.

How it implements the components

  • activation_trigger — the branch conditions that tell a user exactly when to select the new response over ordinary handling.
  • boundary_and_escalation_rule — the no-match and red-flag branches that route unfit cases out instead of forcing them into a response.

It does not define the responses at the leaves — that is Exception Handling Playbook — and it does not sort and prioritize incoming cases before they reach the tree; that is Triage Protocol Update.

  • Instantiates: Response Repertoire Expansion — it makes an added response reachable, so the repertoire's new variety is actually selectable.
  • Consumes: Exception Handling Playbook supplies the responses the tree's branches point to.
  • Sibling mechanisms: Exception Handling Playbook · Triage Protocol Update · Cross-Training Program · After-Action Repertoire Review · Competency Matrix Update · Controlled Pilot · Job Aid Checklist · New Service Tier · Runbook Library Update · Scenario Drill · Tool Capability Addition

References

[1] Ashby's law of requisite variety — only variety can absorb variety; a regulator needs at least as many responses as the disturbances it must handle. A decision tree distributes existing variety to the right cases but adds none, which is why routing can never substitute for a genuinely missing response. ↩