Planning conditions: timing categories and triggers

[colmjude]

I’m sharing where we have got to on condition categories/triggers, and where the current approach might start to break on real condition text.

Purpose of this post

1. Set out what we know so far from condition reviews and community feedback.
2. Show where simple stage labels do not necessarily map cleanly to real condition wording.
3. Agree the smallest changes we need now.
4. Clarify what categorisation is for in the data model, and what rules it needs to be reliable.

Why now

This has come up more than once in recent community sessions.

In January, conditions (and the link between decisions and conditions) were already in scope.
In February, people asked directly about condition labels such as pre-commencement and pre-occupation.

We said we had started this work and would share it for feedback.
This post does that.

User need

dd-need-040

As an applicant, developer, or agent, I need to know exactly when each condition must be complied with (e.g. before commencement, prior to occupation, before above-ground works, or ongoing) so that I can plan works appropriately and avoid unintentionally breaching a condition or triggering enforcement action.

In plain terms, we need to show:

• when a condition starts to apply
• when it stops (if it does)
• what action is needed at each point
• and when a condition is treated as discharged in practice

Question: Are there any other things people need to know about conditions?

Starting point: stage-based triggers

• pre-commencement (any works)
• pre-commencement (other than demolition/site clearance)
• prior to above-ground works
• prior to occupation or use
• non-dischargeable compliance

These came from a planner review of decision notices where conditions are commonly grouped by stage.

This is useful, but a label is only valuable in data if it has clear rules and can be applied consistently.

Question: What do you think of these categories? Useful? What don't they cover? etc

---

Looking real examples

What we tested

• Doncaster decision notice: 11/00246/EXTM

Example 1: one condition, more than one trigger (full text)

Within 6 months of the date of this permission, full engineering details of all proposed highway works, including the highway improvements to Stevens Road and to the junctions of Stevens Road and Littlemoor Lane /Florence Avenue have been submitted to and approved in writing by the Local Planning Authority, and the works so approved shall be completed in full to the satisfaction of the Local Planning Authority before any of the dwellings is occupied.

REASON
In the interests of highway safety.

Why this matters:

• Trigger A: within 6 months -> submit details and get approval.
• Trigger B: before occupation -> complete approved works.

I read this as one condition has two trigger points and two different actions.

Planning feedback: Condition 3 can be read as submit/approve within 6 months, then comply before occupation.

Example 2: event-based condition (full text)

Should any unexpected significant contamination be encountered during development, all associated works shall cease and the Local Planning Authority (LPA) be notified in writing immediately. A Phase 3 remediation and Phase 4 verification report shall be submitted to the LPA for approval. The associated works shall not re-commence until the reports have been approved by the LPA.

REASON
To secure the satisfactory development of the site in terms of human health and the wider environment and pursuant to guidance set out in the National Planning Policy Framework.

Why this matters:

• The trigger is an event (“if contamination is found”), not a fixed stage.
• Work has to stop, details must be approved, then work can restart.

Planning feedback: Condition 19 can be read as a compliance condition unless triggered by contamination, then approval is required.

What these examples show

1. Condition 3 shows a gap: one condition can have multiple trigger points.
2. Condition 19 shows another gap: some conditions are event-based, not stage-based.
3. A single stage label on its own does not always tell you what action is required and when discharge is recorded.

Early practitioner feedback

Some conditions behave as both compliance and discharge, depending on what happens.

---

Questions for discussion

1. Looking at the two examples, is this how your team would read and apply these conditions in real casework?
2. For a condition like Example 1 (condition 3), do you treat it as:
   • one condition with two checkpoints, or
   • two separate things to track?
3. In your current process, when do you mark a condition as “discharged”?
   • only when everything in the condition is done, or
   • in stages as each part is completed? (partially discharged)
4. Are event-triggered conditions like Example 2 (condition 19) common in your authority?
5. What is the minimum information you need in a condition record so applicants/agents can avoid breaches and officers can track them?
6. What problem are we actually trying to solve with categories?
   • What decision or task should categorisation improve (for example validation, case handling, reporting, enforcement, or applicant guidance)?

[colmjude]

We have had further discussions about this and one thing we are now questioning is whether discharge / compliance is the right primary structure.

In practice, some conditions seem to shift depending on wording, timing or what happens next, which makes that distinction harder to apply consistently than it first appears.

What may be more useful is to focus on the operational questions instead:

• is an action required?
  (i.e. does the condition require the applicant or developer to do something, including submission where relevant)
• when is that action required?
  (i.e. the trigger point, such as pre-occupation)
• when has that action been completed / satisfied?
  (i.e. has it been discharged: the applicant says they have done it and the authority formally agrees)

That feels closer to the real tracking and management need for conditions, and may be a better place to start than trying to fully classify all condition types up front.

We are still treating this as exploratory, but the current direction of travel is to look for the smallest consistent structure that supports tracking and management processes in practice.

[colmjude]

Just to update on where we are with modelling conditions: we have a thin baseline for conditions in the decision stage specification at the moment:

• planning-condition records the condition text and reason
• decision-condition links a condition to a decision notice

Given what we know now, I think that is the right level for the initial baseline.

The timing, trigger and discharge questions raised here are important, but they move us into modelling the lifecycle of conditions after the decision is issued. We do not yet have enough concrete examples or agreed user needs to know which parts of that lifecycle are universal enough to model in a national standard.

I’m adding the backlog and enhancement labels so we can pick this up through the change control process after the baseline is agreed.

The next phase should look properly at condition timing, triggers, actions, satisfaction/discharge and how conditions are managed over time.