Technical reference
Mission Analytics docs
System architecture
Mission Analytics separates presentation, server state, API access, and data authorization so the current database layer can later be replaced by a FastAPI service without rebuilding the interface.
The analyst signs in with email and password.
The protected route validates the current account before rendering.
TanStack Query calls an authenticated server function with the session token.
The server function validates input with Zod and queries through the signed-in account.
Database row-level rules authorize the request before rows are returned.
The result is cached by query key and rendered as mission tables, reports, and event views.
Email/password accounts use confirmation-aware sign-up and persistent browser sessions.
Protected pages validate the account before loading; sign-out clears cached protected data.
Every data table has row-level rules and authenticated access grants.
All signed-in analysts can read operational data; owners alone can modify mission records they created.
missions
Mission identity, description, operating dates, creator, and creation time.
reports
Status, summary, participant/event/alert counts, performance, anomalies, and AI summary.
events
Mission-linked event type, occurrence time, severity, and structured JSON payload.
FastAPI replacement boundary
UI components depend on typed mission shapes and query options, not direct database calls. A future FastAPI client can replace the current server-function implementation while preserving route components, query keys, report cards, and loading behavior.