pedwfrontend/lib/domain/representation-type-policy

Representation Type Policy Boundary

Purpose

This directory contains a narrow representation type policy boundary.

It currently owns only the behaviour-preserving rule engine that converts an already prepared policy context into the current ordered array of available representation type strings.

It is not a full representation domain model.

This boundary should be treated as a small, compatibility-preserving extraction seam for type-availability decisions, not as a place to redesign the representation journey.

---

Current ownership

getAvailableRepresentationTypes(context)

Purpose:

prepared context
        ↓
ordered representation-type string array

The helper currently returns the live consumer contract as an ordered array of strings, including values such as:

• Questionnaire
• Statement
• Final comments
• Consultation Response
• Local Impact Report
• Marine Impact Report

---

Explicit contract

Current behaviour intentionally preserves:

• exact string values
• exact ordering
• deduplication behaviour
• current DNS behaviour
• current SIPS behaviour
• current Householder behaviour
• current Advert behaviour
• current CPO behaviour
• current specialist-process behaviour
• current LPA / non-LPA behaviour
• current NRW behaviour

This is a consumer-facing compatibility contract.

Changing any of the following would currently be a contract change, not just an internal refactor:

• returned string values
• returned ordering
• returned deduplication semantics

---

Compatibility requirements

The following date fields are compatibility-sensitive and must be preserved carefully:

• pinswg_startdate
• pinswg_startdates
• pinswg_statementduedate
• pinswg_statementsduedate
• pinswg_applicationacceptedasvalid

These fallbacks are characterized behaviour and must not be casually removed.

---

Explicit non-goals

This boundary does not currently own:

• capacity ownership
• capacity selection UX
• buildRepresentationContext(...)
• translation mapping
• Welsh labels
• file naming
• upload logic
• submission logic
• finalisation logic
• questionnaire routing
• Redux state
• API routes
• CRM queries
• dashboard behaviour

---

Adapter boundary

buildRepresentationContext(...) intentionally remains outside this domain boundary.

It should currently be treated as an adapter layer:

CRM / UI state
        ↓
policy context

It is not currently a domain helper.

---

Future evolution

Any future migration from English string values to:

• stable IDs
• enums
• keys

would be a contract change, not merely refactoring.

That kind of migration must be explicitly scoped and characterized before any implementation.

---

Testing expectations

Current minimum safety net for this boundary:

node tests/phase22/representation-build-reps-arr-rules.test.cjs
npm run lint