Our method · Independent Robotics Ontology (IRO)

Mission first. Evidence always.

Our approach is informed by the Independent Robotics Ontology, a framework that describes any machine across 16 facets and judges independence only for a defined mission, environment and body of evidence.

The IRO is a working framework informed by international standards. It is not itself an ISO or IEEE standard, and it is not a certification. Applicability of each standard is determined for every use case.

CENTRAL DESIGN RULE

Do not infer autonomy from morphology, intelligence from conversational fluency, or independence from the presence of onboard AI.

Every significant claim is linked to a task, an operating context and test evidence.

Five concepts, kept apart

Five questions that are never confused.

A humanoid can be highly human-like yet remotely controlled. A machine with no human features can show strong mission autonomy.

CONCEPTTHE QUESTION WE ASK
AnthropomorphismWhat human-like design cues, behaviors or qualities are present or perceived?
EmbodimentWhat physical body, effectors, sensors and locomotion does the machine possess?
IntelligenceWhat perception, reasoning, memory, learning and planning competence is demonstrated?
AutonomyWhich control, decision and execution functions can it perform without human intervention?
IndependenceCan it satisfy a defined mission despite specified external dependencies, uncertainty and disturbances?

16 facets

One machine, sixteen lenses.

Facets are orthogonal: they overlap and are never mutually exclusive categories. The same machine can have different profiles for different missions.

01Embodiment & formBody plan, morphology, mobility, actuators
02AnthropomorphismDesigned human-likeness and observer perception
03Intelligence & cognitionWorld models, reasoning, memory, planning
04Autonomy & agencyFunction-level autonomy and authority
05Operational independenceMission-specific claims and dependency tolerance
06Perception & sensingSensors, fusion, environmental interpretation
07Physical capabilitiesNavigation, dexterity, force and payload
08Social interactionCommunication, social cues, affective simulation
09Human–machine relationshipsPeople, roles, collaboration, oversight, consent
10Collective intelligenceFleets, swarms and coordination
11Environment & contextOperating domain, hazards, terrain
12AI & computing architectureModels, compute placement, control stack
13Resources & dependenciesPower, connectivity, consumables, maintenance
14Safety & governanceRisk, constraints, audit and override
15Learning & adaptationOffline and online learning, drift, approval limits
16Lifecycle & performanceEvidence, versions, KPIs, incidents

Operational independence

Twelve ways a machine can depend on something else.

A machine can decide autonomously and still depend on a cloud service, an operator, a charger, a fleet manager or a maintenance crew.

 

DIMENSIONINDEPENDENCE CLAIMTYPICAL EXTERNAL DEPENDENCY
CognitiveOnboard reasoning supports mission decisionsCloud planner or remote AI inference
PerceptualCan sense and interpret the relevant scene locallyExternal sensors or remote interpretation
NavigationCan localize, route and avoid obstaclesExternal localization or guide path
ManipulationCan execute required object interactionsHuman intervention or external fixture
DecisionCan choose permitted actions without routine approvalOperator sign-off
ComputingCan execute safety-critical workloads locallyRemote compute availability
ConnectivityCan continue the essential mission during a specified outageNetwork service
EnergyCan manage available charge and recoveryPower and charging assistance
MaintenanceCan diagnose and resolve supported service eventsTechnician or service robot
RecoveryCan restore operation after covered disturbancesRemote operator
CollectiveCan coordinate with peers within a defined modeCentral fleet orchestration
MissionCan achieve mission success criteria independentlyTask-level external direction
CONTEXTUAL DEFINITION

I(R, M, O, T, C): robot, mission, operating domain, time window and constraints.

An independence claim is valid only for the specified mission conditions, evidence scope and defined disturbances.

Operational maturity

Five working classes, never a label alone.

These L1–L5 classes are Iron Vektor working classes. They are not official ISO, IEEE, SAE or NIST levels.

L1Task automation

Executes predesigned instructions; an external system selects objectives and actions.

L2Conditional autonomy

Selects among known responses; significant exceptions remain human-managed.

L3Mission autonomy

Plans and completes bounded missions with limited supervision.

L4Resilient independence

Handles defined disturbances, failures and changes within approved bounds.

L5Extended independence

Manages multiple missions and routine resources with minimal intervention.

Evidence-led assessment

How a claim earns its place.

We evaluate a machine against mission outcomes and explicit stressors, never against an unconditional marketing label.

STEPEVIDENCE CAPTUREDDECISION
1 · Define missionObjective, success criteria, boundaries, time windowIs the mission well specified?
2 · Define environmentConditions, users, terrain and hazardsIs the context representative?
3 · Map dependenciesHuman, compute, power, infrastructure, maintenanceWhich external supports are essential?
4 · Select dimensionsWhich of the 12 independence axes materially affect the missionWhat must be tested?
5 · Run scenariosNominal cases, edge cases, disturbances, simulated failuresDoes the mission complete safely?
6 · Score and recordKPIs, denominators, uncertainty, violation evidenceWhat claim is supported?
7 · Establish controlsEscalation, monitoring, rollback, validity dateUnder what conditions may it operate?
OPERATIONAL KPIS WE REQUIRE, EACH WITH ITS DENOMINATOR AND CONDITIONS
Autonomous mission completionInterventions per 100 missionsMean time between assistanceDisconnected completion rateResource enduranceAutomatic fault recoverySelf-service successConstraint compliance

Why one label is never enough

Seven archetypes, seven different questions.

Generic archetypes, not product specifications. They show why a single-axis classification is inadequate.

ARCHETYPEBODY AND HUMAN-LIKENESSREPRESENTATIVE AUTONOMYCRITICAL INDEPENDENCE QUESTION
Industrial manipulatorFunctional, limited social likenessRepeatable programmed movementsRequires an external cell, fixtures or supervision?
Warehouse AMRWheeled, usually lowBounded navigation missionsCan it continue if the network or fleet service fails?
Inspection quadrupedZoomorphic, low human likenessAutonomous inspection routesCan it recover from terrain disturbance?
Warehouse humanoidHumanoid, high physical likenessTask dependentCan it reliably grasp diverse objects?
Social androidHuman-realistic, highInteraction dependentDoes apparent intelligence exceed verified competence?
Survey droneAerial, lowNavigation and acquisitionWhat happens under loss of link or localization?
Multi-machine swarmDistributed, mixedCollective allocation or coordinationDoes the system fail under peer loss?

Standards and references

Built on recognized foundations.

The IRO maps to, and does not replace, international standards and validated instruments. Their scopes differ and must be determined for each use case.

Ready to assess your mission?

We apply this method to every deployment. Tell us your mission and operating environment.