ISO 8373: Your Robot's Classification Determines Its Regulatory Fate

A robot is not defined by its shape. It is defined by what it does, where it does it, and with whom.

That is the central thesis of ISO 8373, and most engineering teams discover it too late — when architecture decisions are already frozen.

Reclassifying an AMR as a cobot mid-development means opening a different normative tree, with different safety requirements, different PLr levels, different certification files. It is not a paperwork change, it is a program change.

Why classification gets expensive when it arrives late

Here is a scenario that plays out regularly in robotics teams.

The team starts with an AMR designed to operate in zones separated from the operator. ISO 3691-4 classification. Safety requirements are known, the certification schedule is set. In sprint 4, an architecture decision: the robot must be able to operate within reach of a human, without physical barrier. Functionally, this is an improvement. Regulatorily, it is a boundary crossing.

The robot enters the scope of ISO/TS 15066. Risk analyses must be redone. Force and pressure limits must be documented for each contact mode. The required performance level for safety functions increases. The full technical file must be rebuilt.

The team discovers the problem eight months later, during the first review with the certification body.

This scenario is not exceptional. It is structural. It happens because ISO 8373 classification is not treated as an architectural constraint — it is treated as an end-of-program formality.

The normative tree by robot family

ISO 8373 defines the families. Each family points to a distinct normative tree, with its own technical and documentary requirements.

The table is simple. What is complex is that the boundary between cells is not defined by the robot's mechanics — it is defined by its context of use. The same chassis can fall into two different columns depending on the planned deployment. This point is underestimated by almost every team in the design phase.

What engineering teams do with this complexity

The usual answer: an expert knows the classification by heart, communicates it to the rest of the team verbally or in a slide deck, and the information lives in a PowerPoint file somewhere on the server.

The problem is not the expert. The problem is that this information is not connected to the decisions that depend on it.

When an architecture decision modifies the robot's intended use, no one receives an alert. Risk analyses associated with the classification are not automatically marked for review. Sections of the technical file linked to impacted standards are not identified. The Quality Manager learns about the reclassification at baseline review, not at the moment of decision.

Three reasons documentary rigor is a competitive advantage

1. Industrial RFPs test your engineering maturity before your price

A large industrial account evaluating a robotics supplier is not just testing the robot's performance. It is testing the supplier's ability to demonstrate mastery of its configurations, baselines, and certification processes. A team that can produce a structured, traceable, up-to-date technical file in 48 hours wins decisive points. A team that has to reconstruct its file on demand loses time and credibility.

2. Industrial fundraising demands a verifiable engineering truth

Funds investing in series B and beyond into robotics companies run technical due diligence. They ask to see how design decisions are documented, how revisions are managed, how baselines are maintained. A startup that cannot answer these questions slows or blocks its raise. A startup that shows a structured, traceable system accelerates investor confidence.

3. International expansion forces you to recertify your configurations

A robot certified to EN 13849 for Europe often needs to be recertified to ANSI/RIA R15.06 for the United States, and reviewed against local requirements for Asia. Every geographic expansion is a certification exercise. If your engineering data is structured and traceable, that exercise takes weeks. If it lives in disconnected tools, it takes months and exposes inconsistencies you had not seen.

The 2027 watchpoint: European Machinery Regulation

The new European Machinery Regulation (EU) 2023/1230 enters into force in January 2027. It replaces the 2006 Machinery Directive. The major changes that concern robotics: conformity assessment for machinery embedding AI becomes mandatory for high-risk systems, technical documentation requirements are expanded and made explicit, and collaborative robots and AMRs with direct human interaction fall into more constraining risk categories.

For teams certifying today under the old directive, the question is not whether they will have to comply. The question is whether their technical file is in a state that allows a fast transition or whether everything must be rebuilt in 2026.

What Koddex changes in this context

ISO 8373 classification is not a regulatory knowledge problem. Engineering teams working in robotics know the standards. The problem is operational: how to connect classification to architecture, design decisions, risk analyses, baseline reviews — so that a change in intended use cascades to all the dependencies that depend on it.

Koddex structures this layer. Classification becomes an attribute of the system object. It is connected to safety requirements, applicable standards, and sections of the technical file. When a decision modifies the intended use, the impact is visible immediately — not eight months later at the certification review.

This is not a promise to automate certification. It is an infrastructure that makes your engineering truth readable, traceable, and auditable at any moment of the program.

The Machinery Regulation enters into force in January 2027. If your technical files are structured and traceable, the transition is an exercise. Otherwise, it is a project.