Agents for Robotic Compliance

Compliance evidence that keeps pace with every release.

For robot makers, importers and integrators selling in the EU. The agents turn your engineering work (ROS 2 packages, code, tests and releases) into the evidence that notified bodies, customers, market authorities and courts ask for, and keep it current with every release. Agents draft the evidence; your engineers review and approve every item before it counts.

What changes in the EU

Five legal regimes, within six months.

Between September 2026 and February 2027, robots sold in the EU come under new or changed rules for machinery safety, cybersecurity, product liability and batteries. Software becomes part of the regulated product, and every update has to be accounted for.

Date	Rule	What it means for robot makers
11 Sep 2026	Cyber Resilience Act, reporting obligations	Actively exploited vulnerabilities and severe incidents are reported through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours, then a final report. This includes products already on the market. Fines reach €15M or 2.5% of worldwide turnover.
9 Dec 2026	Product Liability Directive (EU) 2024/2853	Applies through national law to products placed on the market after this date. Software, AI and updates can count as products. Non-compliance with safety requirements leads to a rebuttable presumption of defect.
20 Jan 2027	Machinery Regulation (EU) 2023/1230	Replaces the Machinery Directive with no grace period: machines placed on the market from this date must comply. Machines and safety components whose safety functions rely on machine learning always need a notified body. New requirements on protection against corruption, importer obligations and ten-year document retention.
18 Feb 2027	Battery Regulation, battery passport	A digital passport for industrial batteries above 2 kWh, which covers larger mobile robots.
11 Dec 2027	Cyber Resilience Act, full application	Most remaining obligations for connected products apply, including security requirements and conformity assessment.
2 Aug 2028	AI Act, as amended by Regulation (EU) 2026/1744	AI safety requirements for machinery are set through delegated acts under the Machinery Regulation.

In practice

What the new rules ask of a robot that ships software every week.

Updates and the CE marking

A software change the manufacturer did not foresee can be a substantial modification, and whoever makes it takes on the manufacturer's obligations. Changes the documentation describes and limits stay outside that definition.

Proof of the state of the art

Not every harmonised standard will be cited by January 2027, so the presumption of conformity is limited. Where it does not apply, the manufacturer shows compliance with its own evidence.

Machine learning in safety functions

Machines and safety components whose safety functions rely on machine learning are listed in Annex I Part A and always go to a notified body, with an argument for why the function is safe and the evidence behind it.

Importers and procurement

Importers are liable for robots whose technical files are incomplete or only partly translated, and customers' safety officers ask for the risk assessment, the Declaration of Conformity and cybersecurity evidence before they sign.

Compliance pipeline

Every release, checked and documented.

Every release gets one verdict: Ship Review Notified body needed

The agents are installed inside your own infrastructure and work there, next to your Git repositories and CI. Your code never leaves it. A safety.yaml file in each repository declares the safety functions and the code, parameters and model versions that implement them. Agents draft; a named engineer approves every item before it counts.

Your logo

Repository: amr-1/navigation
Pull request: #482
Branch: bump/nav2-1.3.11
Date: 23 Jan 2026

Pull request check

#482 Bump Nav2 to 1.3.11

Specimen. Illustrative CI check.

Checks: 4 passed · 1 waiting for approval

Passedbuild / colcon (Jazzy)Passed in 6m 12s
Passedtest / unit + integration1,284 passed
Passedsecurity / SBOM + vulnerability scan44 components updated · 0 new vulnerabilities
Passedcompliance / foreseen-modification limitsWithin limits (FML-02, FML-05)
Waitingcompliance / safety reviewSafety lead approval required

Review

compliance / safety review

2 changes affect credited risk-reduction measures. Merge blocked until approved.

Release gate · AMR-1 · 1.3.10 → 1.3.11

  REVIEW  3fc1600c  collision monitor height now in base frame
          → M-03 slowdown zone · H-04 low obstacles
          → re-run test T-M03-01

  REVIEW  3320ebf7  obstacle marking range now 2D cell distance
          → M-05 obstacle avoidance · H-04, H-06
          → re-run test T-M05-02

  OK      SF-01 protective stop (safety scanner): unchanged
  OK      within foreseen-modification limits: no notified body needed

  Approver: safety lead · Evidence stored signed, retained 10 years

For the CTO: the release gate

The check runs in the pull request. Two safety-relevant changes block the merge until the safety lead approves.

Your logo

Document: AMR1-CHG-3fc1600c
Release: 1.3.11
Date: 23 Jan 2026
Classification: Internal

Change detail

Commit `3fc1600c`: fix Z base frame transformation

Specimen. Real Nav2 commit.

nav2_collision_monitor/src/pointcloud.cpp · +5 lines · in Nav2 1.3.11

     tf2::Vector3 p_v3_b = tf_transform * p_v3_s;
 
+    // Still need to transfer height from "z" field if not using global height
+    if (!use_global_height_) {
+      data_height = p_v3_b.z();
+    }
+
     // Refill data array
     if (data_height >= min_height_ && data_height <= max_height_) {

What changes in behaviour. Before, point heights were taken from the sensor frame. On AMR-1 the 3D camera is mounted 0.42 m high and tilted, so low obstacles could fall outside the min_height / max_height window and be ignored. After this fix, heights are measured from the robot base, and more low obstacles are detected.

Traceability

Code	`nav2_collision_monitor`, declared in `safety.yaml` as implementation of M-03
Measure	M-03 Slowdown to 0.3 m/s when an obstacle is within 1.0 m (non-safety-rated, credited for occurrence reduction)
Hazard	H-04 Collision with a person or object below 0.3 m height (e.g. pallet foot, crouching worker)
Safety-rated function	SF-01 Protective stop via safety laser scanner: Not affected no firmware or parameter change
Requirement	Machinery Regulation (EU) 2023/1230, Annex III, 1.2.1 (control systems) · clause mapping to be verified by a safety engineer
Evidence	Upstream: unit tests in `collision_monitor_node_test.cpp` pass · Site: test T-M03-01 (low-obstacle slowdown) must be re-run

Foreseen-modification check

Limit	Documented	This release	Result
FML-02 Navigation software updates	Allowed if SF-01 unchanged and credited measures re-validated	SF-01 unchanged · re-validation pending	Within limits
FML-05 Max speed in shared zones	≤ 1.2 m/s	1.0 m/s, unchanged	Within limits

Assessment. Likely a safety improvement, but it changes detection behaviour, so the risk assessment entry for H-04 needs review.

For the safety lead: every change traced

From the code diff to the measure, hazard, requirement and test, with a check against the documented limits of foreseen modifications.

Your logo

Document: AMR1-RIR-1.3.11
Revision: 1
Date: 23 Jan 2026
Classification: Internal

Release impact report

AMR-1 navigation 1.3.11

Specimen. Built on the real open-source Nav2 stack (ROS 2 Jazzy); the code changes are real.

Release	Nav2 `1.3.11` (23 Jan 2026), compared with `1.3.10` (23 Oct 2025)
Scope	13 commits · 129 files · 44 packages updated
Safety functions affected	0 safety-rated · 2 credited risk-reduction measures
Foreseen-modification limits	Within limits (FML-02)
SBOM	44 components updated · 0 added · 0 removed
Known vulnerabilities	0 new (illustrative)

Review

Verdict: Review

Two changes alter how obstacles are detected. Both affect measures credited in the risk assessment, not the safety-rated protective stop. Safety lead approval and a re-run of tests T-M03-01 and T-M05-02 are required before release. No notified body involvement needed: the change stays within the documented limits of foreseen modifications.

Changes by impact

Impact	Commit	Change	Linked to
Review	`3fc1600c`	Collision monitor: height filter now uses robot base frame instead of sensor frame	M-03 slowdown zone · H-04
Review	`3320ebf7`	Obstacle layer: max marking range now measured in 2D map cells instead of 3D distance	M-05 obstacle avoidance · H-04, H-06
Note	`6794f00f`	Collision monitor: optional "height" point field (off by default)	M-03
Note	`77d6579c`	Velocity smoother: optional timestamp smoothing (off by default)	M-02
None	9 others	Planner cost fix, goal checker, visualization, RViz/Groot tooling, typo	—

Next steps

Safety lead reviews 2 changes: approve or reject.
Re-run T-M03-01 and T-M05-02 on the test track and attach the results.
Technical file and Declaration of Conformity draft regenerate automatically after approval.

For the CEO: one verdict per release

What changed, what it affects, what has to happen before you ship, and whether a notified body is needed.

Based on real Nav2 releases: compare 1.3.10 and 1.3.11, or see the collision monitor fix on GitHub.

Specimen for illustration. AMR-1, its safety functions, hazards, tests and limits are fictional, and the vulnerability figure is illustrative. Code excerpts from Nav2 (ros-navigation/navigation2), Apache License 2.0. Independent example, not affiliated with or endorsed by the Nav2 project. Mapping to legal requirements and standard clauses is verified by a safety engineer in every client project.

Partner exchange

One interface for every partner, in both directions.

Integrators, customers, auditors, importers, service partners and insurers connect their own AI agents or tools to your exchange through the Model Context Protocol (MCP). Each partner belongs to a tier with its own permissions, so the same questions no longer arrive by email in different formats.

Partners read approved facts

Integrators: speeds in collaborative mode, stopping times, foreseen modifications, residual risks the cell must cover.
Customers' safety officers: whether a firmware version is covered by the current declaration, and its security status.
Notified-body auditors: the evidence for a given requirement, with time-limited access.
Importers and distributors: whether the file is complete, and in which languages.
Service technicians and insurers: allowed firmware versions, safety checks, certification status.

Partners send data in

Component suppliers: safety parameters, certificates, declarations of incorporation, battery passport data.
Software suppliers: SBOMs and vulnerability notices, which start the CRA workflow when needed.
Integrators and operators: site modifications, checked against the foreseen limits first.
Operators and service partners: field incidents and near misses, for CRA reporting and the risk assessment.
Auditors: review findings, which open tasks against the technical file.

A continuous service

Requirements that stay current with the law.

Regulation keeps moving after the application dates: harmonised standards are cited, delegated acts follow, and member states add national rules. We keep the requirements in your safety graph current with EU and national legislation, and the agents show which releases and documents each change affects.

Requirements updated as EU regulations, harmonised standards and delegated acts change.
National legislation of the member states where you sell, included in the same model.
Every change traced to the affected requirements, evidence and releases.
Documents and partner answers in English and all other official EU languages.

What you receive

Documents your auditors, customers and lawyers can use.

Document	What it contains	Used by
Living risk assessment	Hazards, risks, mitigations and test evidence, linked to code	Safety lead, notified body
Requirements matrix	Each legal requirement, how it is met, the evidence and the standard clause	Notified body, market authority
Technical file per release	The full dossier, rebuilt with every release	Notified body, court
Declaration of Conformity	The legal declaration, drafted and ready to sign	Managing director
Release impact report	Ship, review or notified body needed, with reasons	CTO, release manager
Foreseen-modification limits	Documented limits that keep updates and site changes from becoming substantial modifications	Product, legal, integrators
SBOM and vulnerability report	Software components and known vulnerabilities per release	Security lead, customers' IT security
CRA incident pack	Pre-filled reports for ENISA	Security lead
Importer verification report	Whether a non-EU maker's file is complete and credible	Importers and distributors
Evidence archive	A tamper-evident record kept for ten years	Legal, insurer

How your knowledge stays protected

The agents run inside your own infrastructure. Your source code never leaves it.
The partner MCP server runs in a separate environment that holds only the approved facts. It has no physical access to your code or internal data.
A fact is disclosed only after your safety lead approves it for a partner tier, release by release.
Every answer carries the release version, document ID, hash and signature, and "not disclosed" where a fact is not approved.
Incoming data is validated, signed by the sender and reviewed before it is used.
OAuth 2.1 with short-lived tokens and enterprise SSO, rate limits and a full query log.

What stays with your engineers

Approval of every hazard entry and requirement mapping the agents draft.
The decision to ship a release.
Signing the Declaration of Conformity. Certification stays with the notified body.

Works with

The engineering tools you already use.

Self-hosted by default: the agents run inside your own infrastructure, so your code stays where it is. As an option, we host the partner exchange and the evidence archive in the EU; only approved facts and signed documents go there. Approved facts are also published as Asset Administration Shell (AAS) submodels for your industrial customers' systems.

GitHub
GitLab
CI pipelines
Jira
Linear
ROS 2
Container images
Test and simulation reports
Model registry
CycloneDX SBOM
Asset Administration Shell

Getting started

From a readiness check to every release.

Readiness check: we review your safety file and release process against the 2026–2027 requirements.

Setup: safety.yaml, the CI connection and the first technical file draft, in your infrastructure.

Every release: checked, documented and signed, with requirements kept current as the law changes.

Make every release audit-ready