Specification · FIP v1.0
The Feasibly Interpretation Protocol
How planning-scheme text becomes a citable number — and how to say honestly what that number is worth.
Published as a standard rather than kept as a method. Anyone may apply it, cite it, or argue with it. Eight rules, six confidence levels, and a list of things a conforming system must refuse to do.
What this governs
One parameter, for one parcel. A minimum lot size, a height, a setback, a permit trigger. Not a page, not a report, not a “planning summary”.
The unit matters. Confidence is a property of a value, so a system that tags confidence at document level is averaging things that must not be averaged — a human-read schedule and a machine guess, presented as one number.
The protocol covers values drawn from a state planning instrument, a council instrument, or an authoritative government spatial layer. It does not govern advice, feasibility, valuation or design. A protocol that produced those would be pretending a screening is an assessment.
⚠️ This document is normative about method, not coverage. It says what a value must carry before it may be published; it makes no claim about what anyone holds. Live counts are generated from the data and published on the methodology page — counts stated in prose go stale, which is not hypothetical but the reason this page contains almost none.
Rule 1 — every value carries its own confidence
A published value is { value, confidence, source }, or it is not published. Six levels, in descending order of authority.
| Level | Means |
|---|---|
verified_schedule | The council’s own schedule was read and states this value explicitly. |
verified_vpp_default | The schedule was read, says “none specified”, so the state default governs. The reading happened — this is not a guess. |
verified_spatial | From an authoritative government spatial layer that is the legal instrument. |
state_code_default | A state-wide instrument’s default for the zone. Correct unless a local variation overrides it — and that variation may not be held. |
machine_extract | Codified from a council document by machine. Screening-grade. Explicitly not the same tier as a human-verified schedule. |
unverified_default | A fallback, with no confirmation that it applies to this parcel. |
The distinction that does the work is between the top two and machine_extract. Both produce a number; only one involved a person reading the clause. Render them identically and you have destroyed the only information a professional needs to decide whether to check.
Rule 2 — absence needs a reason
null is a legitimate answer and an uninformative one. Three cases are routinely conflated and mean opposite things.
| Basis | Means |
|---|---|
not_codified | No value is held. Says nothing about the instrument. |
delegated_to_local_scheme | The binding number exists, in an instrument not held. |
no_control_applies | The instrument was read and imposes no such control here. |
“We don’t know” and “there is no control” are different answers to the same question, and only one of them is good news. A response returning bare null has answered neither.
Rule 3 — absence of a finding is never a clearance
The most dangerous failure in planning data is a query that fails and renders as “not affected”.
- A failed check is recorded as a failure, never as an empty result. A hazard layer that did not answer must not become “no hazard”.
assessedmeans the assessment ran, not the assessment found something. A clear parcel isassessed: true, triggers: [].- A clear-case statement must not name a layer that was never reached.
- Every gap is surfaced to the reader, not only to the payload. A caveat that reaches the JSON and not the summary has warned nobody.
This is a rule about upstream systems generally. ArcGIS services report query failure in the body, under HTTP 200 — so a success check does not catch it, and an error body has no features array. Reading “are there features?” without guarding turns a broken bushfire layer into “bushfire: not affected”.
Rule 4 — a value cites the clause, not the vendor
Every published value carries the clause or schedule reference, a source URL, and the instrument’s currency.
Currency is described as the custodian’s published date — never as “as at” or “verified”, which assert something the publisher did rather than something the government did.
A 2022 date on a council scheme means that council last republished in 2022. It does not mean the data is stale, and describing it as staleness is a misreading of whose date it is.
Rule 5 — depth tiers are declared, never collapsed
Coverage is not uniform, and a protocol that lets a publisher imply otherwise is worthless.
| Tier | Means |
|---|---|
| Schedule-deep | Council-specific schedules interpreted from the source ordinance by a person. |
| Machine-extracted | Council controls codified from council documents by machine. Screening-grade. |
| State/territory-API | Zone, overlays and controls from the government’s authoritative spatial API, without per-council interpretation. |
All three are honest. Presenting the third as the first is not. A count of states or councils is a coverage claim, never a depth claim, and the two must not be quoted interchangeably.
Rule 6 — verification is a pipeline, not a benchmark
A published accuracy figure measures one moment. Four standing layers, because passing the first three tells you almost nothing about the fourth.
| Layer | Asks |
|---|---|
| Shape | Does the code fail closed? Are absences recorded rather than substituted? |
| Coverage | Does every supported jurisdiction still return the full contract? |
| Freshness | Is the underlying data within its staleness bound? |
| Answer | Does the live answer match the government’s own published answer? |
Only the fourth catches a confidently wrong output. The first three can all be green while a value is wrong.
⚠️ When the answer layer disagrees, check the source before assuming an amendment. A drift is either a real change or your own regression, and assuming the flattering one is how a regression gets published as news.
⚠️ A guard is not finished until it fails on the real defect. A check never shown to catch the thing it was written for is documentation. Verify by injecting the defect, observing the failure, and restoring.
Rule 7 — monitoring is continuous, and its absence is detectable
Schemes are amended continuously, so a dataset is a claim about a date.
- Detection of instrument change on a stated cadence, per jurisdiction.
- A recorded detection history, so “when did this change” is answerable.
- A dead-man’s switch. A monitor that only reports on change cannot report its own silence, so every run records that it ran — whether or not it found anything.
The third is the one usually missing. A system that alerts only on change is indistinguishable, when healthy, from one that has been broken for months.
Rule 8 — what a conforming system refuses
A specification is defined as much by its refusals.
- Fabricating a citation. If a resolver falls back to a default it must not cite a clause it did not read. An invented statutory reference is worse than no answer, because it is checkable and looks checked.
- Applying one jurisdiction’s engine to another. A fallback that quietly resolves an unknown code to a known one produces a confident number under a reference that does not exist.
- Publishing an estimate as a control. A value whose provenance is “estimated” may not sit beside ones that are published controls.
- Reporting a not-applicable pathway as a negative finding. Where a statutory pathway does not exist in a jurisdiction the field is omitted, not returned as
false— which reads as “assessed, not eligible”. - Averaging confidence. No summary tier over values of differing confidence.
- Restating in prose a number that exists in data.
Citing it
FIP is versioned. A change to the confidence vocabulary or to the refusals is a major version.
Cite as “Processed per Feasibly Interpretation Protocol v1.0” — or, more usefully, with the value’s own confidence level:
minimum lot size 300 m², verified_schedule, Cl. 32.08-3, per FIP v1.0
What this is not
It is not a claim that Feasibly satisfies it perfectly. It is the standard the product is built and audited against, and those audits are gates in a deploy pipeline rather than assertions in a document. Where the product has failed these rules it is recorded publicly in the changelog — including the cases where a rule exists because of the failure.
It is not planning, legal, architectural or financial advice, and no value produced under it substitutes for the relevant council and a qualified professional.
It is not a description of the engineering. It states what a conforming value must carry and what a conforming system must refuse — deliberately, so it can be adopted without adopting our implementation.
See it applied to a real address.
Every value comes back with its confidence level and the clause it came from. Free, no signup.