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.
At a glance
Per-tenant database isolation enforced at the row level by Postgres RLS.
Database credentials never reach the browser; the privileged key is server-side only.
Learner and counterpart audio streams in real-time through Gemini Live and is not retained by Google for model training.
LiveAvatar receives text strings only: no audio, no learner identity, no PII.
Coaching and reports show proficiency, never the words of a practice conversation.
No third-party analytics SDKs. No advertising trackers. No cross-tenant access.
Tenant owns all data in their tenant. Deletion endpoints available on request.
Corporate deployments can be configured to store no learner email at all: the LMS or single sign-on provider holds learner identity.
1. Architecture & data flow
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 avatar's spoken text (and only the text) 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; an EU deployment is available for tenants with data residency requirements.
2. Tenant isolation
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.
3. Authentication & access
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.
The current demo environment is additionally protected by an access-code gate that an unauthenticated visitor cannot bypass: every backend API route is independently enforced server-side, not just in the UI. Production deployments integrate with the tenant's identity provider (SAML, OIDC, or SCORM-tunneled SSO) so only authorized employees can sign in.
4. What we store about a learner
The learner record itself is intentionally minimal:
A stable identifier, used only to recognize the same learner across devices. By default this is an email address; for a tenant whose learners arrive through their own LMS or single sign-on, it is the opaque identifier that system supplies at launch (an LMS user id or an SSO subject), and no email is collected or stored, so the LMS or identity provider remains the system of record for who the learner is.
A name and a role label the tenant defines (e.g. manager). A first and last name are collected only when a tenant's assessment integration needs them to match the learner on the provider's side.
A timestamp for when the learner first appeared.
If the tenant has enabled a module that uses an external assessment, a small set of derived data points for that learner (for the DiSC module: their style and a few derived values) plus a link to their own report file. See “Assessment integrations” below.
Per session, we store:
Start and end timestamps.
Each turn of the conversation — the learner's words and the counterpart's reply — together with that turn's evaluation (the per-concept green / yellow / orange / red state). These per-turn records are what the mastery score is computed from.
The running mastery score for each concept the learner has now exercised.
A full session transcript, kept briefly and only for diagnosis. How long each of these lives, and who can see them, is set out in “Reporting boundary, retention & deletion” below.
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.
5. What we do not store
Raw audio. Learner microphone audio and AI counterpart reply audio are streamed in real time; neither party retains the audio after the conversation ends. The transcript is retained; the audio is not.
Avatar inputs. LiveAvatar receives the AI counterpart's text only: no learner identity, no audio, no transcripts. The avatar has no record of who it was rendering for.
Biometric data. No facial recognition, no voiceprints, no behavioral biometrics.
Third-party trackers. No Google Analytics, no Mixpanel, no advertising pixels, no fingerprinting. The only browser storage we set is local convenience state on the learner's own device — their email and name so they don't retype it, and their microphone and playback preferences. None of it is an advertising identifier, none of it is shared with anyone, and none of it leaves the device except the email/name the learner already gave us.
6. Third-party processors
DriveState relies on a few external services, each receiving only the minimum data needed to do its job.
Google: Gemini Live (audio I/O) + Gemini Embeddings (retrieval)
Processes learner audio in real time and returns the AI counterpart's reply. Also embeds query text for content retrieval. Per Google's published Generative AI API terms, content sent through the API is not used to train or improve Google's foundation models. The Google API is the only AI provider in the live conversation loop.
HeyGen: LiveAvatar (video rendering)
Receives plain text (the AI counterpart's next utterance), renders the avatar speaking that text, and streams the video back. Receives no learner identity, no email, no transcript, and no audio. LiveAvatar is invoked only when the avatar is enabled; in audio-only mode it is never called at all.
Supabase: Postgres database + asset storage
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.
Vercel: application hosting
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.
Make.com: assessment provisioning (only when an assessment module is enabled)
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.
7. Assessment integrations (optional, per tenant)
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:
The learner completes the official assessment on the provider's own platform (Wiley's Everything DiSC / EPIC). DriveState does not administer or score it.
Assigning the assessment and retrieving the finished report is automated through Make.com (above); the learner's name and email are the only personal data passed to provision it.
For a tenant whose learners are identified by their LMS or single sign-on (so DriveState does not otherwise store an email), the email needed to provision the assessment is captured solely for that one request and is not retained; the learner is matched to their finished report by their opaque learner identifier, not by email.
DriveState stores the learner's own report file in its encrypted storage, shown back only to that learner, plus a small set of derived data points from it (for DiSC: the learner's style and a few derived values) used to personalize coaching.
The narrative text of a report is never placed into any AI prompt or model. Consistent with our agreement with the assessment provider, only the derived data points (for example, the style letter) inform the experience; the report itself is for the learner's own reading and is never sent to an AI provider.
8. Reporting boundary, retention & deletion
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, 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.
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:
Per-turn records (the learner's words for each turn, paired with that turn's evaluation) are retained for the life of the tenant, because the mastery score is computed and re-computed from them. They surface only as scores and colored states on tenant screens and reports, never as readable text.
The full session transcript (both sides, verbatim) auto-expires after a maximum of 90 days. It exists so we can diagnose a session that behaved unexpectedly. Deleting a learner or a tenant removes it immediately, ahead of expiry.
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.
9. Encryption
In transit: TLS 1.2 or higher between every component.
At rest: AES-256 on the Supabase Postgres database and the Supabase asset bucket.
Secrets: Live in Vercel and Supabase environment variables. Never in source code, never in version control, never sent to the browser.
10. How we use AI, specifically
The AI components in DriveState are all in the live conversation loop, never in the background:
The AI counterpart (Gemini Live). Generates the AI counterpart's speech in response to the learner. Each session starts fresh; there is no persistent state across learners, no memory between sessions.
The evaluator (a fast Google Gemini model). Scores the learner's most recent turn against the tenant's authored rubric. The prompt contains the rubric, retrieved authored coaching, and the turn itself; no other learners' data is ever in any prompt.
The coach (authored content + retrieval). Returns the tenant's own coaching language; the LLM is not asked to invent guidance, only to find the most relevant authored snippet.
No fine-tuning. We do not fine-tune any model on tenant data. The same base models serve every tenant; the difference is the per-tenant content the prompts are grounded in.
11. Open items, configurable per tenant
A few choices are configurable rather than fixed:
Audio retention: off by default; can be turned on per tenant if QA review is wanted.
Deployment region: US by default; EU available on request.
Data Processing Addendum (DPA) and custom retention SLAs available on request.
Learner identity source: an email for self-serve, or your LMS / single sign-on identity for corporate deployments, with a data-minimal mode that stores no learner email at all (the LMS or identity provider holds the learner's personal data).
SSO / SCORM / xAPI integration tailored to the tenant's LMS.
Last updated: 2026-07-23. Questions or a request for a tenant-specific DPA? Email terry@1010development.com.