Substantial Modification

The primary trigger for re-registration. If the system is deployed for a use case not covered in the original Intended Purpose Declaration, it is a substantial modification.

• Example: A medical imaging AI cleared for detecting fractures is repurposed to diagnose early-stage tumors.
• Impact: The original risk classification and conformity certificate become void, requiring a new assessment against the correct regulatory category.

Modifications to the algorithmic architecture that materially affect output generation. This is distinct from minor bug fixes or security patches.

• Triggers: Switching from a decision-tree ensemble to a deep neural network; altering the objective function that governs model optimization.
• Non-Triggers: Patching a memory leak; updating a library dependency without changing inference logic; retraining on fresh data without changing the model architecture or intended use.

A measurable degradation or unexpected improvement in critical metrics that alters the risk-benefit calculus.

• Degradation: A sudden drop in precision for a specific demographic subgroup, introducing a new disparate impact risk.
• Capability Jump: A language model gains emergent reasoning abilities after a fine-tuning run, enabling it to bypass safety guardrails.
• Monitoring: Continuous Post-Market Monitoring plans must define thresholds that automatically flag a potential substantial modification.

Deploying the same software on fundamentally different hardware or in a new operational environment can trigger re-assessment if it introduces novel failure modes.

• Example: An autonomous vehicle perception stack validated on a sedan is deployed on a heavy-lift cargo truck, drastically changing braking dynamics and blind-spot geometry.
• Context: Moving from a controlled factory floor (low-risk environment) to a public hospital ward (high-risk environment) constitutes a substantial change in the system's operational profile.

While continuous learning is often expected, a permanent shift in the input data distribution that was not anticipated in the original Technical Documentation File can be a trigger.

• Scenario: A credit scoring model trained on a national population is deployed in a new geographic market with fundamentally different financial behaviors and regulatory definitions of creditworthiness.
• Distinction: Normal seasonal variation is not a trigger; a permanent, structural break in the underlying data generating process likely is.

Changes that reduce or remove the Human Oversight Mechanisms specified in the original conformity assessment.

• Trigger: Removing a mandatory human-in-the-loop confirmation step for high-stakes decisions; increasing automation bias by obscuring model confidence scores from the operator.
• Rationale: The original risk mitigation strategy relied on specific human intervention points. Bypassing these fundamentally alters the residual risk profile disclosed to regulators.