Copy the evidence pack from site one, change the facility name, present it to the local compliance team. That approach survives exactly until the auditor at site two asks who here holds the access grants, which local SOP the change-control sign-offs were routed through, and what the validation evidence looks like against this site’s scanner fleet or production line. At that point the pack stops being an asset and becomes a liability, because it asserts things about a facility whose records it does not contain.
A pack is portable when it is explicitly layered. Some sections are authored once and inherited unchanged; others are structurally identical across sites but must be re-evidenced locally with that site’s own artefacts. Teams that draw this line before the second deployment hand over an invariant skeleton and fill a bounded set of local slots. Teams that never draw it re-litigate the entire pack at every site.
What does pack portability between sites actually mean?
It means the pack has two kinds of sections, and each section knows which kind it is.
The invariant layer describes the AI workflow as designed: the pack structure itself, the mapping from controls to regulatory requirements, model provenance, the intended-use statement, and the design of the validation protocol. None of these change because a different hospital or a different plant is running the workflow. The model was trained on the data it was trained on regardless of who deploys it. The intended-use boundary is a property of the system, not of the facility.
The per-site layer is everything whose truth is local. Access trails name people who exist at one site. Training records attach to those same people. Change-control sign-offs route through a local quality SOP with local approvers. Environment and equipment configuration describes hardware that physically sits in one building. Data-handling lineage runs through site-specific systems — this PACS, that LIMS, this batch-record instance.
The test for which layer a section belongs to is short: if this facility disappeared tomorrow, would the artefact still be true? If yes, it is invariant. If no, it must be re-collected. This is the property the parent hub asserts for the pack format, and it is only real when the split is written down section by section rather than assumed.
The layering, section by section
| Pack section | Layer | Why |
|---|---|---|
| Pack structure and section index | Invariant | Same questions, same order, every site |
| Control-to-requirement mapping | Invariant | Maps controls to HIPAA/GxP clauses, not to facilities |
| Intended-use statement | Invariant | A property of the model and workflow |
| Model provenance and lineage | Invariant | Training data and versions do not change per deployment |
| Validation protocol design | Invariant | The protocol is written once; its executions are not |
| Access-trail evidence | Per-site | Names local identities and local grant history |
| Training records | Per-site | Attach to the people who operate the workflow here |
| Change-control sign-offs | Per-site | Routed through the local quality SOP and approvers |
| Environment and equipment configuration | Per-site | Describes hardware physically present at this site |
| Data-handling lineage | Per-site | Runs through this site’s clinical or manufacturing systems |
| Validation evidence per regulated step | Mixed | Protocol inherited; executions re-run where local conditions affect the step |
The mixed row is where most of the argument lives, and it is the row teams get wrong in both directions — either re-validating everything or inheriting everything.
Why local evidence cannot be inherited
Access trails and training records look inheritable because the workflow is identical. It is the actors that differ. At site one, three radiologists and two IT administrators hold grants against the inference service; at site two, a different five people hold grants issued by a different identity provider under a different naming convention. An auditor asking “who could read this patient data during the period under review” is asking about people, and the answer from site one is factually wrong at site two. The same logic applies to training: competency is held by individuals, not by the workflow they operate.
Change-control routing is subtler. The sign-off content — what changed, which model version, which regulated steps were affected — is the same information at every site. The route is not. A hospital network commonly runs one clinical change board per facility with locally delegated authority, so the same model update generates several independent approval records. The pack must represent this without forking: keep one change-control section with one schema, and hold the per-site approval records as instances under it. The moment you fork the section itself, the invariant layer has silently split into two packs that will drift.
We see the drift problem more often than the initial-split problem. A second site is stood up, someone edits the intended-use statement in the site-two copy to reflect a local nuance, and eighteen months later two packs disagree on what the model is for. Version the invariant layer centrally, reference it by version from each site’s pack, and treat any local edit to an invariant section as a change to the central artefact — one that propagates to every site or does not happen at all.
When adding a site triggers re-validation
Not every new site triggers re-validation, and not every trigger requires re-validating the whole workflow. The scoping question is which regulated steps are exposed to something the local environment changes.
- Input-acquisition change — a different scanner fleet, different reconstruction kernels, a different vendor’s line sensors. Re-validate the steps whose inputs those devices produce, against local data, using the inherited protocol.
- Integration change — a different EHR, LIMS or historian feeding the workflow. Re-validate the data-handling and mapping steps; the model’s internal steps are unaffected.
- Infrastructure change — different GPU generation, different container runtime, different Kubernetes version. Re-run the qualification steps that depend on numerical or throughput behaviour, and record the environment configuration; the clinical acceptance criteria are inherited.
- No material change — same equipment, same integrations, same stack image. Inherit the validation executions and record the equivalence justification as its own evidence item.
That last bullet matters. “Inherited” is not the same as “absent” — a site that inherits validation evidence still needs a dated, signed artefact stating why inheritance is justified, or the auditor is looking at a gap. Imaging workflows are where this bites hardest, because scanner-to-scanner variation can move model behaviour without changing anything about the model; the validation-pack view of that problem is developed separately from this one.
What this buys, and what it does not
The commercial reading is straightforward: with an explicit split, the number of per-site evidence items is countable before the rollout starts, so each additional site’s audit prep becomes filling a bounded set of slots rather than rebuilding a binder. The ratio of invariant to per-site sections tells you how much of the first site’s work is genuinely reusable — and that ratio is worth computing early, because a workflow with heavy local integration will have a per-site layer thick enough to change the rollout plan. In our engagements, the sites that go badly are almost never the ones with unusual equipment; they are the ones where nobody decided in advance which layer a section belonged to. (Observed across TechnoLynx governance engagements; not a benchmarked rate.)
What the split does not buy is exemption. A thin per-site layer is still a layer, and it still has to be populated with local artefacts before the local compliance team will sign. The gain is structural predictability, not reduced obligation. If you want the full section anatomy the split operates on, the section-by-section pack anatomy sets out which question each section owns; the broader governance and trust position is on our AI governance and trust page.
Which raises the question worth taking into your next rollout meeting: for the workflow you are about to deploy at a second facility, how many of your pack’s sections could you defend as invariant today — and how many would turn out, under an auditor’s follow-up, to have been per-site all along?
Frequently Asked Questions
What does pack portability between sites mean in practice — which sections are invariant and which are per-site? The core of Multi Site Evidence Pack is this. Portability means the pack is split into sections authored once centrally and sections instantiated locally. Pack structure, control-to-requirement mapping, model provenance, intended-use statement and validation protocol design are invariant. Access trails, training records, change-control routing, environment and equipment configuration, and data-handling lineage are per-site.
Which evidence items must be re-collected at every site, and why can they not be inherited from the first site? Anything naming local people, local systems or local hardware: access grants, training records, approval records, integration lineage and equipment configuration. They cannot be inherited because the auditor’s question is about this facility’s actors and systems, and the first site’s records are factually wrong answers to it.
How do access trails and training records differ per site when the AI workflow itself is identical? The workflow is identical; the actors are not. Different individuals hold grants, issued by a different identity provider under a different naming convention, and competency records attach to those individuals rather than to the workflow they operate.
When does adding a site trigger re-validation, and how is that re-validation scoped to affected regulated steps rather than the whole workflow? Re-validation is triggered when the local environment changes something a regulated step depends on — input-acquisition equipment, upstream integrations, or the infrastructure and software stack. Scope it to those steps only, execute the inherited protocol against local data, and where nothing material changed, record a dated equivalence justification instead.
How is local change-control routing represented in the pack without forking the pack structure? Keep one change-control section with one schema and hold each site’s approval records as instances beneath it. The sign-off content is common; only the route and the approvers vary. Forking the section itself is what turns one pack into several that drift.
How should the pack handle sites with different equipment, imaging fleets, or line configurations feeding the same model? Treat equipment configuration as a per-site evidence item and re-execute the validation steps whose inputs that equipment produces. The model’s internal steps and the acceptance criteria stay inherited; only the executions exposed to the local devices are re-run.
How do you version and maintain the invariant layer so that site copies do not silently drift apart? Version the invariant layer centrally and have each site’s pack reference it by version rather than embedding a copy. Any proposed local edit to an invariant section becomes a change request against the central artefact, propagated to all sites or rejected.
Five invariants let one pack serve twelve locations
Calibration data and edge-case distributions will vary by site, but core architecture claims, failure mode taxonomy, and escalation logic can be documented once and referenced everywhere.
