Real Life Robotics / Platform
Passenger · an automation governance platform
One rulebook across your suppliers, and governance you can prove.
Sensors, meters, trackers, drones, AMRs and delivery robots report into one place, whoever supplied them. The rules you write reach each system you bring on. When one drifts outside them, Passenger raises it the same day, not in the quarterly pack.
One console for the systems you have connected.
Where each machine went, whether it stayed inside the rules you set, and what the operation returned. Passenger normalises data from unrelated hardware into a common form, so a question about yesterday takes one query rather than three vendor portals.
It governs the automation environment, not any one machine.
For most operators the majority of what is already deployed is IoT: sensors, meters, trackers, access control. Passenger takes those first, because they sit in the ground already and they belong to you already. Then it takes the machines that act on them.
The join is the point. A meter reading that used to sit on a supplier’s own screen becomes an instruction the moment a machine can act on it, and from that moment it belongs under the same rules as the machine.
Above the machines. Below the enterprise.
Passenger occupies the layer above each supplier’s own tooling, but below the enterprise systems that run your organisation. Upward, it normalises data your ERP or asset register can ingest. Downward, it translates a decision taken in those systems into a command a specific device understands. Nothing in an enterprise stack addresses a robot directly, which is why the layer has to exist.
What the platform does, part by part.
The framework names eight duties an operator carries. Here is what Passenger does against each one.
Measures
Agree what success means before anything is deployed
Targets agreed before anything is deployed, written in your terms. Passenger records them against the system they apply to, with the review date attached, so nobody grades the pilot retroactively.
Connect
Bring a supplier under governance in days where the pathway exists
A working integration to each supplier, maintained as their firmware and interfaces change. Passenger holds direct agreements with the OEMs in its library rather than depending on open endpoints that can change without notice, so supported integrations can be maintained as supplier interfaces evolve.
Telemetry
See the machines you have connected without opening a vendor portal
Position, status and events from the systems Passenger is connected to, in one place and one format. The operator maintains access to a common operating record that is independent of any single supplier portal.
Policy
Write the rules once, in one place
The operating rules. What a machine may do, what it may not, and how it behaves toward other machines and toward people. Written once, then applied to each system you bring on afterwards.
Compliance
Find out that a rule broke without being told
Operator-accessible evidence continuously checked against defined policies, independently of any single supplier’s reporting environment. Rather than evaluating each supplier through a different reporting framework, the operator sees one cross-supplier view.
Action
Change what a machine is doing, and reach whoever answers for it
A route to change what a machine is doing, and a route to reach whoever answers for it. Passenger records both.
Audit
Answer an insurer eighteen months later
What was required, what happened, what got caught, and what you did about it. Time-stamped and retained, so an operator, an insurer or a council can see the record rather than reconstruct it.
Insight
Learn something no single supplier could tell you
Findings across suppliers that no single one of them could produce. These return to AG-4 Policy and become revised rules, which is the step that turns reporting into governance.
The category. Software built to meet these requirements is an automation governance platform, or AGP — a category in the sense ERP and CRM are categories, sitting above each supplier’s own tooling and below the enterprise systems, and answerable to the operator rather than to any one vendor. Passenger is Real Life Robotics’ AGP. The framework describes what the category has to do; this page describes what Passenger does.
The framework is published open and vendor-neutral. It sets out the operating requirements we believe organisations will need as automation scales, and it can be met with other tools or with none. It describes where this is going, and Passenger is built against it. What can actually be observed or acted on in a given operation depends on the integration, the data a supplier exposes, the permissions granted and, in some sectors, the rules of that sector. Read the framework in full.
Connecting a supplier is the hard part. We have already done it.
Anyone can draw a diagram with every robot connected to one box. Getting a third-party machine to actually talk to that box takes API access, a test rig, an engineer on the other end who has time, and several rounds of finding out what the documentation left out.
Onboarding from weeks to days
We have learned how to onboard hardware suppliers and built our own integration tools and processes. That experience can drastically reduce supported supplier onboarding from weeks to days, though the result depends on the supplier, its interfaces, available data, permissions and deployment requirements.
Integrations maintained beyond the initial deployment as you grow and scale
Real Life Robotics maintains supported integrations as supplier interfaces and firmware evolve, reducing the risk that a deployment becomes a one-off integration nobody owns.
Direct agreements, not open endpoints
Passenger connects through agreements with the OEMs themselves rather than public APIs that can be deprecated without warning. That is better for the operator and better for the supplier, who gets a customer they can support properly.
Bought a new machine from a supplier we have not met? Send us the contact. We onboard them, the integration joins the library, and the operators who come after you get the benefit of it.
Request a demonstration of how Passenger provides visibility and governance across connected automation systems.
We will walk you through how Passenger connects systems from different suppliers, what the operating view shows once they are on it, and how policy-based oversight works against the rules an operator has written.