Security

1.1 Latency

Calchis polls source agencies on a fixed schedule; it does not receive pushed alerts. Displayed data therefore lags the agency by the agency’s own publication delay plus up to one polling interval. Current intervals: USGS earthquakes, SPC outlooks and NWS storm alerts every 5 minutes; NWS flood alerts every 10; NASA FIRMS hotspots every 15; NHC advisories every 30; NIFC fire perimeters every 12 hours.

A twelve-hour perimeter refresh is appropriate for planning and wholly inappropriate for tracking a moving fire front. Match the interval to the decision.

1.2 Model bounds

Scores are hazard scores, not risk scores. They describe the hazard at a location and do not incorporate property exposure, construction type or insured value, so they are not a substitute for actuarial assessment.

Some scoring inputs are measured for the specific location and others fall back to a documented per-state constant. Which is which is published per input in the methodology, under “Per-location inputs: what is measured and what falls back”. A fallback is labeled rather than hidden, but it does mean two addresses in the same state can return the same number for some perils.

One limit deserves singling out. The flood-zone input is derived from FEMA NFIP claims within roughly 11km, and NFIP rounds claim coordinates to one decimal place to protect policyholder privacy. It therefore describes a neighbourhood, not an address, and is not a substitute for a FIRM lookup on a specific parcel.

1.3 When not to rely on this platform

Do not use Calchis as the trigger for evacuation, dispatch or any other life-safety action; it is not a primary alerting system and carries no availability guarantee. Do not use a hazard score as the basis of a flood-zone determination, an insurance rating decision, or a regulatory filing. Do not treat an absence of events as an all-clear — a source outage and a quiet day look the same on a map, which is why /status publishes per-source freshness.

3.1 Data in Transit

All data transmitted over TLS 1.2 or higher. No plaintext communication channels are used for any user data or API traffic.

3.2 Data at Rest

Database storage is encrypted at rest with AES-256 by Supabase, which also encrypts automated backups. Server-side secrets — the Supabase service-role key, Stripe keys, the cron secret and third-party API keys — are held as encrypted Vercel environment variables and are never included in the client bundle. Row Level Security is enabled on every table, so the database enforces tenant separation rather than relying on application code to remember to.

3.3 Incident Data Handling

Two kinds of data sit side by side here, and the distinction matters.

Hazard and event data is public data from cited sources. It is fetched from USGS, NOAA (National Hurricane Center, the Storm Prediction Center and the National Weather Service alert feeds), NASA FIRMS, NIFC and FEMA. None of it originates from users, from private sensors, or from commercial data brokers. Every ingested record stores its source, source_url, ingested_at timestamp and a confidence_score, so any figure on the platform can be traced back to the agency that published it.

The live layer holds currently active events and is refreshed continuously; the historical archive holds roughly seventy years of public disaster records and is retained indefinitely, because it is the basis of frequency and return-period analysis. Both are public-source data and neither is customer data.

Incident records are yours. Anything created in the EOC workflow — incidents, ICS forms, taskings, resource requests, activity logs, cost records and the people assigned to them — is customer data, isolated per organization by Row Level Security and never used to train models or shared with other customers. Cross-agency sharing happens only when a user in your organization explicitly shares an incident. Tenant isolation is verified on every build by dedicated integration suites (tests/integration/cross-tenant.test.ts and cross-tenant-api.test.ts), which are build-blocking: if one organization could read another’s data, the deploy fails.

3.4 User Data Handling

See our Privacy Policy for comprehensive details on personal data collection, use, retention, and deletion.

4.1 Row-Level Security

Every table containing user data is protected by PostgreSQL Row-Level Security (RLS) policies. Users can only access their own saved locations, portfolios, triggers, and alert configurations through the application layer. RLS is enforced at the database level — not the application level — providing defense-in-depth against application bugs.

4.2 Authentication

Authentication is handled by Supabase Auth, which supports two sign-in methods: email-and-password, and a passwordless magic link sent to the address on file. Where a password is used it is stored only as a salted hash held by Supabase; Calchis never receives, stores or logs a plaintext password. Session tokens are short-lived JWTs validated on every API request.

Both methods are single factor. There is no MFA. No TOTP, hardware token or CAC/PIV support exists today. This is the platform’s most significant authentication gap, it fails CJIS Advanced Authentication on its own, and it is tracked as not_started on /compliance.

4.3 API Authentication

Worker routes (cron-triggered data ingestion) authenticate via a shared secret (CRON_SECRET) in the Authorization header. User-facing API routes authenticate via Supabase JWT. All server-side secrets are stored in encrypted environment variables and never exposed to client-side code.

4.4 Rate Limiting

All API endpoints are rate-limited via Upstash Redis. Limits vary by subscription tier. Rate limit headers are included in all API responses. Persistent abuse results in temporary IP blocks.

7.1 Audit Logging

Alert delivery events are logged in an audit table with SHA-256 hashed user identifiers (not raw user IDs). Audit logs are retained for 2 years. API usage logs are retained for 90 days. Server request logs (including IP addresses) are retained for 30 days.

7.2 Compliance Posture

Calchis holds no security certifications and has not been audited. There is no SOC 2 report, no FedRAMP authorization, no ATO and no CJIS certification. No external audit has been performed and none is currently scheduled.

What does exist is an internal readiness self-assessment, published at /compliance. It tracks SOC 2 Trust Services Criteria, NIST 800-53 control families and CJIS requirements, and marks each one met, in_progress or not_started with a note on the evidence. It is a self-assessment by the team that built the system. It is not an audit, nobody independent has reviewed it, and it should not be represented as one.

Two gaps are worth naming here rather than leaving to be discovered: authentication is single-factor — email-and-password and magic link are both supported, but there is no second factor, which fails CJIS Advanced Authentication on its own — and audit logging is partial rather than comprehensive.

Sub-processors carry their own certifications: Supabase is SOC 2 Type II, and Stripe is PCI DSS Level 1. Those attest to those vendors, not to Calchis. California privacy rights (CCPA/CPRA) are addressed in the Privacy Policy.