Merged PR 2398: amends to appeal policy

Related work items: #23754

lib/domain/appeal-type-policy/README.md

@@ -0,0 +1,128 @@
+# 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` / `undefined` handling
+
+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` / `undefined` preserving 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.

lib/domain/appeal-type-policy/getAppealTypeFamily.js

@@ -0,0 +1,5 @@
+import { mapAppealType } from "../case-lifecycle/mapAppealType";
+
+export function getAppealTypeFamily(appealTypeId) {
+    return mapAppealType(appealTypeId);
+}

lib/domain/appeal-type-policy/index.js

@@ -0,0 +1 @@
+export { getAppealTypeFamily } from "./getAppealTypeFamily";