DRAFT GUIDANCE -- Public comment period closes October 19, 2026. This crosswalk reflects the draft text issued by FDA's Center for Devices and Radiological Health (CDRH). Requirements may change in the final guidance. Organizations building compliance evidence today should treat mapped procedures as a baseline that will need reconciliation once the final guidance is published.
Who this is for: Medical device manufacturers, clinical AI development teams, regulatory affairs professionals, FDA reviewers evaluating AI/ML submissions, Quality Management System (QMS) teams maintaining ISO 13485 compliance, and risk management professionals working under ISO 14971. Also relevant to Software as a Medical Device (SaMD) developers and clinical validation teams.
Why This Changes the FDA Conversation
Today: When an FDA reviewer asks "show me that this model change stayed within your PCCP," your regulatory affairs team reconstructs the evidence: design history files, version control logs, validation reports from different systems, and an email thread where someone approved the change. The reviewer cannot verify when these documents were created or whether the validation actually preceded the deployment.
With SWT3: Each step in the model update lifecycle -- baseline performance, change implementation, boundary verification, review approval, and post-deployment monitoring -- produces a tamper-evident Witness Anchor with a cryptographic fingerprint. The timestamps are immutable. The sequence is verifiable. The reviewer confirms the entire PCCP evidence chain in minutes, not weeks.
The shift: Post-market surveillance moves from periodic retrospective reports to a continuous, verifiable evidence stream. When the FDA asks "is this device still performing as validated," the answer is already recorded -- not assembled on demand.
Contents
1. Quick Reference 2. Good Machine Learning Practice: 10 Principles 3. Predetermined Change Control Plans 4. Real-World Performance Monitoring 5. Requirement-to-Procedure Mapping 6. Procedure Detail Cards 7. PCCP Evidence Chain 8. FDA Reviewer Quick Reference 9. Quick Start 10. References1. Quick Reference
| Field | Detail |
|---|---|
| Guidance Title | Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations |
| Issuing Body | FDA Center for Devices and Radiological Health (CDRH) |
| Status | Draft guidance -- public comment period closes October 19, 2026 |
| Scope | AI/ML-enabled device software functions, including Software as a Medical Device (SaMD) and AI/ML embedded in hardware devices |
| Key Concepts | Good Machine Learning Practice (GMLP), Predetermined Change Control Plan (PCCP), Total Product Lifecycle (TPLC), Real-World Performance Monitoring |
| Regulatory Pathway | 510(k), De Novo, PMA -- pathway depends on device risk classification and predicate device availability |
| SWT3 Procedures | AI-DATA.1, AI-HITL.1, AI-DRIFT.1, AI-SAFE.1, AI-AUDIT.1, AI-MDL.5, AI-ROBUST.1, AI-TRANS.1, AI-FAIR.1 |
2. Good Machine Learning Practice: 10 Principles
The FDA's Good Machine Learning Practice (GMLP) framework establishes 10 guiding principles for the development, deployment, and monitoring of AI/ML-enabled medical devices. These principles are not standalone requirements -- they map directly to existing quality system expectations under 21 CFR Part 820 and risk management requirements under ISO 14971. What the GMLP framework adds is specificity about how those expectations apply when the device function is driven by machine learning.
The following table maps each GMLP principle to the SWT3 approach. SWT3 does not replace the manufacturer's quality system. It provides an independent witness layer that records evidence of each principle being addressed throughout the device lifecycle.
| GMLP Principle | SWT3 Approach |
|---|---|
| 1. Multi-disciplinary expertise | AI-HITL.1 records the roles and qualifications of reviewers involved in model development and validation decisions. The reviewer role field distinguishes clinical, engineering, and regulatory expertise. |
| 2. Good software engineering | AI-AUDIT.1 witnesses software development lifecycle milestones. Anchors record code review status, test coverage, and design control checkpoints aligned with IEC 62304. |
| 3. Representative data | AI-DATA.1 records data source characteristics, demographic composition, and intended use population alignment. Each anchor captures the lineage from source dataset to training split. |
| 4. Independent datasets | AI-DATA.1 anchors distinguish training, validation, and test datasets by partition identifier. Cross-contamination between partitions is detectable through lineage chain analysis. |
| 5. Best available reference standards | AI-ROBUST.1 records the reference standard used for clinical validation, including standard version, sample size, and performance metrics against that standard. |
| 6. Model transparency | AI-TRANS.1 witnesses disclosure of model methodology, training data characteristics, and known limitations. Each anchor records what was disclosed, to whom, and through what channel. |
| 7. Focus on performance and safety | AI-SAFE.1 records risk classification, hazard analysis results, and residual risk acceptance decisions. Anchors link directly to ISO 14971 risk management outputs. |
| 8. Training and testing in real-world conditions | AI-DRIFT.1 monitors performance in deployed conditions and records deviations from pre-market performance benchmarks. Degradation triggers are witnessed as they occur. |
| 9. User interface and human factors | AI-HITL.1 records human-in-the-loop review events, including override frequency and escalation patterns. Override rates provide evidence that users can effectively interact with AI outputs. |
| 10. Monitoring of deployed models | AI-DRIFT.1 provides continuous post-market performance monitoring with drift detection. AI-AUDIT.1 witnesses periodic review cycles as required by the TPLC approach. |
3. Predetermined Change Control Plans
The Predetermined Change Control Plan (PCCP) is one of the most consequential concepts in the FDA's AI/ML guidance. Under a PCCP, a manufacturer defines -- at the time of initial marketing submission -- the specific types of model modifications that may occur after clearance without requiring a new 510(k), De Novo, or PMA supplement. If a model change stays within the boundaries defined in the PCCP, it is pre-authorized. If it exceeds those boundaries, a new submission is required.
The compliance challenge is not writing the PCCP. It is proving, for every model update that occurs after clearance, that the change stayed within the predetermined parameters. This is where most manufacturers encounter difficulty: the PCCP defines boundaries in the submission, but the evidence that a specific change respected those boundaries lives in the development and deployment pipeline. Without a systematic witness mechanism, the manufacturer must reconstruct this evidence retroactively when the FDA asks.
What a PCCP Typically Defines
- Description of modifications: The types of changes the manufacturer anticipates (retraining on new data, hyperparameter adjustments, feature engineering updates, threshold recalibration)
- Modification protocol: The process the manufacturer will follow to implement each type of change, including validation requirements
- Performance bounds: Quantitative thresholds that the modified model must continue to meet (sensitivity, specificity, AUC, calibration metrics)
- Impact assessment: How the manufacturer will evaluate whether a change affects the device's safety or effectiveness profile
How SWT3 Supports PCCP Compliance
SWT3 witnesses each model update as it occurs, recording the change type, the performance metrics before and after the change, and whether the change falls within PCCP boundaries. This creates a contemporaneous evidence chain -- not a retrospective reconstruction. When the FDA asks "did this change stay within your PCCP," the manufacturer can produce a sequence of anchors that document exactly what changed, what was measured, and whether boundaries were respected.
The key procedures involved are:
- AI-MDL.5 -- records model version, weight hash, and change description at each update point
- AI-ROBUST.1 -- records post-change performance metrics against the PCCP-defined thresholds
- AI-DRIFT.1 -- provides continuous monitoring between update points, detecting performance degradation that might necessitate a change
- AI-AUDIT.1 -- witnesses the review and approval decision for each change
4. Real-World Performance Monitoring
The FDA's Total Product Lifecycle (TPLC) approach requires that AI/ML-enabled devices be monitored throughout their deployed lifetime -- not just validated at the point of marketing submission. Real-world performance monitoring addresses the fundamental reality that AI/ML models can degrade in production as patient populations shift, clinical workflows evolve, and data distributions change in ways that pre-market testing did not anticipate.
The draft guidance identifies several categories of post-market evidence that manufacturers should collect:
- Performance drift: Systematic changes in model accuracy, sensitivity, or specificity over time
- Safety signals: Adverse events or near-misses attributable to AI/ML device function
- Distributional shift: Changes in the characteristics of input data compared to the training population
- User interaction patterns: How clinicians interact with AI outputs, including override rates and time-to-decision
SWT3 addresses real-world performance monitoring through two complementary procedures. AI-DRIFT.1 records performance metrics on a continuous basis, creating a time-series of anchors that reveal trends before they become safety signals. AI-HITL.1 records clinician interaction events, including overrides and escalations, providing evidence that the device's human factors profile remains appropriate in deployed conditions. Together, these create the evidence package that the FDA expects under the TPLC approach -- not a periodic snapshot, but a continuous record of device performance in clinical use.
For devices where the AI/ML function runs on dedicated hardware (edge inference chips, embedded accelerators, wearable processors), AI-HW.1 witnesses the hardware attestation -- confirming that the inference environment matches the validated configuration. A model validated on one processor architecture may behave differently on another. Hardware attestation anchors prove that the production inference environment matches what was tested.
FDA reviewers evaluating post-market evidence will look for gaps in the monitoring timeline. A continuous stream of AI-DRIFT.1 anchors demonstrates active surveillance. Gaps longer than the manufacturer's stated monitoring interval suggest periods where performance was not being tracked. AI-HITL.1 anchors with consistently zero overrides across thousands of clinical decisions may indicate that clinicians are not exercising independent judgment -- a human factors concern the FDA takes seriously.
5. Requirement-to-Procedure Mapping
| FDA Requirement | SWT3 Procedure | What It Witnesses | Evidence Produced |
|---|---|---|---|
| Data management and representativeness | AI-DATA.1 | Data lineage, demographic composition, partition integrity | Anchor with data source, population characteristics, partition ID, collection methodology |
| Human oversight and clinical review | AI-HITL.1 | Clinician review events, overrides, escalation decisions | Anchor with reviewer role, review type, override status, escalation path, time-to-decision |
| Performance monitoring and drift detection | AI-DRIFT.1 | Continuous performance metrics, distributional shift, degradation events | Anchor with metric name, baseline value, current value, threshold, drift direction |
| Safety and risk management | AI-SAFE.1 | Hazard analysis, risk classification, residual risk acceptance | Anchor with risk level, hazard category, mitigation status, ISO 14971 reference |
| Audit trail and design controls | AI-AUDIT.1 | Design review milestones, audit scope, IEC 62304 checkpoints | Anchor with audit scope, methodology, findings count, assessor identity, lifecycle phase |
| Model versioning and change tracking | AI-MDL.5 | Model version, weight file hash, change description, PCCP boundary check | Anchor with version identifier, weight digest, change type, PCCP compliance status |
| Robustness and clinical validation | AI-ROBUST.1 | Performance against reference standards, stress testing, edge case evaluation | Anchor with reference standard, sample size, sensitivity, specificity, AUC, confidence interval |
| Transparency and labeling | AI-TRANS.1 | Disclosure of methodology, training data, limitations, intended use | Anchor with disclosure type, recipient, delivery channel, content summary |
| Fairness and subgroup performance | AI-FAIR.1 | Performance equity across demographic subgroups | Anchor with bias metric, demographic group, threshold, evaluation result, subgroup sample size |
6. Procedure Detail Cards
Data Lineage and Representativeness
FDA guidance requires: Training, validation, and test datasets must be representative of the intended patient population. Manufacturers must document data sources, collection methodology, demographic composition, and any known biases or gaps in representation. Independent datasets must be maintained for training, tuning, and testing to prevent overfitting.
How SWT3 addresses it: The witnessDataLineage() call records the data source, the intended use population alignment, the demographic composition, and the partition identifier (training, validation, or test). Each stage of data processing -- from raw collection through curation, labeling, and split assignment -- produces a separate anchor. This creates a verifiable chain from source data to model input that can be independently audited without requiring access to the underlying data.
Query AI-DATA.1 anchors by dataset identifier. Each anchor should show the population characteristics of the source data and how they align with the device's intended use statement. Partition identifiers (training, validation, test) must be mutually exclusive -- any anchor appearing in multiple partitions indicates data leakage. Cross-reference demographic fields with the device labeling to verify that subgroups described in the label are represented in the training data.
Human Oversight and Clinical Review
FDA guidance requires: AI/ML-enabled devices must be designed to support appropriate human oversight. For diagnostic devices, clinicians must be able to review, override, and contextualize AI outputs before clinical action. The device's human factors profile must ensure that users can effectively interact with AI-derived information without automation bias or alert fatigue.
How SWT3 addresses it: The witnessHumanReview() call records each clinician interaction with the AI output, including whether the output was accepted, overridden, or escalated. The reviewer role field captures the clinician's qualification level. Override frequency and escalation patterns over time provide quantitative evidence that the human-AI interaction model is functioning as designed.
AI-HITL.1 anchors should appear for every clinical decision point where the AI output informs patient care. The override rate is a critical metric: a rate near zero across thousands of decisions may indicate automation bias (clinicians accepting all AI outputs without independent evaluation). A very high override rate may indicate that the AI output is not clinically useful. Both extremes warrant investigation. The reviewer role field should confirm that overrides are performed by appropriately qualified clinicians.
Performance Drift and Real-World Monitoring
FDA guidance requires: Manufacturers must implement real-world performance monitoring as part of the Total Product Lifecycle approach. This includes continuous tracking of model accuracy, sensitivity, specificity, and calibration against pre-market benchmarks. Performance degradation that exceeds predetermined thresholds must trigger review and potential corrective action.
How SWT3 addresses it: The witnessDrift() call records performance metrics on a scheduled or event-driven basis, capturing the metric name, the baseline value established during pre-market validation, the current observed value, the threshold defined in the PCCP or post-market surveillance plan, and the drift direction. A continuous stream of anchors creates a time-series that reveals gradual degradation before it becomes a safety signal.
AI-DRIFT.1 anchors should form a continuous time-series with no gaps longer than the manufacturer's stated monitoring interval. Trend the current value field over time to identify gradual degradation. Any anchor where the current value crosses the threshold field represents a drift event that should have triggered corrective action -- verify that a corresponding AI-MDL.5 or AI-AUDIT.1 anchor follows. FDA reviewers will look for both the detection of drift and the response to it.
Safety and Risk Management
FDA guidance requires: Risk management for AI/ML-enabled devices must follow ISO 14971 and address risks specific to machine learning: unexpected model behavior on out-of-distribution inputs, failure modes that differ from traditional software, and risks arising from model updates over time. The risk management file must demonstrate that AI-specific hazards have been identified, analyzed, and mitigated.
How SWT3 addresses it: The witnessSafety() call records risk classification decisions, hazard analysis results, and residual risk acceptance judgments. Each anchor links to the specific ISO 14971 risk management activity it documents, creating a verifiable chain from hazard identification through mitigation to residual risk acceptance. AI-specific hazards (distributional shift, adversarial inputs, automation bias) are recorded alongside traditional device hazards.
AI-SAFE.1 anchors should map to entries in the manufacturer's risk management file. The hazard category field should include AI-specific hazards alongside traditional device hazards. Mitigation status must reflect current state -- a hazard initially marked "open" should eventually have a corresponding anchor with "mitigated" status. Risk classification fields should align with the device's overall risk class as submitted to the FDA.
Audit Trail and Design Controls
FDA guidance requires: AI/ML device development must follow design controls per 21 CFR 820.30. This includes design input, design output, design review, design verification, design validation, and design transfer. The audit trail must demonstrate that each phase of the software development lifecycle was completed in accordance with IEC 62304, with appropriate review and approval at each stage.
How SWT3 addresses it: The witnessAuditIntegrity() call records design control milestones, code review events, validation checkpoints, and periodic audit results. Each anchor identifies the lifecycle phase (design input, verification, validation, transfer), the assessment methodology, and the assessor identity. This creates a tamper-evident record of the development process that supplements the manufacturer's design history file.
AI-AUDIT.1 anchors should appear at each IEC 62304 lifecycle phase: requirements, architecture, detailed design, unit testing, integration testing, system testing. Gaps in the lifecycle sequence indicate missing design control steps. The assessor identity field should match the qualified individuals documented in the manufacturer's quality system. For PCCP changes, AI-AUDIT.1 anchors must document the review and approval decision for each model update.
Model Versioning and Weight Integrity
FDA guidance requires: Manufacturers must maintain traceability of model versions throughout the device lifecycle. Each model update -- whether retraining, fine-tuning, or architecture modification -- must be documented with sufficient detail to reconstruct the change and its rationale. For devices operating under a PCCP, each change must be evaluated against the predetermined boundaries defined in the marketing submission.
How SWT3 addresses it: The witnessModelWeights() call records the model version identifier, a cryptographic hash of the model weight file, the change type (retraining, fine-tuning, threshold adjustment), and the change description. For PCCP-governed devices, the anchor also records whether the change falls within predetermined boundaries. This creates an immutable version history where each model state can be independently verified through its weight hash.
AI-MDL.5 anchors should form a linear version history for each model. The weight hash field allows verification that the model in production matches the model that was validated. For PCCP submissions, every AI-MDL.5 anchor after initial clearance should include a PCCP boundary assessment. If the change type is "architecture_modification" rather than "retraining" or "threshold_adjustment," verify that a new marketing submission was filed -- architecture changes typically exceed PCCP boundaries.
Robustness and Clinical Validation
FDA guidance requires: AI/ML-enabled devices must be validated against appropriate reference standards using clinically meaningful metrics. Validation must include performance on edge cases, out-of-distribution inputs, and adversarial conditions. The manufacturer must demonstrate that the device performs reliably across the full range of conditions described in the intended use statement.
How SWT3 addresses it: The witnessRobustness() call records the reference standard used, the sample size, and the performance metrics achieved (sensitivity, specificity, AUC, calibration, confidence intervals). Separate anchors for standard validation, edge case testing, and adversarial evaluation create a multi-dimensional performance profile. Post-change validation anchors link to the corresponding AI-MDL.5 version anchor.
AI-ROBUST.1 anchors should cover three domains: standard clinical validation, edge case performance, and stress testing. The reference standard field must identify a clinically accepted gold standard -- reviewer skepticism increases when the reference standard is another algorithm rather than clinical ground truth. Sample sizes should be adequate for the performance claims in the device labeling. For PCCP-governed changes, post-change AI-ROBUST.1 anchors must demonstrate that performance thresholds defined in the PCCP are still met.
Transparency and Device Labeling
FDA guidance requires: Device labeling must describe the AI/ML methodology, the characteristics of the training data, known limitations, and performance metrics. Users must understand what the AI/ML component does, how it was developed, and where its performance boundaries lie. Transparency extends to the information provided to patients when AI/ML outputs inform clinical decisions that affect them.
How SWT3 addresses it: The witnessTransparency() call records what was disclosed (methodology, training data characteristics, limitations, performance metrics), the recipient (clinician, patient, regulator), and the delivery channel (device labeling, user interface, instructions for use). Each transparency event is anchored to the specific model version it describes, ensuring that disclosures remain synchronized with the deployed model.
AI-TRANS.1 anchors should correspond to the device's labeling requirements. At minimum, there should be transparency anchors covering methodology, training data, limitations, and performance metrics. The recipient field should include "clinician" and, where applicable, "patient." After any model update (AI-MDL.5), new AI-TRANS.1 anchors should appear to confirm that labeling was updated to reflect the changed model -- stale labeling that describes a previous model version is a common FDA finding.
Fairness and Subgroup Performance Equity
FDA guidance requires: Manufacturers must evaluate model performance across clinically relevant demographic subgroups, including age, sex, race, and ethnicity. Performance disparities across subgroups must be disclosed in device labeling. Where the training data does not adequately represent a subgroup, the manufacturer must disclose this limitation and describe the potential impact on performance for that population.
How SWT3 addresses it: The witnessFairness() call records the bias metric applied (equalized odds, demographic parity, calibration across groups), the demographic subgroup evaluated, the sample size for that subgroup, the performance threshold, and the evaluation result. Regular fairness evaluations -- not just at initial validation -- produce a longitudinal record of performance equity across populations.
AI-FAIR.1 anchors should cover every subgroup identified in the device's intended use statement and labeling. The subgroup sample size field is critical -- fairness evaluations on subgroups with insufficient sample sizes are statistically unreliable. Performance disparities between subgroups should be acknowledged in corresponding AI-TRANS.1 anchors (labeling). For devices used in diverse clinical settings, post-market AI-FAIR.1 anchors demonstrating ongoing subgroup monitoring strengthen the TPLC evidence package.
7. PCCP Evidence Chain
For devices operating under a Predetermined Change Control Plan, the evidence chain for each model update follows a predictable sequence. SWT3 anchors document each step of this sequence, creating an auditable record that the manufacturer can present to the FDA upon request.
Step 1: Pre-Change Baseline
Before any model modification, AI-DRIFT.1 anchors establish the current performance baseline. AI-MDL.5 records the current model version and weight hash. These anchors define the "before" state against which the change will be evaluated.
Step 2: Change Implementation
When the model is updated, a new AI-MDL.5 anchor records the new version, the updated weight hash, the change type, and the change description. The change type field (retraining, fine-tuning, threshold adjustment) determines which PCCP boundary checks apply.
Step 3: PCCP Boundary Verification
AI-ROBUST.1 anchors record post-change validation results against the performance thresholds defined in the PCCP. If all metrics remain within predetermined bounds, the change is documented as PCCP-compliant. If any metric exceeds a boundary, the anchor records the exceedance and signals that a new marketing submission may be required.
Step 4: Review and Approval
AI-AUDIT.1 records the formal review and approval decision for the change. The assessor identity field documents who approved the change and their qualification. AI-HITL.1 may record additional clinical review if the change affects the device's clinical output characteristics.
Step 5: Post-Change Monitoring
After deployment of the updated model, AI-DRIFT.1 resumes continuous monitoring against the new baseline. Any performance degradation following the update is detected and recorded through the same drift monitoring mechanism used before the change.
The strength of a PCCP evidence chain is measured by its completeness. An FDA reviewer will look for all five steps for each model update. A missing AI-ROBUST.1 anchor between an AI-MDL.5 change and an AI-AUDIT.1 approval suggests that the change was approved without post-change validation -- a significant finding. The timestamps on the anchors must follow logical order: baseline before change, validation before approval, monitoring after deployment.
8. FDA Reviewer Quick Reference
| Reviewer Question | Where to Look |
|---|---|
| Is the training data representative of the intended use population? | AI-DATA.1 anchors with demographic composition fields. Cross-reference with the intended use statement in the 510(k) or PMA. Missing subgroups in the data anchors indicate representation gaps. |
| How are model changes tracked and validated? | AI-MDL.5 anchors form a version history. Each change should be followed by AI-ROBUST.1 validation anchors before an AI-AUDIT.1 approval anchor. The weight hash field allows independent verification of model identity. |
| Does this change require a new submission or is it within the PCCP? | AI-MDL.5 change type field distinguishes retraining from architecture modification. AI-ROBUST.1 anchors show whether post-change metrics remain within PCCP thresholds. Boundary exceedances are explicitly recorded. |
| Is real-world performance being monitored? | AI-DRIFT.1 anchors should form a continuous time-series after market clearance. Gaps indicate monitoring interruptions. Trend the current value field to identify gradual degradation. |
| Are clinicians able to override the AI output? | AI-HITL.1 anchors with override status. A non-zero override rate across a meaningful sample demonstrates that clinicians exercise independent judgment. The reviewer role field confirms appropriate clinical qualifications. |
| Has the device been validated against appropriate reference standards? | AI-ROBUST.1 anchors with reference standard, sample size, and performance metrics. Clinical ground truth is the expected reference -- algorithm-to-algorithm validation without clinical correlation will draw scrutiny. |
| Are there known performance disparities across patient subgroups? | AI-FAIR.1 anchors by demographic group. Performance differences should be disclosed in AI-TRANS.1 labeling anchors. Subgroups with insufficient sample sizes should be flagged as limitations. |
| Does the labeling accurately describe the AI/ML component? | AI-TRANS.1 anchors covering methodology, training data, limitations, and performance. After model updates (AI-MDL.5), new AI-TRANS.1 anchors should confirm labeling currency. |
| Has risk management addressed AI-specific hazards? | AI-SAFE.1 anchors with AI-specific hazard categories (distributional shift, adversarial input, automation bias) alongside traditional device hazards. Mitigation status should reflect current state. |
| Were design controls followed during development? | AI-AUDIT.1 anchors at each IEC 62304 lifecycle phase. Sequential timestamps and assessor identities demonstrate that design control milestones were completed by qualified personnel in the correct order. |
9. Quick Start
pip install swt3-ai
# Initialize with healthcare AI profile
swt3 init --profile nist-ai-rmf --tenant YOUR_TENANT
# Run the demo to see data lineage, drift, and safety anchors
python -m swt3_ai.demo
# Or use TypeScript
npm install @tenova/swt3-ai
npx swt3-init --profile nist-ai-rmf
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup
10. References
- FDA: AI/ML-Enabled Medical Devices -- CDRH AI/ML resource page including draft guidance documents
- 21 CFR Part 820 -- Quality System Regulation for medical devices
- IEC 62304:2006+AMD1:2015 -- Medical device software lifecycle processes
- ISO 13485:2016 -- Medical devices quality management systems
- ISO 14971:2019 -- Application of risk management to medical devices
- FDA: PCCP for ML-Enabled Device Software Functions -- Guidance on predetermined change control plans
- IMDRF: SaMD Clinical Evaluation -- International framework for SaMD risk categorization
- EU AI Act Crosswalk -- Comparable comprehensive AI governance framework for EU market access
- SWT3 UCT Registry -- 279 procedures across 10 namespaces
- SWT3 Bidirectional Framework Crosswalks -- Machine-readable JSON, 84 frameworks
- SDK Documentation -- Python, TypeScript, and 8 additional language SDKs