# Dental attributes of a service live in an extension table, not on ServiceItem

Whether a service is priced per tooth, per surface or per canal — and whether booking it must ask for a
tooth at all — is dental-only knowledge, but `ServiceItem` is shared by every practice domain. Those
attributes therefore sit in a one-to-one `dental_service_profiles` row in the Dental context, keyed by
`service_item_id`, so a beauty clinic carries no dental columns and the next domain is not invited to add
its own set to the shared table. The cost is a join whenever the dental profile is needed, which is the
same pattern the codebase already uses elsewhere.

## Consequences

The reverse choice was made deliberately one level down: the tooth and surfaces a visit line was actually
billed for are columns on `SessionService` itself, because that row is the clinical and financial record
of the visit rather than shared configuration, and splitting it would allow a billed line to lose its
target unnoticed.
