Step 3 of 6 · Testing - practitioner kit

Run Record Template

One record per controlled run, with versions, run type, chain states, outcome and evidence references.

Use this template

A template is not evidence. Fill in sanitized identifiers only.

Purpose

Preserves each execution separately so results can be compared, reproduced and audited.

When used: During execution, completed immediately after every baseline, positive control, stimulus, variant or regression run.

Run identity
Field	What to record
Assessment ID	From the Test Plan.
Case ID	Library or local case identifier.
Run ID	Unique per execution, for example ASM-2026-014/PI-TST-006/R03.
Date / time / timezone	Start and end, with time zone.
Tester	Person who executed and recorded the run.
Environment	Named sandbox or test environment.
Principal / test account	Identity the actions ran under.
Run type	Baseline, positive control, test stimulus, parameter variant or regression.

If any of these differ from another run, the runs are not directly comparable.

Versions
Field	What to record
System version	Application build or commit.
Model / version	Provider-reported model version.
Prompt / template version	System prompt and template revision.
Policy version	Version of enforced policies.
Tools / catalogue / config version	Tool registry, catalogue snapshot and connector configuration.
Fixture version / hash	Version or hash of the synthetic fixture used.

Record each state as observed, unobserved, unavailable or not applicable, with the evidence reference.

Observed chain states
Field	What to record
Pre-run state	Baseline state of the target resource, read from the system of record.
Context observed	Whether the fixture reached model-visible context.
Model / plan influence	Observed change in plan or output.
Proposed action	Action and parameters proposed, if any.
Control decision	Allow, deny or approval required, with policy version.
Submission status	Submitted, not submitted, or unknown.
Execution status	Executed, rejected, or unknown, from the tool gateway.
Downstream effect	State after the run, from the system of record.
Impact classification	Principal, resource, action, destination and policy result.

Result and handling
Field	What to record
Outcome	Pass, Fail, Inconclusive or Control not exercised, by the case rules.
Evidence references / correlation IDs	Evidence record IDs and trace identifiers.
Cleanup completed	Yes or no, with post-reset state reference.
Notes / deviations	Anything that differed from the plan, including interruptions and version drift.

Why every run stays separate
Principle	Reason
One record per run	Model behavior is non-deterministic; individual runs show which conditions led to which chain states.
No averaged success rate	Three runs with one unauthorized execution are a demonstrated failure, not a 67 percent pass. A single authoritative Fail outweighs any number of non-events.
Non-events are not passes	A run where the model never proposed the action is recorded as "Control not exercised" for that control, however many times it repeats.
Positive controls are runs too	Their success in the same versions is what makes a deny decision meaningful.
Version drift breaks comparison	If any version changed, record it and treat cross-run conclusions as Inconclusive until rerun.