Ask a machine builder, automation supplier, or robotics manufacturer whether their products are safe, and the answer arrives quickly and with confidence.
Ask that same organization to produce, on demand, the complete evidence chain for a single hazard, how it was identified, which safety function mitigates it, what performance level that function achieves, how the function was validated, and against which revision of the design, and the answer takes weeks.
That gap deserves a precise name, because it is routinely misdiagnosed as an engineering problem. It usually is not. The analysis was performed. The testing happened. The engineering judgment was sound.
What the organization has is a compliance evidence gap: the work exists, but the proof of the work is distributed across systems, formats, teams, and calendars, and reassembling it is a project in its own right.
Industrial Regulatory Compliance Increases the Burden of Compliance Evidence
Four regulatory and standards shifts are converging on this sector at once. None of them fundamentally changes what good engineering looks like. All of them raise the bar on what you must be able to demonstrate, retain, and retrieve.
EU Machinery Regulation (EU) 2023/1230
The EU Machinery Regulation applies from 20 January 2027, replacing Machinery Directive 2006/42/EC. Technical documentation and the EU declaration of conformity must be kept at the disposal of market surveillance authorities for at least ten years after the machinery is placed on the market. Where safety-related software is involved, source code or programming logic must be made available to competent national authorities on reasoned request, if needed to verify conformity.
ISO 10218-1:2025 and ISO 10218-2:2025
The first substantive revision since 2011. The revisions state functional safety requirements directly, where the 2011 edition left them to inference, introduce a robot classification scheme that drives differing control requirements, absorb most of ISO/TS 15066 on collaborative applications into Part 2, and add cybersecurity requirements for networked industrial robots.
EU Cyber Resilience Act (Regulation (EU) 2024/2847)
Vulnerability and serious incident reporting obligations apply from 11 September 2026 in the EU Cyber Resilience Act. The main obligations, including conformity assessment, CE marking, and technical documentation, apply from 11 December 2027. Manufacturers must identify and document vulnerabilities in their products and the components they contain, including maintaining a software bill of materials (SBOM).
ISO 13849-1:2023
Restructured so that its organization follows the design process, with the validation requirements previously held in Part 2 adopted into Part 1. Verification and validation are now positioned as integral to design rather than as a downstream activity.
The common thread is demonstrability. Each of these instruments assumes that a competent engineering organization can produce, on request and years after the fact, an ordered account of what it decided and why. That is an evidence management capability, not an engineering capability, and it is the one most industrial organizations have never deliberately built.
What the Compliance Evidence Gap Costs
Because the cost is absorbed as effort rather than booked as a line item, it tends to stay invisible until a deadline forces it into view. It shows up in familiar places.
| Where it Shows Up | What it Costs |
| Audit and assessment preparation | Senior engineers pulled onto documentation archaeology for weeks, the people least replaceable and most expensive to divert from active development. |
| Notified body review | Findings and re-submissions caused by gaps in the record rather than gaps in the design, extending certification lead times that are already measured in months. |
| Engineering change | Change impact assessed by consultation and memory instead of by trace, so downstream verification is re-run more broadly than necessary, or missed entirely. |
| Product variants and platforms | Evidence rebuilt from scratch for each configuration because nothing from the base platform was structured for reuse. |
| Commercial cycles | Deals delayed where the customer, integrator, or end user makes documentation a condition of acceptance. |
| Organizational continuity | Key-person dependency: when the engineer who “knows how that interlock was validated” leaves, the rationale leaves with them. |
None of these consequences follows from poor engineering. All of them follow from an inability to show the engineering.
The Root Cause: Evidence is a By-Product, Not an Output
In most industrial machinery, automation, and robotics organizations, compliance evidence is never actually produced. It is reconstructed.
- Requirements live in documents.
- Hazard analyses and performance level calculations live in spreadsheets.
- Verification results live in test tooling or an ALM system.
- Design data lives in PLM.
- Supplier declarations arrive as PDFs.
And the reasoning that connects all of it, why this safeguard, why this category, why this test was considered sufficient, lives in review meetings, email threads, and the memory of the people who were in the room.
Four failure modes follow predictably from that arrangement:
1. No Durable Link Across the Chain
A hazard, the requirement that controls it, the safety function that implements it, the required performance level, the verification method, and the result may all exist as six independent artifacts with no machine-readable relationship between them. The chain is reassembled by hand every time someone asks for it.
2. Version Ambiguity
The most expensive question in an audit is often the simplest one: which revision of the design was this test actually run against? Where artifacts are versioned independently and stored separately, that question can take days to answer with confidence and sometimes cannot be answered at all.
3. Distributed Ownership
Responsibility is split across the OEM, the system integrator, component and safety-device suppliers, and contract engineering. Under the Machinery Regulation, obligations follow the role — manufacturer, importer, distributor — but the evidence itself sits with whoever generated it, in whatever form suited them at the time.
4. A Reconstruction Culture
Once teams accept that the technical file is assembled at the end, they stop treating evidence capture as part of the work. Documentation becomes a phase, staffed under deadline pressure, by people summarizing decisions they did not make.
A Practical Framework: Design for Evidence
Design for evidence is an engineering approach in which the compliance evidence needed to demonstrate conformity, including relationships, decisions, approvals, versions, and verification results, is captured as part of development.
Five moves make that shift concrete.
1. Define the Evidence Model Before the Project Starts
For each product line, write down what your technical file must contain, mapped to the clause or annex that demands it, and name an owner for each item. Annex IV of the Machinery Regulation gives you the structure; ISO 13849-1, ISO 10218, and applicable type-C standards give you the technical content. This is a one-page artifact, and it converts a vague obligation into an assignable list.
2. Treat Traceability as a Live Relationship, Not a Deliverable
A traceability matrix produced at the end of a program is a snapshot of what someone believed on the day they made it. A live trace, covering hazard to requirement to safety function to performance level to verification to result, is queryable at any moment and shows you coverage gaps while you can still act on them.
The difference is not formatting. It is whether the relationships are maintained by the system or by a person.
3. Baseline Deliberately
Freeze and label the exact set of requirements, risk assessments, and verification results that a given conformity claim rests on. Baselines answer the version question directly and let engineering continue to move without disturbing the record of what was certified.
4. Capture Reasoning Where the Work Happens
Review outcomes, approvals, dissent, and rationale should be recorded against the artifact under discussion, at the moment of decision, by the person who made it. Rationale captured months later is a summary; rationale captured in the moment is evidence.
5. Extend the Model Across the Supply Chain and the Full Lifecycle
Specify the evidence you require from suppliers and integrators in the same structure you use internally and keep it under the same version control. Then extend forward. With ten-year retention obligations, vulnerability reporting duties, and software updates that can alter safety behavior in the field, the evidence chain does not end at shipment. It must remain accurate for as long as the machine is in service.
Used together, the five moves change what the organization is able to answer.
| The Question You Will Be Asked | What Answers It | Common Failure Mode |
| Which hazards does this safety function address? | Linked risk assessment and requirement records | Hazards tracked in a spreadsheet with no link to the requirement set |
| What performance level is required, and was it achieved? | PLr assignment plus calculation and validation records | Calculation held in a standalone tool with no versioned link to the design |
| Was this tested against the shipped configuration? | Baselined requirements tied to verification results | Test reports referencing a document revision that has since moved on |
| Why was this design decision made? | Review and approval records attached to the artifact | Rationale in email threads and meeting notes, or lost with staff turnover |
| What changed, and what must be re-verified? | Change impact analysis run across the live trace | Impact judged by consultation, producing over-testing or missed coverage |
What Changes When Compliance Evidence is a Designed Output
Organizations that make this shift report a consistent pattern of outcomes:
- Audit and assessment preparation shifts from a multi-week effort to a targeted exercise in export and review.
- Coverage gaps surface during development, when they are inexpensive, rather than during assessment, when they are not.
- Change impact is scoped from the trace, so re-verification is proportionate to what changed.
- Evidence becomes reusable across variants, configurations, and platform derivatives instead of being rebuilt each time.
- Compliance capability becomes independent of the availability of specific individuals.
How Jama Connect® Supports Compliance Evidence and Traceability
The framework above is a discipline, not a product. It can be implemented with rigorous process and considerable manual effort.
For machinery, automation, and robotics teams, that means maintaining the relationships among hazards, requirements, safety functions, verification, approvals, and product configurations as the engineering work changes.
What a purpose-built platform changes is the cost of maintaining it, and whether it survives schedule pressure. Jama Connect supports the continuous capture and management of compliance evidence in specific ways:
- Live Traceability™ across requirements, risk, and verification. Relationships are maintained as data rather than assembled in a document, so the trace is current when someone asks for it.
- Coverage and gap analysis. Unverified requirements and uncontrolled hazards are visible during development rather than discovered by an assessor.
- Baselines and version history. A defensible answer to the version question, with a retained record of what a given conformity claim was based on.
- Reviews, approvals, and electronic signatures. Decision rationale captured against the artifact under review, at the time of the decision.
- Integrations with ALM, PLM, and test tooling. Evidence generated in adjacent systems is linked into the chain rather than re-keyed, which is where accuracy is usually lost.
The result is compliance work that keeps pace with engineering and a technical file grounded in the team’s actual development history.
A Low-Risk Place to Start
You do not need a platform decision to test whether you have a compliance evidence gap. Take one product line and one hazard. Time how long it takes to produce the full chain: hazard, requirement, safety function, required performance level, verification method, result, and the design revision each was recorded against.
Note where the evidence lived, how many systems and people were involved, and how confident you are that the answer would hold up under examination. That measurement is usually clarifying enough on its own.
If it points toward a structural problem rather than a documentation backlog, we are glad to walk through how other industrial machinery, automation, and robotics teams have closed the gap.
See how Jama Connect supports industrial machinery, automation, and robotics teams, or request a demo to walk through the approach with a Jama Software expert.
[Explore Jama Connect] [Get Demo]
