How Twinbook Safely Processes Dense Learning Content

Twinbook Trust & Engineering series · ~6 min read

A medical textbook chapter is not a tweet. Turning hundreds of pages of dense slides and PDFs into structured, queryable, personalized study material is a real problem — and doing it safely, without leaking data between learners or exposing the work to the open internet, matters just as much as doing it well.

This post explains, at a level that respects both your trust and our security, how Twinbook processes that content: what has to be true before anything is touched, what the AI providers ever see, and the lines we won't cross with your data. We deliberately keep the deeper architecture out of a public post — the detailed version is available under NDA as part of a security review.

Everything starts with authentication

Nothing gets processed anonymously. When you upload a PDF, slide deck, image, note, or video, the request is authenticated and authorized first: you have to be signed in, and you have to have access to the workspace you're adding to. Uploads are size- and type-checked, and stored in private file storage — never a public bucket or an open link.

Your data is scoped to you and your workspace

Twinbook is built around hard isolation. Your content and learning data are scoped by user and by workspace, and that scoping is enforced on every request that touches protected data — not just at the edge, but where the data actually lives. One learner can't read or modify another learner's spaces, content, members, or learning memory. We've verified this against direct cross-account access attempts rather than assuming it.

The heavy processing happens in services the internet can't reach

The expensive, sensitive work — understanding documents, generating study materials, building your learning memory — runs in internal processing services that are not publicly accessible. They don't accept anonymous requests; work flows to them only through authenticated, service-to-service authorization and verified internal job processing. The practical effect: there's no open AI endpoint for an outsider to point at, and no way to inject work or siphon processing without a valid, attributable internal identity.

What AI providers actually see

Twinbook uses AI providers for specific tasks — understanding documents, generating study material, creating embedding models for retrieval, and answering questions. For each task we send only the content that task needs (a page to read, the relevant passage and your question to answer, a concept to embed) — never your whole library, and never advertising identifiers.

And the hard line on training:

Twinbook does not train or fine-tune models on user-uploaded content, learner data, private notes, conversations, learning memory, or institutional education records. We may develop or fine-tune models using Twinbook-owned, licensed, public, or synthetic data to improve quality — never your content. We select AI providers under terms where submitted content is not used to train their foundation models.

The providers we use, their purpose, and their regions are listed on our Subprocessors page.

Answers stay grounded in your own materials

When the Space Assistant answers a question, it uses grounded retrieval over your own materials — pulling the relevant passages and citing them — rather than free-associating. This is both a quality choice (better answers, fewer hallucinations) and a safety one: a grounded, cited answer over a bounded set of your content is far harder to hijack with instructions hidden inside an uploaded file than an ungrounded completion would be.

Outputs are validated before you ever see them

Generated study materials are validated against the structure we expect before they're used, so malformed or off-task generations are caught rather than shown. Anything rendered or exported is sanitized (no scripts, no embedded frames), and document export runs in a hardened, locked-down environment. There's more on this in Our Approach to AI Safety in Education.

Deletion is real

Delete a document, a space, or your account, and Twinbook removes the associated content from its database, document store, and file storage, with relationships configured so nothing is left orphaned. Financial records are retained where law requires. The full schedule is on the Data retention & deletion page.

For security reviewers and partners

This is the public version. If you're evaluating Twinbook — a university, a creator, an author, or any institution — and your security team needs the detailed architecture (service topology, authentication mechanics, data-flow diagrams, and our internal security-review and verification results), we share that under NDA as part of an active review. See our University readiness roadmap, or get in touch.


More: Trust & Security · Our Approach to AI Safety in Education · What Is Learning Memory — and How Students Control It.