Version: 1.1.0
This guide translates traditional GxP compliance milestones into the ROSIE framework components. It is designed for QA, Regulatory Affairs, and auditors to understand how digital evidence replaces paper artifacts.
Understanding ROSIE’s Boundary
ROSIE is a specification, not a complete system. It defines:
- How to structure compliance artifacts in code repositories
- How to compute integrity hashes
- The API contract for approval systems
Your organization’s System of Record (SoR) handles:
- User authentication and authorization
- Approval workflows and electronic signatures
- Audit trail storage and retention
Any QMS, PLM, or custom system that implements the ROSIE API (RFC-004) can serve as the SoR.
1. Traditional vs. ROSIE Mapping
| Traditional GxP Deliverable | ROSIE Digital Equivalent | Why This is Better for Compliance |
|---|---|---|
| User Requirements (URS) | specs/urs/*.md | Living specs: requirements are version-controlled alongside code |
| Functional/Design Specs (FRS/DS) | specs/ds/*.md and @gxp-id | Direct links: the design is part of the code |
| Traceability Matrix (RTM) | ROSIE graph (auto-generated) | Real-time accuracy: derived from code, no manual drift |
| Test Protocols (IQ/OQ/PQ) | tests/ with @gxp-type | Automated execution: tests run on every change |
| Validation Summary Report | gxp-execution.json | Immutable evidence: logs, hashes, and screenshots |
| Handwritten signatures | SoR e-signatures | Part 11 compliant: signatures are linked to a specific Git hash |
2. Navigating the Audit Trail
In a traditional audit, you look at a binder. In a ROSIE-enabled audit, you look at the Dual-Ledger.
1. Prove the Intent (the repo)
Auditor question: “Where did you say the system would do X?”
Answer: The Markdown file in /specs. Git history shows who wrote it and when.
2. Prove the Design (the code)
Auditor question: “How did you implement that requirement?”
Answer: The ROSIE Engine follows the @gxp-id tag to the exact function in code.
3. Prove the Verification (the evidence)
Auditor question: “How do I know this actually works?”
Answer: The gxp-execution.json shows test results, evidence attachments, and the RRT.
3. Hard-Gate vs. Traditional “Go-Live”
| Traditional “Go-Live” | ROSIE Hard-Gate |
|---|---|
| Human check: a person verifies signed documents | Digital check: deployment is blocked if any signature or hash is missing |
| Point-in-time: validation is a snapshot from last month | Continuous: validation is a live status of the current build |
| High friction: releases wait on paperwork routing | Low friction: releases proceed because evidence is generated during development |
4. Addressing GAMP 5 and CSA Principles
- Critical thinking (CSA): The AI agent flags high-risk changes (e.g., security, data integrity), so QA focuses on the most important areas
- Fitness for purpose: Self-validation proves the tool works correctly on every run, not just during a one-time validation
5. Summary for Auditors
ROSIE supports 21 CFR Part 11 compliance by ensuring:
- Integrity: The manifest hash prevents undetected changes to validated code
- Traceability: Every requirement is digitally linked to code and tests
- Accountability: Every approval is a timestamped, cryptographically secure e-signature
Key References
| Document | Purpose |
|---|---|
| RFC-001: Data Standard | How requirements and traces are structured |
| RFC-002: Engine Spec | How the Hard-Gate and sync work |
| RFC-003: Evidence Standard | How evidence is captured and packaged |
| RFC-004: API Interface | How ROSIE connects to your SoR |
| RFC-005: TQ Baseline | How the tool validates itself |