A Robot’s Capability Is Not Its Authority

A new robotics adoption programme

The UK has launched eight Robotics Adoption Hubs to help organisations explore, test and deploy robotics and autonomous systems.

The programme spans surgery, agriculture, manufacturing, waste, logistics, drones, autonomous vehicles and robots operating in public spaces.

Practical demonstrations will be central to the programme. They can help an organisation establish whether a robot can perform a useful task.

Before deployment, another question must also be answered: under which conditions is that robot authorised to perform the task?

A successful demonstration proves capability

Consider a service robot being evaluated for deliveries across a large site.

A demonstration might establish that it can:

• Navigate between buildings.
• Avoid obstacles.
• Carry the required load.
• Communicate its location.
• Complete the journey within the expected time.

Those results matter. They do not define the robot’s operational mandate.

The robot may be capable of entering a restricted area, changing its destination or continuing after communications are lost. Capability alone does not establish that any of those actions are permitted.

Authority changes with the action and context

Robotic systems encounter changing environments.

A delivery route may become unavailable. A drone may propose leaving its approved area. An agricultural robot may encounter a different field or crop. A manufacturing robot may receive a task outside the scheduled production window.

Each change can produce a new proposed action.

An organisation may need to establish:

• Which robot and task are involved.
• What action is being proposed.
• What operational context applies.
• Which location, person or asset would be affected.
• What authority is available.
• Whether human approval is required.
• What should happen when information is missing or contradictory.

Depending on that context, the governed result might be to Allow, Deny, Modify, Step Up or Stop the Line for the specific action.

Stopping one proposed movement or task need not disable the robot or unrelated operations.

Evidence must connect the decision with the physical result

A record showing that an action was authorised does not prove that the robot performed it.

Equally, telemetry showing that a robot moved does not establish that the movement was properly authorised.

A useful operational record should connect:

• The task and approved operating conditions.
• The robot, software and configuration involved.
• The information available at the time.
• The action proposed.
• The applicable authority.
• The governed result.
• Any modification or escalation.
• The instruction presented to the robot.
• Trusted evidence of what the robot reported as the resulting effect.

Records of authorisation and evidence of execution perform different jobs. Both are required for a credible account.

Adoption testing can include authority without live actuation

A robotics adoption exercise does not need to begin by allowing a new governance component to control physical equipment.

Representative action requests can first be evaluated using synthetic scenarios, recorded telemetry, simulated environments, replayed mission changes or a controlled shadow workflow.

The exercise could test whether:

• A change of target triggers a fresh evaluation.
• An action outside the approved area is denied.
• An excessive request is modified.
• Missing evidence causes an appropriate escalation.
• An action-specific stop leaves unrelated activity available.
• A reviewer can reconstruct the evaluation afterwards.

This would assess the authority boundary without issuing commands to a live robot.

PF Systems’ bounded relevance

PF Memory can provide the governed operational knowledge and context relevant to an evaluation. It does not decide or execute.

PF Kernel can evaluate the proposed action and return Allow, Deny, Modify, Step Up or Stop the Line.

PF Core can preserve linked evidence and the material needed to trace, check and deterministically replay that governed evaluation. It does not make the underlying probabilistic AI deterministic or automatically reproduce a physical action.

ClientBridge can connect participating systems without inheriting PF Kernel’s authority. Trusted evidence from the robot, controller or other executing system remains necessary to establish what became effective.

Proof Harness could qualify the available evidence against a defined, controlled exercise. It would not certify the robot, establish functional safety or approve a deployment. PF Trace could display preserved evidence without creating it.

The new adoption hubs can help organisations understand what robotics can contribute.

The complementary governance principle is: before a robot enters practical use, test not only whether it can perform the task—but whether each consequential action remains within its authority.