Open reference framework

The Automation Governance Framework

A vendor-neutral reference for organisations that operate automated systems supplied by more than one vendor.

Version 1.0 (draft) Published September 2026 Licence CC BY 4.0 Status Public review draft, open for comment

Abstract

Automation is now procured piecemeal. An organisation acquires one system from one supplier, then a second from another, and the obligations that attach to the resulting operation fall to the operator rather than to any of the suppliers. The standards literature addresses the device, the autonomous product and the management system. The operator’s duty over a multi-supplier operation is where the guidance is still developing, and that is the gap this framework sets out to address.

The eight parts that follow are the operating requirements we believe organisations will need as automation scales. They describe where this is going rather than what any product does today, and no tool on the market meets all of them for every machine in every deployment.

Four things worth keeping separate when reading this document. The operating requirements are what the eight parts describe, and they are deliberately ahead of the market. A platform’s present capabilities are what a given product does today. What any one deployment can actually do depends on the participating systems, the integrations in place, the data each supplier exposes, the permissions granted and, in some sectors, the rules of that sector. The roadmap is what a supplier intends to build next. Conflating the first with the second is the error this framework is written to avoid.

Passenger, the platform Real Life Robotics builds, supports the definition and application of operating requirements across connected automation systems. The capabilities available within any deployment depend on the participating systems, integrations, available data, permissions and applicable sector requirements.

The category. Software built to meet these requirements is an automation governance platform, or AGP. The name matters for the same reason ERP and CRM did: a buyer cannot ask for a category that has no name, and a market cannot compare products that each describe themselves differently. An AGP sits above the individual supplier’s tooling and below the enterprise systems, and it is answerable to the operator rather than to any one vendor. Real Life Robotics builds one, called Passenger. This document describes what the category has to do, not what any product in it currently does.

This document sets out that duty in eight parts, ordered as they arise in a deployment and closing into a cycle. Each part states a definition, an operational expression, and a signal by which an operator may determine that the part is absent. The framework is descriptive rather than certifying: it confers no conformity mark and mandates no product. It is published under a permissive licence so that operators, suppliers, insurers and procurement authorities may cite and adapt it independently of its author.

01 · Scope and the gap addressed

The standards in force govern the machine, the autonomous product and the management system. Multi-supplier connected operations are where the guidance is still developing.

Robot safety, autonomy assurance, AI management and enterprise risk are each well covered. Each of the standards in the table below takes a single device, a single system or a single supplier as its subject.

Consider an operator running several dozen machines drawn from half a dozen suppliers across a number of sites, which is the configuration this framework is written for. None of the standards in the table below sets out which rules that operator should set, how to verify that a supplier is observing them, what recourse applies when one is not, or what record to retain. The duty of care attaches to the operator regardless. This framework aims to address an operator-level gap across existing standards, or where no applicable standard yet exists.

Scope. This document addresses the operator of an operation of automated physical systems supplied by two or more parties. Out of scope: the design and certification of individual machines, the internal safety case of an autonomous product, and the conduct of any single supplier, each of which the cited standards already address.

Coverage of existing standards
Standard	Governs	Does not address
ANSI/RIA R15.08-1/-2	Industrial mobile robot safety	Interaction between machines from different suppliers
ISO 3691-4:2023	Driverless industrial trucks	Operation-wide policy or evidence
ISO 10218-1/-2:2025	Industrial robot safety requirements	The operator's ongoing obligations
UL 4600	The autonomous product's safety case	How a buyer verifies that case in service
ISO/IEC 42001:2023	AI management systems within one organisation	Physical automation across suppliers
ISO/IEC 38507:2022	Board oversight of AI use	Operational control of deployed machines
ISO 31000:2018	Enterprise risk management, generally	Anything specific to automated systems

This framework describes what an operator is responsible for, in eight parts, and is written to sit alongside the standards above. It replaces none of them.

02 · The framework

Eight parts of automation governance

Each part states what it is, what it looks like in practice, and how an operator can tell they do not have it. The parts are ordered as they occur in a deployment. They form a cycle rather than a checklist.

AG‑1
Measures

Measures

The definition of success, agreed before a system is deployed, and stated in the operator's own terms.

In practiceNamed metrics with target values and a review date, written into the pilot scope and the contract.
Failure signalAt the end of a pilot, the parties disagree about whether it worked, and no document settles it.

AG‑2
Connect

Connect

Every system in the operation reachable, readable and instructable through one layer, whoever supplied it and whatever it speaks.

In practiceA working integration to each supplier, maintained as their firmware and interfaces change, so that a system connected once stays connected.
Failure signalA system was integrated once by whoever had time, and a firmware update silently broke it. Nobody owns putting it back.

AG‑3
Telemetry

Telemetry

Continuous visibility of where systems are and what they are doing, available to the operator independently of any vendor interface.

In practicePosition and status data from every system, with the events that produced it, retained by the operator in one place and in a common form.
Failure signalAnswering a question about yesterday requires logging into more than one vendor portal, or asking a vendor.

AG‑4
Policy

Policy

The operating rules. What systems may and may not do, and how they behave toward each other and toward people.

In practiceRules written once by the operator and applying to every vendor, covering permitted behaviour, prohibited behaviour and interaction.
Failure signalThe rules differ per vendor because each vendor wrote its own, and no single document states them.

AG‑5
Compliance

Compliance

Operator-accessible evidence checked against defined policy, performed continuously, so the operator can assess the whole operation consistently rather than supplier by supplier.

In practiceAutomated checking of observed behaviour against stated rules, with exceptions raised as they occur.
Failure signalCompliance is asserted in a vendor report rather than observed by the operator.

AG‑6
Action

Action

The ability to intervene when a rule is not being followed, addressed either to the machine or to the person responsible for it.

In practiceA defined route to change a system's behaviour, and a defined route to notify its operator, with both recorded.
Failure signalA breach is detected and the only available response is an email to the vendor's account manager.

AG‑7
Audit

Audit

A durable record of what was required, what happened, what was detected and what was done, retained by the operator.

In practiceA time-stamped record of requirements, events, exceptions and responses, available to an operator, an insurer or a council after an incident.
Failure signalReconstructing an incident depends on data a vendor holds and could decline to provide.

AG‑8
Insight

Insight

Analysis across systems that no single supplier could produce, used to evaluate the operation and to revise policy.

In practiceData from unrelated systems joined and examined together, producing findings about the operation as a whole.
Failure signalThe organisation can report on each system separately and cannot say what the operation as a whole returned.

AG‑8 →
AG‑4

Insight returns to policy, which is what turns the framework from a sequence into a cycle. Findings about how an operation behaves become revised operating rules, and those rules may be made either more permissive or more restrictive. Absent this return path, AG‑1 to AG‑7 constitute a reporting regime. The return path is what makes the set a governance regime.

03 · Self-assessment

Automation governance maturity

The governance problem appears at a predictable point: the arrival of a second supplier. An operation’s position on this scale indicates which parts of the framework apply first.

0ConsideringAutomation is under discussion. Nothing is deployed.

1First pilotOne system, one site, run by the vendor. Measures are usually the vendor's.

2Scaling one systemThe same supplier at more sites. The vendor's own tooling still suffices.

3Second supplierTwo interfaces, no shared view, and no single owner of the whole. The framework’s subject matter begins here.

4Scaling a portfolioSeveral systems across several sites, assembled one vendor at a time.

5Systems interfereMachines from different suppliers obstruct each other. Coordination becomes a requirement.

6Safety and liabilityAn incident or near-miss occurs, and the record needed to explain it is found to be incomplete.

7Portfolio valueThe operation is material, and nobody can state what it returns.

04 · Adoption

Using the framework

The framework is published so that it can be copied, cited and adapted. Use of it is unconditional and depends on no product.

Operators

Locate your operation on the maturity scale, then work through the eight parts in order. Each failure signal is drafted so that its presence or absence can be established from records the operator already holds.

Suppliers

Use the eight parts to describe what a system exposes to the operator who buys it, and state which parts it supports and which it does not.

Procurement and counsel

The parts are drafted to be referenced directly in procurement documents and vendor agreements.

05 · Contributors

Who reviewed this draft

Version 1.0 is being opened for review across the disciplines the framework touches. The seats below show the intended composition of the review group. Reviewers are acknowledged by name and organisation once they accept.

Municipal operations

Review seat

Insurance and risk

Review seat

Internal audit

Review seat

Robotics supplier

Review seat

Academic research

Review seat

Safety standards

Review seat

Large-operation operator

Review seat

Legal and procurement

Review seat

06 · Stewardship and licence

Open by licence

Real Life Robotics is the founding steward of the Automation Governance Framework. The framework will evolve through practical deployments, industry participation and multidisciplinary review, with material revisions documented publicly. It is offered under Creative Commons Attribution, and may be used, adapted and built on by anyone, including competing suppliers.

Attribution is the only condition. Adaptation and commercial use are both permitted, including by organisations that compete with the steward.

Scope of the licence. The open framework describes governance principles and operating requirements. It does not include or license Passenger software, integrations, assessment tools, implementation methods, customer data, templates or Real Life Robotics trademarks. What is published here is the category definition, the governance principles, the operating outcomes, the component structure, general examples and the revision history. Product architecture, integration tooling, data structures, onboarding processes, implementation methods and scoring methodologies are not part of it.

Automation Governance Framework, Version 1.0.
Real Life Robotics, September 2026. CC BY 4.0.
realliferobotics.com/framework

07 · References

Standards cited

ANSI/RIA R15.08-1 and R15.08-2, Industrial Mobile Robots — Safety Requirements. American National Standards Institute and the Association for Advancing Automation.
ISO 3691-4:2023, Industrial trucks — Safety requirements and verification — Part 4: Driverless industrial trucks and their systems. International Organization for Standardization.
ISO 10218-1:2025 and ISO 10218-2:2025, Robotics — Safety requirements — Parts 1 and 2. International Organization for Standardization.
UL 4600, Standard for Evaluation of Autonomous Products. UL Standards & Engagement.
ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system. International Organization for Standardization and the International Electrotechnical Commission.
ISO/IEC 38507:2022, Information technology — Governance of IT — Governance implications of the use of artificial intelligence by organizations. ISO and IEC.
ISO 31000:2018, Risk management — Guidelines. International Organization for Standardization.

Editions are given where the framework relies on a specific revision. Readers should confirm the current edition before citing this table in a procurement document.