Q223 - Model_provider_version_definition_example_and_why_it_matters
Q223 — Model, provider, version — definition, example, and why it matters in RAIDT
← RAIDT · Star S4 - Evidence Architecture and Artefacts · primary item: S4.08 · Model/provider/version identifier
D. Evidence Architecture | Ordered by mind-map priority: inner circles first, then operational detail.
Appears in sources
workshop_dense_100#slide 46
Answer
In RAIDT, 'model/provider/version' is a configuration-provenance field in the run-level evidence pack. It records which provider supplied the model service, which model or deployment identifier was invoked, and which version or immutable deployment state was active where that can be known. The point is not catalogue-style documentation. The point is to bind one output to the actual technical service that generated it, so the organisation can later reconstruct, inspect, and challenge the run. This follows directly from RAIDT's premise that the run is the unit of governance.
A simple example would be a healthcare note summarisation run that stores a prompt template version, a model deployment ID, the provider, decoding settings, any retrieval snapshot hash, the output hash, and the recorded review action. In RAIDT, those fields are assembled into a reviewable evidence object rather than left scattered across logs. They then support a score profile across the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability).
Why it matters is straightforward. Model-level documents can describe a system in general terms, but they do not show what happened in one disputed use. By contrast, model/provider/version lets reviewers connect provenance, oversight, and behavioural evidence to a specific run. Because RAIDT treats influence methods as governance interventions, deployment choice is governed configuration, not metadata clutter. Under the anchors 1=missing / 3=partial / 5=audit-ready, this field is therefore basic to determining whether a run can genuinely be reconstructed and defended.
Practical example
In a public-service eligibility advice workflow, a caseworker uses a generative assistant to draft a response to a citizen. The answer draws on a policy retrieval step and is then approved by staff. Later, the citizen disputes the advice and asks which system produced it. If the organisation only knows that 'an LLM' was used, it cannot meaningfully evidence the run.
If the evidence pack records the provider, exact deployment identifier, and active version, alongside the prompt version, retrieval snapshot, and approval record, the review becomes concrete. Auditors can examine whether the system used an approved deployment, whether the response was generated before or after a provider update, and whether the resulting score profile on Auditability and Traceability was justified. In RAIDT terms, that turns a vague assurance claim into reviewable governance evidence.
Sources in RAIDT papers
08-RAIDT_Foundations_M_V5013-RAIDT-Evidence-Review_M_v10