Why date labels need two columns

A planning research log becomes clearer when it has two visible groups of dates. The first group covers dates stated on the public planning record. The second covers dates created by your team while researching.

This distinction matters because official dates describe the authority’s process, while internal dates describe your evidence trail. For example, the day you downloaded drawings is not the same as the day an application was validated. Mixing those dates can make a file look more certain than it really is.

According to GOV.UK’s guidance on determining a planning application, the statutory period for deciding an application runs once a planning application has been validated. That makes the validation date one of the most useful official dates to capture in England.

  • Official council-record dates: dates shown by the planning authority on the application record.
  • Researcher dates: dates your team created, such as first seen, last checked and next review due.
  • Interpretation notes: comments explaining what a date may mean, and what it does not prove.

Official planning application dates worth logging

The exact labels vary by council system, so your log should record the wording you saw and the source page checked. Even so, some date fields are usually more useful than others for project research.

Start with the application type as well as the date fields. GOV.UK’s guidance on making an application says there are 2 main types of application: full planning permission and outline planning permission. It also lists other application types including approval of reserved matters, discharge of conditions, amendments to proposals with planning permission, lawful development certificates, prior approval in some cases, and some non-planning consents. Because those records serve different purposes, the same date label can have different practical meaning across files.

For outline cases, GOV.UK explains that outline permission decides the general principles of development, with one or more reserved matters approved later. It also says reserved matters applications normally must be made within a specified time limit, normally 3 years from the date outline planning permission was granted. That means a chronology may span several linked records, not one single application.

  • Application received date, if shown.
  • Validation date, if shown.
  • Decision date, if shown.
  • Status-change dates, such as when the record later shows decided or withdrawn, if the system displays them.
  • Outline permission grant date, where later reserved matters timing may depend on it.
  • Dates on linked records for reserved matters, condition discharge or amendments, where relevant to the same site history.

Researcher dates your own log should always keep

Internal dates are not planning-status facts. They are quality-control facts about your research process. They help your team know when evidence was collected and when it should be checked again.

A simple log can therefore include a first-seen date, a last-checked date and a next-check date. These are especially helpful because GOV.UK also says a longer timetable can be agreed in writing between the applicant and the local planning authority, either through an extension of time or through a planning performance agreement. If that agreement is not visible on the summary page, a missed statutory period on your spreadsheet may not mean the authority is overdue.

Your next-check date should be a monitoring prompt only. It should not be described as the expected decision date unless the source itself states that clearly.

  • Date first found by your team.
  • Date documents were downloaded or reviewed.
  • Date the record was last checked.
  • Planned next review date.
  • Date an internal note was added about a new issue, such as linked applications or missing plans.

A practical date structure for one record

A useful way to build the log is to give each application one row or card with three blocks: authority dates, research dates and context notes.

In the authority block, copy the date label exactly as shown by the council where possible. In the research block, use your own consistent labels. In the notes block, explain why the timing may need caution. For instance, if the record is an outline application, note that later reserved matters may follow. If the record concerns discharge of conditions, note that it is not the same as a fresh full application.

This structure helps avoid a common mistake: treating every planning date as evidence of the same project stage.

  • Authority dates: received, validated, decided, and any linked-application dates you can verify.
  • Research dates: first seen, last checked, next check.
  • Context notes: application type, linked references, and any timing limitation visible from the source.

Fictional worked chronology

The following example is fictional and is included only to show how a chronology can be logged without predicting an outcome.

Fictional example: a team finds a council record for an outline planning application in England. The public page shows an application received date of 3 February, a validation date of 10 February and no decision yet. On 14 February, the researcher first checks the file and downloads the available plans. Because GOV.UK says statutory determination periods run from validation, the team treats 10 February as the key official timing point, not 14 February.

On 28 February, the team checks again. The status is still pending. The researcher adds a note that outline permission deals with general principles and that reserved matters may follow later if permission is granted. The next review date is set for 21 March. On that date, the council page now shows a decision date. The team records the decision date in the authority section and 21 March as the last-checked date in the research section. If a later reserved matters application appears, it is logged as a linked but separate record, with its own received, validated and checked dates.

  • Do not merge council dates and researcher dates into one undifferentiated timeline.
  • Do not treat the first day you saw a record as the start of the statutory determination clock.
  • Do not assume that a delayed decision means the file is stuck; a written extension may exist.

Limitations and next checks

A research log is only as good as the evidence visible to you. GOV.UK says determination periods can be extended by written agreement, but that agreement may not be obvious on a public summary page. Some councils also display more date fields than others.

Your log therefore cannot prove the full procedural history on its own. It is a research tool, not a legal record. It also does not tell you whether a permission will be implemented or when work might start.

As a next step, check the original council record, confirm the application type, and look for linked records on the same site so that outline, reserved matters, condition and amendment stages are not confused with one another.

  • Check whether the record is full, outline, reserved matters, discharge of conditions, amendment, prior approval or another type listed by GOV.UK.
  • Use the validation date as the main official timing anchor where it is available on an England planning record.
  • Review linked applications before treating several dates as one project timeline.
  • Keep internal review dates separate so colleagues can see when evidence was last verified.

Sources & further reading

  1. Making an application - GOV.UK Accessed 23 September 2026
  2. Determining a planning application - GOV.UK Accessed 23 September 2026