S4.01 - run_id

S4.01 ? run_id

flowchart LR
    A[Fragmented records
prompts, outputs, logs, notes] --> B[RAIDT
run-level evidence framework]
    H[Practical fields
timestamp, prompt ID, hashes,
tool trace, reviewer notes] --> C[[run_id
unique linking spine for one run]]
    B --> C
    C --> D[Evidence pack]
    C --> E[RAIDT score profile]
    D --> F[Reviewer reconstruction
and contestability]
    E --> G[Governance readiness
and organisational learning]

? Star S4 - Evidence Architecture and Artefacts

Star context: Specifies the concrete fields and artefacts that make a run record inspectable, joinable, and reconstructable inside RAIDT's run-level evidence architecture.

Academic picture

Definition / background

run_id is the unique identifier assigned to one specific GenAI run so that all evidence generated in that run can be connected, retrieved, and reviewed as a single unit. In RAIDT, a run is one configured use of a generative AI system for a defined task, at a particular time, in a particular organisational context. The run_id is therefore the identifier for the unit of governance itself.

Conceptually, run_id sits at the boundary between record architecture and governance method. In ordinary data management, identifiers are often used for indexing or transaction handling. In RAIDT, the identifier has a more specific function: it makes the evidential unit inspectable by ensuring that prompts, system settings, retrieved materials, outputs, reviewer interventions, and decision records can be shown to belong to the same event of use.

This distinguishes run_id from nearby concepts. It is not the same as a timestamp, because many runs may occur close together in time. It is not the same as a prompt ID, because the same prompt template may be reused across many runs. It is not the same as a case ID, document ID, or user ID, because those refer to surrounding entities rather than to the run itself. run_id identifies the run as the core evidential container.

Within RAIDT, this item belongs inside Evidence Architecture and Artefacts because the framework depends on run-level evidence being linkable across multiple artefacts. Without a stable run_id, an evidence pack becomes fragile, the basis of a score profile becomes harder to defend, and the claim that a particular run can be reconstructed weakens significantly. The identifier is therefore a small field with large governance consequences.

Why this concept matters

run_id solves a basic but consequential governance problem: evidence can exist without being governable if there is no reliable way to prove which artefacts belong together. Organisations often capture many pieces of information around GenAI use, but when these are stored across prompts, tools, review forms, and logs, the absence of a common identifier makes later reconstruction uncertain.

The concept also prevents a common confusion between having data and having linked evidence. A folder full of outputs, screenshots, prompts, and logs may look comprehensive, yet if those artefacts cannot be tied to one specific run, reviewers cannot confidently determine what happened in that event. run_id converts scattered records into a coherent evidential chain.

If run_id is missing, risks appear quickly: duplicate or ambiguous records, weak audit trails, failed reviewer reconstruction, difficulty contesting a disputed output, and reduced confidence in any score assigned to the run. For organisations using GenAI in operational settings, this is not a cosmetic metadata issue. It is a precondition for evidence integrity.

RAIDT uses run_id to move governance from principles to operations. It provides the reference point that allows one run to be assembled, checked, challenged, compared, and learned from over time.

Key idea: run_id matters because RAIDT can only govern one run as one evidential unit if every artefact for that run is unambiguously linked together.

What this item enables

It enables all artefacts from one run to be linked into a single evidence record.
It enables reviewers to reconstruct the chronology and content of a run without guessing which files belong together.
It enables evidence-pack assembly across prompts, outputs, logs, tool traces, and human review notes.
It enables defensible scoring because the underlying evidence can be traced back to one identifiable run.
It enables de-duplication and comparison between runs that use the same prompt, model, or workflow.
It enables escalation, audit, and incident review by giving investigators a stable reference point.
It enables organisational learning because lessons can be attached to a concrete run rather than to vague recollections of system use.

Practical example / likely audience question

Audience question

If a system already records timestamps, filenames, and user details, why does RAIDT still need a separate run_id?

Answer

The concern behind this question is that run_id may appear redundant if other metadata already exist. The direct answer is that timestamps, filenames, and user details describe aspects of a run, but they do not reliably define the run as a single governed event. Two runs may involve the same user, the same prompt template, similar filenames, and closely adjacent times. Without a distinct run identifier, the evidence boundary remains uncertain.

A practical example is a policy analyst using a GenAI drafting tool several times in one afternoon to generate alternative versions of a briefing note. The same operator, same task label, and same source folder may be involved in each attempt. If one output is later challenged, reviewers need to know exactly which prompt instance, model setting, retrieved material set, and review action belong to that contested run. run_id makes that possible.

RAIDT handles this better than a generic AI governance approach because it does not treat metadata as a loose collection of helpful fields. It treats the run as the unit of governance and therefore requires an explicit identifier for that unit. run_id is what turns many surrounding records into one inspectable object of review.

Practical example in RAIDT terms

Consider a finance setting in which a bank compliance analyst uses a GenAI assistant to draft a summary of unusual transaction activity for internal escalation. The GenAI use case is legitimate, but several similar drafts may be produced during the same case review as the analyst refines the request, checks source excerpts, and compares wording options.

The run-level issue is not simply whether the model performed well in general. The issue is whether one particular draft summary can be reconstructed and justified if it is later questioned by a senior reviewer or regulator. The evidence needed includes the run_id, timestamp, analyst role, task label, prompt version, prompt hash, model/version identifier, retrieved case documents, output hash, reviewer notes, and final escalation decision.

The most affected RAIDT pillars are Auditability and Traceability, because the organisation must show that the output under scrutiny is the output from this run rather than from a neighbouring attempt. Responsibility is also affected because the analyst and reviewer roles must be attached to the same run record. Governance readiness improves because the bank can present one coherent evidence pack rather than a bundle of partially related artefacts.

Detailed link to RAIDT

run_id links to RAIDT in four ways.

First, it gives operational form to RAIDT's core idea that governance should attach to one concrete run rather than to general claims about a model or policy.

Second, it links directly to the run as the unit of governance by naming that unit in a way that can be propagated across all relevant artefacts.

Third, it stabilises the evidence pack and the score profile because every prompt, output, review note, and trace element can be assembled under one run reference.

Fourth, it supports reviewability, contestability, audit readiness, and organisational learning because later reviewers can ask for one run_id and reconstruct the relevant event with less ambiguity.

run_id ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

Link to the five RAIDT pillars

Responsibility

run_id supports Responsibility by ensuring that accountability records attach to the correct run rather than to a general workflow or user account.