Supported 18 Partially supported 34 Not supported 27 Customer responsibility 13 — 92 clause verdicts in total
Compliance Matrix
AAA-RNS — regulatory position, clause by clause
This page exists because the product's own thesis is that a claim without evidence cannot be recorded. Applying that rule to ourselves means publishing what AAA-RNS does not do as carefully as what it does. The word "compliant" does not appear as a verdict anywhere on this page, and never will. Compliance is a property of a validated, configured, documented and operated system inside your organisation. It is not a property of software, and no vendor can sell it to you.
Scope of this assessment. AAA-RNS is a local browser application. server.py binds to localhost only. There are no accounts, no cloud, no telemetry. The Content-Security-Policy is connect-src 'self', with one exception: three AI endpoints (Anthropic, Google, OpenAI), reachable only when the user explicitly opts in, off by default, and never required for any gate, seal, signature or verification. Team use is a company shared folder reached through the browser File System Access API. The source is published under Apache-2.0.
Not legal or regulatory advice. This is a supplier's self-assessment offered so that your QA, RDM or 연구관리 function can start its own review from a truthful baseline rather than from marketing copy.
How to read the verdicts
| Verdict | Meaning |
|---|---|
| Supported | The application does this itself, deterministically, and leaves an artefact you can inspect or recompute. |
| Partially supported | A real mechanism exists but does not reach the full requirement of the clause; the shortfall is named in the evidence column. |
| Not supported | There is no mechanism. Buying this product does not move you toward this clause. |
| Customer responsibility | The clause governs your procedures, your infrastructure or your organisation. Software cannot satisfy it, and we will not pretend the purchase does. |
Five structural facts that drive most of the verdicts
- There is, by default, exactly one identification component. A self-registered name and e-mail, plus a PIN stored as a salted PBKDF2-SHA256 hash (210,000 iterations; pre-v2.1.0 unsalted hashes are upgraded in place on the next successful entry). Since v2.1.0 every signature also carries a per-user device key (ECDSA P-256, non-extractable, held in the browser's IndexedDB) and can carry an optional passkey (WebAuthn); both are locked under the seal hash. What none of this is: a certificate, or a federated identity — no third party vouches for who holds the key.
- Time defaults to the client machine's clock. Since v2.1.0 an administrator can enable opt-in RFC-3161 timestamping: at sealing, the 32-byte seal hash — never content — is sent to a TSA and the signed token is stored beside the seal, verifiable offline with
openssl ts -verify. It is off by default, degrades silently to the local clock when offline, and the shipped default TSA (FreeTSA) is not an accredited authority. - Integrity is strong and honestly bounded. A sealed note's SHA-256 covers both the content and the signatures (
seal_algo: v2) and chains to the previous sealed note; verification recomputes the signature digest from the actual signatures rather than trusting a stored field. This makes alteration detectable. It does not make it impossible. - There is no access control in the application. The PIN is a confirmation prompt, not an authorisation boundary. Real access control is the OS permission set on the shared folder, and it is yours.
- There is no validation package. No URS, FS or DS. No IQ, OQ or PQ. No traceability matrix. No validation summary report. Every clause that begins "the system shall be validated" is unmet at the supplier level.
1. US FDA — 21 CFR Part 11
The framing, stated plainly
The industry distinction is that a piece of software may be **Part 11-capable — it provides the technical controls the rule requires — while only a configured, validated, operated system, inside an organisation with the procedures Part 11 also demands, can be Part 11-*compliant***. That distinction is real, and it is routinely abused: vendors claim "capability" to imply "compliance."
We do not claim Part 11 capability either. As shipped by default, AAA-RNS employs one identification component. A second component exists since v2.1.0 — a WebAuthn passkey that can be required at signing — but it is optional and unenforced, so § 11.200(a)(1) is at best partially met and Subpart C as a whole remains unmet. Everything below follows from that.
Note also that FDA's 2003 guidance Part 11, Electronic Records; Electronic Signatures — Scope and Application narrowed the rule's application and announced enforcement discretion for parts of it. That guidance changes what your inspector is likely to press on; it does not change what the regulation says, and this matrix assesses against the regulation.
§ 11.10 — Controls for closed systems
Whether your installation is a closed system at all is your determination, not ours: § 11.3(b)(4) defines it as "An environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system." Because access control here is the OS permission set on a shared folder, that condition is satisfied or defeated by your IT configuration. If the environment is open, § 11.30 additionally requires measures such as document encryption and appropriate digital signature standards — Not supported.
| Clause | Requirement | Verdict | Evidence / explanation |
|---|---|---|---|
| § 11.10(a) | Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records | Not supported | The "discern altered records" half is met by the seal_algo: v2 hash chain, but no validation lifecycle evidence of any kind is supplied, so the clause as a whole is unmet at the supplier level and the entire validation burden falls on you. |
| § 11.10(b) | Ability to generate accurate and complete copies in both human readable and electronic form | Partially supported | The electronic half is strong — a full ZIP backup with a per-file SHA-256 manifest, and a restore that writes nothing unless every file verifies — while the human-readable half is whatever the browser renders and prints, which we do not warrant as a validated rendition. |
| § 11.10(c) | Protection of records to enable accurate and ready retrieval throughout the retention period | Customer responsibility | Records are plain files in a folder you own; the chain and manifest let you detect loss or alteration, but retention, media management and archival survival are entirely yours. |
| § 11.10(d) | Limiting system access to authorized individuals | Not supported | The PIN is a client-side confirmation prompt, not an access boundary — anyone with read access to the shared folder can read every record without ever meeting the PIN. |
| § 11.10(e) | Secure, computer-generated, time-stamped audit trails independently recording date and time of operator entries and actions that create, modify or delete records; changes must not obscure previously recorded information | Partially supported | The append-only log covers gate verdicts, signatures, sealing, backup, restore and role transfers, and nothing overwrites prior information (revisions are additive, -R1, -R2 …), but the audit-log timestamps are the client clock (opt-in RFC-3161 attests the seal events only, not log entries), the log is a file an OS-level user can reach, and pre-seal draft editing is deliberately not trailed. |
| § 11.10(f) | Operational system checks to enforce permitted sequencing of steps and events | Supported | Four deterministic gates (G1 evidence mapping, G2 longitudinal consistency, G3 numeric/unit audit, G4 required fields and attached originals) run before sealing, a note with outstanding findings cannot be sealed, and the two-person rule enforces author-then-different-reviewer ordering. |
| § 11.10(g) | Authority checks so that only authorized individuals can use the system, sign, access, or alter a record | Partially supported | Cross-approval is genuinely enforced — the author cannot approve their own note — and the PIN is re-prompted before destructive actions, but the enforcement is client-side JavaScript in an Apache-2.0 codebase that anyone who can edit the source can remove. |
| § 11.10(h) | Device checks to determine validity of the source of data input | Partially supported | Since v2.1.0 each signature is bound to a per-user device key that never leaves the machine it was created on, so a signature does identify a device-held key; there is still no check on the validity of data-input sources (instruments, terminals), which is the larger half of this clause. |
| § 11.10(i) | Determination that persons who develop, maintain or use the system have the education, training and experience | Customer responsibility | This is a personnel qualification record your organisation keeps; the product neither holds nor checks training status. |
| § 11.10(j) | Written policies holding individuals accountable for actions under their electronic signatures | Customer responsibility | The product cannot create your policy; without one, the signatures here carry only whatever weight your institution has agreed to give them. |
| § 11.10(k) | Controls over systems documentation, including distribution control and revision/change control with a time-sequenced audit trail | Partially supported | Publishing the source with public version history gives time-sequenced visibility of modification, but there is no controlled distribution, no documented change-control procedure and no supplier quality system behind it. |
§ 11.50, § 11.70 — Signature manifestation and linking
| Clause | Requirement | Verdict | Evidence / explanation |
|---|---|---|---|
| § 11.50(a)(1) | Printed name of the signer | Supported | The signer's self-registered name is recorded with the signature and is inside the sealed hash. |
| § 11.50(a)(2) | Date and time the signature was executed | Partially supported | The time is recorded and bound into the seal digest so it cannot be altered afterwards undetected, but its source is the client clock. With opt-in RFC-3161 enabled the seal time is attested by a TSA token; the signature-execution times themselves remain self-asserted, and the option is off by default. |
| § 11.50(a)(3) | The meaning associated with the signature (review, approval, responsibility, authorship) | Partially supported | The two roles — author signing as contributor, a different reviewer giving final approval — carry meaning implicitly, but there is no explicit enumerated meaning field in the signed payload; making it explicit is the cheapest item on our roadmap. |
| § 11.50(b) | The three items subject to the same controls as the record and included in any human-readable form | Partially supported | Name and time are inside the seal digest and therefore under the same controls, but their appearance in every printed or displayed rendition is not something we currently guarantee. |
| § 11.70 | Signature/record linking such that signatures cannot be excised, copied or otherwise transferred to falsify a record by ordinary means | Supported | This is the product's strongest clause: seal_algo: v2 hashes content and signatures together and chains to the previous sealed note, and verification recomputes the signature digest from the actual signatures rather than trusting a stored field, so excising, copying or transplanting a signature breaks verification. |
§ 11.100, § 11.200, § 11.300 — Electronic signature requirements
| Clause | Requirement | Verdict | Evidence / explanation |
|---|---|---|---|
| § 11.100(a) | Each signature unique to one individual, never reused or reassigned | Partially supported | Registration binds a PIN to a name and e-mail locally, and since v2.1.0 each user is issued a distinct non-extractable device key whose public half is recorded in the key registry — a signature made with a key not in the registry is flagged. But nothing prevents two people sharing a machine and PIN, so the binding of key to person is still a procedural assertion rather than an enforced property. |
| § 11.100(b) | The organization shall verify the identity of the individual before sanctioning the signature | Not supported | Identity is self-registered with no verification step, and even if you verify identity out of band the software has no mechanism to bind that verification to the signing credential. |
| § 11.100(c) | Certification to the agency that e-signatures are the legally binding equivalent of handwritten signatures | Customer responsibility | This is an organisational letter to FDA; no software feature can produce it, and none should imply it. |
| § 11.200(a)(1) | Non-biometric signatures shall employ at least two distinct identification components | Partially supported | By default there is exactly one identification component (a PIN). Since v2.1.0 a WebAuthn passkey can be enrolled and required at signing, making a signature take PIN + platform-authenticator gesture — two distinct components. Because the second component is optional and not enforced system-wide, we still do not claim this clause or Part 11 capability. |
| § 11.200(a)(1)(i)–(ii) | All components at first signing in a continuous session; at least one thereafter; all components for non-continuous signings | Not supported | The re-prompt before destructive actions echoes the spirit of (i), but the mechanic is meaningless with only one component to prompt for. |
| § 11.200(a)(2) | Used only by their genuine owners | Customer responsibility | The PIN hash is salted PBKDF2-SHA256 at 210,000 iterations since v2.1.0, which removes precomputed tables and raises the per-guess cost by that factor — but a short numeric PIN's search space is small enough that offline recovery by anyone with file access remains feasible in hours, not centuries. Sole-ownership still rests on your OS permissions and staff discipline. |
| § 11.200(a)(3) | Attempted use by anyone other than the genuine owner requires collaboration of two or more individuals | Not supported | A single person in possession of the folder and the PIN can sign as that user; nothing forces collaboration. |
| § 11.200(b) | Biometric signatures usable only by their genuine owners | Not supported | No biometric capability exists, so this conditional clause is not engaged — but neither can it be claimed. |
| § 11.300(a) | Uniqueness of each combined identification code and password | Not supported | There is no password and no global uniqueness constraint; the PIN hash gained a per-user salt in v2.1.0, which changes none of that. |
| § 11.300(b) | Periodic checking, recall or revision of code/password issuances (e.g. ageing) | Not supported | No expiry, no rotation, no periodic review mechanism. |
| § 11.300(c) | Loss management to deauthorize lost, stolen or compromised credentials | Not supported | Data Custodian role transfer with PIN confirmation and an audit entry is the only credential lifecycle event; there is no deauthorisation of a compromised PIN. |
| § 11.300(d) | Transaction safeguards to prevent unauthorized use and to detect and report it in an immediate and urgent manner | Not supported | There is no lockout, no attempt throttling, and — being offline by design — no channel on which to report anything urgently. |
| § 11.300(e) | Initial and periodic testing of tokens or cards | Not supported | No tokens or cards are used, so the clause is not engaged. |
2. EU GMP Annex 11 — Computerised Systems
Assessed against the in-force 2011 revision (deadline for coming into operation 30 June 2011), whose clause headings are quoted from the European Commission's published text. A draft revision was published on 7 July 2025 with consultation closing 7 October 2025, expanding the annex to seventeen chapters plus a glossary and adding cybersecurity, identity and access management and AI provisions. We have not confirmed whether a final text has been adopted as of this writing; our expectation is that the revision widens the gaps below rather than narrowing them, particularly on identity and access management.
| Clause | Requirement (2011 text) | Verdict | Evidence / explanation |
|---|---|---|---|
| Principle | The application should be validated; IT infrastructure should be qualified; no decrease in quality assurance where a computerised system replaces a manual operation | Not supported | Neither validation nor qualification evidence is supplied, so the Principle is unmet before the numbered clauses are reached. |
| 1. Risk Management | Risk management applied throughout the lifecycle; validation extent and data integrity controls based on a justified, documented risk assessment | Customer responsibility | Your risk assessment must decide whether a system with client-clock time and single-factor identity is acceptable for your process — and for GMP-critical data our honest expectation is that it is not. |
| 2. Personnel | Close cooperation between Process Owner, System Owner, QP and IT; appropriate qualifications, level of access and defined responsibilities | Partially supported | The Data Custodian role — first registrant, transferable with PIN confirmation, written to the audit log — is the only role concept in the product, and "level of access" cannot be differentiated because the application has no access levels. |
| 3.1 Suppliers | Formal agreements with third parties, stating responsibilities | Not supported | There is no supplier entity offering a formal agreement; Apache-2.0 supplies the software "as is" with warranties disclaimed. |
| 3.2 Suppliers | Supplier competence and reliability as selection factors; audit need based on risk assessment | Not supported | There is no auditable supplier organisation to assess. |
| 3.3 Suppliers | Documentation supplied with COTS products reviewed by regulated users against user requirements | Partially supported | The complete source is published, which permits a far deeper review than most COTS documentation allows, but there is no requirements documentation to review it against. |
| 3.4 Suppliers | Quality system and audit information relating to suppliers or developers made available to inspectors on request | Not supported | No supplier quality management system exists, and we will not claim one. |
| 4.1–4.8 Validation | Lifecycle validation documentation and reports; change control records; system inventory and description; User Requirements Specifications traceable throughout the life-cycle; supplier assessment; formal quality and performance assessment for bespoke systems; evidence of test methods and scenarios; migration checks that data are not altered in value or meaning | Not supported | No URS, FS, DS, traceability matrix, test protocols or validation summary report exist; the one partial analogue is 4.8, where the backup manifest and all-or-nothing restore do verify that data are not altered in value during transfer. |
| 5. Data | Systems exchanging data electronically with other systems should include built-in checks for correct and secure entry and processing | Partially supported | By design the application exchanges data with nothing (connect-src 'self'), which removes most of the risk this clause addresses; the exception is the opt-in AI endpoints, and evidence ingestion is checked by SHA-256 at attach time. |
| 6. Accuracy Checks | For critical data entered manually, an additional check on accuracy, by a second operator or by validated electronic means | Supported | Both limbs are present — a different reviewer must give final approval, and G3 performs a deterministic numeric and unit audit including unsupported "achieved" claims in free text — though the electronic limb is not validated, so it is the second-operator limb that carries the clause. |
| 7.1 Data Storage | Data secured by physical and electronic means against damage; checked for accessibility, readability and accuracy; access ensured throughout the retention period | Customer responsibility | The bytes live on your storage under your OS permissions; we supply the means to check integrity, not the means to secure the medium. |
| 7.2 Data Storage | Regular back-ups; integrity and accuracy of back-up data and the ability to restore checked during validation and monitored periodically | Partially supported | The mechanism is genuinely good — full ZIP with per-file SHA-256 manifest, and a restore that writes nothing unless every file verifies — but regularity, periodic monitoring and the validation of that mechanism are yours. |
| 8.1 Printouts | Possible to obtain clear printed copies of electronically stored data | Partially supported | Browser printing produces a legible copy, but there is no controlled, validated print rendition. |
| 8.2 Printouts | For records supporting batch release, printouts indicating if any data has been changed since the original entry | Partially supported | Revisions are issued as -R1, -R2 … and both the original and the revision history are retained, so the change is always recoverable from the record set, but we do not guarantee that a single printed page announces its own revision status. |
| 9. Audit Trails | Risk-based, system-generated record of all GMP-relevant changes and deletions; reason for change or deletion documented; available and convertible to a generally intelligible form; regularly reviewed | Partially supported | The append-only log is system-generated and covers gate verdicts, signatures, sealing, backup, restore and role transfers, and nothing is ever deleted — but there is no captured reason-for-change on a revision, and "regularly reviewed" is your procedure. |
| 10. Change and Configuration Management | All changes, including system configurations, made in a controlled manner per a defined procedure | Not supported | There is no defined change-control procedure on the supplier side and no configuration management inside the application. |
| 11. Periodic evaluation | Periodic evaluation to confirm the system remains in a valid state | Customer responsibility | A system that was never established as valid cannot be confirmed to remain so. |
| 12.1 Security | Physical and/or logical controls restricting access to authorised persons | Customer responsibility | The OS permission set on the shared folder is the entire control; the PIN is not one. |
| 12.2 Security | Extent of security controls depends on system criticality | Customer responsibility | You must decide whether a folder ACL is proportionate to the criticality of what you are recording. |
| 12.3 Security | Creation, change and cancellation of access authorisations recorded | Partially supported | Data Custodian transfers are recorded in the audit log; ordinary user registration is self-service and there is no authorisation to cancel. |
| 12.4 Security | Management systems designed to record the identity of operators entering, changing, confirming or deleting data, including date and time | Partially supported | Identity, date and time are recorded and bound into the seal, but the identity is self-asserted and the time defaults to the client clock (opt-in RFC-3161 attests seal time only). |
| 13. Incident Management | All incidents, not only system failures and data errors, reported and assessed; root cause of critical incidents identified | Not supported | There is no incident capture, no error logging surface and no route by which an offline application could report one. |
| 14. Electronic Signature | Signatures expected to (a) have the same impact as hand-written signatures within the company, (b) be permanently linked to their respective record, (c) include the time and date applied | Partially supported | (b) is Supported and is the product's best feature — the hash covers content and signatures and chains forward; (c) is Partially supported because the time is present but client-sourced by default (opt-in RFC-3161 attests the seal time, not each signature); (a) is Customer responsibility, because only your company can declare that equivalence. |
| 15. Batch release | System allows only Qualified Persons to certify batch release, identifying and recording the person, using an electronic signature | Not supported | The product has no batch certification function and must not be used for QP certification. |
| 16. Business Continuity | Provisions for continuity of critical processes in the event of system breakdown; arrangements documented and tested | Partially supported | Verified ZIP backup and all-or-nothing restore are a real continuity mechanism, and the records are plain files usable without the application, but the documented and tested continuity plan is yours. |
| 17. Archiving | Archived data checked for accessibility, readability and integrity; retrieval ensured and tested if relevant system changes are made | Partially supported | Integrity is checkable offline at any future date by recomputing the chain, and the open file format is favourable for long-term readability, but there is no archival tooling, no format-migration path and no retrieval testing. |
3. ALCOA+
The nine attributes as used in MHRA, WHO and PIC/S data-integrity guidance. Two of these deserve more than a verdict.
| Attribute | Requirement | Verdict | Evidence / explanation |
|---|---|---|---|
| Attributable | It must be possible to identify who performed an action and, where relevant, who reviewed it | Partially supported | See the note below — attribution is cryptographically frozen but not independently proven. |
| Legible | Records readable and permanent for their whole lifetime | Supported | Records are stored as plain files in an open format, readable without the application or any proprietary viewer, and G1 adds a second kind of legibility by making every narrative sentence traceable to the evidence ID it came from. |
| Contemporaneous | Recorded at the time the activity was performed | Partially supported | See the note below — the product attacks non-contemporaneity of content while remaining silent on non-contemporaneity of clock. |
| Original | The first capture, or a verified true copy, preserved | Supported | Uploaded originals are attached with their SHA-256, sealed notes cannot be edited, and issuing a revision preserves both the original and the full revision history rather than replacing anything. |
| Accurate | Correct, truthful, complete, valid and reliable; no editing without documented amendment | Supported | G1 refuses any narrative sentence that does not map to an evidence ID, G3 audits numerics, units and unsupported "achieved" claims in free text, and amendment is only possible as a documented revision — with the honest limit that we check internal consistency and evidence linkage, never the truth of the underlying measurement. |
| Complete | All data including repeat or reanalysis performed; nothing discarded | Supported | This is the product's defining behaviour: nothing is discarded — when a gate refuses a seal, both the offending text and the finding are retained, so a refusal is itself a permanent record rather than an invitation to try again quietly. |
| Consistent | Chronological, with date and time stamps in expected sequence | Supported | G2 checks each new note for longitudinal consistency against all previously sealed notes, and the seal chain fixes the order of notes independently of any date field. |
| Enduring | Recorded on controlled, durable media for the retention period | Customer responsibility | Open-format plain files with no vendor lock-in are a good starting point, but media durability, refresh and retention enforcement are entirely outside the application. |
| Available | Accessible for review and audit over the record's lifetime | Partially supported | Being fully offline with no vendor dependency means availability cannot be revoked by a supplier going out of business, but availability over decades is a function of your storage, not our software. |
On Attributable
Attribution here has two separable properties, and honesty requires separating them.
What AAA-RNS can prove: that the attribution has not changed since the seal. Because seal_algo: v2 hashes the signatures together with the content, and verification recomputes the signature digest from the actual signatures rather than trusting a stored field, you cannot later swap a signer, add one, remove one, or move a signature between notes without breaking verification. That property is genuine, offline-checkable, and stronger than most electronic notebooks offer.
What AAA-RNS cannot prove: who the person was. The signer is a self-registered name and e-mail authenticated by a salted PBKDF2 PIN, and since v2.1.0 the signature carries a device key checked against the key registry — signing as a colleague now requires their unlocked browser session, not just their PIN. But there is still no identity proofing, no certificate, no third-party attestation, and a determined insider with access to that session can still sign as them.
The precise claim is therefore: we can prove that the attribution has not been altered; we cannot prove the identity behind it. An auditor who accepts your institution's own identity procedures as the identity layer may accept this. One who requires the software to establish identity will not, and should not.
On Contemporaneous
The usual vendor answer to contemporaneity is a timestamp, and a timestamp from the client machine's clock is worth precisely as much as the operator's honesty — which is to say, exactly what this attribute exists to stop relying on. We will not dress that up.
What is genuinely unusual here is that AAA-RNS attacks contemporaneity from the other direction. Back-dating is rarely a matter of a wrong clock; it is a matter of reconstructing, weeks later, a narrative that fits the result you now know. G2 checks every new note for longitudinal consistency against every previously sealed note, so a reconstruction that contradicts the sealed history is caught and its finding retained. The chain fixes ordering irrespective of dates. Revisions append rather than overwrite. The effect is that writing a plausible retrospective record is expensive and leaves marks, even though writing a falsely dated one is trivial.
So: the content is made hard to back-fill; the clock, by default, is not made hard to move. Since v2.1.0, opt-in RFC-3161 timestamping fixes each seal's hash and time under a TSA's signature — for notes sealed after it is enabled, never retroactively, and with a shipped default TSA (FreeTSA) that is not an accredited authority. Contemporaneity therefore remains Partially supported, and any institution whose evidentiary needs turn on the time itself — patent priority in particular — should still treat this as a blocking gap until it has chosen and enabled a TSA it accepts.
4. ISO/IEC 17025:2017 — § 7.5 Technical records, § 7.11 Control of data and information management
Citation caveat. ISO/IEC 17025:2017 is a copyrighted standard and is not freely republished. The requirements below are summarised, not quoted at length, and the sub-clause numbering within § 7.11 was cross-checked against secondary sources rather than a controlled copy. Verify the numbering against your own licensed copy before relying on it in an accreditation submission. Where our confidence in a sub-clause number is lower, we say so in the row.
§ 7.5 — Technical records
§ 7.5.1 is very nearly a restatement of this product's thesis, and it is worth being exact about how far that goes. The clause requires that technical records for each laboratory activity contain the results, the report, and sufficient information to facilitate — if possible — identification of the factors affecting the measurement result and its associated measurement uncertainty, and to enable the repetition of the laboratory activity under conditions as close as possible to the original. It further requires that records include the date and the identity of the personnel responsible for each activity and for checking data and results, and that original observations, data and calculations be recorded at the time they are made and be identifiable with the specific task.
"Enough information for a competent person not involved in the original work to repeat the activity" is, almost word for word, the standard AAA-RNS was built to enforce. But the correspondence is partial in a way that matters, and overstating it would be exactly the kind of claim this page exists to prevent:
- G1 enforces that every narrative sentence maps to an evidence ID. That guarantees each claim has a source. It does not guarantee that the method description is complete enough to reproduce. A note can pass G1 while omitting a reagent lot, an instrument setting or an ambient condition, because those omissions are absences, and a gate that checks sourcing cannot detect an absence it was never told to expect.
- G4 enforces required fields and attached originals. That covers the identity and date obligations and the "original observations attached" obligation.
- Methodological sufficiency remains a scientific judgement made by the author and the reviewer. The product makes that judgement visible, reviewable and permanent. It does not make it automatic.
| Clause | Requirement | Verdict | Evidence / explanation |
|---|---|---|---|
| § 7.5.1 (results, report, sufficient information) | Records shall contain enough information to identify factors affecting the result and its uncertainty, and to enable repetition of the activity under conditions as close as possible to the original | Partially supported | G1's evidence mapping and G4's required-fields-and-originals checks mechanise the sourcing and completeness-of-fields halves of this clause, while the judgement of whether the method detail suffices for repetition stays with the author and the second-person reviewer. |
| § 7.5.1 (date and identity) | Records shall include the date and the identity of personnel responsible for each activity and for checking data and results | Partially supported | The two-person rule captures both roles — author as contributor, a different reviewer as final approver — and both are inside the seal digest, but the identity is self-asserted and the date is client-clock. |
| § 7.5.1 (original observations at time of making) | Original observations, data and calculations recorded at the time they are made, identifiable with the specific task | Partially supported | Originals are attached with SHA-256 and are identifiable with the note, subject to the contemporaneity limit set out under ALCOA+ above. |
| § 7.5.2 | Amendments shall be traceable to previous versions or to original observations; both original and amended data retained, including the date of alteration, an indication of the altered aspects and the personnel responsible | Supported | This is the single clause on this page that AAA-RNS satisfies most completely: sealed notes cannot be edited, change requires issuing a revision (-R1, -R2 …), the original and the full revision history both remain, each revision carries its own signatures inside its own seal, and the chain makes the sequence recomputable offline. |
§ 7.11 — Control of data and information management
| Clause | Requirement | Verdict | Evidence / explanation |
|---|---|---|---|
| § 7.11.1 (numbering: medium confidence) | The laboratory shall have access to the data and information needed to perform its activities | Supported | Everything is local, in an open format, with no network dependency and no supplier who can withdraw access. |
| § 7.11.2 | Information management systems used for collection, processing, recording, reporting, storage or retrieval of data shall be validated for functionality, including interfaces, before introduction; changes authorised, documented and validated before implementation | Not supported | Same wall as § 11.10(a) and Annex 11 § 4 — no validation package exists, and this is the clause an accreditation assessor will reach first. |
| § 7.11.3 (numbering: medium confidence) | Systems shall be protected from unauthorized access, safeguarded against tampering and loss, operated in conformance with supplier specifications, maintained to ensure data integrity, and shall record system failures with appropriate corrective actions | Partially supported | "Safeguarded against tampering" is met in the detect-not-prevent sense by the hash chain, "protected from unauthorized access" is Customer responsibility via OS permissions, and "recording system failures and corrective actions" is Not supported. |
| § 7.11.4 | Where the system is managed or maintained off-site or by an external provider, the laboratory shall ensure the provider complies with the applicable requirements | Customer responsibility | By design nothing is off-site — with one exception you must assess: if a user opts into the AI features, note content is sent to an Anthropic, Google or OpenAI endpoint, which makes that endpoint an external provider under this clause; the features are off by default and never required for any gate, seal or verification. |
| § 7.11.5 | Instructions, manuals and reference data relevant to the system shall be readily available to personnel | Partially supported | User documentation and the complete source are published, but there is no controlled, versioned document set of the kind an assessor expects. |
| § 7.11.6 | Calculations and data transfers shall be checked in an appropriate and systematic manner | Supported | G3's numeric and unit audit is systematic by construction — it runs on every note before sealing, cannot be skipped, and a note with outstanding G3 findings cannot be sealed. |
On accreditation language: ISO/IEC 17025 accredits laboratories, never software. No product can be "17025 certified," and any vendor who says otherwise is telling you something that cannot be true.
5. Korea — 국가연구개발사업 연구노트 지침
Citation caveat, stated first because it matters. We could not retrieve the official verbatim text from 국가법령정보센터 — the site serves the article body through script rather than in the fetched page. What we could confirm is that the current national instrument is 「연구노트 지침」, 과학기술정보통신부훈령 제44호, 시행 2018. 10. 12. (earlier titled 「국가연구개발사업 연구노트 관리 지침」), and that the three functional requirements for a 전자연구노트 are stable across versions. The article number is not stable: secondary sources place the requirement at 제7조 in the national 지침, while institutional regulations reproduce the identical three requirements at 제5조 제2항 (서울대) and 제4조 제2항 (덕성여대). Confirm 제7조 against your own controlled copy before citing it in a 연구관리 submission. A second and more important correction. We could not verify that a phrase such as "공인된 시점인증" or "공인 시점확인" appears as a verbatim requirement of the national 지침. What the 지침 requires is 기록한 날짜와 시각의 자동기록 기능 — automatic recording of the date and time. 시점인증 exists as a service offered through the national 전자연구노트 포털 (e-note.or.kr), in which a hash of the notebook file is relayed by 한국특허전략개발원 (연구노트확산지원본부) to the 행정안전부 전자문서진본확인센터, which issues the timestamp. It is an evidentiary strengthening and, in many institutions, an internal-rule expectation — but we will not represent it as a clause of the 지침 when we could not read the clause. If your 자체규정 requires it, treat the row below as blocking.
| Requirement | Verdict | Evidence / explanation |
|---|---|---|
| 제7조 ① — 기록자의 「전자서명법」 제2조제5호에 따른 전자서명인증 기능 | Not supported | 전자서명법 제2조제5호 defines 전자서명인증 as the act of confirming and proving that the 전자서명생성정보 uniquely belongs to the 가입자 — an act performed by an 전자서명인증사업자, i.e. a third party — and a self-enrolled ECDSA device key bound to a self-declared name is not that under any reading: v2.1.0 made the signature cryptographic, but the third-party confirmation the law defines is still absent. |
| 제7조 ① — 기록한 날짜와 시각의 자동기록 기능 | Partially supported | Date and time are recorded automatically and are bound into the seal digest so they cannot be altered after sealing without breaking verification, but the default source is the client machine's clock — opt-in RFC-3161 (v2.1.0) attests the seal time under a TSA's signature, though the shipped TSA is not a Korean accredited service. If your 자체규정 requires 시점인증 through the 전자연구노트 포털 specifically, that remains Not supported. |
| 제7조 ① — 기록의 위·변조 확인 기능 | Supported | seal_algo: v2 hashes content and signatures together and chains each sealed note to the previous one, and verification recomputes the signature digest from the actual signatures rather than trusting a stored field, so any alteration to a sealed note or its signatures is detectable offline by anyone holding the folder. |
| 제7조 ② — 서면연구노트 요건 (제본, 기관명·과제명·일련번호·쪽번호, 기록자·확인자 서명 및 날짜) | Not supported | This clause governs paper notebooks and is not addressed by an electronic product. |
| 연구노트 기재사항 — 기관명, 연구개발과제명, 연구책임자, 기록자, 관리번호, 쪽번호 | Partially supported | G4 enforces a required-field set before sealing, but whether that set matches your institution's 기재사항 list is a configuration question you must check field by field; we do not claim a match we have not verified for you. |
| 연구노트 기재사항 — 기록자 및 점검자의 서명, 기록일자·점검일자 | Supported | The two-person rule maps directly onto 기록자 and 점검자 — the author signs as contributor, a different reviewer gives final approval, self-approval is refused, and both signatures with their dates are inside the sealed hash. |
A note on 전자서명법 and the disappearance of 공인전자서명
The 전자서명법 was fully amended (전부개정) with effect from 10 December 2020, abolishing the 공인인증서 / 공인전자서명 regime after twenty-one years and giving all electronic signatures equal legal footing, with 전자서명인증사업자 and 운영기준 준수사실 인정 replacing the old 공인 designation.
Two consequences follow, and both cut against us:
- A demand for "공인전자서명" is now legally obsolete, so an institutional rule still phrased that way should be re-read against the current law before it is applied to any product.
- The abolition does not help AAA-RNS. The 지침 points at 전자서명법 제2조제5호 — 전자서명인증 — which still presupposes a third party confirming that the signing credential belongs to the signer. Equal legal footing among signature technologies does not turn a local PIN into a certified one. We will not describe our signature as 법적 효력이 있는 전자서명.
6. Japan — 厚生労働省 ER/ES指針 (薬食発第0401022号)
The 「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電子署名の利用について」 notification, issued by the 厚生労働省医薬食品局長 on 1 April 2005, requires that systems using electromagnetic records establish 真正性 (authenticity), 見読性 (readability) and 保存性 (preservation), and sets separate requirements for 電子署名.
Citation caveat. The published PDFs of the 指針解説 (JCROA, 平成18年3月30日 第1版 and 令和6年3月26日 改訂版) are image- or stream-encoded and we could not extract the sub-requirement headings verbatim. The three-pillar framing and the substance below are confirmed by multiple sources; individual sub-item numbering within 第3 and 第4 is not verified and is therefore not cited.
| Requirement | Verdict | Evidence / explanation |
|---|---|---|
| 真正性 — records complete, accurate and reliable, with clear responsibility for creation, change and deletion | Partially supported | Responsibility is unusually well established — a two-person rule with enforced cross-approval, an append-only audit trail of gate verdicts, signatures, sealing, backup, restore and role transfers — but 作成者の識別 rests on self-registration — the v2.1.0 device key proves continuity of a signing key, not the identity behind it — and that remains the weakest link in the pillar. |
| 真正性 — 変更・削除前の記録の保存 and 監査証跡 | Supported | Sealed notes cannot be edited, change requires a revision (-R1, -R2 …) with both the original and the revision history retained, deletion of a sealed note is not a supported operation, and gate findings are kept even when they refuse the seal. |
| 見読性 — content readily displayable and readable when required | Supported | Records are plain files in an open format, displayed and printable in an ordinary browser with no proprietary viewer and no vendor dependency — though the rendition is the browser's and is not a validated one. |
| 保存性 — 真正性 and 見読性 maintained throughout the statutory retention period | Partially supported | Integrity over time is verifiable at any future date by recomputing the chain and the backup manifest offline, which is the hard part, but the storage medium, retention period, migration and format survival are yours. |
| 電子署名 — 本人性 (the signature shows the record was created by the signer) | Not supported | Establishing 本人性 requires a credential a third party can vouch for; ours is a self-enrolled device key (plus an optional passkey) that no 認証局 stands behind. |
| 電子署名 — 非改ざん性 (that no alteration has occurred) | Supported | The seal hash covers both content and signatures and chains forward, and verification recomputes the signature digest rather than trusting a stored field. |
| 電子署名 — display of 署名者の氏名, 署名日時, 署名の意味 | Partially supported | 氏名 and 日時 are recorded and bound into the seal digest, but 日時 comes from the client clock (opt-in RFC-3161 attests seal time only) and there is no explicit enumerated 署名の意味 field — the same § 11.50(a)(3) gap, and the same cheap fix. |
| 電子署名法 conformance | Not supported | We make no claim under 電子署名法 and hold no certificate from any certification service provider. |
What we would need to build
In ascending order of cost. Each item names the clauses it would move and the honest reason it costs what it costs.
1. Explicit signature meaning, and a reason-for-change field — days
Add an enumerated meaning to every signature (authorship / review / approval / responsibility), include it in the signed payload and in the seal digest, and render it beside the name and time in every human-readable view and printout. Add a required reason-for-change when a revision is issued.
Moves: § 11.50(a)(3), § 11.50(b), Annex 11 § 9 (reason documented), 電子署名 署名の意味.
Why it's cheap: it is a schema field and a rendering change; the signing and sealing machinery already exists.
2. Salt and a KDF for the PIN — shipped in v2.1.0
The PIN is now stored as salted PBKDF2-SHA256 at 210,000 iterations; pre-existing unsalted hashes upgrade in place on the next successful entry, with an audit entry. (This page originally suggested Argon2id or scrypt; PBKDF2 was chosen because WebCrypto provides it natively and this product refuses dependencies.)
Moves: nothing, formally — exactly as predicted. It creates no second factor and unlocks no clause; it removes an indefensible weakness, which is why it was done first.
3. Controlled human-readable rendition — 1–2 weeks
A deterministic print/PDF export carrying the full signature manifestation (name, time, meaning), the note's revision status, the evidence IDs behind every sentence, and the seal hash.
Moves: § 11.10(b), § 11.50(b), Annex 11 § 8.1 and § 8.2, 見読性.
4. Hash-chained, exportable audit log — 1–2 weeks
Chain the audit log the way sealed notes are chained, so that removing or reordering an entry is detectable, and export it in a generally intelligible form.
Moves: § 11.10(e) ("secure, computer-generated"), Annex 11 § 9 (available and convertible to an intelligible form), 真正性 監査証跡.
5. Trusted time — RFC-3161 half shipped in v2.1.0; the 시점인증 half has not
The opt-in RFC-3161 timestamp token shipped exactly as specified here: obtained at seal time, stored beside the seal, verifiable offline with openssl ts -verify, off by default, degrading silently to the local clock when offline, and never a precondition for sealing. The shipped default TSA (FreeTSA) is not an accredited authority, and the Korean 시점인증 through the 전자연구노트 포털 relay to the 행정안전부 전자문서진본확인센터 remains not built — its eligibility is institutional, not technical.
Moves: § 11.10(e), § 11.50(a)(2), Annex 11 § 14(c), ALCOA+ Contemporaneous, 연구노트 지침 자동기록/시점인증, 真正性.
What the constraint was, and how it held: a network call contradicts the product's offline guarantee, so it had to be opt-in, degrade silently to local time when offline, and never become a precondition for sealing — the shipped implementation does all three, and only the 32-byte seal hash ever leaves the machine.
6. Certificate-based signature — 1–3 months, plus a CA relationship
The first half — a non-extractable key pair (WebCrypto ECDSA held in IndexedDB), plus an optional WebAuthn passkey — shipped in v2.1.0. The half that moves clauses is the second: a certificate from a Korean 전자서명인증사업자, an eIDAS trust service provider, or an equivalent, binding that key to a verified person. That half requires a CA relationship and is not built.
Moves: § 11.100(a) and (b), § 11.200(a)(1)–(3), Annex 11 § 14, 연구노트 지침 제7조 전자서명인증, 電子署名法 本人性, ALCOA+ Attributable.
Why it costs what it does: the cryptography is the easy part. Key lifecycle is the hard part — enrolment, loss, revocation, device migration, and what happens to notes signed with a key that was later revoked. Every one of those is a product decision with an evidentiary consequence.
7. Per-user OS or OIDC identity, and real access control — months, and a product decision
Bind application identity to an OS account or an OIDC/SAML identity provider, enforce authorisation where it cannot be edited away by the record's own author, and retire the fiction that a client-side PIN is a control.
Moves: § 11.10(d) and (g), § 11.100(b), § 11.200, § 11.300(a)–(d), Annex 11 § 12.1 and § 12.3, ISO § 7.11.3.
Why it is the most expensive item that is still code: it ends "no accounts, no server, no identity provider," which is a founding property of the product and the reason it can run on a disconnected instrument PC. This is not a feature to be scheduled; it is a fork in the road, and it may be right to build it as a separate deployment mode rather than as an upgrade.
8. The validation package — the largest single line item
URS, FS and DS; a requirements traceability matrix carrying each requirement through design, test and release; IQ, OQ and PQ protocols with executed records; a validation summary report; and a supplier quality system capable of answering Annex 11 § 3.4 when an inspector asks.
Moves: § 11.10(a), Annex 11 Principle and § 3–4, ISO § 7.11.2 — that is, the clause that blocks first in every one of the three regimes above.
The honest structure of the work: most of it is document engineering plus a recorded, repeatable test harness — and it is only half the vendor's to do. A vendor can supply the specifications, the design evidence and the OQ protocols. The PQ is executed in your environment, against your process, by your people, and it is yours to own. Any vendor offering you a "pre-validated" system is offering you something that cannot exist.
9. Credential lifecycle — only meaningful after item 7
Password ageing, lockout, attempted-use detection and reporting, deauthorisation of compromised credentials, and an identity-verification workflow feeding § 11.100(b).
Moves: § 11.300(a)–(d), Annex 11 § 12.3.
Placed last deliberately: building password ageing on top of a single-factor client-side PIN would produce the appearance of a control without the substance, which is precisely the failure mode this page exists to avoid.
Statements we will not make
These are exact phrases the project refuses to use — in the product, in documentation, in a sales conversation, in a grant application, or in a slide. Each is followed by the reason.
| Phrase we refuse | Why |
|---|---|
| "21 CFR Part 11 compliant" / "Part 11 compliant" | Compliance is a property of a validated, configured and operated system inside an organisation, never of software — and separately, we fail § 11.200(a)(1) as shipped. |
| "Part 11-ready" / "Part 11-capable" / "Part 11 준수" | We will use "capable" only when § 11.50, § 11.100, § 11.200 and § 11.300 are met at the software level. Today they are not, and "ready" is the same claim wearing a softer word. |
| "Annex 11 compliant" / "GMP compliant" / "GxP validated" | No validation package, no supplier quality system, no formal supplier agreement — Annex 11 § 3 and § 4 are unmet before any feature is discussed. |
| "Validated software" / "pre-validated" / "validation included" | Nobody can validate software for a process they have never seen; the PQ is executed in your environment by your people. |
| "Tamper-proof" / "immutable" / "unalterable" / "위변조 불가" | The chain makes alteration detectable, not impossible. Anyone with write access to the folder can delete every file in it, and no hash prevents that. We say tamper-evident, and we say what it detects. |
| "Blockchain-grade" / "blockchain-level security" | There is no distributed consensus and no external anchor; it is a local hash chain, and comparing it to a blockchain implies a trust property it does not have. |
| "Legally binding electronic signature" / "법적 효력이 있는 전자서명" / "공인전자서명" | 공인전자서명 was abolished on 10 December 2020; ours is not 전자서명인증 by any 인증사업자; and legal effect is determined by a court, not asserted by a vendor. |
| "Certified timestamp" / "trusted timestamp" / "시점인증" / "타임스탬프 인증" | The default time is the client clock. The opt-in RFC-3161 token (v2.1.0) is real and openssl-verifiable, but it is off by default and the shipped TSA is not an accredited authority — "certified" and "시점인증" name accredited services we do not provide. |
| "Audit-proof" / "감사 대응 완료" / "inspection-ready" | No third party has certified anything about this product, and no software makes an organisation ready for an inspection. |
| "ISO 17025 certified" / "17025 accredited software" | ISO/IEC 17025 accredits laboratories. No software can hold it, and any vendor claiming it is describing something that does not exist. |
| "연구노트 지침 준수" / "국가연구개발사업 연구노트 요건 충족" | 제7조's 전자서명인증 requirement is not met, and two of three functional requirements would have to be claimed falsely to say this. |
| "Meets ALCOA+" / "ALCOA+ 완벽 준수" | Attributable and Contemporaneous are Partially supported. Seven of nine is not nine. |
| "AI-verified" / "AI가 검증한" / "AI-validated evidence" | The four gates are deterministic checks; the AI drafts prose and nothing else. No claim is ever admitted on an AI's say-so, and calling the gates "AI" would invert the product's entire argument. |
| "Guarantees data integrity" | We detect alteration of sealed records. We cannot guarantee that the science was right, that the instrument was calibrated, or that the person who signed was who they said. |
| "Secure" (with no object) | We will always name what is protected, from whom, and by what mechanism — because a bare "secure" is what people say when the answer is uncomfortable. |
| "GDPR compliant" / "HIPAA compliant" | The product processes whatever you type into it, on your machine, under your controls; those obligations are yours and cannot be transferred by a purchase. |
| "No data ever leaves your machine" (unqualified) | True only with AI features off. They are off by default and never required — and we will state that exception every single time we make the claim, including here. |
| "Replaces your validated ELN" | For GMP-critical or regulated-submission records it does not, and telling a customer otherwise could cost them a filing. |
Verification notes
Recorded so that a reviewer can see which citations rest on primary sources and which do not.
Verified against primary or authoritative sources
- 21 CFR Part 11 — § 11.3(b) definitions; § 11.10(a)–(k); § 11.50; § 11.70; § 11.100(a)–(c); § 11.200(a)–(b); § 11.300(a)–(e). Section titles and paragraph text confirmed.
- EU GMP Annex 11 (2011) — the complete clause set, Principle plus 1–17 with headings and text, taken from the European Commission's published PDF (Annex 11: Computerised Systems, revision 1, deadline for coming into operation 30 June 2011) and decompressed locally.
- EU GMP Annex 11 revision status — draft published 7 July 2025, consultation closed 7 October 2025, alongside a new Annex 22 (Artificial Intelligence) and a revised Chapter 4. Whether a final text has since been adopted is unconfirmed, and this matrix assesses against the 2011 version.
- 전자서명법 제2조제5호 — 전자서명인증 defined as the act of confirming and proving that the 전자서명생성정보 belongs uniquely to the 가입자.
- 전자서명법 전부개정 — in force 10 December 2020; 공인인증서 / 공인전자서명 abolished; equal legal effect across signature technologies.
- 「연구노트 지침」 — 과학기술정보통신부훈령 제44호, 시행 2018. 10. 12.
- ER/ES指針 — 薬食発第0401022号, 厚生労働省医薬食品局長, 1 April 2005; the 真正性 / 見読性 / 保存性 framing.
- 시점인증 service architecture — hash relayed via 한국특허전략개발원 (연구노트확산지원본부) to the 행정안전부 전자문서진본확인센터.
Not verified — flagged in place rather than guessed
- 연구노트 지침 article number. We could not retrieve the official verbatim text from 국가법령정보센터. The three 전자연구노트 requirements are confirmed by multiple institutional reproductions, but those place them at 제5조 제2항 and 제4조 제2항 as well as 제7조. Confirm against a controlled copy.
- "공인된 시점인증" as a clause of the 지침. Not verified. The requirement we could confirm is 기록한 날짜와 시각의 자동기록 기능; 시점인증 is confirmed as a national portal service, not as 지침 clause text.
- ISO/IEC 17025:2017 § 7.11 sub-clause numbering. § 7.11.2, § 7.11.4, § 7.11.5 and § 7.11.6 are corroborated by secondary sources; § 7.11.1 and § 7.11.3 are inferred from the resulting structure and are marked medium confidence in the table. The standard is copyrighted and was not reproduced.
- ER/ES指針 sub-item numbering within 第3 and 第4. The published 解説 PDFs are image- or stream-encoded and could not be extracted, so no sub-item numbers are cited.
This matrix is a supplier self-assessment. It will be revised when the product changes and when the Annex 11 revision is adopted. If you find a verdict here that is more favourable than the evidence supports, that is a defect — report it the same way you would report a bug.