What we store, who touches it, and what the system will not do.

Anonymity is enforced by the architecture

Most feedback tools treat anonymity as a setting an administrator can change. Here it is a property of how the system is built, which means there is no toggle — for us or for your managers — that quietly undoes it.

• No employee accounts exist. Responders are never asked who they are. There is no name field, no employee record, and no login, so a response has nothing to be attributed to.
• Responses are labelled by counter, not identity. Each response gets a code such as E-03 based on the order it arrived that month. The code is not derived from an email address, IP address, or device.
• Email addresses are stored apart from responses. The roster exists only so invitations can be sent. No record links an address to a submission.
• Supervisors cannot generate a brief on demand. Briefs are produced on a fixed monthly cycle. A manager cannot run one immediately after a difficult conversation and infer who said what.
• Department-level briefs are never generated. Not hidden — never produced. Leadership sees one pooled, company-wide brief across all departments.
• A minimum response threshold applies. Company-wide briefs do not run until enough responses exist for individuals to be unidentifiable.
• Supervisors cannot read ahead. Past months are reviewable; months that have not opened are not visible.

One limitation worth stating plainly, because no product can engineer it away: if someone writes something only they could have written, a manager who knows the team may still guess. We protect the record, not the distinctiveness of what a person chooses to share. We say so on the response screen too.

What we store

• Organization and department names, their URL slugs, and their monthly position in the question program.
• Supervisor passcodes, stored only as bcrypt hashes. Nobody at Road Command LLC can read them back.
• Supervisor and department manager email addresses, used to deliver briefs and for SSO matching.
• Employee email addresses supplied by the customer, used solely to send monthly invitations.
• Check-in responses, stored against an organization, month, and anonymous code.
• Generated monthly briefs.

What we do not store

• Employee names, job titles, or any other identifying profile data.
• Any link between an email address and a response.
• Analytics, advertising, or third-party tracking cookies. The product sets no tracking cookies at all.
• Payment card details. Billing is handled by invoice outside the application.

Access and authentication

• Supervisor access is gated by a per-organization or per-department passcode, hashed with bcrypt.
• Optionally, supervisors sign in with your existing identity provider over OpenID Connect. Access is granted by matching the verified email against the supervisor address on file — a valid company account alone is not enough.
• Sessions use signed, HTTP-only cookies scoped to a single organization or department, and expire after 12 hours.
• Employees authenticate with nothing at all, which is precisely what keeps them anonymous.

Infrastructure

• Hosted on Vercel, served over TLS.
• Data stored in a managed Postgres database (Neon), encrypted at rest and in transit.
• Secrets and API keys are held as environment variables and are never exposed to the browser.
• All AI calls are made server-side. No AI provider key is ever present in client code.

Sub-processors

These third parties process customer data on our behalf in order to deliver the service.

Responses sent to Anthropic for brief generation are pooled and carry only anonymous codes. They are sent through the commercial API, which does not train models on submitted data.

How the AI is used

Once a month, the pooled responses for an organization are sent to Anthropic's API with a prompt that returns a structured brief. The output is a summary, not a judgment: it can be wrong, it can miss nuance, and it should never be the sole basis for a decision about any individual. Treat it as a prompt for a conversation.

Retention and deletion

Data is retained while an organization is active. On request, or when an organization is closed, we delete it along with its departments, roster, responses, and briefs. Backups held by our infrastructure providers roll off on their own schedules. Full detail is in the privacy policy.

Current certification status

We do not hold a SOC 2 report today, and we would rather say so than imply otherwise during procurement. If a formal attestation is a requirement for your organization, tell us as part of your evaluation and we will discuss where it sits on our roadmap.

Reporting a vulnerability

Email admin@roadcommand.co with the detail and we will acknowledge it. Please give us a reasonable window to fix anything you find before disclosing it publicly.