Principles
Hard constraints, not aspirations.
These are the lines BeaconNZ is built behind. They predate the product surface and outlast any individual feature. They are written into the repository, reviewed alongside code, and softened only by explicit, documented review — never quietly.
Preamble
BeaconNZ serves two first-class audiences: the public, deciding whether to evacuate, shelter, or travel; and the responders deciding where resources go. Both audiences read these principles when evaluating us. Both audiences depend on the same data spine — and so trust earned in one surface either compounds across both, or is consumed by both when broken.
The lines below are deliberately negative. “What we will not do” is easier to enforce, easier to audit, and harder to dilute through marketing copy than “what we promise to do.” They are written as red lines because they are red lines.
01
No facial recognition on any feed.
Why
Hazard reporting and emergency response do not require, and are corroded by, surveillance over individuals. Adding face matching to a public-good infrastructure normalises it as a default in domains where the chilling effect outweighs any operational gain.
How enforced
No model, library, or service performing facial recognition is permitted in the ingest, alerts, or operator surfaces. CCTV/imagery feeds, when added in future phases, will be processed only for non-identifying signals (e.g. road blockage detection from camera frames) with documented model cards before deployment.
02
Human accountability on critical alerts.
Why
Automated alert issuance at the warning/emergency tier is a category of decision that should never be defensible only by reference to a model. A named human accepts every critical alert at point of issuance, every time.
How enforced
The alert engine refuses to issue at warning or emergency severity without a populated operator identity and a captured review step. Audit trails are append-only and time-stamped per issuance. The composer · review · audit flow is enforced in code, not policy.
03
No personal data sold; aggregated insurance products only with consent.
Why
Trust is the moat. Selling individual location, subscription, or interaction data to third parties — including insurers — would convert a public-good infrastructure into a surveillance vendor. Aggregated, consented data products may still serve risk modelling, but only with explicit opt-in and demonstrable de-identification.
How enforced
No third-party analytics on user-location surfaces. Third-party CDN (Cloudflare) handles only public assets — no personal data crosses the CDN boundary. Any future commercial data product requires consent flow, de-identification pipeline, and a published methodology before sale.
04
No dark patterns in commerce or subscription flow.
Why
Donation, subscription, and operator-licensing flows are read by the same audiences who rely on us in an emergency. Predatory UX in commerce contaminates the operational trust we need for alerts.
How enforced
Cancel-anywhere is honoured one click in. No artificial scarcity, fake countdowns, dark-pattern decoy pricing, or manipulative copy. Receipts and pricing displayed clearly before any transaction. The supporter tier (when launched) opts in, not out.
05
No models in production without a published model card.
Why
Every ML model deployed against emergency information acquires the trust we have already built. Without a model card — purpose, training data, evaluation, known failure modes — that trust is borrowed against, not earned.
How enforced
A model card is required before any model touches production data flow. Cards live in the repo, are linked from this page, and are versioned alongside the model. Cards include intended use, evaluation metrics, known failure modes, and a date of last review.
06
No operation in jurisdictions without local data sovereignty compliance.
Why
BeaconNZ is built for Aotearoa first. Expanding the surface to other jurisdictions imports their compliance frameworks; the only honest posture is to engage with each one structurally before serving a single user from it.
How enforced
Operational data lives in NZ — Catalyst Cloud (Wellington) and AWS Auckland (ap-southeast-2). Any extension of service to another jurisdiction begins with a sovereignty review and partnership engagement before code or infrastructure work.
Governance
These principles live in the repository at CLAUDE.md and on this page. Updates require pull-request review. Material changes — adding, removing, or softening a line — require a documented justification in the commit message and a corresponding update to the version number above.
Questions, challenges, or proposed amendments are welcome. They go to partnerships@ for governance kōrero, or directly as issues on the public repo.