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 neighborhood, 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 gate the merge: they run in continuous integration against a live project when its secrets are present, and a change in which one organization could read another’s data does not merge. They are not run by the deployment itself.

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.

A second factor is available: a time-based one-time code from an authenticator app (TOTP, RFC 6238). A user enrolls it under Settings → Account; from then on every sign-in, by password or magic link, stops for the code before the application shows a session, and the code is verified by the authentication provider, never by Calchis. Operator access to the platform requires it. Customer accounts are not required to enroll, and an agency that needs enforcement across its seats should say so in its agreement. Hardware keys and CAC/PIV are not supported; SMS codes are deliberately not offered. Status is tracked 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 per minute in the application, and API keys carry a daily quota counted in the database. Limits vary by subscription tier. Rate limit headers are included in all API responses; a request over the limit is refused with HTTP 429 until the window resets. The per-minute limiter is in-process memory on each function instance (since 2026-10-21), so under load several instances each allow the stated rate; it is a burst control. The daily quota, counted in the database, is the ceiling that bounds extraction.

7.1 Audit Logging

Alert delivery events are logged in an audit table with SHA-256 hashed user identifiers (not raw user IDs). Those audit rows are retained until the account is deleted: no scheduled purge runs today, and an earlier version of this page that promised a two-year purge described a job that did not exist. API usage is counted per account per day and the counters are purged after 7 days. Server request logs (including IP addresses) are Vercel’s and are kept for Vercel’s own retention period; no log drain is configured. The privacy policy’s retention section is being brought into line with this.

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: two-factor authentication is available and required for operators but not enforced for customer accounts, and audit logging is partial rather than comprehensive (administrative changes to an account are logged since migration 176; reads are not). The adopted policy set is docs/security-policies.md and the incident procedure docs/security-incident-response.md in the repository; both were written and adopted by the founder and reviewed by nobody independent.

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.