Regulatory Change Impact Simulator
See how a regulatory change propagates through an organization’s digital twin: pick which requirement changed and the simulator traces the impact along real relationships to the affected controls, systems, SOPs, validation packages, and evidence. Impact is classified confirmed (directly linked) vs potential (reached transitively — needs assessment), and nothing beyond the graph’s edges is asserted. Runs on an illustrative twin, not your organization. A scoping aid, not a validated assurance system.
OUTPUT
TIME
Limitations — read before you rely on this
- This is a scoping aid, not a validated system, and not your organization’s digital twin. It runs on an illustrative graph to demonstrate the traversal; reproduce it against your own maintained twin, and treat the output as a map to assess, not a conclusion.
- It shows reachability, not certainty. A "potential" impact means the graph connects the change to that object — whether the revised requirement actually changes it is a judgement the traversal cannot make.
- It is only as complete as the twin. A relationship your graph does not record is an impact this tool cannot show; the capability depends entirely on keeping the twin current and correct.
- It classifies by distance, a deliberately simple, transparent rule. Real impact can jump or stop in ways distance does not capture, so confirmed/potential is a triage to guide assessment, not a substitute for it.
WHAT THIS CALCULATES
How a regulatory change propagates through an organization’s digital twin. From the requirement(s) that changed, it traces the impact along real relationships to the affected controls, systems, applications, SOPs, validation packages, and evidence, and classifies each as confirmed (directly linked to the change) or potential (reached only transitively and needing assessment). It makes "what does this change touch?" a traversal of the graph rather than a memory exercise — and asserts nothing the graph’s edges do not support.
THE METHOD
level(node) = source if distance = 0, confirmed if distance = 1, potential if distance ≥ 2; distance = shortest edge-path from any changed node (BFS)- distance
- the number of relationship hops from the nearest changed requirement to the node, by shortest path
- node
- an object in the twin — a control, system, application, SOP, validation package, or evidence record
- source
- the changed requirement itself (distance 0)
- confirmed
- a node directly linked to the change (distance 1) — impact is supported by a real relationship
- potential
- a node reached only transitively (distance ≥ 2) — impact is plausible but must be assessed to confirm
Traversal is a deterministic breadth-first search over the twin’s directed impact edges, so the shortest distance wins and the result is reproducible. Unknown or unlinked nodes contribute nothing — a missing relationship yields no impact rather than a guess. The public tool runs on an illustrative twin; a real deployment traverses the organization’s own access-controlled graph.
THE INPUTS, AND WHAT THEY MEAN
- Which requirement changed
- The regulatory requirement whose text, interpretation, or applicability changed. It is the seed of the traversal — the change flows outward from here to the controls that satisfy it and everything downstream. You can select more than one.
- The twin (illustrative here)
- The graph of requirements → controls → systems/applications → SOPs → validation packages → evidence. In this public tool it is a fixed illustrative fragment; in a real deployment it is your organization’s own maintained, access-controlled digital twin.
Trace a requirement change through the organization.
Pick which requirement changed and the simulator traces the impact along real relationships to the affected controls, systems, SOPs, validation packages, and evidence. Impact is confirmed (directly linked) or potential (reached transitively — needs assessment); nothing beyond the graph’s edges is asserted. Runs on an illustrative twin, not your organization.
The twin is an illustrative fragment — two requirements governing controls in an eQMS, documented by SOPs and evidenced by validation records. In a real deployment the twin is your organization’s own access-controlled graph. A SPEQ scaffold, not a validated assurance system.
- Audit-trail configuration & review control · CONFIRMED
- eQMS audit-trail module · POTENTIAL
- Audit-trail IQ/OQ record · POTENTIAL
- SOP-QA-014 audit-trail review · POTENTIAL
- eQMS (quality management system) · POTENTIAL
- QA system owner · POTENTIAL
- eQMS validation package · POTENTIAL
1 changed requirement → 1 directly-linked (confirmed) and 6 transitively-reached (potential) impacted objects. Potential impacts need assessment to confirm; nothing beyond the graph’s edges is asserted.
HOW TO READ THE OUTPUT
- Confirmed and potential are a triage, not a ranking. Confirmed impacts are where the change certainly lands — start the assessment there. Potential impacts are leads to check, because a transitive path may or may not carry the change; the tool flags them rather than pretending to know.
- Absence of a link is information. If an object you expected to see is not impacted, either the change genuinely does not reach it or your twin is missing a relationship — both are worth knowing, and the tool will not invent the edge to make the picture look complete.
- The twin is only as good as its edges. Impact traversal is powerful precisely because it uses real relationships, which means an out-of-date or incomplete twin under-reports impact — maintaining the graph is the actual work behind this capability.
- This is the change-impact half of change control. Once you know what a change touches, the reassessment level for each affected system is a separate risk-based decision — see the change-impact assessor.
WORKED EXAMPLE
A revision to 21 CFR 11.10(e) (audit trail) is published. You select it as the changed requirement in the illustrative twin.
- Changed requirement
- 21 CFR 11.10(e) — audit trail
- Twin
- illustrative eQMS fragment
RESULT
The audit-trail control is a confirmed impact because the requirement directly governs it — that is where reassessment certainly starts. The eQMS module, the review SOP, the system, and the validation evidence are potential impacts: the change plausibly reaches them through the control, but each must be assessed to confirm whether the revised requirement actually changes them. The tool has drawn the map; the assessment is still yours.
REGULATORY BASIS
- 21 CFR Part 11 — Electronic Records; Electronic Signatures
- A canonical requirement whose change ripples into controls, systems, and evidence — the kind of propagation this traversal maps.
- EU GMP Annex 11 — Computerised Systems
- The periodic-evaluation and change-control expectations that make requirement-to-system traceability necessary.
- ICH Q10 — Pharmaceutical Quality System
- The change-management principle that a change be assessed for its full impact across the quality system, not just its point of origin.