# Treatment workflows are tagged services, not a configurable engine

Everything that differs between specialties as *data* — categories, protocol steps, resource types,
form fields — is already stored as data. What is left is behaviour: when a case opens, what happens
when a session completes. That is expressed as a `TreatmentWorkflow` interface with one
implementation per practice domain, resolved through a Symfony tagged-service registry, so booking
code never names a specialty and a new one is a new class rather than a core change.

## Considered Options

A data-driven state machine editable by clinic managers was rejected: no clinic manager will author a
state machine, so in practice only developers would use it — code with worse syntax, no type safety
and no debugger.
