Associated applications: the chain, where it can be shown, on one page

A development is rarely one application. An outline settles the principle, reserved matters fill in the design, a variation moves a condition, and a run of discharges follows with the details the conditions demanded. On the council register each has its own number, and finding the rest means a search for every one.

Application pages now carry an Associated applications section beneath the documents: the principal application the page belongs to, labelled Part of, and every other application we can prove belongs with it, as a tree.

Rows lead with the proposal in plain words, the citation clause removed and the reference in small print. Each carries its route: Outline, Reserved matters, Variation, Conditions. The branch you are on is open; the rest sits behind a one-line summary such as "Show 11 more - 5 approved, 6 pending". Live applications link to their Plota page. Archived ones, back to 2016, open in place with a button through to the council's record.

How the links are made

Few council portals link related applications, and those that do miss a good deal. Plota works the links out from the record itself, in two ways.

What councils write. Case officers cite the parent reference in the description: "Reserved matters pursuant to outline 21/01187/OUT". We read those references out of the text. Every authority formats them differently, and the same string is in use in dozens of councils at once, so a citation becomes a link only when it matches exactly one application in the same council, live or in our archive of more than 10 million applications back to 2016. A citation we cannot place stays as text.

How councils number. Many authorities keep the core of the number and change the suffix: 24/01355/FUL, then 24/01355/COND1. Matching on the number alone would be wrong often enough to matter. Some councils reuse it across unrelated sites, and a FUL and an HOU sharing a number are usually two separate applications. So a shared number links only when both applications are at the same site, the later one is procedural, the earlier one is an application for permission, and the descriptions differ. We read a matched pair from every council before switching it on. It adds around 600 families the descriptions would have missed, across 43 councils.

Both signals favour precision over coverage: where a link cannot be proved, nothing is shown. Most householder applications stand alone. Just over 70,000 applications carry the section today, across 348 councils, and the links are rebuilt every night, so a new discharge joins its family the morning after we collect it.

In the API

Data customers get the same graph. GET /v1/applications/{id}/associated returns the family as a flat list in date order, each member with its procedure, a parent_id and depth to rebuild the tree, and linked_by to say whether the description named the parent or the shared number and site proved it. Every application the API returns now carries a links.associated URL.

/v1/applications/og3h4jnm/associated

{ "data": {
    "role": "member",
    "principal": { "reference": "23/00405/OUTFUL",
                   "procedure": "outline", ... },
    "count": 9,
    "applications": [
      { "reference": "23/00405/OUTFUL", "procedure": "outline",
        "depth": 0, "parent_id": null, "source": "live", ... },
      { "reference": "23/00405/CND47", "procedure": "discharge",
        "depth": 1, "parent_reference": "23/00405/OUTFUL",
        "linked_by": "citation", "is_this": true, ... },
      ... ] },
  "meta": { "historical_available": true } }

Historical members are included on paid plans. The rest is in the developer docs.