Mapping of specific application type description fields to a general description field

[pixeltrix]

Each application type has it's own version of what could be called the 'description', i.e. a string that describes what the application is. For example, in advertising.json it is advertisement-types/advertisement-proposal-description; in s73.json it is con-remove-vary/reason; and in full.json it is proposal-details/proposal-description.

Is this being documented anywhere and if not are there any plans to, or is it up to each implementor to decide how to generate a general description?

[colmjude]

Thanks, this is a fair point.

We agree the current position is not clear enough for implementers. At the moment, description-like content appears in different fields depending on application type (for example proposal-description, advertisement-proposal-description), which can force local mapping logic.

Our direction is to define a consistent cross-type approach so implementers do not need to invent their own mapping.

Why we haven’t changed it immediately:

• we need to confirm whether some of these fields carry distinct meaning in specific edge cases (for example cases where there may be more than one description-like concept),
• and we don’t want to lose that meaning by doing a simplistic merge.

Next step:

• review current description fields across application types,
• confirm where semantics are genuinely different,
• align the model where it makes sense to, while preserving meaningful differences where needed.

We'll share progress as we go

[colmjude]

After reviewing the fields and their purpose, we think there is a clear opportunity to rationalise them. We also think description and reason should remain separate concepts in the specification.

• description captures what is being proposed or changed
• reason captures why it is being proposed or requested

So the proposal is to rationalise into two reusable concepts, not one merged field. That gives greater consistency without overloading fields.

Principles for deciding whether to rationalise a field

• Rationalise only when fields mean the same thing in practice, not just when they have similar names.
• Do not rationalise when module context changes the meaning, for example legal justification, mitigation detail, or evidence-specific statements.
• Keep legal and policy meaning intact. If wording is tied to a statutory test or decision route, keep a separate field.
• Do not reduce data quality. A rationalised field should not remove detail that users or decision-makers need.
• Keep implementation practical. If rationalisation adds ambiguity or complex conditional logic for little benefit, keep fields separate.

[colmjude]

Description field rationalisation candidates

After reviewing the fields, we think the fields below are candidates for rationalisation. We'll decide on each of these in turn using the principles outlined above.

field	module	application-types	notes
proposal-description	proposal-details	demolition-con-area, full, hh, lbc, outline, outline-all, outline-some, reserved-matters, technical-details-consent
advertisement-proposal-description	advertisement-types	advertising
development-description	dev-type	extraction-oil-gas
proposal-building-operations-description	proposal-details-ldc	ldc-prospective-use
proposal-change-of-use-description	proposal-details-ldc	ldc-prospective-use

We already have a description field that is used in multiple places. We also need to decide if the field should be called description, proposal-description, description-of-development or something else:

field	description	module	application-types
description	Description of proposed development including non-residential development	proposal-details-inc-non-residential	pip
description	A detailed description of the proposed works (including existing and proposed materials and finishes) together with details of those parts) of the building that are likely to be affected.	desc-proposed-works-lb-ldc	ldc-proposed-work-lb

[colmjude]

Reason field rationalisation candidates

After reviewing the fields, we think the "reason" fields below are candidates for rationalisation. We'll decide on each of these in turn using the principles outlined above.

field	module	application-types	notes
use-lawful-reason	grounds-existing-use	ldc-prospective-use
removal-reasons	hedgerow-removal	hedgerow-removal
bng-condition-exemption-reasons	bng	demolition-con-area, full, hh, outline, outline-all, outline-some, technical-details-consent

We already have a reason field that is widely used:

field	description	module	application-types
reason	The reason why the applicant wishes condition(s) to be removed or changed	con-remove-vary	s73
reason	Reason for demolition	demolition	lbc
reason	Why is it necessary to demolish all or part of the building(s) and structure(s)?	demolition-reason	demolition-con-area
reason	A textual reason (field default; no module override)	grounds-proposed-use	ldc-prospective-use
reason	A textual reason (field default; no module override)	grounds-ldc	ldc-existing-use
reason	Reason why applicant wants to make the amendment	nm-amendment-details	non-material-amendment

[colmjude]

The fields that it made sense to rationalise have now been updated. See tickets above.