21 CFR Part 11 and GAMP 5 | Smart.Industrial Docs

Summary

The components provide the client-side parts of the 21 CFR Part 11 requirements. The system-side parts remain the responsibility of the application. Part 11 governs electronic records and electronic signatures: how they are created, protected, retained, retrieved, attributed and signed. Retention, access control, identity verification and the server-side copy of the audit trail are properties of the system and cannot be provided by a UI component. The components provide the signing dialog, the signature manifestation on a signed record, the audit entries a change produces, the hash chain that makes a copy of the trail tamper-evident, and the reviewer's view of the trail. These are listed below, clause by clause.

This page lists what the components provide for each clause so that every Part 11 reference in the documentation and demos can be checked. Using the components does not make an application compliant; the application is compliant when the system around the components meets the remaining requirements.

Where Part 11 is referenced in a Smart.Industrial screen, the reference describes the regulated system the screen is part of, not the components.

What the components provide

The signing dialog (§11.50, §11.200, §11.300(d)). smart-esignature shows the record being signed and its SHA-256 hash, asks for the meaning of the signature, the two components of a non-biometric signature (a user ID and a password), and a reason where the procedure requires one. It raises the signRequest event and waits for the application to check the credentials against its user directory and call accept() or reject(). The component does not verify or store the password; the field is cleared when the event is raised. Rejections are counted and the panel locks after maxAttempts; the application is informed and enforces the same limit on the server. With continuousSession enabled, a repeat signing by the same user within the timeout asks for the password only, as allowed by §11.200(a)(1)(ii). The first signing always requires both components.
The manifestation and the link to the record (§11.50, §11.70). The signature produced by the dialog contains the user ID and printed name of the signer, the meaning, the date and time with the UTC offset, the reason and the hash of the record at the time of signing. smart-signature-block displays it as a sentence, for example "Approved by Alice Smith, 2026-09-18 14:32:00 +03:00, Batch release", and, when the current record is provided, reports whether the record still matches the signature. Smart.Industrial.Audit.verifySignature() performs the same check without a component. The check uses a SHA-256 hash without a key: it shows that the record is the one that was signed, not who computed the hash (see §11.70 below).
Computer-generated, time-stamped, tamper-evident audit entries (§11.10(e)). Smart.Industrial.Audit.Trail stamps every entry in ISO 8601 with the UTC offset and millisecond precision, numbers it, keeps the previous value next to the new one, rejects an entry without a user or an action, freezes appended entries, and links each entry to the previous one with a SHA-256 hash. verify() reports whether a copy is the chain that was written and, if not, at which entry it differs. Entries removed from the end leave a shorter chain that still verifies; they are found only against an anchor kept outside the trail (the last hash and the entry count, passed to verify({ head, count }) or to the viewer's expectedHead and expectedCount). An entry given its own at keeps it, so for a computer-generated time stamp the application must not pass one. This is tamper evidence, not tamper proofing: it shows whether a copy matches what was written, but it cannot prevent a system with write access from rewriting the chain. The server-side copy is part of the system.
The reviewer's view and copies (§11.10(b), §11.10(e)). smart-audit-trail shows the user, the time, the action and both values; provides search and filters by user, action and time; verifies the chain and reports where it breaks; and exports the whole trail, including the hashes, as CSV or JSON. A JSON copy can be verified as it is; a CSV copy only after each value has been converted back to its original type, because the hashes cover the typed values. It cannot edit, delete or reorder entries.
Timestamp resolution. Smart.Utilities.DateTime stores microseconds and nanoseconds as separate fields instead of as a fraction of a millisecond, so a timestamp keeps its resolution when it is stored, sorted and printed. The sequence of events screen shows the effect: at millisecond resolution, thirteen of the fourteen events in a twelve-millisecond sequence share a timestamp and the order is lost.
Derived results. smart-sequence-editor holds limits as data (a range, or a nominal value with a tolerance) and computes pass or fail by comparing the measurement with the limit, or with the application's own limitEvaluator function where one is set. It does not accept a claimed pass or fail, so a reviewer can check the calculation; a measurement that cannot be judged is shown as not evaluated, never as a pass. A step without a limit is an action step and counts as passed once it has run.

The audit trail demo shows the complete path: a setpoint entered on smart-numeric-keypad and rejected outside its limits, signed with a reason on smart-esignature, appended to a Trail, displayed in smart-audit-trail, and a copy with one altered entry breaking the chain.

Clause by clause

Part 11 requirement	Provided?
§11.10(a) Validation of the system	No. Validation is of your system in your environment. The component test evidence below can be cited as supplier documentation; it is not a validation.
§11.10(b) Accurate and complete copies of records	Partial. `smart-audit-trail` exports the complete trail it holds, every field and every hash, in CSV and JSON, and `Trail.from()` re-verifies a JSON copy. The components hold no other records; a copy of a batch record is the system's to make.
§11.10(c) Record protection and retention	No. There is no storage layer. The hash chain makes a retained copy checkable; retaining it is the system's job.
§11.10(d) Limiting access to authorised individuals	No. There is no authentication anywhere in the line. `smart-esignature` collects the two components and hands them to the application; it does not verify them.
§11.10(e) Secure, computer-generated, time-stamped audit trails	Partial. `Smart.Industrial.Audit.Trail` generates entries with a time stamp and offset, sequence numbers, both values and a hash chain; `smart-audit-trail` displays them without obscuring previous values and verifies the chain. "Secure" is the system's: the entries have to be written where the operator cannot rewrite them, and the time stamp has to be the trail's own (an `at` passed by the caller is kept).
§11.10(f) Operational system checks / sequencing	Partial, presentational only. The sequence editor can enforce step order in what it displays and can stop on failure; it does not enforce anything about the process.
§11.10(g) Authority checks	No. Whether a verified user may sign with a given meaning is the application's decision in its `signRequest` handler; the demo shows an operator refused an approval. The component provides the place to refuse, not the rule.
§11.50 Signature manifestations	Yes, for what the components render. The signature carries printed name, date and time with offset, and meaning; `smart-signature-block` and `smart-audit-trail` show all three. Printouts are the system's.
§11.70 Signature/record linking	Partial, by hash. The signature carries the SHA-256 of the record as signed; `verifySignature()` and the block report a mismatch when the record changed. The hash has no key, so anyone who can write the record store can also produce a record, a signature object and a hash that match. Ensuring that a signature cannot be copied to another record undetected therefore needs a store the operator cannot write to, or a server-side signature over the hash; both are the system's, as is access control on the record store.
§11.100 General requirements (uniqueness, identity verification)	No. The organisation's.
§11.200(a) Two distinct components; first signing uses both; later signings in a continuous session may use one	Yes, in the ceremony. User ID and password; both on the first signing; password only for a repeat by the session user within `sessionTimeout` when `continuousSession` is on. What counts as a session is the application's to configure.
§11.200(a)(2)–(3) Used only by their genuine owners; collaboration of two or more people to falsify	No. The organisation's controls.
§11.300(a)–(c) Uniqueness, periodic revision and loss management of identification codes and passwords	No. The identity system's.
§11.300(d) Transaction safeguards against unauthorised use; reporting attempts	Partial. The panel counts refusals, locks at `maxAttempts` and raises `lockout`; the application is expected to lock the account and report. The panel locking is what the operator sees, not what protects the account.
§11.300(e) Device checks	No.

GAMP 5 categorisation

For a supplier assessment, Smart.Industrial is best treated as a GAMP 5 Category 1 infrastructure / Category 3 non-configured software component: a commercial off-the-shelf UI library used without modification. It becomes part of a Category 4 or 5 application depending on how much the application configures or adds around it. The library itself is not categorised software on its own.

Supplier evidence available for an assessment:

More than 1,300 automated specs for the Industrial components and modules, run in a real browser, with a documented baseline.
The engineering maths is tested against reference values: the Bluestein FFT against a direct DFT at n = 3, 5, 7, 12 and 100, the window gains against their published values, and the SPC constants against the published tables.
A WCAG 2.2 AA conformance report based on measurement, with a known limitations section.
An ISA-18.2 statement listing which alarm lifecycle stages are and are not addressed.
A per-component accessibility page. The source is kept under version control; the package itself contains minified files.

Not available: a formal supplier audit package, an IQ/OQ/PQ protocol set, a validation summary report, or a change control procedure that meets the GAMP 5 expectations for a Category 4 supplier. If an assessment requires these, the library does not currently provide them.