PaperlayerView exact revision on arXiv

Source-linked AI summary

ARC: Autonomous Robotics Compliance A Three-Layer Governance Architecture for Deployed Autonomous Systems

Tord Eide, Einar Holt

arXiv:2609.12932v1cs.ROcs.AIcs.CY

TL;DR

Autonomous robots are being deployed at scale, but governance has not formalized the distinction between capability and permission. ARC proposes model validation, system certification, and operational authorization as connected layers; the cited ASIMOV evidence reports that no major frontier model’s constraint violation rate falls below 30% in a specified joint-reasoning setting.

  • Problem

    Governance has not operationally formalized what a robot may do in a particular deployment context, distinct from what it can do.

    Source: §1 · p. 2, §4.1 · p. 8

  • Method

    ARC links model safety validation, independent system-level cognitive certification, and site-specific operational authorization.

    Source: §1 · p. 2, §7 · p. 12

  • Results

    No major frontier model achieves a constraint violation rate below 30% when reasoning simultaneously about embodiment-specific limitations, physics, and visual inputs.

    Source: §2.2 · p. 3

  • Takeaways & Limitations

    ARC makes authorization specific to a robot, task, and site, and grounds it in continuously reviewed evidence.

    Source: §7 · p. 12

    Integration protocols, full CRAB evaluation methodology, and infrastructure for monitoring LEA learning-mode caps remain to be specified.

    Source: §6.4 · p. 12

Abstract

from arXiv · show

Proposed governance framework for autonomous robotic systems, introducing a three-layer compliance architecture (ARC) instantiated through model safety validation, cognitive certification benchmarks, and operational authorization standards.

1. Introduction

Autonomous robots are moving into operational deployment, while existing governance does not formalize the distinction between what a system can do and what it is authorized to do. ARC proposes a three-layer architecture connecting model validation, system certification, and site-specific authorization.

1. Introduction

  • The paper frames independent governance as an operational necessity as autonomous robots enter large-scale deployment.It cites deployments and announced activity across logistics, hospitals, home robotics, and humanoid control.Source: §1 · pp. 1–2
  • Existing frameworks do not operationally formalize the difference between a robot’s capability and its authorization for a specific context.Authorization depends on conditions, population, and regulatory environment.Source: §1 · p. 2
  • ARC separates model safety validation, independent system-level cognitive certification, and task- and site-specific operational authorization.Its layers are ASIMOV, CRAB, and LEA, respectively.Source: §1 · p. 2

2. Background and Related Work

Existing robotics standards and benchmarks address physical safety or controlled research comparison, but leave gaps in certifiable cognitive assessment and operational authorization. The ASIMOV evidence base reports substantial frontier-model constraint violations and identifies modality, embodiment, and latency gaps.

2.1 What Exists — and What It Does Not Cover

  • Physical-safety standards cover robot behavior, while current IEEE projects and academic benchmarks do not provide transferable, certifiable cognitive assessment or operational authorization.The cited standards address physical constraints; the academic benchmarks support controlled research comparison [2] [30] [31] [32].Source: §2.1 · pp. 2–3
  • A review of 20 European elder-care robotics projects found limited attention to ethical and legal dimensions and weak treatment of robots within accountability structures.Source: §2.1 · p. 3
  • ARC connects human-robot interaction, healthcare acceptance, runtime assurance, and the NIST AI RMF into an operational governance architecture.Source: §2.1 · p. 3

2.2 The ASIMOV Evidence Base

  • No major frontier model achieves a constraint violation rate below 30% when reasoning jointly about embodiment constraints, physics, and visual inputs.The ASIMOV evidence base identifies modality, embodiment, and latency gaps; its components assess injury risk, constraint adherence, and video-based risk perception.Source: §2.2 · p. 3
  • The ASIMOV-Agentic evaluation was incorporated into the Gemini Robotics 2 release on July 30, 2026.Source: §2.2 · p. 3
  • ASIMOV-Agentic evaluates model behavior under test conditions but does not certify integrated systems or determine what a robot may do at a particular site.CRAB and LEA address those respective gaps.Source: §2.2 · p. 3

3. The ARC Architecture

ARC’s layers depend on one another: outputs from each layer constrain the next, and the full architecture requires all three to address both system certification and operational authorization.

3. The ARC Architecture

  • Layer 1 outputs constrain Layer 2 evaluation design, while Layer 2 profiles constrain Layer 3 authorization ceilings.Source: §3.1 · p. 4
  • No single layer, or pair omitting Layer 3, answers the operational authorization question; omitting Layer 2 leaves system certification unanswered.Source: §3.1 · p. 4
  • Full governance requires all three ARC layers.Source: §3.1 · p. 4

3.2 Layer 1 — Model Validation (ASIMOV)

ASIMOV validation is intended to evaluate the specific model version against scenarios calibrated to the deployment’s contact class and environment. Its results are necessary to proceed to system-level evaluation, but are not sufficient for deployment authorization.

3.2 Layer 1 — Model Validation (ASIMOV)

  • ASIMOV evaluation should use scenarios calibrated to the intended contact class and environment for the specific model version being deployed.The passage contrasts this with relying on a generic benchmark result.Source: §3.2 · p. 4
  • ASIMOV performance is conditional on its test distribution and does not capture sensor-fusion errors, actuation noise, real-world disturbances, or multihour operational continuity.A model may perform well on ASIMOV scenarios while failing on out-of-distribution physical configurations.Source: §3.2 · p. 4
  • Layer 1 outputs are necessary to proceed to Layer 2, but they are not sufficient for deployment authorization.Source: §3.2 · p. 4

3.3 Layer 2 — System Certification (CRAB)

CRAB proposes independent cognitive certification of the integrated system, complementing model-level validation and site-specific authorization. It uses domain suites and per-dimension profiles as its primary governance evidence, with cryptographic attestation proposed for assessment records.

3.3 Layer 2 — System Certification (CRAB)

  • CRAB proposes independent cognitive certification of the integrated system, rather than assessing only the model or relying on a single score.The framework is a draft proposal whose claims, thresholds, and governance arrangements remain open to peer review and revision.Source: §3.3 · p. 4

3.3.1 Eight Cognitive Dimensions Tier 1 — Core Cognitive Capabilities:

  • SCA tests whether systems recognize authority limits, refuse out-of-scope requests, escalate appropriately, and document interactions; CRAB-H tests this across healthcare scenarios.For example, a medication request should prompt refusal and escalation to nursing staff, not compliance.Source: §3.3.1 · p. 5
  • CRAB-H transparency scenarios assess both post-hoc reasoning summaries and whether residents correctly understand real-time behavioral signals.The passage notes that people commonly misinterpret robot intent, which can depend on movement, form, and behavioral expression.Source: §3.3.1 · pp. 5–6

3.3.2 Domain Suites

  • CRAB defines healthcare, administrative-coordination, and industrial-logistics suites with scenarios tailored to each deployment domain.CRAB-H double-weights SCA and DT and requires their mandatory minimum thresholds; it also allows accredited bodies to publish advance domain-specific Tier 1 floors.Source: §3.3.2 · p. 6

3.3.3 Capability Profile and Attestation

  • Per-dimension capability profiles are the primary governance evidence; aggregate summaries are subordinate and cannot serve as a certification basis.Cardano anchoring is proposed as tamper-evident evidence that a credential existed and was not altered, but does not validate evaluator competence, test validity, or continuing status.Source: §3.3.3 · p. 6

3.4 Layer 3 — Operational Authorization (LEA)

LEA authorizes grants tied to a particular robot, task class, and site, so authorization varies with deployment context even when capability is unchanged. Its grant dimensions, fallback and incident rules, and graduation thresholds define how authorization is earned and maintained.

3.4 Layer 3 — Operational Authorization (LEA)

  • LEA classifies grants—not robots—and binds each grant to one identified robot, task class, and site.The same platform can hold different grants for different tasks and environments; a grant for a controlled warehouse does not establish the same authorization in a care facility.Source: §3.4 · pp. 6–7

3.4.1 Five Grant Dimensions

  • Autonomy levels range from teleoperation (A0) to open autonomy (A5), while contact classes cap physical assistance at A2 and clinical actions at A1.A5 has no defined conformance path; C2 requires live supervision, and C3 actions remain those of authorized healthcare personnel under continuous supervision.Source: §3.4.1 · p. 7
  • Evidence from a lower environment class does not transfer to a higher-numbered class, so institutional evidence does not justify a household grant.The framework distinguishes controlled industrial (E0), certified institution (E1), and private household (E2) environments.Source: §3.4.1 · p. 7
  • Learning mode constrains permitted autonomy, and grant status depends on logged supervised operation and ongoing metric monitoring.LM2 on-site learning is capped at A3; a grant failing maintenance conditions becomes SUSPENDED and automatically drops one autonomy level.Source: §3.4.1 · p. 7

3.4.2 Fallback Ladder and Incident Response

  • The fallback ladder prescribes five ordered responses to exceptions, while incident severity determines logging, suspension, or revocation.S1 deviations are logged, S2 incidents trigger automatic suspension, and S3 incidents trigger automatic revocation and mandatory reporting.Source: §3.4.2 · pp. 7–8

3.4.3 Graduation Thresholds

  • The illustrative A3/C1/E1 graduation proposal requires at least 400 supervised hours, an intervention rate no greater than 0.25 per 100 hours, and no unresolved S2-or-higher incident.These are informed proposals, not empirically validated optima, and should be revised as deployment evidence becomes available.Source: §3.4.3 · p. 8

4. Capability Is Not Permission

The section distinguishes capability—what a system can do—from permission, which depends on deployment context. It argues that authorization evidence should rise with autonomy and remain valid only while operational evidence supports it.

4.1 The Core Distinction

  • Capability describes what a system can do, while permission describes what it is authorized to do in a particular context.Permission depends on deployment context, regulation, the population served, and oversight arrangements.Source: §4.1 · p. 8
  • A system’s capability does not itself authorize the same task or autonomy level across settings, such as from a warehouse to a care home.The section characterizes equating capability with permission as a category error with practical consequences.Source: §4.1 · p. 8

4.2 Why the Distinction Becomes More Critical as Capability Increases

  • The governance burden should increase with the autonomy level sought, and LEA requires more supervised hours, lower intervention rates, and higher fallback integrity for higher autonomy.The section links ongoing authorization to the fact that AI-based workers can change through learning, updates, and environmental adaptation.Source: §4.2 · pp. 8–9

4.3 The Static Certification Problem

  • LEA addresses changing system behavior by making authorization validity depend on current operational metrics rather than a one-time certification event.For a system in LM2, the paper gives the example that it may be substantively different after 90 days; authorization expires de facto when performance evidence no longer supports it.Source: §4.3 · p. 9

5. Healthcare Deployment Case Study

The case study proposes a care-facility meal-delivery deployment and applies the ARC layers to it. The illustrative CRAB-H result is conditional because the generalization score is below a proposed domain floor, so the initial LEA record uses supervised task autonomy while site-specific evidence accumulates.

5.1 Scenario and Sensor Selection

  • The proposed care-facility platform uses gated updates and mono-thermal and depth sensing, with RGB video restricted to authorized, time-limited fault diagnosis.The cited work reports mono-thermal cameras as a balance between technical utility and privacy perception, while RGB is experienced as more intrusive.Source: §5.1 · p. 9

5.2 Layer 1 Application

  • Before deployment consideration, the specific model version must meet a proposed constraint-violation threshold below 15% for C1 scenarios on ASIMOV-Agentic.The evaluation is intended to reflect the deployment’s contact class and model version, rather than a generic foundation-model benchmark.Source: §5.2 · p. 9

PROPOSED CRAB-H ASSESSMENT — meal-round-logistics

  • The illustrative CRAB-H profile yields a weighted mean of 857, but the aggregate is contextual only and does not determine authorization eligibility.The per-dimension record remains the basis for authorization decisions.Source: §5.3 · p. 9, PROPOSED CRAB-H ASSESSMENT —… · p. 10
  • CG 720 falls below the illustrative domain-specific floor of 750, producing a conditional outcome that requires enhanced supervision until further deployment evidence supports out-of-distribution reliability.The supplementary Tier 1 floor is an illustrative accreditation-body option that must be published in advance; the profile also reports SCA 920 as a patient-safety strength.Source: PROPOSED CRAB-H ASSESSMENT —… · p. 10

PROPOSED LEA RECORD — meal-round-logistics

6. Discussion

The discussion frames ARC as a proposal rather than a recognized compliance mechanism and identifies regulatory, trust, empirical-calibration, and specification questions that remain open.

6.1 Regulatory Alignment

  • The EU AI Act does not prescribe CRAB or LEA metrics, and both could only inform future compliance after independent legal and technical validation.High-risk classification depends on Article 6 criteria; ARC is proposed for testing and comment, not as a recognized compliance mechanism.Source: §6.1 · p. 11

6.2 Trust Infrastructure

  • Full CRAB credential verifiability requires an agreed W3C-compatible architecture, while who may issue, suspend, revoke, and audit credentials remains open.The proposed infrastructure includes decentralized identifiers, verifiable credentials, trusted issuer registries, revocation services, and audit access rules.Source: §6.2 · p. 11

6.3 ROBOWELL and Empirical Calibration

  • LEA graduation thresholds are governance proposals, not empirically derived optima; ROBOWELL data could help calibrate E1/C1/A2–A3 thresholds, subject to ethics approval and participant consent.The proposed calibration would draw on longitudinal behavioural data from elder-care deployments.Source: §6.3 · pp. 11–12

6.4 Open Questions and Future Work

  • Further work must specify layer integration, CRAB scenario construction, scoring and inter-rater reliability, learning-mode monitoring, and a standardization pathway.CRAB v0.3 specifies dimensions and domain-suite requirements, but not the full evaluation methodology needed for accredited body qualification.Source: §6.4 · p. 12

7. Conclusion

The conclusion argues that demonstrated task capability is not authorization for a particular deployment context. ARC proposes three distinct, complementary governance layers as a candidate minimum architecture, while remaining open for review rather than an adopted standard.

7. Conclusion

  • A system’s demonstrated ability to perform a task does not authorize it for a specific deployment context, population, or regulatory setting.The paper identifies conflating capability with permission as the central governance failure.Source: §7 · p. 12
  • ARC proposes model-level safety validation, independent system-level cognitive certification, and site- and task-specific operational authorization.The layers are ASIMOV-Agentic, CRAB, and LEA, respectively.Source: §7 · p. 12
  • The three layers together form a candidate minimum governance architecture for safety-critical deployment, but CRAB and LEA are not adopted standards or legally recognized authorization mechanisms.The proposal is intended for peer review, pilot design, public consultation, and regulatory engagement.Source: §7 · p. 12
  • ARC connects capability and permission without treating them as the same thing.The framework’s concise formulation is “Capability is not permission. ARC connects both.”Source: §7 · p. 12
Loading 2609.12932v1…