Reproducibility: Encode the Change Process and the Audit Becomes Architecture

Reproducibility is the sixth of the seven properties, and it is the one that decides how an ISO 42001 audit spends its time. Per Schellman's guide to the process, Stage 1 reviews the documentation and design of the AI management system and lasts 1–2 days. Stage 2 "evaluates the operational effectiveness" of those controls and runs 3–9+ days, followed by annual surveillance audits for the three-year life of the certificate. Only the short first stage reads your policy. The expensive part is "prove the policy ran, every time, including the times nobody was watching."

That is the gap reproducibility closes, by making the evidence a property of the environment and the workflow rather than something you assemble for the auditor. When the change process is encoded as the workflow itself, "do you follow your policy?" stops being a question about discipline and becomes a question about architecture.

Stage 2 audits operation, not paperwork

A traditional change-management answer is a document plus a sample: here is the policy, here are 25 sampled changes, here is evidence each one was reviewed. The sample exists because the policy and the execution are separate things, and humans drift. Surveillance audits repeat the exercise every year, on a sampling basis; Schellman scopes them at 2–5+ days against Stage 2's 3–9+.

AI volume breaks the sampled-discipline model from both ends. More changes mean more chances to drift, and an agent will not remember a policy it was only told about. The compliance platforms channeling auditor questions say this plainly: Vanta's audit-preparation guidance distills the auditor's stance as "evidence, not policies," and asks whether you can show "oversight is consistent," not point-in-time reviews.

The fix is to remove the gap between policy and execution entirely. If the only way a task can move is through the defined sequence, consistency is not a behavior you sample for.

The encoded process is the policy

The reference architecture runs every task through the same ordered sequence, write then review then approve then ship, and parks it at the declared gates. A change cannot skip the review step, because no path through the workflow omits it. The author cannot self-approve, because the approval step belongs to a different actor, which is the segregation of duties property. Reproducibility does not add a new mechanism here. It reads the workflow definition itself as the change-management policy in executable form.

This inverts the usual audit posture:

The full lifecycle of every task is recorded against the process it ran under. So the Stage 2 answer is one artifact: here is the workflow definition (the policy), and here is every task's recorded path through it (the evidence).

Versioned images reproduce the conditions

The second half of the property is environmental. Auditors ask versions of "can you reconstruct the conditions?" constantly. Kognitos's SOX question list includes "How is the AI's decision logic version-controlled?" and "How do you handle changes to the underlying model?" A-LIGN sets the retrieval bar: "Can your organization demonstrate, for any deployed agent, what it was capable of at any point in the past six months?"

Because every task environment boots from a versioned, known-good image, the conditions a change was produced under are reproducible on demand. The task record names the image version; the image still exists; you can boot it and stand in the environment the agent stood in. A-LIGN's prescription that agent updates be treated "like product launches, not software patches" falls out for free: a new image version is a release, with a version number an auditor can ask about. The laptop model has no answer here at all. Whatever was on the engineer's machine that day is gone. See versioned images for the mechanics.

What reproducibility does not promise

Two fences.

First, this is reproducibility of conditions and process, not of output. Re-running the same task on the same image will not produce the same code; models are not deterministic, and the corpus is silent on bit-exact replay of agent output. What you can replay is the session record of what the agent actually did, which is the audit trail's job, not this property's.

Second, the image versions the sandbox, not the brain. Auditors ask "what version ran on date X" about the model and prompts too, and the field's answer there is weaker: upstream model upgrades arrive on the vendor's schedule, and no platform in this guide's corpus publishes model-version pinning as a compliance control. Record the model identifier in the task log and treat a model change as a change-managed event.