The evidence layer in machine risk assessment is now available in Safety Software. It fixes a problem most teams know too well: the decision sits in the risk table, but the basis for that decision is buried somewhere else. A photo on a phone. A test report in a shared folder. A validation report saved under an unclear file name. Then, weeks later, someone asks the only question that really matters — on what basis?
A machine risk assessment is not just a table of hazard, protective measure, and residual risk. It should also show why the risk was rated that way, why a specific protective measure was selected, and what confirms that it actually works. That is what the Evidence feature is built for. It lets you attach photos, technical documents, test reports, validation reports, SISTEMA reports, and other supporting files directly to the exact place where the technical decision was made.
That matters because good engineering is not only about writing conclusions. It is about leaving a usable evidence trail. If the trail is weak, the assessment becomes hard to defend, hard to review, and painful to revisit later.
What the evidence layer in machine risk assessment actually solves
Most machine risk assessment projects do not fail because engineers cannot identify hazards. They fail because the supporting material ends up scattered across the project. The assessment says a risk was reduced. The project team may even know why. But the proof is fragmented, detached from context, and difficult to recover when the project moves into validation, CE work, audit, modernization, or customer review.
Evidence closes that gap. It keeps the basis for the decision next to the decision itself. Instead of treating attachments as a separate archive, it links them to the actual hazard, risk assessment scenario, or protective measure. That sounds simple, but in practice it changes the quality of the whole record.
- A hazard can carry its own supporting photo or technical document.
- A risk assessment scenario can include the material used to justify severity, frequency, or avoidance assumptions.
- A protective measure can include the files that confirm implementation and effectiveness.
The result is straightforward: no one has to guess later what a file was meant to support. The evidence is visible in context, where it belongs.
Where Evidence sits inside the assessment process
Evidence works directly inside the machine risk assessment workflow. It is not a side module and not a disconnected document store. It is part of hazard identification, risk evaluation, and risk reduction.
Hazard identification and the risk assessment scenario
In the hazard identification view, Evidence is visible next to the hazard being analyzed. If a photo of the dangerous area or a technical document has been attached, that fact is also visible in the hazard identification table. This is a practical detail, but it matters. Engineers can immediately see which entries are supported and which still need work.
The same logic applies to the risk assessment scenario. When the team documents a specific exposure case, Evidence can hold the supporting material that explains the assumptions behind the rating. That may be a layout photo, an operating sequence note, a technical document from the machine builder, or a site-specific record collected during inspection.
Risk reduction and safety function confirmation
Evidence also covers the risk reduction stage, which is exactly where many assessments become too declarative. Writing that a protective measure was applied is not enough. A note that says a guard was installed or an interlock was implemented may help the table look complete, but by itself it is a weak technical record.
Now the protective measure can carry its own evidence: a photo of the guard, a test report, a validation report, technical documentation from the component, or a SISTEMA report that supports the safety function. This creates a much stronger link between the machine risk assessment and the real work done on the machine.
In practical terms, Evidence sits where engineers already work. You can add, review, or remove files without breaking the assessment flow. That matters because if documenting the basis is awkward, teams stop doing it. A usable system has to work at engineering speed.
What you can document in Evidence
The scope is broad by design. Evidence is meant to support real engineering work, not force everything into a narrow document type. You can attach material to the key elements of the assessment, including hazards, each risk assessment scenario, and every protective measure.
Typical examples include:
- photos of hazards and dangerous areas,
- a technical document or a set of technical documents,
- test reports,
- validation reports,
- SISTEMA reports,
- files confirming that a protective measure was implemented,
- supporting material used for hazard identification and risk reduction.
This is important because evidence in machine safety is rarely one neat PDF. It is often a mix of field photos, calculations, component data, test records, and validation output. Evidence is designed to hold that mix without losing the technical connection between the file and the decision it supports.
Project evidence index: one project-wide reference point
A single attachment view inside each hazard or protective measure is useful, but large projects also need a project-level perspective. That is why Safety Software now includes a project evidence index. It is a dedicated tab in the project view that gathers the material from the whole machine risk assessment in one place.
The project evidence index works in read-only mode. That is the right choice. Its job is not to change technical decisions. Its job is to provide a clean reference catalog for the entire assessment.
At project level, you can quickly check:
- which photos and documents have been collected,
- which hazard, risk assessment scenario, or protective measure each file is assigned to,
- which material may be included in technical documentation,
- whether the project has a sufficient evidence trail.
This sounds administrative, but it is more than that. It gives the project team an immediate picture of documentation completeness. You can see whether the assessment is technically supported or whether it still relies too heavily on bare statements.
Download a complete evidence package as ZIP
The new functionality also allows you to download a complete evidence package for the project as a ZIP archive. That package contains the attached files together with a relationship list showing where each file came from and which part of the machine risk assessment it supports.
That is a strong step toward digital technical documentation. Instead of exporting only the assessment table and then rebuilding the supporting material by hand, the team can pull the evidence package in one go. For handover, external review, internal audit, or archive purposes, that is a major improvement.
Just as important, the ZIP package preserves context. A file without context is just a file. A file with a clear link to the relevant hazard, risk assessment scenario, or protective measure becomes technical evidence.
Why the evidence layer in machine risk assessment matters for CE and audits
This is not just about convenience. It goes directly to the quality and defensibility of the technical record.
Under Regulation (EU) 2023/1230, the machine builder or integrator must be able to show that risk reduction decisions were made on a sound basis and that technical documentation reflects the real state of the machine. ISO 12100 expects structured hazard identification and systematic risk reduction. Where safety-related control functions are involved, ISO 13849-1 and the related validation work demand traceability that goes beyond a short note in a table.
That is where weak assessments get exposed. They contain the conclusion but not the support. They say the residual risk is acceptable, but do not show the photo, the test report, the validation report, or the technical document that explains why. They say a protective measure was applied, but cannot quickly show what was installed, how it was tested, or how the safety function was confirmed.
Auditors, customers, and internal reviewers eventually ask for the same thing: show me the basis. Not later. Not after two days of folder searching. Now.
The evidence layer in machine risk assessment turns the process from a form into a more auditable technical workflow. Each significant decision can carry its own justification. That helps with CE work, technical documentation, validation, project reviews, later modifications, and even incident investigation if the machine is revisited years after commissioning.
What changes for engineering teams in practice
The biggest change is not theoretical. It is operational. Engineers spend less time reconstructing project history. Validation specialists do not have to chase scattered files. Technical authors can build technical documentation from a cleaner base. Project leads can judge documentation maturity without opening ten separate folders.
It also improves continuity inside the team. When one engineer hands over to another, the rationale travels with the assessment. When a project is reopened for a retrofit, the old decisions are easier to understand. When a safety function is reviewed, the related SISTEMA report or validation report is already tied to the relevant protective measure.
In other words, Evidence does not replace engineering judgment. It preserves it.
Bottom line
A good machine risk assessment should show more than what was entered in the table. It should show why that decision was made and what confirms it. That is the whole value of the Evidence feature.
By adding a structured evidence layer to hazards, each risk assessment scenario, and every protective measure, Safety Software makes the machine risk assessment easier to review, easier to defend, and more useful as part of digital technical documentation. Evidence is now available in Safety Software.