Privacy, in plain English.
What we collect, what we do with it, and what we will never do — written for buyers and their counsel, not for hiding things in.
What we collect
We collect the data needed to operate the services you choose to use:
- Account and application details — your name, email, organization, and role when you create an account, request a cohort seat, or submit an inquiry.
- Practitioner applications — your name and email, current-practice narrative, selected disciplines, links you provide, preferred engagement, and reason for applying. We also keep the application's workflow status, internal review notes, and append-only decision history.
- Learning progress — node completion and current state, cohort enrollment state, saved adaptive-path revisions, artifacts, reviews, and credentials. If an artifact review is interrupted, its durable command retains body-free request identity while it is reserved, reviewing, or recovering. Only after an automated review is checkpointed does that command retain the submitted body and review until the same request completes, is abandoned, or the account is deleted, so recovery does not create duplicate evidence. Abandoning stops recovery and clears any retained submission and checkpoint; it cannot stop or undo a provider call that already started and does not alter completed Portfolio evidence.
- Assessment data — signed-in runs store your capability profile and path, five profile answers, fifteen criterion scores with deterministic score labels, and each exercise's character and word counts plus an account-scoped cryptographic digest. Exercise text and model-authored assessment notes or summaries are processed but not retained.
- Organization operations — for memberships already on record, we store the tenant membership, whether the account is a facilitator or participant, the participant's revocable aggregate-sharing choice, and attributable provisioning, export, and consent events. Email-based roster attachment is disabled until an expiring invitation can be accepted by the signed-in participant; the organization console does not use uploaded addresses to look up or bind accounts.
- Capability Foundry governance — when an authorized administrator drafts or preregisters a Foundry cycle, we retain the frozen package and protocol documents, the administrator's account identifier, opaque command identifiers, timestamps, and a hash-linked event record. When an administrator records pilot consent or reviewer coverage, we retain only an opaque participant code or roster reference, the SHA-256 digest of the signed document, its stated retention scope, and the same attributable event chain; the signed documents themselves, and any name or contact detail in them, stay with the operator off-platform. When an administrator records pilot measurement — an observation, an independent rating, an adjudication, or a close-out outcome — we retain only the opaque participant code, the pre-registered measure identity, the roster reference of the rater or adjudicator, a 0-4 integer score, whether dissent was preserved, ledger-derived counts, SHA-256 digests of the off-platform submission packet and review documents, and the same attributable event chain; no submission content, learner prose, or reviewer prose can enter these records by construction, and a lone rating's score is withheld from every read surface until both independent ratings exist. The schema creates no record by itself.
- Governed FDE capstone review — the dormant BME-10 schema defines how a later review version would bind an exact private practice artifact, receipt, instrument, evidence manifest, revision lineage, reviewer authorization, assignment, dimension rating, adjudication, and appeal to SHA-256 digests and attributable hash-linked events. Rating and decision rows can contain only 0–4 integer dimension values, approved evidence-anchor identifiers, dispositions, document digests, opaque reviewer references, actor account identifiers, and timestamps; they cannot contain learner or reviewer prose. A lone rating would be withheld until the independent pair is complete. The initial instrument has no reliability threshold, appeal window, retention window, pinned evidence issuer, or database-verifiable issuance attestation, so activation, runtime case mutation, and public claims remain disabled. The migrations create zero programs, reviewers, specimens, cases, ratings, decisions, or outcomes.
- Artifacts you submit — prompts, specs, agent configurations, and project work you upload for review and certification.
- Community records — posts and replies under your account handle, linked artifact references, reports you submit with their reason and optional details, and the actions taken on reported content. We also retain moderation decisions and account-level community suspension or reinstatement records so actions can be reviewed and explained.
- Checkout preview details — contact information, requested cohort and seat count, and a mock order reference. No tuition price or charged amount is quoted or recorded; the preview stores zero in its required total field because tuition is not published. This checkout is a product preview. Payments and paid enrollment are not live. No card is collected or charged, and a preview confirmation is not a purchase or paid enrollment.
- First-party activity events — the closed server-side vocabulary records assessment started, assessment completed, account created, seat requested, and artifact submitted, with bounded category metadata such as the scoring path. Events contain no prompt, exercise, or result text, IP address, user agent, referrer, or page URL. The random guest cookie expires after seven days and is cleared at signup. Its matching server-side bridge can remain in event rows until account deletion severs it or an operator performs the documented 180-day cleanup; that cleanup is not yet automatic.
What we do with it
- Run the platform — track your progress, maintain your evidence portfolio, and operate cohort or session records only when those services are activated.
- Review your artifacts — submitted work can be evaluated against an authored rubric. Human expert spot-checks and credential defense activate only when vetted roster coverage is in place.
- Review practitioner applications — assess fit for a stated engagement, document the decision, and contact applicants about next steps.
- Operate and safeguard the community — deliver member content, investigate reports, enforce the community rules, document moderation decisions, and restrict community access when needed.
- Improve the curriculum — we can study aggregate product patterns, such as where lessons create repeated difficulty. Cohort patterns exist only after a real cohort runs. Aggregates, not your individual work.
- Operate an organization program — facilitators can see roster identity, membership role, whether a current baseline or comparable reassessment exists, and each member's preference state. Individual assessment scores, levels, responses, exercise text, and named evidence counts are not exposed. One revocable preference covers the latest current-instrument dimension scores and scorer provenance plus completed-node, verified-artifact, and active-credential counts. No aggregate outcome is published in this release at any roster size; fixed cohort snapshots and reporting windows must prevent longitudinal differencing before activation, and any future release must still require at least five consenting contributors.
- Govern the capability standard — preserve who drafted or preregistered an operating protocol, the exact frozen content, and its append-only event chain. A runtime Foundry record is an internal governance record; it does not by itself change the public standard or establish ratification, calibration, learner outcomes, or effectiveness.
- Govern a future FDE practice review — the dormant, runtime-read-only schema defines the exact authored instrument, private evidence binding, reviewer authority, blind ratings, adjudication, revision, and appeal provenance a later version must preserve. These internal records do not create graph progress, role proof, a credential, employment readiness, a hiring recommendation, or a public effectiveness claim.
- Communicate with you — cohort logistics, schedule changes, and platform updates. Marketing email only if you opt in.
What we never do
- Sell your data, or share it with advertisers. There is no advertising on the platform.
- Train third-party models on your artifacts without your explicit consent.
- Publish or showcase your artifacts outside the platform without your permission.
- Give an organization facilitator your individual assessment score, level, response, exercise text, or named evidence count through the organization console. The future aggregate preference is off by default and can be revoked from your workspace; no aggregate outcome is published in this release.
- Attach your account to an organization from an uploaded email address. Participant membership requires a signed-in acceptance flow; that claim flow is not active yet.
- Deliberately ask for unrelated personal data. Each field we collect must support the service, its safety, or an application you submit.
Model providers
When a configured live provider is available, prompt review, assessment, practice exercise, mentor, or artifact-review content may be processed under that provider's API terms. Scripted and offline fallbacks are labeled; they do not call a provider and cannot impersonate a verifying model result. We do not retain prompt-review input or result text, assessment exercise text, or model-authored assessment notes and summaries. Where providers offer API terms that exclude training on customer data, we choose them.
Before a paid provider attempt, a shared execution-control ledger records only HMAC-derived account, network, operation, provider, and request references; fixed-window counters; conservative input-byte and output-token reservations; provider-start state; and timestamps. It never stores prompts, submitted work, provider output, scores, email, raw account or network identifiers, credentials, or provider error bodies. These reservations are capacity and safety records, not billing or exact token-usage records.
The platform is not designed for PHI or otherwise regulated data, and by default you should not paste it in. The healthcare track runs entirely on synthetic and mock data. If your organization needs regulated-data workflows, that is an enterprise conversation — contact us before you upload anything.
Retention and deletion
We keep account and progress data while your account is active. Assessment evidence — the five profile answers, fifteen criterion scores with deterministic labels, and exercise lengths and digests — can be erased directly from the signed-in workspace. Erasing it also clears stored assessment prose and leaves the placement record — level, track, six numeric dimension scores, and selected module path — plus a durable technical marker that prevents later writes from recreating erased detail. For historical erasures, the marker's recorded time can reflect the migration that established this protection rather than the original request time.
Artifacts tied to an issued credential or human expert review are routed to verified manual disposition so a public verification or human decision is not silently broken. Other uncredentialed, non-expert-reviewed artifacts can be removed with eligible learner self-deletion. Community posts, replies, reports, and suspension records are retained with the related account and content unless they are deleted after a verified request; moderators can also restrict content visibility. If an account or its content is deleted, those linked records are removed from the primary store. An append-only moderation ledger can remain so we can preserve an accountable decision history; it contains opaque record identifiers, status changes, selected reasons, and moderator-entered notes. We review that ledger when handling deletion requests and explain any safety or accountability record that must be retained.
Practitioner applications and their decision history are retained while we evaluate and operate the practitioner network. The checkout preview may retain a mock order record, but it is not a payment record. Once payments activate, transaction records will be kept as long as tax and accounting rules require.
Organization membership and consent records are retained while the organization program is active. Organization audit events retain actor and subject account identifiers, the operation, counts or state changes, and time; they do not retain assessment content. No aggregate outcome is published in this release. Revoking the future aggregate preference keeps your assessment dimensions, scorer provenance, completed-node count, verified-artifact count, and active-credential count outside any later privacy-protected report unless you opt in again.
Foundry cycle and event rows are immutable governance history. They can retain administrator account identifiers, opaque command identifiers, content and event digests, state changes, and timestamps; they contain no participant submission in the initial control plane. An account linked to that history is routed to assisted export or deletion review so attribution is not silently broken. Where policy permits retention, the governance record can remain with opaque attribution after disposition.
Governed FDE-review records are also immutable accountability history. They can retain learner, administrator, expert-reviewer, adjudicator, and appeal-resolver account links; opaque reviewer references; authorization, assignment, score, disposition, and appeal metadata; approved evidence-anchor identifiers; document and content digests; state changes; and timestamps. The learner's authored work remains in the private artifact rather than being copied into review rows. Until a reviewed retention policy is activated, every linked account is routed to assisted export or deletion review and no self-service deletion claims that this history was universally erased.
An external provider credential record is a private learner-owned claim, separate from a LockedIn credential. It stores the selected catalog offering and issuer snapshot, the identifier and public issuer-record URL entered by the learner, issue and expiry details, claim versions and digests, and a bounded issuer-check history. Public-record review can confirm issuer provenance and standing, but it does not prove that the account holder controls the issuer record, satisfy a capability gate, issue FDE-P, or create talent visibility. The account extract includes the claim and a safe verification projection; it excludes raw issuer responses, verifier access, and administrator identity. Eligible self-deletion removes the local claim and history without revoking the provider's record.
A human mentor escalation is a private asynchronous support case created explicitly by the learner. It stores the learner-edited subject and summary, bounded learner-visible replies, cohort and optional owned-artifact context, state changes, assignment and operational audit references, and timestamps. It does not copy the AI mentor conversation, and it cannot change progress, artifact review, credentials, qualification, organization reporting, or talent visibility. The portable account extract includes the learner-visible case history while excluding queue-owner, assignee, and actor identities plus internal command identifiers and digests. Eligible learner self-deletion removes these cases with the account.
A signed-in member with a password can download a versioned portable extract of the account and learning records exposed through Data controls. The extract is scoped to the signed-in account and includes session reservations, private external-provider claims with safe issuer-check provenance, learner-visible human-support cases, body-free continuity metadata for pre-checkpoint and abandoned artifact reviews, and the body plus automated checkpoint for a reviewed command waiting to finalize. Completed submission commands are omitted because the finished artifact and review already appear in the ordinary evidence history. It also includes the learner's governed FDE-review attempt and revision lineage, content digests, terminal adjudication or appeal-decision dimensions and disposition, or a nonterminal revision-directive digest and timestamp, plus the learner's own appeal digest and filing time. It excludes password and session credentials, internal security material, artifact-submission digests, lease capabilities, provider-start and retry metadata, raw issuer responses, verifier and support-staff identities, other people's records, separately submitted email-only records such as an unlinked practitioner application, waitlist entry, or enterprise inquiry, and internal lifecycle or governance markers such as the assessment-erasure marker timestamp, Foundry commands, governed-review reviewer identities, assignments, raw blind ratings, authorization and calibration records, command identifiers, actor identifiers, and event hashes. Excluded records remain available through the assisted verified-request process below.
The portable extract and self-service deletion do not directly enumerate or mutate the separate execution-control store. Ordinary reservation receipts are removed lazily when that partition is next written after its bounded replay grace. Conditioned practice-attempt claims retain replay authority until their recorded retention boundary, which is at least 31 days after completion, but the claim Blob currently persists until an authorized manual deletion; the store does not promise automatic physical deletion at day 31. A verified assisted request includes these HMAC-linked safety records in the retention review, but the application has no automated provider-store purge. We explain any retained record and perform an exact authorized deletion only when it can be safely targeted; until then an opaque record can remain after primary-account deletion under this disclosed operational boundary.
A password-backed learner account with no credential, human-expert-review, payment-retention, organization-accountability, Foundry-governance, governed FDE-review, community-safety, or other review-required relationship can also delete its primary linked data from Data controls after current-password confirmation. Incomplete artifact-submission commands are removed with that account and never create a separate deletion blocker. The operation is deliberately fail-closed: privileged, passwordless, credentialed or expert-reviewed, paid or retained, organization-linked, Foundry-linked, governed-review-linked, and community-linked cases move to verified manual review before anything is changed. Deidentified activity counts and the opaque accountability ledgers described above can remain when their retention is required and disclosed.
For an assisted export or deletion, records outside the account-linked runtime store, or an explanation of a retained safety, accounting, or legal record, email legal@lockedinlabs.ai. We respond to verified requests within 30 days.
Contact
Questions, requests, or a data-processing discussion for an enterprise agreement: legal@lockedinlabs.ai.
This page is informational and does not constitute legal advice.