Scope
AfterResponse is deployed separately for each subscribing emergency-service organisation. Each organisation's data is isolated from every other organisation's. This policy describes how AfterResponse handles data within a single organisation's deployment.
What we collect
- Account & role data: your name, email, organisation membership, and the role(s) your organisation assigns you (crew, team leader, duty manager, dispatch, peer supporter, WHS admin, org admin).
- Incident references: a tokenized record that an incident occurred (time, category) — never a clinical or narrative description of what happened.
- Recovery offers & responses: that a recovery offer was made and whether it was responded to. The specific action someone chose (e.g. a quiet timer vs. talking to a crewmate) is visible only to the person themself — never to their team leader, dispatch, or WHS.
- Stand-down requests: that a stand-down was requested and its outcome (approved/declined, duration). There is no field anywhere in the system for the reason — the schema does not have one.
- Peer-support referrals: only if you opt in, and only what you choose to share: a preferred contact method/timeframe and a reason picked from a short fixed list — never free text.
- Audit trail: a record of who took which action and when, for accountability. This record cannot be edited or deleted once written (enforced by the database itself, not just application code).
What we deliberately do not collect
- No free-text clinical or psychological notes, anywhere, ever — there is no field in the database for them.
- No ongoing or longitudinal monitoring of any individual — no scheduled re-check-ins, no personal trend history.
- No clinical care is delivered by AfterResponse — a peer-support referral only initiates a handoff to a destination your organisation configures (e.g. its EAP), with your explicit, timestamped consent.
- No connection to CAD/dispatch systems — incidents are logged manually.
- No AI, machine learning, or automated profiling is applied to your data.
Who can see what
Visibility is restricted by role at the database query level, not just in the interface:
- Dispatch sees only a unit's current operational status and when it's next reviewed — never who is on it or why.
- WHS/wellbeing admins see only de-identified, aggregated statistics with a minimum group size — any group below that threshold is shown as suppressed, never as a fabricated zero or a blank.
- Team leaders can see that an offer was made and responded to, never which option was chosen.
- Peer supporters see only referrals sent to them, with the information the referring person chose to include.
Where data is stored & who processes it
Application data is hosted on Neon (PostgreSQL) and served via Vercel. Authentication is handled by Clerk. None of these providers are given access to interpret or act on your data beyond hosting/authenticating it. We do not sell data or share it with advertisers. We do not currently integrate with any third-party notification, SMS, or AI service.
Your rights
You can ask your organisation's admin what data is held about you. Because the audit trail is append-only by design (it is what makes the accountability promise in this policy trustworthy), individual audit entries cannot be deleted — this is a deliberate trade-off, not an oversight. [Placeholder: process for data access/correction/export requests to be finalised with counsel and the pilot organisation before go-live.]
Changes to this policy
[Placeholder: change-notification process to be finalised.]
Contact
[Placeholder: contact details to be added before go-live.]