S4.02 - Timestamp

S4.02 ? Timestamp

flowchart LR
    A[Temporal governance problem
Models, prompts, retrieval, and policies change over time] --> B[RAIDT
Run-level evidence framework]
    H[Operational fields
ISO 8601, UTC, timezone, start/end time, tool events] --> C[[Timestamp
Temporal anchor of the run]]
    B --> C
    C --> D[Evidence pack integrity]
    C --> E[Score profile defensibility]
    C --> F[Reviewer reconstruction]
    C --> G[Governance readiness
Reviewability, contestability, audit readiness]
    C --> I[Temporal interpretation
Which policy, model, and index applied then]
    I --> G
    D --> G
    E --> G
    F --> G

? Star S4 - Evidence Architecture and Artefacts

Star context: Identifies the temporal anchor that makes a RAIDT run record reconstructable, comparable, and reviewable across changing models, prompts, policies, tools, and evidence sources.

Academic picture

Definition / background

A timestamp is the recorded date and time associated with a specific RAIDT run, ideally captured in a standard machine-readable format such as ISO 8601 and anchored to an explicit timezone or UTC reference. In the simplest sense, it answers the question: when did this run occur? In governance terms, however, it does much more than record a clock value. It provides the temporal reference point that allows the run to be interpreted against the exact technical and organisational conditions that existed at that moment.

Conceptually, timestamping comes from long-established practices in auditing, logging, security, records management, and distributed systems, where events must be ordered and reconstructed reliably. In GenAI governance, the same logic becomes more important because outputs are often shaped by components that change rapidly: prompts are revised, models are updated, retrieval corpora are refreshed, moderation rules shift, and human oversight arrangements evolve. A run record without time is therefore incomplete, because it cannot be properly located in the sequence of changes that shaped it.

Within RAIDT, timestamp is not the same as a file creation date, a document version date, or a casual note of when someone remembers using the system. It is the authoritative temporal marker attached to the run as a governed event. It differs from adjacent fields such as run_id, which uniquely identifies the run, and Prompt ID and version, which identifies what was used. Timestamp explains when that identified configuration was instantiated.

This is why the item belongs inside RAIDT's evidence architecture. RAIDT treats the run as the unit of governance, and every governed run exists in time as well as in context. The timestamp helps convert a run from a transient interaction into an inspectable evidence object that can sit inside an evidence pack, support pillar scoring, and enable later review, challenge, comparison, and improvement.

Why this concept matters

Timestamp solves a basic but consequential governance problem: organisations often know that an AI output was produced, but cannot reliably reconstruct the exact moment of production relative to changing models, policies, datasets, and review rules. That gap creates ambiguity during assurance, incident response, quality review, and external scrutiny.

A clear timestamp avoids confusion between similar but different questions, such as when a file was saved, when a reviewer opened it, when a source document was last updated, and when the AI run itself occurred. If these are conflated, accountability weakens. An organisation may defend or criticise the wrong configuration, cite the wrong policy version, or misunderstand whether the output reflected the knowledge base available at the time.

For organisations using GenAI in operational settings, the absence of a trustworthy timestamp creates practical risk. It becomes harder to investigate harmful outputs, harder to compare runs over time, harder to prove that a required review step occurred before release, and harder to explain apparent drift in system behaviour. Timestamp therefore helps RAIDT move governance from abstract principles to operational evidence by making the run chronologically intelligible.

Key idea: Timestamp matters because responsible governance requires not only knowing what happened in a run, but knowing precisely when it happened in relation to changing technical and organisational conditions.

What this item captures

The recorded time at which the governed run occurred.
The temporal ordering of one run relative to earlier and later runs.
The link between a run and the prompt, model, policy, retrieval index, or adapter version that was in force at that moment.
The basis for reconstructing incidents, exceptions, escalations, and review decisions in sequence.
The temporal context needed to judge whether evidence, sources, or approvals were valid at the time of use.
The minimum chronology required for a run-level evidence pack to support audit and contestability.

Practical example / likely audience question

Audience question

If we already store the run_id, prompt version, and output, why do we still need a timestamp?

Answer

The concern behind this question is the assumption that identification alone is enough for governance. It is not. A run_id can tell us which run we are discussing, but it does not tell us where that run sits in time relative to model updates, policy changes, retrieval refreshes, or reviewer interventions. In a dynamic GenAI environment, those temporal relationships are often decisive.

The direct answer is that timestamp makes the rest of the evidence interpretable. Suppose an organisation can show the exact prompt version and model identifier used in a run, but cannot prove whether the run happened before or after a safety policy update. During review, that missing temporal anchor means the organisation cannot reliably defend whether the run complied with the controls that should have applied.

RAIDT handles this better than a generic AI governance approach because it ties timestamp to a run-level evidence architecture rather than treating it as miscellaneous metadata. In RAIDT, timestamp sits alongside other run fields so that reviewers can reconstruct a complete event: what was done, by whom, with which configuration, and at what time. That is a stronger basis for assurance than a policy statement saying that logs are generally kept.

Practical example in RAIDT terms

Consider a healthcare use case in which a hospital team uses a GenAI assistant to draft discharge summaries from structured notes and retrieved clinical guidance. A specific run produces a suggested summary for a patient at 08:42 UTC on 12 March 2026. Later that day, the hospital updates the retrieval index to remove an outdated antibiotic recommendation and introduces a stricter review rule for medication-related outputs.

The run-level issue is straightforward: if a clinician later questions why the draft referenced the outdated recommendation, the organisation must know whether the run occurred before or after the retrieval update and before or after the stricter review rule took effect. The evidence needed includes the run timestamp, retrieval index ID, document hashes, model version, prompt version, reviewer notes, and any downstream approval or override record.

The RAIDT pillars most affected are Auditability, Traceability, and Dependability, with Responsibility also clearly engaged. Timestamp improves governance readiness here because it allows the hospital to reconstruct the run against the correct temporal state of its system and policy environment. Without that field, the organisation may know what output was produced but still be unable to explain whether the output reflected an outdated knowledge base, a delayed control rollout, or reviewer non-compliance.

Detailed link to RAIDT

Timestamp links to RAIDT in four ways.

First, it supports RAIDT's core idea that governance should be grounded in evidence about specific runs rather than generic claims about a system.
Second, it gives each run a temporal location, making the run-level record reconstructable in relation to version changes, tool events, and organisational controls.
Third, it strengthens both the evidence pack and the score profile because several governance judgements depend on whether evidence can be sequenced and validated over time.
Fourth, it improves reviewability, contestability, audit readiness, and organisational learning by allowing reviewers to distinguish between failures of design, failures of timing, and failures of control execution.

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

In practice, timestamp is one of the fields that lets RAIDT connect technical artefacts to organisational judgement. It turns a run from an isolated output into a time-situated governance event.

Link to the five RAIDT pillars

Responsibility

Timestamp supports Responsibility because obligations, approval rules, and escalation expectations are time-bound in practice. An organisation can only judge whether people acted responsibly if it can show which process, policy, or review requirement applied when the run occurred.