Features/MCP Workflows/Verification evidence index

Verification evidence index

The test reports exist. The index that says which report proves which requirement, and which requirements have none, is what the assessor actually reads. This produces it from the model in minutes, correct again after every test campaign.

File creationRead-only

The problem this solves

Producing the evidence index by hand costs a week before every assessment, and it is wrong again by the next test campaign because it is a snapshot of links that live in the model. Generated from those links, the index is a re-run rather than a rewrite, and the requirements with no evidence stop hiding in the middle of a spreadsheet.

How it works

Which report proves which requirement, and which requirements have none, current at every re-run. The requirement-by-requirement evidence table, the test-case coverage table, and a safety view by hazard, with the report files referenced by name. A requirement counts as verified only on a Passed run or a declared non-test method with a description.

01
Run the coverage audit first
The verification coverage audit finds the unlinked test cases, the never-run runs and the unverified safety requirements while they are still cheap to fix.
02
Build the requirement evidence table
Ordered by customer ID: each requirement with its declared methods, linked test cases, latest run status, attached reports by name, and an evidence status that is never inferred.
03
Build the test case coverage table
Each test case with its purpose, systems under test, linked requirements, latest run status and attachments, so the index reads in both directions.
04
Add the safety view
Each hazard's mitigating requirements with their evidence status, which is the page an assessor turns to first.
05
Close with the annexes
The ranked gap annex, safety requirements first, and the provenance annex with the element IDs behind each row.

Run the audit first

Regulation (EU) 2023/1230 applies from 20 January 2027, and the technical file is kept for ten years after the machine is placed on the market. This workflow generates a document from the model; it is not a conformity assessment, and it assumes the audit has been run and its findings acted on.

  1. 01Run the verification coverage audit and work its findings, so the index you hand an assessor is a record of evidence rather than a list of gaps.
Regulation (EU) 2023/1230 on EUR-Lex

The prompt

Generate the verification evidence index for a technical file under Regulation (EU) 2023/1230, Annex IV Part A, from the connected Dalus model. Do not modify the model.

Step 1. Read all requirements with customer ID, statement, type, priority, status, verifications and assigned systems; all test cases with type, purpose, linked requirements with rationale, systems under test, procedure, runs with status and step results, and attachments; and all hazards with mitigating requirements.

Step 2. Requirement evidence table, ordered by customer ID: requirement, statement, type, declared verification methods, linked test cases with status, latest run status, attached reports by name and kind, evidence status ("verified" only with a Passed run or a declared analysis, inspection or demonstration with description; otherwise "planned", "failed", "blocked" or "no verification").

Step 3. Test case coverage table: name, type, purpose, systems under test, linked requirements, latest run status, procedure step count, attachments.

Step 4. Safety evidence view: for each hazard, its mitigating requirements and their evidence status.

Step 5. Gap annex, ranked: safety requirements not verified, hazards with unverified mitigations, other requirements with no verification, test cases with no runs, runs with failed or blocked steps, links without rationale, attachments with no file or URL.

Step 6. Provenance annex: element IDs behind each row.

Output rules:
- Word document titled "Verification Evidence Index, Annex IV Part A", title block with model name, date and revision placeholder.
- Tables in the body, one paragraph of explanation per section.
- A requirement is verified only on a Passed run or a declared non-test method with a description. Never infer a pass.

What you get

Word document: Verification Evidence Index, Annex IV Part A
Requirement evidence table ordered by customer ID, reports referenced by name
Test case coverage table
Safety evidence view by hazard
Gap annex, ranked, and a provenance annex
Outputs are drafts for expert review. This workflow supports, and does not replace, qualified safety and certification engineering.

Common questions

When does Regulation (EU) 2023/1230 apply?
From 20 January 2027, when it replaces the Machinery Directive 2006/42/EC. The technical file it requires must be kept for ten years after the machine is placed on the market.
Is this a conformity assessment?
No. It is an index of the evidence the model records. Conformity assessment remains your CE marking procedure, with a notified body where the Regulation requires one.
Does it contain the test reports?
No. The report files stay where they live and are referenced by name and kind. The index is the map between requirements and reports, which is the part that goes stale when maintained by hand.
What counts as verified?
A Passed run, or a declared analysis, inspection or demonstration with a description. A pass is never inferred, and a requirement with a test case that has never run is listed as planned.