Open Intent: A Canonical Taxonomy for Autonomous Actions

Intended, Inc., USA research@intended.so

Taxonomy-alignment and branding revision. Aligned to the Open Intent taxonomy version 2.1 (29 domains, 173 canonical intent categories; the 2.1 revision is an additive record-schema enrichment over 2.0 — domain and category membership are unchanged), published through the open-intent repository. The Open Intent repository (https://github.com/intended-so/open-intent) serves as the normative source of truth for domain definitions, category identifiers, and future taxonomy revisions.

ACM Reference Format: Intended, Inc. 2026. Open Intent: A Canonical Taxonomy for Autonomous Actions Across Digital and Physical Systems. 1, 1 (2026). https://doi.org/10.1145/nnnnnnn.nnnnnnn

Abstract

Autonomous systems execute increasingly high-impact actions across identity, infrastructure, software delivery, financial operations, customer operations, and physical action (industrial robotics, autonomous machines, embodied AI systems). Governance controls have not kept pace because action semantics are fragmented across both software-agent frameworks and physical-agent control stacks. This paper presents Open Intent, a canonical taxonomy of 173 canonical intent categories across 29 domains — 80 categories across 14 digital-operations domains, 86 categories across 14 embodied/physical-operations domains, and 7 categories in a dedicated embodied-AI-safety domain — for classifying autonomous actions into deterministic, auditable, and interoperable control classes under a unified naming grammar.

Open Intent is not a software taxonomy. Open Intent is an autonomous-action taxonomy spanning both digital and physical systems. It operates at the intent-category layer: implementations may map thousands of vendor-specific actions, API calls, robot commands, workflow events, and autonomous behaviors into these canonical categories. Surface forms as varied as POST /deployments, terraform apply, MAV_CMD_NAV_TAKEOFF, a ROS 2 Pick action, and an OPC-UA MoveAxis command may all normalize into the appropriate canonical Open Intent category. Open Intent defines the canonical classification layer — not the exhaustive list of every possible action.

This manuscript defines the taxonomy model, naming grammar, disambiguation rules, conformance levels, and interoperability mappings. Internal validation reports complete intent-breadth coverage, full constrained pairwise route-adapter coverage, large combinational coverage with zero capability-resolution mapping failures, and end-to-end physical-domain coverage including authority-token issuance, actor-registration gating, emergency-stop deny pathways, and revocation propagation. The paper also defines an external replication protocol for independent evaluation against third-party traces. The goal is to establish a reusable classification layer for policy portability, audit comparability, and standards alignment across both digital and physical autonomous deployment contexts.

1. Executive Summary

Open Intent provides a vendor-neutral classification framework for autonomous actions across software agents, robotics, industrial systems, autonomous vehicles, medical robotics, drones, and embodied AI. It is a shared classification layer between runtime actions and governance controls. The contribution is a canonical intent-category taxonomy intended for cross-vendor use, independent of any single runtime implementation.

The manuscript contributes:

• a taxonomy artifact with 173 canonical intent categories across 29 domains, spanning both digital and physical autonomous action;
• normative classification and disambiguation rules;
• conformance profiles for implementation claims, including a Physical-Action Conformance level for implementations that classify physical-domain action;
• internal validation results with explicit methodological boundaries, covering both digital-domain pathway coverage and physical-domain authority-token + actor-registration + emergency-stop + revocation lifecycle;
• a standards-oriented framework mapping model, including European Union Artificial Intelligence Act alignment logic and EU Machinery Regulation 2023/1230 interoperability for physical-agent deployments;
• extended physical-domain classification covering robotic, autonomous-machine, and embodied-agent action primitives under the same disambiguation grammar used for digital action.

The central claim is constrained: Open Intent improves semantic consistency and control portability for autonomous-systems governance. The manuscript does not claim complete external generalization without independent third-party trace replication.

1.1 A Note on Naming

The taxonomy was originally developed under a working name whose three-letter acronym collided with the dominant vocabulary of the petroleum sector — an unnecessary ambiguity for a standard that spans energy and utilities, mining, industrial automation, autonomous vehicles, robotics, drones, and embodied-AI safety. As the framework expanded beyond software agents into physical and embodied AI systems, the project adopted Open Intent as the primary standards identity, with OI- as the canonical identifier prefix (for example, OI-2901). The identifiers are implementation artifacts; Open Intent is the name of the standard. Numbering is unchanged from earlier releases — only the prefix differs — so identifiers published under the legacy prefix map 1:1 to their OI- forms. Subsequent references in this manuscript use Open Intent for the standard and reserve the OI- prefix for the identifier codes themselves.

1.2 Open Intent in the Broader Ecosystem

Open Intent is one layer of a larger architecture, and the taxonomy is deliberately scoped so that it does not absorb the branding or the responsibilities of the layers around it. The layers are distinct:

• Open Intent — the open classification standard for autonomous actions. This manuscript specifies it.
• Large Intent Model (LIM) — the interpretation engine that resolves observed actions and natural-language requests into governable Open Intent categories. LIM is an interpreter built on top of the standard, not part of the taxonomy.
• Authority Tokens — the portable authority primitive: short-lived signed grants that carry verifiable proof that an action was authorized.
• Intent Verification Infrastructure — the governance category in which intents are classified, policy-checked, enforced, and recorded.
• Intended — the company building the infrastructure around these standards.

Readers should understand these as separate layers of one ecosystem. Open Intent is the vocabulary; the other layers interpret, enforce, and operate over that vocabulary.

Figure 1 summarizes the overall structure of the standard: 29 domains and 173 canonical intent categories allocated across three surfaces.

Figure 1. Open Intent taxonomy structure. The standard comprises 29 domains and 173 canonical intent categories across three surfaces — digital (OI-100–OI-1400; 14 domains, 80 categories), physical/embodied (OI-1500–OI-2800; 14 domains, 86 categories), and a dedicated embodied-AI-safety surface (OI-2900; 7 categories) — all governed by one identifier grammar and one conformance regime.

2. Why a Standard Is Needed Now

Autonomous-system ecosystems increasingly combine orchestration frameworks, tool adapters, and policy engines. Across these stacks, equivalent actions are expressed through inconsistent terms such as task, tool call, function invocation, operation, and step [11]–[14]. This lexical fragmentation degrades control portability and produces audit evidence that is difficult to compare across organizations.

The governance consequence is structural:

• policy definitions become implementation-specific;
• compliance mappings are manually re-authored per platform;
• audit interpretation varies by vendor schema rather than control intent;
• regulators and assessors lack a stable action ontology.

A standard taxonomy must therefore be both expressive and constrained: expressive enough to represent real operational behavior and constrained enough to support deterministic classification.

2.1 Lexical fragmentation in physical-agent ecosystems

The same lexical fragmentation that motivates a canonical taxonomy for software agents recurs in physical-agent ecosystems. Robotic control stacks express equivalent physical actions through inconsistent terms. The Robot Operating System describes a manipulation primitive as an action; behavior-tree-based stacks call the same primitive a node or a skill; programmable-logic-controller-derived industrial frameworks use operation or work-cell command; autonomous-vehicle stacks call equivalent kinematic decisions trajectories, maneuvers, or plans. Equivalent emergency-stop semantics appear under the labels e-stop, safety halt, protective stop, emergency power off, and category-0 stop, sometimes with materially different downstream behavior under the same label across vendors.

The governance consequence is structurally identical to the digital case. Policy authored against one robot's vocabulary does not port to another vendor's stack. Safety audits compare event streams whose semantics are not directly comparable. Standards bodies maintain crosswalks across the EU Machinery Regulation, ISO 10218 industrial robot safety, ISO 13482 personal care robot safety, ISO 26262 automotive functional safety, and AI-specific obligations under the EU AI Act, with no shared action-classification substrate to anchor any of them.

A taxonomy that succeeds at canonical classification for software agents but treats physical-agent action as a different problem leaves the governance landscape bifurcated at exactly the layer where embodied AI systems are arriving in production. The Open Intent contribution is that the same naming grammar, the same disambiguation rules, and the same conformance regime apply uniformly to both surfaces.

This normalization is illustrated in Figure 2: heterogeneous surface forms drawn from both digital and physical stacks resolve to a single canonical intent-category layer.

Figure 2. Autonomous action normalization pipeline. Surface forms as varied as POST /deployments, terraform apply, a ROS 2 Pick action, MAV_CMD_NAV_TAKEOFF, an OPC-UA MoveAxis command, a medical-robot motion, and a category-0 stop all normalize into canonical categories (for example OI-104 Deployment & Release, OI-1502 Pick & Place, OI-2101 Flight Operations, OI-2201 Surgical Procedure, OI-2901 Emergency Stop). Policy attaches to the canonical category, not the vendor surface form.

3. Related Work

3.1 Security Taxonomy Precedents

MITRE ATT&CK demonstrates how a shared behavior taxonomy can improve cross-team and cross-tool consistency in cybersecurity operations [1], [2]. Common Weakness Enumeration provides a complementary precedent in software security classification [16]. Open Intent is analogous in ambition but scoped to autonomous-action governance semantics rather than adversary behavior or software weakness classes.

3.2 Governance and Trustworthiness Frameworks

NIST AI RMF 1.0, NIST adversarial machine learning taxonomy work, and trustworthiness-taxonomy research establish strong governance terminology and risk language [3], [4], [10]. Open Intent complements these frameworks by focusing on canonical runtime action classification as the missing link between governance principles and enforceable control attachment.

3.3 Agent-Security and Evaluation Literature

Recent work on agent attack surfaces, including AgentDojo, demonstrates that autonomous and tool-using agents require systematic evaluation frameworks [9]. Open Intent addresses a different layer: standardized action semantics for governance, evidence, and policy portability across heterogeneous systems.

3.4 Metadata and Interoperability Standards

Cross-domain standards such as Dublin Core show that stable metadata schemas can enable interoperability at ecosystem scale [15]. Open Intent applies this design philosophy to operational action semantics in autonomous-systems governance.

3.5 Physical-Agent Safety and Embodied-AI Literature

Physical-agent action safety is governed by a mature body of standards that predates AI-specific governance. The International Organization for Standardization publishes ISO 10218-1 and ISO 10218-2 for industrial robots [23], ISO 13482 for personal-care robots [24], and ISO 13849 for the safety of machinery control systems generally [25]. The International Electrotechnical Commission publishes IEC 61508 as the parent functional-safety standard [26] and IEC 62443 for industrial automation cybersecurity [27]. ISO 26262 governs road vehicle functional safety [28]. ASTM F3269 defines methods to safely bound flight behavior of unmanned aircraft systems containing complex functions [29]. The Robotic Industries Association publishes ANSI/RIA R15.06 as the United States national standard for industrial robots [30]. IEEE Std 1872 specifies an ontology for robotics and automation that supplies shared vocabulary for robot types, tasks, and environments [31]. NIST Interagency Report 8419 addresses cybersecurity and safety standard selection for industrial robots specifically [32].

These standards establish hardware and control-system safety primitives and prescribe risk-management processes. They do not provide canonical action-intent classification at the policy boundary. The contribution of Open Intent in this context is the same as for software agents: a canonical intent layer that sits on top of existing safety primitives, allowing policy attachment, audit comparability, and standards-track classification of autonomous actions across heterogeneous physical platforms. The intent grammar applied to actuator commands, manipulation primitives, and navigation actions is identical in structure to the grammar applied to identity, deployment, and data-handling actions.

4. Design Goals, Standard Criteria, and Non-Goals

4.1 Design Goals

Open Intent is designed for:

1. Determinism: equivalent actions map to equivalent canonical intent categories.
2. Auditability: each classification is explainable and evidence-compatible.
3. Vendor neutrality: taxonomy use is independent of runtime vendor choice.
4. Cross-domain applicability: one schema spans heterogeneous digital and physical operations.
5. Extensibility: additive evolution without breaking compatibility.
6. Surface neutrality: the same naming grammar, disambiguation rules, and conformance regime apply uniformly to digital and physical autonomous action.

4.2 Standard Criteria

A standards-track taxonomy must provide:

• normative naming grammar;
• explicit versioning and compatibility policy;
• conformance tests and profile definitions;
• transparent governance for updates and deprecations.

4.3 Non-Goals

Open Intent is not:

• a policy language;
• a runtime enforcement engine;
• a universal risk-scoring model;
• a functional-safety certification regime.

These layers are implementation choices. Open Intent defines the canonical action-classification substrate they consume. In particular, Open Intent does not replace or subsume the obligations of ISO 13849, ISO 13482, ISO 26262, IEC 61508, or the EU Machinery Regulation 2023/1230 for physical-agent deployments. Implementations that classify physical-domain action under Open Intent must independently satisfy the safety-primitive obligations of the applicable safety regime. Open Intent contributes canonical action classification on top of those safety primitives, not in place of them.

5. Open Intent Core Model

5.1 Canonical Identifier Structure

Open Intent uses stable numeric identifiers for canonical intent categories. Domains are identified by a hundreds-block code (for example, OI-100 Software Development, OI-1500 Manipulation, OI-2900 Embodied AI Safety), and the categories within a domain are numbered sequentially beneath it (for example, OI-104 Deployment & Release, OI-1502 Pick & Place, OI-2901 Emergency Stop). Identifier stability is treated as a compatibility requirement: numeric identifiers are stable across releases, and the repository is the normative source of truth for the assignment of identifiers to categories.

Human-readable aliases and runtime-specific action mappings may be layered on top of these identifiers by implementations. The canonical layer is the numeric category identifier; the surface form an implementation observes — whether a digital API call, an infrastructure-as-code operation, a robot command, or an industrial control message — is normalized into that identifier rather than serving as the identifier itself. The same numeric grammar resolves digital resources (identity, deploy, data) and physical resources (manipulation, locomotion, actuation, emergency stop); the grammar is identical in both cases.

On the OI- identifier prefix. The canonical identifier prefix is OI- (OI-100, OI-1500, OI-2900). These codes are implementation artifacts. Earlier taxonomy releases published the same identifiers under a longer legacy prefix; the numbering is unchanged and the two forms map 1:1, so this is a naming transition only — the taxonomy is not renumbered and the specification is unchanged. The open-intent repository is the normative source for identifier assignment and resolves the legacy prefix during the transition. Open Intent is the name of the standard; the OI-prefixed codes are stable identifiers that resolve to the same canonical categories regardless of the brand under which the standard is published.

5.2 Domain Allocation Model

The 173 canonical intent categories are allocated across 29 domains and three surfaces. The repository is the normative source for the exact membership of each domain; the allocation model is summarized here and enumerated in Appendix A. Figure 3 shows how the standard spans both the digital and physical surfaces under one classification standard, with safety as a surface in its own right.

Figure 3. Digital-to-physical coverage map. Open Intent spans a digital surface (enterprise, software, cloud, finance, security) and a physical/embodied surface (robotics, manufacturing, vehicles, medical, drones, energy) under a single classification standard, with a dedicated embodied-AI-safety surface (OI-2900) spanning every physical deployment.

Digital Enterprise Operations — OI-100 through OI-1400. 14 domains, 80 categories. Examples of domains: Software Development, Security Operations, Infrastructure, Cloud Operations, Financial Operations, Revenue Operations.

Embodied and Physical AI Operations — OI-1500 through OI-2800. 14 domains, 86 categories. Examples of domains: Manipulation, Locomotion & Mobility, Sensing & Perception, Actuation & Control, Manufacturing & Production, Autonomous Vehicles, Aerial Systems, Surgical & Medical Robotics, Energy & Utilities. The full physical-surface breadth is enumerated in Figure 4.

Figure 4. Physical AI domain coverage. The 14 physical-operations domains (OI-1500–OI-2800, 86 categories) span manipulation, mobility, perception, control, manufacturing, vehicles, aerial systems, medical robotics, agriculture, construction, hazardous environments, energy, mining, and logistics, with embodied-AI safety (OI-2900) as a first-class safety domain.

Embodied AI Safety — OI-2900. 1 domain, 7 categories. Examples of categories: Emergency Stop, Geofencing, Human-Presence Detection, Safety-Rated Motion, Lockout / Tagout.

This three-surface allocation lets a reader immediately understand the structure of the taxonomy: a digital surface, a physical surface, and a dedicated safety surface, all governed by one identifier grammar and one conformance regime.

5.3 OI-2900 — Embodied AI Safety

Unlike most physical-AI taxonomies, Open Intent explicitly models safety primitives as first-class intent categories rather than as metadata attached to other actions. The OI-2900 Embodied AI Safety domain contains seven canonical categories:

• OI-2901 Emergency Stop
• OI-2902 Geofencing
• OI-2903 Human-Presence Detection
• OI-2904 Safety-Rated Motion
• OI-2905 Lockout / Tagout
• OI-2906 Collision Avoidance
• OI-2907 Compliance & Certification

Safety is not metadata. Safety is an operational intent category. Modeling emergency stop, geofencing, human-presence detection, safety-rated motion, lockout/tagout, collision avoidance, and compliance/certification as canonical intent categories means that safety actions are classified, policy-attached, evidence-bearing, and auditable under the same regime as every other autonomous action — rather than being inferred from vendor-specific control-loop semantics. This is what makes the Open Intent safety model independently observable and comparable across heterogeneous physical platforms. It does not replace the functional-safety obligations of the applicable regime (Section 4.3); it provides canonical classification and provenance on top of them.

5.4 Intent Record Requirements

As of taxonomy version 2.1, each of the 173 canonical intent-category records in the repository carries the following fields. The repository is the normative source; the field definitions, allowed values, and derivation rules are documented alongside the taxonomy asset.

• identifier (code): the stable numeric OI- identifier.
• semantic definition (description): the canonical human-readable definition.
• disambiguation boundary notes (disambiguationNotes): a note separating the category from its nearest siblings.
• contextual entities (contextualEntities): entity types that scope classification, split into required (must be present to classify) and optional (refine when present).
• evidence expectations (evidenceExpectations): the artifact classes an auditor should expect as proof of the intent for downstream audit usage.

Two further fields carry the physical-action authority semantics. Both are populated on all 173 records so that classification tooling can rely on their presence uniformly; their values follow the physical/digital distinction below.

• safety-relevance flag (safetyRelevant): a Boolean indicating whether actuation of this intent requires a signed authority token at an actuator boundary. It is true for every physical-domain intent (OI-1500–OI-2800) and every safety-domain intent (OI-2900), and false for digital-domain intents (OI-100–OI-1400), which have no physical actuator boundary and whose audit-evidence sufficiency does not require cryptographic actuation provenance. Enforcement of token issuance keys on this flag being true.
• actor-class constraint (actorClassConstraint): the registered actor classes permitted to invoke this intent, enforced at the authority-token issuance point. It is derived per domain from a documented actor-class enumeration; digital domains resolve to software-agent, each physical domain to its primary registered actor class, and the safety domain (OI-2900) to the intentionally-open sentinel * (per §5.5 rule 6).

The safety-relevance flag is intentionally binary in version 2.1; a graded severity enumeration is a documented target for a future version, not a shipped field (see §12).

5.5 Disambiguation Rules

Classification precedence is:

1. operation semantics over tool-native labels;
2. target resource semantics over call-site naming artifacts;
3. action-effect semantics over user-prompt surface wording;
4. governance-relevant outcome semantics over framework-local event aliases;
5. for physical actions, the canonical intent category is determined by the effect on the physical environment, not by the controller-side command primitive. A pick-up action expressed as a behavior-tree leaf, a ROS action, or a programmable-logic-controller operation classifies identically (into OI-1502 Pick & Place) when the effect on the workspace is equivalent;
6. emergency-stop and safety-override actions are classified into the dedicated safety domain (OI-2900) irrespective of the originating control loop. The Open Intent identifier for emergency stop (OI-2901) is canonical across category-0, category-1, and protective-stop variants, with the safety-relevance flag set true and the actor-class constraint intentionally open.

5.6 Versioning

Open Intent versions evolve additively by default. Deletions and semantic-breaking changes require deprecation windows and explicit migration mappings. Numeric identifiers, once assigned, are stable.

6. Methodology and Validation Process

6.1 Methodological Scope and Evidence Classes

The manuscript uses three evidence classes:

1. taxonomy-source evidence;
2. deterministic internal validation evidence;
3. external replication protocol evidence.

Claims are limited to those evidence classes. No broad external generalization claim is made without independent third-party trace results.

6.2 Corpus Construction

The corpus used for taxonomy and validation consists of:

• Canonical intent-category corpus: 173 canonical intent categories across 29 domains, comprising 80 categories across 14 digital-operations domains, 86 categories across 14 embodied/physical-operations domains, and 7 categories in the dedicated embodied-AI-safety domain (OI-2900). The April 2026 software-only revision (306 fine-grained intents across 14 domains) was restructured to a category-level grain when the physical-agent domains were added; the restructure preserved coverage while improving cross-surface consistency in identifier resolution. Open Intent now operates at the intent-category layer, into which implementations normalize thousands of vendor-specific actions, API calls, robot commands, and workflow events.
• Canonical language corpus: curated intent-linked example inputs spanning both digital and physical autonomous action.
• Programmatic synthetic corpus: deterministic synthetic-template expansions for controlled offline coverage.
• Deterministic validation traces: validation session traces including a full intent-breadth sweep across both surfaces, a constrained route-adapter pairwise matrix, combinational taxonomy/intent/model/capability-resolution route-profile sweeps, and physical-domain end-to-end coverage including authority-token issuance, actor-registration gating, default-policy emergency-stop deny, idempotency-key replay behavior, and revocation propagation.

The reported validation window is bounded to the May 2026 session. Reported internal metrics are therefore deterministic validation outcomes, not population-level production telemetry estimates.

6.3 Classification and Annotation Protocol

Internal protocol is deterministic and rule-driven:

• each case resolves to a canonical intent category or a governed deny/escalate outcome;
• pathway checks assert normalization, capability resolution, route handling, and execution-gating consistency;
• deny-envelope normalization preserves semantic equivalence across route-adapter variants;
• profile-conditioned checks include baseline, hinted, evidence-shortfall, and fail-closed policy contexts.

External protocol is independent and dual-review:

• two independent annotators classify sampled third-party traces;
• disagreement adjudication is recorded and reported;
• ambiguity classes are explicitly published;
• scoring scripts and outputs are published for replication.

6.4 Reliability and Quality Metrics

Measured internal metrics, digital-domain. These figures are produced by a reproducible benchmark harness (packages/oi-benchmark) that runs an enumerated space of tasks × capability profiles × policy profiles through the real authority engine (evaluateAuthority) and the real Open Intent taxonomy, with no mocked decisions. The evaluated policy is the engine's conservative deny-by-default bootstrap policy set (the out-of-the-box posture for an un-configured tenant); a tenant that installs a permissive policy set will see a correspondingly higher allow rate. The committed results artifact and its content hash are cited in §6.5. The numbers below are the harness's actual output, not target figures.

• Intent breadth (digital-domain coverage): 80 / 80 digital categories exercised (100%), across all 14 digital domains (OI-100 … OI-1400), with 0 capability-resolution mapping failures.
• Combinational sweep: 2,240 combinations (80 tasks × 7 capability profiles × 4 policy profiles) executed with 0 capability-resolution mapping failures.
• Route-adapter validity: 16 / 16 route-adapter pairs valid (4 ingress routes × 4 framework adapters); 0 deny-envelope semantic-equivalence violations (each task's decision is identical across all route-adapter variants).
• Policy behavior checks: explicit fail-closed deny, evidence-shortfall guarded escalation, and the always-on catastrophic-argument floor were each exercised and observed on live engine output.
• Combinational outcome distribution (primary decisions): ALLOW = 12; REQUIRE_APPROVAL = 240; ESCALATE = 468; DENY = 1,520. The deny-heavy distribution is the expected, honest consequence of a deny-by-default starter policy in which only low-risk non-production reads auto-approve.
• Derived diagnostic buckets: allow = 12; guarded (ESCALATE + REQUIRE_APPROVAL) = 708; deny = 1,520; of which evidence-shortfall-guarded = 240, catastrophic-floor-guarded = 160, fail-closed-deny = 1,040 (default-deny fall-through = 480, domain-pack/LIM fail-closed = 560). Sub-buckets are decision-consistent subsets of the primary buckets.

Measured internal metrics, physical-domain (May 2026 session):

• Authority-token issuance lifecycle: issue / verify / revoke round-trip covered for the full physical-domain category surface.
• Actor-registration gating: denies issuance for unregistered actors; permits issuance for registered actors under clean policy state.
• Default-policy emergency-stop deny: issuance is denied with the canonical safe-default safety subclass (OI-2901) when the emergency-stop predicate is asserted.
• Idempotency-Key handling: replayed identical bodies return the cached response; replayed-with-different-body requests return 409 Conflict.
• Revocation propagation: revocations are written to the revocation feed and observable by edge verifiers within their poll interval.

These results establish deterministic internal validity for taxonomy-integration pathways across both surfaces. They do not independently establish external ecological validity across heterogeneous third-party deployments.

6.5 Reproducibility

Reproducibility requirements in the publication package: fixed taxonomy release identifier and hash; benchmark execution metadata; conformance vectors and profile outputs; external replication protocol and reporting template.

The digital-domain figures in §6.4 are regenerated by a single command over the real engine and taxonomy:

pnpm --filter @intended/oi-benchmark bench

The harness (packages/oi-benchmark) is deterministic: all identifiers are seeded and all timestamps are fixed constants, so the same input yields byte-identical output (asserted by packages/oi-benchmark/src/determinism.test.ts). It emits a committed results artifact with metadata (generation date, commit SHA, taxonomy version, seed, config) and a SHA-256 content hash computed over the deterministic result body (metadata excluded):

• Artifact: packages/oi-benchmark/results/benchmark.json
• Taxonomy version: 2.1
• Content hash: sha256:c54b3956637d9a9cc5e040b01f9e190861d84a33b3253c31ea38a64b05f4fd60

A smoke subset (one category per digital domain) regenerates via pnpm --filter @intended/oi-benchmark bench:smoke and is rerun in CI.

7. Governance and Risk Use Cases

7.1 Policy Attachment

Control logic is attached to canonical intent categories rather than runtime-native labels. This improves portability across orchestration frameworks and tool ecosystems. A deployment policy attached to OI-104 (Deployment & Release) governs every runtime whose surface action normalizes into that category; a manipulation policy attached to OI-1502 (Pick & Place) governs every robot stack whose workspace effect is equivalent, regardless of controller vocabulary.

7.2 Escalation and Human Oversight

Canonical intent categories provide deterministic escalation anchors for sensitive operations, reducing reviewer ambiguity and improving decision-trace consistency.

7.3 Incident Reconstruction

Taxonomy-indexed logs improve forensic reconstruction by normalizing heterogeneous event semantics into a unified evidentiary view.

7.4 Third-Party Governance

Procurement and assurance teams can specify classification requirements independent of vendor stack, improving comparability in security and compliance evaluations.

7.5 Physical-Action Authority Issuance and the Audit Chain

Physical actuation in robotics, autonomous machines, and embodied AI systems requires more than policy classification. The Open Intent contribution at the policy boundary is canonical intent identification; the deployment runtime additionally requires cryptographic authorization at the actuator boundary so that physical actions cannot be invoked without a verifiable approval. This applies across the physical surface — manipulation primitives such as Pick & Place, Assembly, and Tool Use (OI-1500); mobility decisions such as Lane Change, Mission Planning, and Driver Handoff (OI-2000); aerial operations such as Flight Operations, Beyond-Visual-Line-of-Sight, and Multi-Drone Coordination (OI-2100); medical-robotics actions such as Surgical Procedure, Medication Dispensing, and Diagnostic Imaging (OI-2200); and industrial operations such as CNC & Machining, Batch Processing, and Production Scheduling (OI-1900).

The reference runtime implements this as follows. The authority engine issues short-lived RS256-signed tokens at the moment a physical intent is classified and approved by policy. Each token carries a unique JWT identifier for revocation lookup, the Open Intent identifier, the registered actor identity authorized to actuate, the environment context (cell, station, fleet, geofence) within which actuation is permitted, a short expiration window (single-digit seconds for actuator commands; longer for orchestration-level intents), and a snapshot reference linking the token to the workspace state at issuance time.

Edge actuator firmware verifies the token signature, the actor identity, the environment context, and the expiration window before commanding the actuator. Revocations are published to a revocation feed that edge verifiers poll on a configurable cadence; the worst-case lag from policy revocation to actuator-side enforcement is bounded by the poll interval.

The audit chain links every physical action to a signed token, a classification record, a policy version, and a workspace snapshot. This provides forensic reconstruction at the same fidelity as digital-domain governance, with the additional property that the audit evidence carries cryptographic provenance from the policy decision through to the actuator command.

This architecture sits on top of (not in place of) the safety-system primitives required by the applicable functional-safety regime. ISO 10218 protective-stop circuits, ISO 13482 collision-avoidance behaviors, and ISO 26262 ASIL-rated control loops remain the mandatory safety substrate; the Open Intent authority-token layer adds canonical-intent provenance and policy-driven access control at the layer above.

8. Reference Mapping and Interoperability

8.1 Framework Mapping Scope and Crosswalk Status

The mapping model targets: SOC 2; ISO/IEC 27001:2022 [5]; NIST AI RMF 1.0 [3]; Cloud Controls Matrix v4.x [7]; European Union Artificial Intelligence Act (Regulation (EU) 2024/1689) [6]; ISO 10218 industrial robot safety [23]; ISO 13482 personal care robot safety [24]; ISO 26262 road vehicle functional safety [28]; IEC 62443 industrial automation cybersecurity [27]; European Union Machinery Regulation (Regulation (EU) 2023/1230) [33]. Figure 5 positions Open Intent relative to these governance and safety regimes.

Figure 5. Standards crosswalk. Open Intent maps to governance and software-assurance regimes (EU AI Act, NIST AI RMF, ISO/IEC 27001, SOC 2, CSA CCM) and to physical-system safety and machinery regimes (EU Machinery Regulation 2023/1230, ISO 10218, ISO 13482, ISO 26262, IEC 61508, IEC 62443). It contributes canonical action classification on top of these regimes and does not replace their safety or compliance obligations.

What the crosswalk is — and is not. The crosswalk is an interoperability mapping, not a certification, attestation, or conformity claim. It lets an action that has been classified into an Open Intent category be lined up against the external framework provision(s) that the action implicates, so that governance, procurement, and audit teams can reason about one action across several regulatory and safety regimes at once. It does not assert that Open Intent, any implementer, or any deployment is certified, attested, or compliant against any framework; framework conformity is a determination made by the deploying organization together with its counsel, notified bodies, and auditors. This is consistent with the capability posture stated elsewhere in this work: the standard produces classification and evidence toward controls; it does not ship certified control mappings and is not a certification authority.

Record schema. Each crosswalk record uses five fields — the Open Intent identifier; the framework; the specific framework reference (an article, annex point, essential health-and-safety requirement, or standard clause); the mapping relationship (maps-to, informs, supports-evidence-for, or conditional); and audit-interpretation notes — together with a review-status marker and, where applicable, the minimum evidence artifact. The machine-readable crosswalk is published as a versioned repository artifact (packages/open-intent/src/oi-crosswalk.json) alongside the taxonomy (v2.1) it is built against, and a conformance test asserts that every row carries all five fields, cites a non-empty framework reference, and names an Open Intent identifier that exists in the taxonomy.

Phased status. The crosswalk is delivered in phases so that every populated row is defensible rather than aspirational. Phase 1 (this release) is populated for the physical and safety surface only (OI-1500 through OI-2900), mapped to the EU AI Act, the EU Machinery Regulation, and the applicable functional-safety standards (ISO 10218, ISO 13850, ISO 13849-1, IEC 61508, IEC 61496, ISO 14118, ISO/TS 15066, ISO 13482, ISO 26262, ISO 21448). Phase 1 populates the highest-signal, most-defensible rows, not an exhaustive mapping of every physical category. The digital surface (OI-100 through OI-1400) — SOC 2, ISO/IEC 27001, NIST AI RMF, and the CSA Cloud Controls Matrix — is defined in the schema but not yet populated; those rows are in progress. (A separate, control-centric runtime export maps a subset of digital controls to live governance evidence; the taxonomy-centric digital crosswalk described here is distinct future work.)

Review status. The physical/safety crosswalk is a DRAFT pending compliance-expert and legal-counsel review. These are public regulatory claims: each row's reference was grounded against authoritative framework text when drafted, and rows whose exact clause number, standard edition, or deployment applicability still require expert verification are explicitly marked for counsel review in the artifact. No row is represented as cleared for publication until that review is complete.

8.2 European Union Artificial Intelligence Act Focus

The AI Act mapping is constrained and explicit, and it uses the two classification routes the Act actually defines [6]. First, under Article 6(1), an AI system is high-risk where it is a safety component of — or is itself — a product covered by the Union harmonisation legislation listed in Annex I and that product is required to undergo third-party conformity assessment. This is the route for machinery-embedded, medical, and vehicle-embedded autonomous systems: Annex I references the machinery legislation (currently Directive 2006/42/EC, to be read with Regulation (EU) 2023/1230 from 20 January 2027), the Medical Devices Regulation (EU) 2017/745, and the motor-vehicle type-approval Regulation (EU) 2018/858. Second, the Annex III standalone high-risk list applies where a deployment falls within one of its enumerated areas — most relevantly for physical autonomy, Annex III point 2, which covers AI "intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity." Whether either route is triggered for a given deployment is a determination for the deployer and their counsel; the crosswalk records the applicable citation and marks its applicability as conditional. The two routes carry different application dates under the Act: the Annex III standalone high-risk obligations apply from 2 August 2026, and the Article 6(1)/Annex I product-route obligations from 2 August 2027. Mapping outputs are defined as crosswalk records, not narrative interpretation.

8.3 Machinery Regulation and Dual-Regime Interoperability

Physical-agent deployments are frequently governed simultaneously by the EU AI Act (Regulation 2024/1689) and the EU Machinery Regulation (Regulation 2023/1230, taking full effect 20 January 2027 — a date set by the corrigendum to Regulation (EU) 2023/1230 (OJ, 4 July 2023); the original 29 June 2023 text stated 14 January 2027 — and replacing Directive 2006/42/EC). An agent that controls a physical actuator can be an AI system under the former and a safety-relevant component of machinery under the latter. The Open Intent crosswalk addresses this dual regime by carrying, where both apply, an EU AI Act reference and an EU Machinery Regulation reference for the same physical-domain intent.

The mapping logic resolves to two parts. The Machinery Regulation reference applies whenever the action affects machinery operation, through the essential health and safety requirements in Annex III — for example, safety and reliability of control systems (EHSR 1.2.1), emergency stop, isolation of energy sources, and risks due to moving parts. Because Annex III of Regulation (EU) 2023/1230 carries forward, but also revises, the essential-requirement structure of Directive 2006/42/EC, the exact Annex III sub-clause numbers are marked for counsel verification in the artifact rather than asserted here. The AI Act reference applies conditionally: via Article 6(1) + Annex I where the autonomous function is a safety component of machinery, a medical device, or a type-approved vehicle subject to third-party conformity assessment; and via Annex III point 2 where the function is a safety component in critical-infrastructure operation such as the supply of electricity or the management of road traffic. (An earlier draft of this section cited Annex III(5)(b), (8)(a), and (4) for these physical cases; those points in fact concern creditworthiness scoring, judicial decision-support, and employment decisions respectively, and have been corrected.)

8.4 Interoperability Targets

Interoperability targets include schema adapters for orchestration frameworks; security information and event management systems; governance, risk, and compliance systems; and audit evidence repositories.

9. Implementation Specification

The specification package contains a normative schema; parsing and validation rules; conformance profile levels; reference vectors; and a compatibility policy.

Conformance levels:

1. Classification Conformance: correct canonical mapping under normative rules.
2. Evidence Conformance: required evidence fields present and valid.
3. Governance Conformance: stable downstream use in policy and reporting layers.
4. Physical-Action Conformance: for implementations that classify physical-domain intent categories, conformance additionally requires canonical mapping of every issued authority token to an Open Intent identifier; actor registration prior to authority-token issuance; a signed audit chain from intent submission through actuation event; emergency-stop and safety-override pathways (OI-2900) exercised and traced under conformance test conditions; a revocation feed published and consumable by edge verifiers; and documented mapping from each physical Open Intent category to the applicable functional-safety standard (ISO 10218, ISO 13482, ISO 26262, or equivalent national / sectoral standard).

Open Intent compatibility claims require explicit conformance-level declaration and test-report evidence. Compatibility claims for physical-action implementations must declare Physical-Action Conformance explicitly and supply test-report evidence for each requirement above.

10. Benchmarks and Empirical Results

10.1 Internal Results

Internal deterministic validation is produced by the reproducible benchmark harness described in §6.4 and §6.5 (packages/oi-benchmark, artifact packages/oi-benchmark/results/benchmark.json, content hash sha256:c54b3956637d9a9cc5e040b01f9e190861d84a33b3253c31ea38a64b05f4fd60). It demonstrates, over the real authority engine and the real taxonomy: full digital-domain breadth (80 / 80 categories, 100%); complete route-adapter validity (16 / 16 pairs) with zero deny-envelope semantic-equivalence violations; a 2,240-case combinational sweep with zero capability-resolution mapping failures; and the observed outcome distribution reported in §6.4 (ALLOW = 12; REQUIRE_APPROVAL = 240; ESCALATE = 468; DENY = 1,520 under the deny-by-default bootstrap policy). These results support internal consistency and fail-closed pathway integrity; they are internal validity only and do not establish external ecological validity (§10.2). The distribution reflects the conservative starter policy, not a ceiling on allowable actions — a tenant-installed policy set changes the mix.

10.2 External Validation Protocol

This manuscript does not report broad external trace results. It provides a replication protocol with three required outputs: external action coverage; unambiguous classification rate; and disagreement and boundary profile. This approach prioritizes methodological honesty and independent verification.

11. Adoption Path — Standardization Target

Open Intent's intended path to independent standardization is submission to a recognized standards body. The primary target venue is the Cloud Security Alliance (CSA) — specifically its Artificial Intelligence Safety Initiative and its Cloud Controls Matrix working group. No affiliation, membership, endorsement, review, or working-group relationship with the Cloud Security Alliance exists today. This section describes a planned future submission, not a current engagement or an existing alignment.

A prospective submission package would comprise the full manuscript, a two-page intake brief, a taxonomy appendix summary, and a standards-integration proposal note. Governance commitments accompanying any such submission would include a published maintainership policy, a stated release cadence, and a dispute-resolution procedure for taxonomy evolution. Until a submission is made and accepted, Open Intent remains an independently published specification and makes no claim of standards-body status.

12. Limitations and Open Questions

• unresolved boundary conditions in emerging multimodal and high-autonomy behaviors;
• regional interpretation variance in regulatory mappings;
• trade-offs between taxonomy stability and update velocity;
• external generalization uncertainty pending broader independent trace studies;
• the safety-relevance flag on intent records is binary; some real-world systems require continuous severity scoring (for example, robot speed-and-separation monitoring where the safety obligation scales with proximity). Future taxonomy versions may extend the flag to a graded enumeration; the boundary between Open Intent's classification responsibility and the safety-system's runtime responsibility remains an open question;
• actor-registration semantics across heterogeneous robot fleets are an open boundary. A "robot" in the registration record may be a single physical unit, a fleet, a logical controller, a software process, or a virtual actor in a simulation. The current taxonomy does not disambiguate these registration scopes;
• the authority-token model assumes online verification at the actuator boundary. Offline robot operation — common in field deployments with intermittent connectivity — requires either token caching with bounded acceptance windows or a different cryptographic primitive (capability tokens with cryptographic constraints on environment context).

These limitations are explicit to support rigorous review.

13. Conclusion

Open Intent defines a canonical, vendor-neutral taxonomy for autonomous-action classification. The manuscript provides a complete specification, deterministic internal validation evidence, and an independent replication protocol for external evaluation. This combination supports progression from implementation-specific action vocabularies toward an interoperable industry standard.

The manuscript additionally specifies how the Open Intent taxonomy spans physical-agent action under the same naming grammar, the same disambiguation rules, and the same conformance regime. Physical-action authority issuance via short-lived signed tokens, actor-class constraints, and a forensic audit chain from intent classification through actuator command provide a unified canonical classification layer across digital and embodied AI deployment contexts. The taxonomy artifact and conformance vectors are released under Apache 2.0 and the same release-identifier discipline that governs the software-domain components, supporting independent implementation and external validation of both surfaces under one specification.

Open Intent is not a software taxonomy. It is an autonomous-action taxonomy spanning both digital and physical systems — 173 canonical intent categories across 29 domains, with safety modeled as a first-class operational domain.

13.1 Positioning

By way of conclusion, the standard and the ecosystem around it are positioned as follows. Open Intent is the open classification standard for autonomous actions. The Large Intent Model (LIM) interprets actions into governable intent. Intent Verification Infrastructure governs those intents. Authority Tokens provide portable evidence of authority. Intended is the company building the infrastructure around these standards. This separation creates a cleaner architecture and clearer standards positioning, and it avoids the ambiguity that the legacy OI acronym introduced in industries such as energy and utilities. Readers should leave with one name for the standard: Open Intent.

Data and Artifact Availability

The Open Intent taxonomy is maintained at https://github.com/intended-so/open-intent under Apache 2.0; the canonical taxonomy is published through the open-intent repository. The Open Intent repository serves as the normative source of truth for domain definitions, category identifiers, and future taxonomy revisions. The reference implementation is developed by Intended, Inc. The taxonomy specification and conformance artifacts are implementation-independent and are published with release identifiers, reproducibility metadata, and replication templates. This manuscript is aligned to taxonomy version 2.1; future repository revisions take precedence over the figures reproduced here, and the repository is authoritative in the event of any discrepancy. The digital-domain benchmark figures (§6.4, §10.1) are regenerated by packages/oi-benchmark and committed as packages/oi-benchmark/results/benchmark.json (taxonomy 2.1; content hash sha256:c54b3956637d9a9cc5e040b01f9e190861d84a33b3253c31ea38a64b05f4fd60).

Appendix A — Open Intent Domain Map

This appendix enumerates all 29 domains for independent validation of the manuscript against the repository. Category-level membership is defined in the repository and is not reproduced exhaustively here. Surface values are Digital, Physical, and Safety. Domain codes retain the OI- prefix for repository continuity; Open Intent is the name of the standard.

Representative repository-native categories by surface include, on the physical surface: Pick & Place, Assembly, and Tool Use (Manipulation); Lane Change, Mission Planning, and Driver Handoff (Autonomous Vehicles); Takeoff / Flight Operations, Beyond-Visual-Line-of-Sight, and Multi-Drone Coordination (Aerial Systems); Surgical Procedure, Medication Dispensing, and Diagnostic Imaging (Surgical & Medical Robotics); and CNC & Machining, Batch Processing, and Production Scheduling (Manufacturing & Production).

References

[1] B. E. Strom, A. Applebaum, D. P. Miller, K. C. Nickels, A. G. Pennington, and C. B. Thomas, "MITRE ATT&CK: Design and Philosophy," MITRE Technical Report, 2018. [2] MITRE ATT&CK, "ATT&CK Knowledge Base," 2026. https://attack.mitre.org [3] E. Tabassi, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," NIST AI 100-1, 2023. doi:10.6028/NIST.AI.100-1. [4] A. Vassilev et al., "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations," NIST AI 100-2e2025, 2025. [5] ISO/IEC, "ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements," 2022. [6] European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 (Artificial Intelligence Act)," Official Journal of the European Union, 2024. [7] Cloud Security Alliance, "Cloud Controls Matrix (CCM) v4.x," 2026. [8] OWASP Foundation, "OWASP Top 10 for LLM Applications 2025," 2025. [9] E. Debenedetti et al., "AgentDojo: A Dynamic Environment to Evaluate Attacks and Defenses for LLM Agents," NeurIPS Datasets and Benchmarks Track, 2024. [10] J. Newman, "A Taxonomy of Trustworthiness for Artificial Intelligence," UC Berkeley Center for Long-Term Cybersecurity, 2023. [11] LangChain, "LangChain Documentation," 2026. https://docs.langchain.com [12] CrewAI, "CrewAI Documentation," 2026. https://docs.crewai.com [13] AutoGPT, "AutoGPT Documentation," 2026. https://github.com/Significant-Gravitas/AutoGPT [14] Microsoft, "Semantic Kernel Documentation," 2026. https://learn.microsoft.com/semantic-kernel [15] Dublin Core Metadata Initiative, "Dublin Core Metadata Element Set, Version 1.1 (ISO 15836-1:2017)," 2017. [16] MITRE, "Common Weakness Enumeration (CWE)," 2026. https://cwe.mitre.org [17] NIST, "Cybersecurity Framework (CSF) 2.0," 2024. [18] ISO/IEC, "ISO/IEC 42001:2023 Artificial intelligence — Management system," 2023. [19] OECD, "OECD Principles on Artificial Intelligence," 2019. [20] NIST, "NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations," 2020 (updated). [21] Cloud Security Alliance, "AI Safety Initiative," 2026. https://cloudsecurityalliance.org/ai-safety-initiative/ [22] European Union Agency for Cybersecurity, "Multilayer Framework for Good Cybersecurity Practices for AI," 2023. [23] ISO, "ISO 10218-1:2025 Robotics — Safety requirements for industrial robots — Part 1," 3rd edition, 2025 (the edition in force; supersedes ISO 10218-1:2011 and absorbs ISO/TS 15066:2016); ISO 10218-2 governs robot systems and integration. [24] ISO/IEC, "ISO 13482:2014 Robots and robotic devices — Safety requirements for personal care robots," 2014. [25] ISO/IEC, "ISO 13849-1:2023 Safety of machinery — Safety-related parts of control systems," 2023. [26] IEC, "IEC 61508:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems," 2010. [27] IEC, "IEC 62443 series Industrial communication networks — IT security for networks and systems," 2018–2023. [28] ISO/IEC, "ISO 26262:2018 Road vehicles — Functional safety," 2018. [29] ASTM International, "ASTM F3269-17 Standard Practice for Methods to Safely Bound Flight Behavior of Unmanned Aircraft Systems Containing Complex Functions," 2017. [30] ANSI / Robotic Industries Association, "ANSI/RIA R15.06-2012 American National Standard for Industrial Robots and Robot Systems — Safety Requirements," 2012. [31] IEEE, "IEEE Std 1872-2015 IEEE Standard Ontologies for Robotics and Automation," 2015. [32] NIST, "NIST IR 8419 Considerations for Selecting and Evaluating Cybersecurity and Safety Standards for Industrial Robots," 2022. [33] European Parliament and Council of the European Union, "Regulation (EU) 2023/1230 on machinery," Official Journal of the European Union, OJ L 165, 29.6.2023.