What OrbiVigil is — and is not
OrbiVigil is a decision-support tool. It fuses satellite thermal detections, weather and open hazard data into a graded confidence ladder, and it never issues a public evacuation instruction directly. Alerting the population and engaging response resources remain the exclusive responsibility of the fire services, prefectures and operations centres that use it.
Automated fusion can raise a detection to at most Level 2 (“probable”). The transition from Level 2 to a confirmed Level 3 event always requires a named analyst.
OrbiVigil does not write to residents, does not replace an official alert chain, and reports cloud cover rather than hiding it as “no fire”.
Where the data lives
OrbiVigil runs on a managed global edge platform with points of presence in the EU: we operate no origin servers of our own.
- Object storage — explicitly configured as EU-jurisdiction storage for raw satellite artifacts, GeoJSON cache snapshots, tiles and provenance exports.
- Account and territory data — account records, sessions and saved monitoring areas live in a dedicated database and key-value namespace bound only to the authentication service. Unlike the object storage above, that database carries no explicit jurisdiction setting — we cannot yet state a contractual EU-only guarantee for it and treat this as open until confirmed in writing.
- Transactional email is sent through the platform's own native email service, not a third-party mail provider.
What personal data we process
For a citizen or institutional account, we hold:
- Name and email address (the account identity).
- Session metadata used for sign-in and security: IP address, user agent, and coarse network-derived location (city, region, country, latitude/longitude, and the edge point of presence that served the request).
- Saved monitoring areas: a name and a centre point/radius per area, capped per plan (Citoyen Pro: 1 area; business and institutional plans: more) at up to 50–100 km radius.
- A payment-processor customer identifier for accounts on a paid plan, and subscription/plan/trial state. No card details are held by OrbiVigil; the payment processor handles payment directly.
- For institutional pilots (mairies, SDIS, préfectures): a contact name, professional email, optional phone number, and the commune/INSEE code used to pre-configure the watched territory.
A monitoring area is never guessed from a place name: coordinates come from the request, or from the official commune centroid, or the area is created empty.
Subprocessors
- The managed edge platform that hosts and stores the service.
- The payment processor used for accounts on a paid plan.
Both are named, with their roles and the categories of data they touch, in the signed DPA and to institutional buyers on request.
No other third party receives account data as part of the product today, to the best of our knowledge of this codebase. A change to this list would be a structural change and is expected to update this page in the same commit (see this repository's own contribution rules).
Data retention
Where a lapsed institutional trial is concerned, we can be precise: expiry removes the paid entitlement (email alerts stop) and deletes nothing — the account, its saved areas and its history remain exactly as they were, and reactivating a pilot restores rather than rebuilds the service.
Beyond that specific case, this repository does not currently define a general data-retention schedule (e.g. how long an inactive account or its sessions are kept) in code. Retention periods beyond the pilot-expiry behaviour above are documented on request — use the contact form.
Any account holder can also delete their own account and its data at any time, self-service, from the account dashboard: a confirmation email is sent first, and only clicking the emailed link deletes anything — at that point any active subscription is canceled immediately and the account, its saved areas and its two-factor setup are permanently removed. For anything that flow doesn't cover, use the contact form.
Status and uptime transparency
The platform's live health surface is public at api.orbivigil.com/health. It reports service state and, for data feeds published out-of-band (e.g. Canadian cloud-state ingestion published out-of-band), a per-publisher freshness block so a stale upstream is visible rather than silently served.
We are not publishing a numeric uptime/SLA commitment on this page — the health endpoint is a transparency surface, not a contract. An SLA is available as part of an institutional agreement; ask your OrbiVigil contact.
The one-pager for your DPO
If your procurement process needs a GDPR data-processing summary to attach to a file, use /trust/dpa/. It covers roles, our standard Article 28-style commitments, and how to request a signed DPA.
Questions this page does not answer, or a formal document you need for a file: use the contact form.