Managing planning permit conditions: from permit PDF to live register

The lawyer’s reading of a permit asks whether each condition is valid and what it strictly requires. The delivery reading asks a different question of every condition: what does this block, and when? On a Victorian permit the answer is usually encoded in a handful of recurring phrases, and experienced practitioners scan for them the way an estimator scans for provisional sums.

Two structural traps hide in this reading. First, a single condition frequently contains several obligations — a drainage condition might require a design submission, a works outcome and an authority acceptance, each with a different owner and timing. If your register maps one condition to one row and one status, the row is lying to you for most of the project. Second, conditions are issued by the council but discharged through many hands: referral authority conditions sit on the same permit with the council’s, and the entity that must be “satisfied” differs condition by condition.

Almost every team starts with the same artefact: the permit PDF, highlighted, with a companion spreadsheet. It works for the first month. It fails in the same four ways every time.

• Amendment breaks the numbering. Permits get amended — through a formal amendment process or by secondary consent to the endorsed plans. Condition 12 becomes condition 14, the spreadsheet keyed to the old numbering silently points at the wrong obligations, and nobody notices until an authority does.
• Evidence has no home. A condition is not discharged when the work is done; it is discharged when the responsible authority accepts the evidence. The spreadsheet has a “complete” column but no answer to “complete according to whom, shown by what document, sent when”.
• The register decays with its author. The person who built the spreadsheet carries its conventions in their head. When they roll off the project — and on a multi-year subdivision, they will — the register becomes archaeology.
• Nothing connects to the programme. The spreadsheet knows condition status; the programme knows dates. The fact that an open drainage condition gates the Statement of Compliance, which gates settlement, lives in neither — it lives in a meeting, monthly, if someone remembers to raise it.

A register earns its keep through its fields. The minimum set experienced teams converge on, whatever tool they use:

• Condition number and full obligation text — verbatim, because paraphrase is where obligations get lost.
• Category — drainage, landscaping, traffic, environmental, subdivision, services, engineering — so the register can be worked by discipline, not read end-to-end.
• The gate — commencement, endorsement, Statement of Compliance, occupation, or ongoing — read from the condition language.
• Responsible party — the consultant, contractor or developer entity that will actually do the discharging, which is rarely the permit holder for every condition.
• The authority that must be satisfied — council or the specific referral authority, because that determines whose acceptance letter you are chasing.
• Status that reflects reality — not started, in progress, complete, not applicable — with “complete” reserved for accepted, not merely submitted.
• Evidence, attached — the submission, the response, the acceptance. The condition row should be the index of its own paper trail.
• Due date where one genuinely exists — permit expiry and commencement timeframes are real dates; most conditions otherwise inherit urgency from what they block.

Plan endorsement deserves its own tracking, separate from conditions. Endorsement rounds have their own submission-review-resubmission cycle with the responsible authority, and conditions elsewhere on the permit reference the endorsed plans — so “where are the plans up to” is a workflow question the condition register alone cannot answer.

The register conversion is mostly transcription — retyping sixty conditions, categorising them, spotting the gate language. It is exactly the work machine extraction should do and exactly the work it is safe to let it do, because the output is reviewable line by line against the source document before anything depends on it.

The interesting engineering detail is in gate detection. The phrases that gate commencement, occupation and Statement of Compliance are highly conventional — conventional enough that deterministic pattern matching catches most of them without a model involved. The robust approach is therefore two-stage: regex-style rules first, a language model only for the residue the rules cannot classify. You get speed and audit-ability on the common cases and judgement on the rare ones, instead of paying model uncertainty on all of them.

The register becomes genuinely valuable at the moment it connects to the programme. Sort the conditions by gate and the Statement of Compliance checklist assembles itself months before anyone is preparing the application — and, more usefully, it surfaces the SoC-gated conditions that involve physical works or authority acceptance, which are the ones that must be engineered into the construction programme rather than discovered after practical completion.

That inversion is the whole game. Teams that track conditions as a compliance afterthought reconstruct the critical path backwards from a stalled SoC application. Teams that track them as a live register with gates read the critical path forwards from week one. The permit is the same document in both cases. The difference is whether it was converted into a system while there was still time for the answer to matter.