Your First Verification Report
Last updated: 2026-07-163 min read
A first verification report is a bounded record of one real change: the task, immutable change reference, exact checks and observed outcomes, known omissions, reviewer and decision. It is useful because its evidence and limits are explicit-not because it sounds complete.
Contents
Choose one real change and define the boundary
Start with a recurring change small enough for a reviewer to understand. Before the AI-assisted run, write the goal, allowed paths, exclusions and testable acceptance criteria. This gives the reviewer a reference independent of the generated implementation. BSI/ANSSI guidance recommends that developers check generated source code and remain able to reproduce it; it does not prescribe this report format or promise that a recorded check makes code correct.
- Define the task. State an observable goal, file boundaries and yes/no acceptance criteria before execution.
- Reference the observed change. Record an immutable commit or diff and the files actually touched.
- Run independent checks. Capture exact commands, outcomes, timestamps and available receipts-including failures and skipped checks.
- Name uncertainty. List what was not tested, why, and what review is still required.
- Record a decision. Identify reviewer, role, decision and time; do not imply independence that did not exist.
Use a template that cannot impersonate evidence
The sample deliberately contains placeholders rather than successful results. Copy it only as a schema. Fill it after a real execution from command output and immutable repository references. A complete-looking synthetic report is worse than a short record that honestly says a check was not run.
Illustrative template - not a real report
verification-report-template.mdtext/markdown
Illustrative sample · not evidence# Verification report · <change ID> · <date>
## Task
Goal: <observable goal>
Boundaries: <allowed paths and exclusions>
Criteria: <testable criteria>
## Change
Commit/diff: <immutable reference>
Files: <observed list>
## Validation
Command: <exact command>
Outcome: <passed | failed | not run>
Receipt/log: <reference or "not available">
## Open limits
- <area not checked and why>
## Decision
Reviewer: <name/role>
Decision: <approved | rejected | changes requested>
Timestamp: <ISO-8601>Read each field at its actual evidence level
A task records intent; it does not validate the chosen goal. A commit identifies a change; it does not establish who authored every line. A test receipt shows one command’s observed outcome under its environment; it does not cover every security, quality or compliance property. A reviewer decision records accountability; it is not automatically independent assurance.
What an artifact establishes - and what it does not
| Task | Change | Validation | Decision | |
|---|---|---|---|---|
| Can establish | Intended goal, scope and criteriaEditorial evidence boundary · 2026-07-16Only when the record is complete, immutable and reviewable. | Link to a concrete diff/commitEditorial evidence boundary · 2026-07-16Only when the record is complete, immutable and reviewable. | Which command produced which outcome and whenEditorial evidence boundary · 2026-07-16Only when the record is complete, immutable and reviewable. | Who recorded which decisionEditorial evidence boundary · 2026-07-16Only when the record is complete, immutable and reviewable. |
| Does not establish | Not that the goal was correctly chosenEditorial evidence boundary · 2026-07-16Requires separate review or additional evidence. | Not authorship or correctnessEditorial evidence boundary · 2026-07-16Requires separate review or additional evidence. | Not complete security, quality or complianceEditorial evidence boundary · 2026-07-16Requires separate review or additional evidence. | Not independent assurance or future correctnessEditorial evidence boundary · 2026-07-16Requires separate review or additional evidence. |
A first report should
- Reference a real change
- Name commands and observed outcomes
- Make omissions visible
- Record reviewer and decision
It should not claim
- The code is defect-free
- Every line has a known human or AI author
- Security or compliance is complete
- One report proves ROI
Grow only after reviewing the first record
Ask whether the task boundary was clear, receipts were reproducible, failures remained visible and the decision was understandable later. Refine the template before adding more workflows. If you want to test whether the practice changes rework or review effort, define a baseline with the verification-debt measures and compare a bounded period. One report cannot establish ROI.
Reality Graph can retain task, run, validation and decision records as part of an existing workflow. The same boundary applies: generated records are evidence only when they reference real execution and preserve failures, exclusions and review decisions. How those records are collapsed into a single outcome, and why a run can stay blocked while every test is green, is set out under the verdict rules.
FAQ
- How quickly can a team produce its first verification report?
- The duration depends on the change, existing checks and review depth. Start with one bounded change rather than a time promise. A useful report records the task, immutable change reference, exact validation commands and observed outcomes, omissions, reviewer and decision.
- What is the smallest useful first step?
- Write one real task before one AI-assisted change: goal, allowed paths, exclusions and testable acceptance criteria. After the run, attach the actual diff or commit and validation receipts. Do not pre-fill passing outcomes.
- Do we need to buy a tool to start?
- No. A Markdown record and existing CI can be enough for a first bounded workflow. Tooling becomes useful when it reliably captures provenance, receipts and decisions without hiding failures or changing the evidence standard.
- Who should own the report?
- The change owner records the task and execution facts; the named reviewer records the decision. Teams may add a control owner for higher-risk work. A report should not imply independent assurance when the same person performed and approved every step.
- What can a verification report prove?
- It can establish that a named command produced a recorded outcome for a referenced change at a time, and that a reviewer documented a decision. It cannot by itself prove defect-free code, complete security or compliance, authorship of every line, or future correctness.
- How do we grow from one report to a team practice?
- Review whether the first record was complete and useful, refine definitions, then repeat on one stable workflow. Compare completeness, rework and review effort over a defined period before expanding policy or tooling. A single report does not prove ROI.