Appeal Type Policy
Purpose
This boundary currently owns one narrow question only:
What family does this appeal type belong to?
It does not currently own any broader appeal-type behaviour.
This boundary exists to provide a thin, reusable identity/family layer without introducing duplicate mappings or broad appeal-type policy abstractions too early.
Current ownership
The boundary currently exposes:
getAppealTypeFamily(appealTypeId)
This helper answers which family a supplied appeal type belongs to, while preserving the application’s existing behaviour exactly.
Current source of truth
getAppealTypeFamily(...) currently delegates to:
lib/domain/case-lifecycle/mapAppealType.js
This is intentional for now.
The goal is to avoid creating duplicate appeal-type family mappings while the family contract is still being stabilised through small characterization and adoption slices.
At this stage, this boundary is a thin wrapper around the existing source of truth rather than an independent mapping table.
Current consumers
The boundary is currently consumed by:
lib/domain/representation-policy/lib/domain/representation-type-policy/
Adoption has been limited to rules that were clearly family/group-based.
Explicit non-goals
This boundary does not currently own:
- appeal type rollout control
pages/api/endpoint/getappealtypesfornewappeal_api.js- lifecycle stages
- query-field selection
- CRM field selection
- representation windows
- representation availability
- dashboard behaviour
- capability matrices
- specialist-process logic
Those concerns remain in their existing domain or application-specific homes.
Family vs specific-type rules
An important distinction emerged during adoption.
Some rules are genuinely family-based, for example:
- DNS
- SIP / SIPS
Some rules are genuinely appeal-type specific, for example:
- Householder
- Advert
- CPO
- Rights of Way
- Common Land
Because of this, raw appeal-type IDs should not automatically be replaced with family classification.
Family classification should only be adopted where the rule is clearly about a broader family/group identity.
Known behavioural contracts
The current behaviour of getAppealTypeFamily(...) is characterized and should be preserved.
That includes:
- numeric inputs
- string inputs
- alias mappings
- unknown values
null/undefinedhandling
Examples of preserved behaviour include:
- known numeric mappings returning the current family key
- known aliases resolving to the current family key
- unknown values falling back to current behaviour
null/undefinedpreserving current behaviour rather than being normalised
This helper should not be “cleaned up” or broadened without characterization first.
Future guidance
Future slices should:
- characterize first
- adopt selectively
- avoid broad replacement of appeal-type checks
Future work should continue to distinguish between:
- identity/family classification
- specific appeal-type business rules
This boundary should remain narrow until there is strong evidence that additional shared ownership is both stable and behaviour-preserving.