Every control on this page is one the software has today. Where something is planned rather than built, it is listed at the bottom under Not in place yet, not mixed in with what is.
Your records are never used to train AI models. We do not train any models. The AI features run on Anthropic's Claude API, and the excerpts we send it are covered by Anthropic's Commercial Terms of Service, which state in Section B:
“Anthropic may not train models on Customer Content from Services.”
When you draft a section, analyse a predicate, or ask a question, we send the relevant device details and excerpts of your own records and documents to Anthropic.
For the full list of who processes your data, see the privacy policy.
Every record carries a workspace identifier and every query is scoped to the workspace you are working in. Underneath that, PostgreSQL row-level security enforces the same boundary as a second, independent check. The database role the application connects as does not own the tables, so it cannot switch that check off. For a consultant, this is the guarantee that one client's records are not visible from another client's workspace.
We describe these as Part 11-ready records, not as a compliant system. Part 11 compliance also depends on validating the software for its intended use, and that validation package does not exist yet (see below). The clause-by-clause mapping shows where each requirement stands.
How the software answers each requirement of Part 11, what it does not cover yet, and what stays with you whatever software you use. The requirements are summarised in our words; read the regulation itself before relying on any line. This is our reading, not a compliance opinion: confirm it with your quality team or a qualified professional.
| Clause | What it asks | In the software | Not covered, or yours |
|---|---|---|---|
| 11.10(a) | Validated system; able to discern invalid or altered records | The audit trail is hash-chained, so an altered entry breaks the chain, and every verification record reports whether it held. | Not covered: no validation package (IQ/OQ/PQ) for this tool exists yet. Validating it for your intended use is your responsibility, and today we cannot hand you the evidence for it. |
| 11.10(b) | Accurate, complete copies, human-readable and electronic | PDFs per device (design history file, traceability matrix, verification record, classification rationale, substantial-equivalence comparison), a verification certificate per controlled document, and spreadsheets (QMS register, matrix, audit trail with its hashes). A workspace owner can export the whole workspace as one ZIP, with every uploaded file checked against its checksum, a readable index, and a workspace-wide audit trail. | Yours: keeping your copies. |
| 11.10(c) | Records protected and retrievable for the retention period | Versions are never overwritten, and the database refuses any edit or deletion of the audit trail. | Retention rules per record type, and legal holds that block deletion, obsoleting and unlinking until an owner releases them. Yours: your retention schedule, and disposal decisions. |
| 11.10(d) | Access limited to authorised individuals | Sign-in on every request; workspaces isolated twice, in queries and by database row-level security; owners invite and remove members. Outside reviewers get expiring, revocable, read-only links to one device, and every view is logged. | Not yet: two-factor sign-in. Yours: deciding who is given access. |
| 11.10(e) | Secure, computer-generated, time-stamped audit trail that doesn't obscure earlier entries | The server writes each audit entry with its own timestamp. The trail is append-only, enforced by the database, and hash-chained, and earlier versions of a record stay readable. | — |
| 11.10(f) | Operational checks on the permitted sequence of steps | AI drafts count as evidence only once verified; a signature aimed at a revision that changed since review is refused; the same signature can't be recorded twice. | Yours: any further sequence your procedures require. |
| 11.10(g) | Authority checks: only authorised people sign, alter or operate | 4 roles across 20 permissions, checked on the server for every request, including signing and verifying. | Yours: assigning roles that match people's responsibilities. |
| 11.10(h) | Device checks on the source of input, as appropriate | Requests must come from a signed-in session, and changes carry an anti-forgery check. | An owner can restrict a workspace to approved networks with an IP allow-list. Yours: whether you need it, and keeping the list current. |
| 11.10(i) | People who build, maintain or use the system are trained | Training records can be kept, and signed, in the app. | Yours: training your users. We do not yet supply documented evidence of our own team's training. |
| 11.10(j) | Written policies holding people accountable for their e-signatures | — | Yours. |
| 11.10(k) | Control over systems documentation | Every change to this software goes through a pull request and automated tests, and both are recorded. A second person’s approval isn’t required yet. | Not yet: a documentation package for customers. Yours: control of your own procedures (the documents module versions and signs them). |
| 11.30 | Extra controls for open systems | We treat a workspace as a closed system: its owner controls who has access. All traffic is encrypted in transit (HTTPS with HSTS). | Yours: whether your quality team classes a hosted service as open or closed. Signatures here are not cryptographic digital signatures. |
| 11.50 | Signatures show the printed name, date and time, and meaning | Each signature records the signer, when, and what it means (authored, reviewed or approved), and exports print them. | — |
| 11.70 | Signatures linked to their records so they can't be copied to another | Every signature belongs to one record. A document signature also carries a hash of the exact revision signed. | Partly: signatures on other records (design-history elements, design reviews, training) are tied to the record but not hash-bound to a revision. |
| 11.100(a) | Each e-signature unique to one person, never reassigned | One account per email address, and an account's email address can't be changed, so a signature can't pass to someone else. | Yours: forbidding shared logins. |
| 11.100(b) | Identity verified before a signature is assigned | — | Yours: we do not verify a person's identity. |
| 11.100(c) | Certification to FDA that e-signatures are legally binding | — | Yours: a one-time letter to FDA, before or when you first use electronic signatures. |
| 11.200(a) | Two distinct identification components; used only by their owner | Your password is re-entered for every signature. The user ID comes from your signed-in session rather than being typed again. | Yours: whether a signed-in session counts as the ID component is a judgement for your quality team, as is the policy that nobody shares a password. |
| 11.200(b) | Biometric signatures | Not used. | — |
| 11.300(a) | Each ID and password combination unique | One account per email address. | — |
| 11.300(b) | Passwords periodically checked or revised | Not enforced: passwords don't expire. | Yours: a policy requiring changes, if you want one. |
| 11.300(c) | Lost or compromised credentials deauthorised | Changing a password signs out every other session; an owner can remove a member at once; API tokens can be revoked. | Yours: the procedure for reporting a lost or compromised password. |
| 11.300(d) | Attempts at unauthorised use prevented, detected and reported | Wrong passwords are rate-limited at sign-in and locked out at signing. A wrong password at signing is written to your workspace's hash-chained audit trail: who, when, and what they tried to sign, never the password. | Not yet: failed sign-ins (as opposed to signing attempts) are recorded only in our application log. |
| 11.300(e) | Tokens and cards tested | No tokens or cards are used. | — |
What the AI is asked to do, what it is never asked to do, and where it can still be wrong.
Where it can be wrong. The AI can misread a document, miss a relevant record, or phrase something with more confidence than the evidence supports. We test predicate search against past FDA clearances, which is a best case, because the right answer is known to be in FDA's data. We do not publish an accuracy figure yet. Nothing here is regulatory advice: confirm pathway and predicate decisions with FDA or a qualified professional.
Listed so that nothing above is read as covering them.
If any of this matters to a decision you are making, email us. We would rather answer a hard question now than have you find the answer later.