siting

Build log

1. P0

   Domain live, build log published

   in build

   The host answers over HTTPS and states which build is serving. This page is the progress channel for every phase after it.

   • /healthz proves the persistent volume is mounted AND writable by writing and unlinking a probe file — the API flag alone cannot tell you that.
   • /healthz carries the version, so the ~5s container restart that any definition update causes is distinguishable from a failed deploy.
   • Dependency-free: node's own http, no npm install, no native build.
2. P1

   Screening engine and data spine

   planned

   Point and polygon screening fanned across two independent data sources, returning both answers plus an agreement flag rather than one confident answer.

   • Protected areas, flood extent, transmission lines and substations, mining cadastre, districts and wards — queried, not just drawn.
   • Slope banded from terrain tiles decoded in pure JS; no GDAL, no native dependency.
   • Soil clay fraction screens the expansive-clay reject trigger.
   • Every layer row records source, URL, retrieval time and licence.
3. P2

   Map and candidate register

   planned

   Basemap proxied through this origin so the content-security policy stays self-only. Candidates carry the full field capture sheet, the pass/caution/reject rating and a polygon.

4. P3

   Contiguous-area finder

   planned

   Grids each search zone, scores every cell against the screening criteria, then clusters passing cells into contiguous blocks that meet the area target. Returns a ranked shortlist, never a single answer.

5. P4

   Consent chain and dossier

   planned

   Resolves district, ward, local authority and traditional authority for a parcel, and emits the ordered consent chain with its statutory basis — including the additional wildlife-authority consent where a parcel falls inside a game management area.

   • Every authority record stores source, confidence, and who verified it when.
   • A dossier renders as UNVERIFIED until a human has confirmed the authority by phone or visit. The console never asserts a traditional authority as fact.
   • Exports to the formats field officers actually use.
6. P5

   Hardening

   planned

   Named accounts with per-record salted hashes, server-side capability checks, append-only audit, rate limiting, and backups of the volume.

Standing caveats

• Preliminary screening support only. Nothing here approves a land parcel or replaces field verification, geotechnical investigation or an environmental impact assessment.
• Transmission and substation positions are taken from public mapping, not from the utility. No evacuation route or connection point shown here is confirmed; any grid concept remains subject to a formal grid impact study, wayleave confirmation and interconnection design.
• Administrative boundary layers can be stale with respect to district reorganisation, and some are derived from open mapping rather than the survey authority. Screening validated against a real 12-pin survey found district attribution disagreeing with the source document on a third of the pins — which is why every screen is dual-sourced and disagreement is surfaced rather than resolved silently.
• Traditional authority boundaries are not published as an authoritative national dataset and are contested in places. Authority records here are researched hypotheses carrying a verification state, never determinations.
• A zero result is only trustworthy where the query has been positive-controlled. Layers are checked against a location known to fall inside them, so a renamed upstream layer fails loudly instead of quietly reporting every parcel as unconstrained.