User Requirements Specification — QMS Nordic

Generated from the platform's requirement register, not written by hand, and regenerated on every change. A build check fails if this document falls out of step with the code it describes, so it cannot quietly stop being true — which is what happens to a hand-maintained matrix within two releases.

---

These are the platform behaviours we specify and, where noted, verify. They use the same identifiers as customer template T2 — both documents are generated from one register, and a build check fails if an identifier exists in one and not the other. So a QA lead confirming URS-AUD-02 in their own document can look up exactly what evidence we hold for it.

Requirements marked customer testing required have no automated evidence from us. That is stated rather than omitted — see the traceability matrix (QMSN-TM-001) for the full picture and your resulting testing burden.

Document control

URS-DOC-01 — The general lifecycle — draft, revision, review, a second person's signature, effective, and back to draft on the next revision — is run in order through the real actions on a rebuilt database (added 2026-09-07). The reviewer's identity in that suite is proven by the demo-mode confirmation; the passkey assertion itself is URS-SIG-01. Your own approval route, with your own people and passkeys, is T4.

URS-DOC-02 — Reference formatting, the version increment on revision, and the retention of every superseded version's content are covered by automated tests on a rebuilt database (retention evidence added 2026-09-07). Confirm your own documents' identifiers and version history in T4.

URS-DOC-03 — Enforced in the action from v1.3.0, and tested. Before that release the rule lived only in the interface — the button is rendered for approved documents, but the action behind it accepted any status — so a form post could take a draft straight to effective. If you validated a release before v1.3.0 and relied on this behaviour, see the release record.

URS-DOC-04 — A superseded document is marked obsolete, linked to what replaced it, and cannot return to effective. Note the scope: automatic retirement applies to single-instance types — quality policy and quality manual — where one effective document per scope is the rule. For SOPs and the rest, retiring the predecessor is a step in your own process, and it is what T4 should exercise.

URS-DOC-05 — A document with a review schedule is surfaced to its owner and to the QA administrators from 30 days before the review date, daily thereafter but not more than once a week, and as urgent once the date has passed. The rules are tested without a database; the daily job that applies them is exercised end to end on the CI database. Until 2026-09-05 this requirement carried no evidence — the behaviour had existed since the data model, the tests had not.

Record integrity

URS-AUD-01 — Audit writing is covered for the AI drafting path. Coverage across all modules is not automated — spot-check the modules you rely on.

URS-AUD-02 — Exercised, not merely asserted to exist: the test runs as the application's own database role and confirms both an UPDATE and a DELETE are refused. A role carrying BYPASSRLS — the migration owner — is outside what a trigger can stop; that case is covered by URS-AUD-03, which detects rather than prevents. A trail that cannot be altered also cannot be redacted, so what goes into it is a decision that cannot be revisited: every audit call in the application is scanned, and one writing an email address fails the build. Each such case found was redundant — the row already names the invitation, ticket, user or grant whose own record holds the address and can be redacted — and the domain is kept where it was useful, because it identifies nobody. The scan reads the values rather than the field names, having missed half the cases when it read the names, and expands shorthand properties, having walked past one written that way. The same scan refuses a live credential: the access token for a technical documentation pack was hashed in its own table and the original kept in the audit row beside it, which is the hashing undone — that row outlives the token's revocation, ignores the expiry date printed next to it, and leaves in every CSV export of the trail. Nothing in the trail is now a key to anything. Reading the source can only ever catch what the source says, so the recorder checks the values themselves a moment before writing: an address typed into a reviewer's rationale or a comment reaches the trail at run time, in a string no parser could look inside. Outside production that write is refused outright; in production it is written with the offending value replaced and the incident reported, because a missing audit row is a gap in evidence that no later fix can fill and is worse than an imperfect one.

URS-AUD-03 — The test alters an audit row as the owner role — the one party a trigger cannot stop — and confirms an independent recomputation of the hash no longer matches. The claim is not that a record cannot be changed, but that a change cannot be hidden.

URS-AUD-04 — The trail exports as CSV carrying every field including hash and prevHash, so the chain can be verified outside the platform. Two limits worth knowing: the export is capped at 50,000 events, which is above any current tenant but is a ceiling rather than a guarantee of completeness under Part 11 §11.10(b); and it is a whole-trail export, not a filtered one, so producing the events for a single record means filtering the file yourself.

Electronic signature

URS-SIG-01 — Covered as a gate, on both ways of signing a document — direct approval and each step of an approval route: a signature cannot be produced without a live SIGN challenge issued to this user, and the action refuses to sign at all once a passkey is enrolled. The cryptographic verification itself is @simplewebauthn's, and we do not re-test it — forging a valid assertion to prove the happy path would only prove we can forge one. Note also that §11.200(a) sets a two-component test for non-biometric signatures and §11.200(b) a different bar for biometric ones; a passkey with user verification is not squarely either, and FDA has published no position. Decide which limb you are relying on and record the reasoning.

URS-SIG-04 — An edit produces a new version and returns the document to draft, so a signature cannot carry silently onto text it did not approve; the version that was signed stays retrievable; and from v1.2.0 the signature itself records which version it released, so the link can be read without joining to the audit trail. Signatures recorded before v1.2.0 carry no version where the audit trail did not supply one — that is shown as absent rather than filled in, because inventing a version number on a signature record would be worse than declaring the gap.

Access control

URS-ACC-01 — The permission matrix is asserted role by role, the action is shown to consult it rather than merely the interface, and a refused attempt is shown to be audited. What remains yours: which of your people hold which role.

URS-ACC-04 — This is a customer process requirement, not a platform one. The platform removes access when told to; knowing when to tell it is your joiner/leaver process. Most commonly found gap under this clause — test it.

Retention and availability

URS-RET-01 — Every version's content stays retrievable, and retiring a document deletes neither its versions nor the signatures on it. What is still absent is a retention period: the platform does not delete records, but neither does it enforce or track how long you have undertaken to keep them. That undertaking, and evidence that nothing in your own configuration removes records before it expires, remains yours.

URS-RET-02 — Documents and the audit trail export to CSV without our involvement, and each export is itself audited. Not covered: there is no single whole-tenant export — you export per entity — and document content leaves as Word or Markdown from the document itself rather than in the CSV. Export what you would actually need in an inspection and confirm it is complete and readable outside the platform.

URS-RET-03 — Witnessed restore, 2026-08-28. A point-in-time copy of production was restored to a separate branch and verified: all 4,006 audit records rehashed to their contents, all reachable from the start of their chain, and row-level security and tenant isolation present on the copy — a scoped read returned 31 of 547 documents. The application was then run against the restored copy and signed into. Measured recovery time 45 minutes, from deciding to restore to the system being usable, against our stated four-hour recovery commitment. One finding is recorded in the report rather than omitted: 67 places where two audit rows share a predecessor, from batched writes between 23 May and 22 June 2026 — records unaltered and none missing, but at those points the chain alone does not prove nothing was removed. That finding stood against data which no longer exists: on 2026-09-09, before the first customer, the audit chain was restarted from empty and every tenant on the platform was demo or test data. The advisory lock that caused those shared predecessors was fixed in migration 20260427300000; the rows that predated the fix are gone, and the chain running today began after it. The rehearsal itself is unaffected — it evidenced a restore capability on a day, and that day happened. Rehearsed annually; next due 2026-08-28 + 12 months. The restore window itself was confirmed on 2026-09-09 and is 7 days: the platform moved off the provider's free tier, whose 6-hour history could not have supported the recovery the published security overview describes. Beyond seven days there is no restore point, which bounds what this requirement can claim — a fault introduced more than a week before it is noticed is not recoverable by this route.

AI-assisted drafting

URS-AI-01 — Art. 50 addresses disclosure of AI-generated content to people who encounter it; an internal SOP draft reviewed and approved by your own staff may fall outside it. Cited because provenance is recorded either way.

URS-AI-02 — The platform now refuses to make any document effective without an approval record, so an unreviewed AI draft cannot reach effective status. Stated plainly, because this file said otherwise until v1.3.0: that guarantee did not previously exist. The claim was that approval was required; the check was in the interface only. Whether your own process then permits an approver to sign an AI draft without reading it is still yours to control, and AI output remains non-deterministic and unvalidated — so this is still worth testing in your context.

URS-AI-03 — Fixed in v1.0.0. Documents drafted before that release may be incomplete — see the platform release record (QMSN-CL-001).

URS-AI-04 — Fixed in v1.0.0. Before that release a busy provider silently substituted a template.

Change control

URS-CHG-01 — Type checking and linting block on every change, in CI and in the build itself. Until 2026-09-09 the build suppressed both, to live with 145 type errors across 39 files that the release record disclosed; those errors are gone and the suppressions with them, so a deploy that skipped the pipeline can no longer ship a type error either. Code-owner review is configured but branch protection is not enforced — that needs a paid GitHub plan on a private repository, and the rule is published as procedural rather than technical until it is.