Home/Methodology
How the data is built, and what we won’t claim.
BuildsConnect is built for buyers who ask hard questions: finance, insurance, government, enterprise. This page explains where every number comes from, what is recorded versus what is inferred, and the honesty rules the product itself enforces. Every figure below is queried from the live platform database and re-baked into this page on each refresh. The date underneath is when.
Figures last refreshed 3 August 2026.
Project timing & trade windows is measured but not yet on sale, how the windows are calibrated and what they refuse to claim.
Sources
Two kinds of public data.
The statewide planning record. The NSW Planning Portal’s ePlanning open data: development applications (DAs), construction certificates (CCs), occupation certificates (OCs) and complying-development certificates (CDCs), published by the NSW Government published by NSW DPHI. We currently track 466,017 development projects across all 128 NSW councils, with 604,924 consent lineages and 237,286 CDC records behind them. The statewide planning record refreshes on a regular ingest run, not continuously, and every count on this site says which run it came from.
The document plane. Alongside the feed, we read council DA registers directly, including the Statement of Environmental Effects (SEE), the document a council requires with a DA that describes what will actually be built and names the project’s point of contact. Three numbers, and they are three different things, which is why this page and /data-coverage once appeared to disagree: we enrol 57,928 applications from councils whose document registers we read, 6,946 of those have at least one document we hold, and 4,754 have a Statement of Environmental Effects we have actually read, across 79 councils. It is much smaller than the planning record and grows continuously; signals derived from documents exist only where a document exists, and we say so wherever they appear.
Both are the public planning record. Nothing is drawn from private databases or bought contact lists. See the contacts policy for what that means in practice.
The verdict problem
What “inferred approval” means, and why.
The public feed has a gap most data products quietly paper over: for most DAs, the council’s merit verdict is simply absent. The record shows a determination happened, but not whether the outcome was consent or refusal.
We resolve part of that gap by inference. A construction certificate or occupation certificate cannot lawfully issue without a development consent in force, so when the record shows downstream certificates, we mark the DA inferred_approved. That label is carried everywhere the signal appears: dashboards, API payloads, alert emails. It is presented as an inference from certificates, never as the council’s own recorded verdict, and it is never shortened to a bare verdict word.
The unknowable share is published, not hidden. Of the 304,864 DA consents on the planning record that carry a determination date, 213,932 resolve by certificate inference, and 87,455 are genuinely unknowable: determined, but with no downstream certificate to infer from. They may have been consented and never built, consented with no certificate required, or refused. The record does not say. We mark these verdict_unknown and surface them in every relevant view rather than folding them into either side of the ledger.
Two more distinctions we keep rather than blur: a merit refusal (refused, near-nil in the statewide record) is never summed with an administrative rejection (rejected_invalid); and on CDC records the verdict belongs to the private certifier, not the council. The row says which.
Measured, then gated
How often we read a document right is a number, not a promise.
An LLM pipeline reads each SEE document and extracts the trades a project will need, a plain-language project brief, the project value where the document declares one, and the stated contacts of record. Extraction can be wrong, so we treat its quality as something to measure and publish, not assert.
How the gate works. Every reading job carries a version. Each version’s precision is measured against a gold set of real applications labelled blind (the labellers never see the extractor’s output), and the measured figure is recorded in the database next to the data it describes. The alert product’s read path enforces the gate in SQL: it serves only extraction versions whose recorded measured precision meets the serving bar (currently 0.85). A version that is unmeasured, or whose re-measurement regresses below the bar, stops serving automatically. There is no override in the read path.
The current figure, with its definition. The trades extraction task is at version 3. Its recorded measurement is precision 0.886 with recall 0.935, on a blind-labelled gold set of 74 real applications (779 individual trade predictions), measured against the raw SEE text the production system actually reads, under the comprehensive by-type definition, where a predicted trade counts as correct when the described works genuinely engage it, not only when the document names it outright.
How the gold set was labelled, stated plainly. The labels are AI blind-consensus labels: multiple independent labelling passes per application, blind to the extractor’s output, with an arbiter on splits. The figure is AI-blind-consensus-measured, not human-certified, and the measurement record in the database carries that caveat verbatim. When a human-labelled gold set supersedes it, the recorded figure will change with it, and so will this page.
Linkage confidence
Modification history: heuristic chains, flagged as such.
A consent’s later life (s4.55 modifications and s8.2 reviews) matters to anyone pricing risk. The catch: roughly 40% of modification applications in the source data carry no explicit reference number linking them to their parent DA, so chains are built heuristically.
Every consent row therefore carries a linkage_confidence field, and rows where it is low also carry mod_links_low_confidence: true. Their modification and review counts are flagged estimates, not exact counts. The flag rides with the data into the dashboard, the API and exports.
The same discipline applies product-wide: every API response carries machine-readable honesty notes (coverage gaps, right-censored recent quarters, capped value sums, inference labels) in the payload itself, so a downstream system inherits the caveats along with the data.