# Planning Notes: Land + Beacon Registration

## Core Data Model

Use Firestore for structured records:
- `plots/{plotId}`
  - `owner`: name/contact
  - `beaconIds`: array of beacon serials
  - `geometry`: polygon coordinates
  - `areaM2`, `center`, `notes`
  - `createdBy`, `updatedBy`, `timestamps`
- `beacons/{beaconId}`
  - assignment status, battery data, lastSeen, firmware
- `plotEvents/{eventId}`
  - append-only audit log (create/update/reassign/dispute)

Use Realtime Database for high-frequency location/telemetry:
- `liveBeaconState/{beaconId}` -> latest ping/state

## Registration Workflow

1. Officer enters plot metadata and owner details.
2. Officer enters one or more beacon IDs.
3. Officer draws polygon on map.
4. Client validates required fields + polygon points.
5. Record is saved to Firestore.
6. Optional workflow: submit for approval before status becomes `active`.

## Technical Decisions To Lock Early

- Coordinate precision (e.g., 6 decimal places).
- Source of truth for parcel boundaries (field map vs legal GIS file).
- Duplicate beacon policy (hard reject vs warning).
- Conflict policy for overlapping plots.
- Offline strategy for field registration.

## Security Baseline

- Enforce auth on all write paths.
- Restrict writes to permitted roles.
- Separate read access for sensitive owner data.
- Log all write operations with actor + timestamp.
- Add App Check and HTTPS-only endpoints for production.

## Deployment Checklist

- Firestore rules reviewed and tested.
- Realtime DB rules reviewed.
- Hosting deployed with caching headers.
- Error logging enabled (Crashlytics/Cloud Logging).
- Backup/export schedule defined.