DriveState is a per-tenant Performance Learning platform. Learner activity is stored against the tenant that paid for it, isolated from every other tenant, and never used to train any public AI model. This page summarizes how data moves through the system, what we keep, and what we don't.
The browser talks to a web application hosted on Vercel, which in turn talks to a managed Postgres database (with vector search for content retrieval) hosted on Supabase. Learner audio is captured in the browser and streamed directly to Google's Gemini Live API; the AI counterpart's reply comes back through the same channel. When the avatar is on, the audio of that reply (synthesized speech, never the learner's voice) is forwarded to LiveAvatar, which returns a rendered video stream to the browser.
Vercel and Supabase are both SOC 2 Type II certified. The default deployment region is the United States. For enterprise agreements, the application and its database can be hosted in the EU on request. AI processing is carried out by the subprocessors listed below, which do not currently guarantee EU-only processing.
Every record (learner, session, turn evaluation, mastery score, authored content) is tagged to its owning tenant. Database row-level security ensures no query, including a malformed or malicious one from the application, can return rows across tenants. Each tenant's data is fully partitioned: no shared learner pool, no shared mastery pool, no shared content library.
The privileged database credential (the one that can bypass row-level security) is stored only as a server-side environment variable and is read solely by server-side functions. The browser never sees any database credential, and no database key is shipped in the client bundle.
Who may sign in is decided per tenant. The default is an invitation-only roster: an administrator adds a learner, and nobody else can create an account. A tenant may instead admit anyone at an approved email domain, or anyone at all (the public demo).
How a learner signs in, whichever way the tenant offers:
Every backend API route enforces access on the server, not just in the interface. Live checkpoint rounds, the debrief display projected to a room, and Ask channels are reachable by their link on purpose: they identify nobody and expose nothing but their own screen. The one exception is chosen by the visitor: an Ask channel can offer to have a person follow up, and a visitor who takes that up gives us an email address or phone number on purpose. We keep it with that one conversation so someone can reply, and nothing else about them.
The learner record itself is intentionally minimal:
Per session, we store:
We do notstore demographic data, performance reviews, compensation, records of the learner's real-world work, or any data about the real people the learner will eventually interact with. DriveState is a practice environment; it has no awareness of the learner's real-world activity.
DriveState relies on a few external services, each receiving only the minimum data needed to do its job.
Processes learner audio in real time and returns the AI counterpart's reply as synthesized speech. Also embeds query text for content retrieval, and turns a few short lines of text into speech, such as a narrator's stage direction and the audio check greeting. Per Google's published Generative AI API terms, content sent through the API is not used to train or improve Google's foundation models. During a conversation with the AI counterpart, Gemini Live is the only service that ever hears the learner's audio.
Receives the AI counterpart's synthesized speech audio (generated by Gemini Live), renders the avatar speaking it, and streams the video back. Receives nothing from the learner: no learner audio, no learner identity, no email, and no transcript. Conversations run in LiveAvatar's Avatar Only (Lite) mode, in which it only renders the audio it is given. Per HeyGen's published LiveAvatar FAQ, no session data is retained in that mode. LiveAvatar is invoked only when the avatar is enabled; in audio-only mode it is never called at all.
Stores tenant data (learners, sessions, mastery, authored content) and tenant asset files (coach videos, content snapshots). Encrypted at rest with AES-256; encrypted in transit with TLS 1.2+. SOC 2 Type II certified. The database is per-deployment, never shared across tenants other than at the schema level.
Serves the application bundle and runs the serverless API routes. Sees request metadata (URLs, headers, response codes) for operational logging but does not persist learner transcripts or mastery data. SOC 2 Type II certified.
Reads text, never audio. Scores each turn of a practice conversation against the tenant's rubric, reads a typed checkpoint answer, writes the short debrief a learner sees after a conversation from their own turns, and, for a live checkpoint round, reads that round's conversations together to describe what the room did. It receives the words of the conversation, the tenant's rubric and authored coaching, and no learner name, email or identifier. Per Anthropic's commercial terms, content sent through the API is not used to train Anthropic's models.
Delivers sign-in codes, invitations and the weekly practice report. Receives the recipient's email address and the message. Open tracking and link tracking are switched off, so no email reports back whether or when it was read. Nothing about a learner's practice is in any email except the aggregate figures a tenant administrator asked to receive.
When a learner chooses to sign in with a Microsoft or Google account, the sign-in happens on that provider's own page, from the learner's own browser. The provider tells us the verified email address and display name; we send the provider nothing about the learner's activity, and we request no access beyond that identity.
A tenant that connects its own public website to an Ask channel can ask for a review of that site's content. The review is run on an OpenAI model and receives the tenant's own public web pages, which are already public. It never receives learner data, conversations or scores.
For tenants that enable a module built on an external assessment (today, Everything DiSC® from Wiley), Make.com automates the provisioning: it passes the learner's name and email to the assessment provider and retrieves the location of the finished report. It receives no DriveState learner activity: no transcripts, no mastery scores, no session data.
Some tenants enable a module that draws on an external, professionally administered assessment. Today that is the Everything DiSC® profile from John Wiley & Sons. When a tenant uses it:
Coaching and reports show proficiency, never the conversation.What a learner said while they were still getting a skill wrong is not shown to their manager, their organization, or anyone else on the tenant's side. Every tenant-facing surface, the learner roster, the proficiency dashboards and the weekly team report, is built from mastery scores and per-turn evaluation states (the green / yellow / orange / red results), never from the words of the conversation. That boundary is what makes a practice space genuinely safe to be bad in.
Live checkpoint rounds are the one place a room hears about a conversation, and only in the aggregate.For a round a facilitator runs with a class, a model reads the round's conversations together and describes what the room did in paraphrase (“most of the room answered the price question with the sticker”). It is shown only once at least three people have finished, it never quotes anyone, it never says who did what, and anything fewer than three people did is not said at all. Each participant separately sees a short debrief of their own conversation, and nobody else sees it.
Tenant data is retained for as long as the tenant is active. On contract termination, all tenant rows can be deleted in cascade (sessions, turn events, mastery, content assets, content chunks, asset files), leaving no residual data in our systems. The deletion is idempotent and operates entirely within the tenant scope.
The words of a conversation are kept in two forms, with different lifetimes, and neither is ever shown to the tenant as text:
Improving the product with de-identified data.To find and fix errors in our software and coaching content and to raise quality, we may review, export, and retain conversation data with the learner's identity removed: no name, no email, no account or learner identifier, and nothing that links a conversation back to an individual person. De-identified data is used only for our own quality assurance and product improvement, is never shown to the tenant, is never re-associated with an individual, and is not used to train third-party AI models. A tenant that prefers its practice data be excluded from this entirely can request that in its data processing addendum.
Individual learner deletion (right-to-erasure) is supported at the application level: a learner's sessions, turn events, and mastery scores can be wiped in one call while preserving the tenant's aggregate analytics. Learner deletion is already an in-product action available to administrators.
Every use of a model in DriveState is listed here, with what the model sees:
A few choices are configurable rather than fixed:
Last updated: 2026-10-03. Questions or a request for a tenant-specific DPA? Email info@drivestate.ai. The Terms of Service are on their own page.