Reproducible robustness runs: seeds, dataset hashes and the protocol run record

The method

Art. 15(1) of Regulation (EU) 2024/1689 requires a high-risk AI system to perform consistently in accuracy, robustness and cybersecurity throughout its lifecycle, and Art. 9(8) requires testing against prior defined metrics and probabilistic thresholds. Annex IV section 2(g) asks the technical documentation to hold the validation and testing procedures, the validation and testing data with their main characteristics, the metrics, and the test logs and test reports. The duty applies from the Annex III application date 2027-12-02Deferred. A test report that states a metric value without the data, the seed and the environment behind it does not let an assessor repeat the measurement, and the Art. 15 obligation page lists that gap among its common findings.

The seed matters because of the method. ISO/IEC TR 24029-1:2021Published, a published technical report, groups robustness assessment into statistical, formal and empirical methods. A statistical method samples perturbed inputs and estimates the metric with a confidence interval, which is step 18 of PR-15-ROB. The sample depends on the state of the random generator, so a run with an unrecorded seed produces a value that no second run can match. Step 1 of the protocol records the random seeds in the environment manifest, one seed per generator that touches the run: the perturbation sampler, any data shuffling, and the sampling temperature of a system built on a language model. A seed fixes the sampler and not the arithmetic. Two tool versions or two accelerators can round differently, so the manifest also records the tool versions and the hardware, and the interval of step 18 carries the sample size that absorbs the residual variation.

The dataset hash fixes the second variable. Step 10 assembles a held-out set untouched by training or model selection and a distribution-shifted set from the condition register, and records sample counts and hashes in the test set provenance record. The hash is computed on the file with sha256sum, and for a set stored as many files on the sorted list of per-file hashes. A held-out set that changes between two runs breaks the version consistency comparison of step 34, because the difference per metric then mixes a model change with a data change. The provenance record also answers Annex IV section 2(g) on the validation and testing data and section 2(d) on the provenance of the data sets. A pitfall from the protocol's own record structure: a set re-exported from a database with a different row order or line ending carries a new hash while holding the same samples, so the record names the export tool and its configuration next to the hash.

The environment manifest of step 1 holds the third variable: the model version hash, the inference configuration, the tool versions and the hash of the dependency lock file. Step 14 then runs the held-out set through the frozen model and records every input, output and metric value, which is the test log that Annex IV section 2(g) names. Step 45 records the re-test triggers: the model, data and operating-environment changes that invalidate each report, with an archive of every record by hash.

What the test produces

Every report of PR-15-ROB v1.0 ships with a protocol run record: the executed copy of the versioned protocol, with the run identifier, the system version hash, the environment manifest, a step log that marks each step as executed or skipped with the reason, the data set manifest with hashes, and the operator function without an individual name. The record is delivered as a JSON run log with a Markdown rendering. The example below is synthetic; every hash, count, path and seed is a placeholder and none is a requirement of the Act.

{
  "_note": "synthetic example, placeholder values",
  "run_id": "RUN-SYN-0001",
  "protocol": { "id": "PR-15-ROB", "version": "<from the methodology page>" },
  "system": { "id": "cv-ranker", "model_version": "v3", "weights_sha256": "3f9c...e1a0" },
  "environment": {
    "inference": { "endpoint": "http://localhost:8080/rank", "batch_size": 64, "precision": "fp32" },
    "seeds": { "numpy": 4711, "torch": 4711, "perturbation_sampler": 4711 },
    "tool_versions": { "python": "3.12.4", "numpy": "2.1.0", "onnxruntime": "1.19.0" },
    "requirements_lock_sha256": "b7d2...40c9",
    "hardware": "cpu, x86_64"
  },
  "datasets": [
    { "id": "heldout-v3", "sha256": "9a1e...77b2", "samples": 12000, "origin": "client-provided" },
    { "id": "shifted-v3-q", "sha256": "c04d...1e58", "samples": 3000, "origin": "assembled in step 10" }
  ],
  "steps": [
    { "step": 1, "status": "executed", "record": "manifest/environment.json" },
    { "step": 10, "status": "executed", "record": "provenance/test-sets.json" },
    { "step": 14, "status": "executed", "record": "results/heldout-v3.csv" },
    { "step": 18, "status": "executed", "config": "goal RG-03, 2000 draws per magnitude", "record": "results/rg-03-interval.json" },
    { "step": 22, "status": "skipped", "reason": "system does not learn after placing on the market" }
  ],
  "operator_function": "test engineer",
  "independent_check": "second operator function repeated step 18 from this record"
}

A repeat run starts from this record. The third party verifies the dataset hashes, sets the seeds from the manifest, runs steps 14 to 18 against the same model version, and compares each value with the recorded one. A value inside the recorded interval confirms the report. A value outside it is a finding about the environment or the data, and the run record names which of the two moved. The run record does not decide whether the declared level is the appropriate one; the protocol's limitations section leaves that judgement with the provider under Art. 15(1) and its notified body and counsel.

The reports and their run records are delivered by the robustness and adversarial testing service within the limits stated at what we cannot do. After a model, data or environment change, the regression testing service reads the re-test triggers of step 45 and repeats the affected steps from the same run record, so that the delta report compares two runs that differ in one recorded variable.

What to do now

1. Write the environment manifest before the first measurement: model version hash, inference configuration, one seed per random generator, tool versions and the hash of the dependency lock file, as step 1 of PR-15-ROB v1.0 asks.
2. Hash every test set with sha256sum and record the count, the hash and the export tool in the test set provenance record of step 10.
3. Run the held-out and shifted sets and keep every input, output and metric value as the test log that Annex IV section 2(g) names, following the robustness testing guide.
4. Report each statistical result with its sample size and confidence interval, and mark any generator that could not be seeded in the run record.
5. Record the re-test triggers of step 45 and file the run record next to each test report in the Annex IV section 2(g) part of the technical documentation.

Related pages

The obligation, protocol, guide, services and hubs this post rests on.

Obligations

• Art. 15

Protocols

• PR-15-ROB v1.0

Guides

• Robustness testing with ISO/IEC TR 24029-1

Services

• Robustness and adversarial testing
• Regression testing after substantial modification

ICP hubs

• Annex III providers
• GPAI providers

Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.

Ask about scopehello@aiassurancelabs.com