Protective work is only useful if the information behind it is safe.

There is no public sign-up and no shared password. Access is issued to a person by invitation and can be revoked instantly, so the circle of who can open a trip is always known and current.

• Invitation-only access, issued and revoked centrally
• Personal identity plus a one-time code — the code stored only as a hash, never in the clear
• Role-based, per-trip governance by a team lead is rolling out on this foundation

Sensitive values are replaced with typed placeholders through a per-session mapping before anything is sent for assessment, so the principal's real identity isn't the thing traveling across the network — and the profile still works, under a protected name.

• Real names and identifying values masked before queries leave the device
• The watch profile stays effective while the identity stays protected
• Real values are restored only locally, for the team that owns the trip

Stored trips — the people, the movement details, and the point-in-time assessment — are encrypted where they live, and the on-disk entry is a non-identifying stub. Without the key, a record reads as a protected placeholder, not a roster.

• Trip sessions encrypted at rest (AES-GCM-256) with hardened key derivation
• On-disk entry carries no readable names, coordinates, or agenda
• The decrypt key is the operator's access grant, held separately from the data

The platform's privileged credentials never ship to the field device — the team works from the phone while the secrets stay on the secure server — and the assessment engine is reached through a server-side gateway with de-identified queries.

• Privileged credentials and third-party keys held server-side, off the end-user device
• Assessments generated through a server-side gateway; the AI credential never reaches the device
• Developed under a disciplined, self-checking engineering process