@intended-inc/open-intent

Open Intent — the open taxonomy for classifying AI agent actions across 29 enterprise and embodied-process domains.

The Open Intent provides a shared language for describing what AI agents intend to do, whether the agent is a software process executing API calls or a robot reaching for an object. Every action — deploying code, processing invoices, escalating tickets, picking a part, landing a drone, dispensing medication — maps to a stable intent family and category. This enables consistent verification, authorization, auditing, and policy evaluation across any AI agent platform, digital or physical.

v2.1 — Digital + Physical

OI v2 extends the original 14 digital-operations domains (OI-100 through OI-1400) with 14 physical / embodied-process domains (OI-1500 through OI-2800) and 1 embodied-safety domain (OI-2900). The numeric prefix is the only contract: any tooling pinned to v1 codes still works; new physical codes are strictly additive. Versioning policy: domain codes never re-number; categories may add but not be removed within a major version. v2.1 is an additive record-schema enrichment over v2.0 (April 2026); domain and category membership is unchanged.

Digital domains (OI-100 — OI-1400)

| Code | Domain | Categories | Description | |------|--------|-----------|-------------| | OI-100 | Software Development | 7 | Build, test, deploy, release, and govern code | | OI-200 | Security Operations | 7 | Detect, respond to, and remediate security threats | | OI-300 | Infrastructure | 7 | Provision, scale, and maintain compute and network systems | | OI-400 | Cloud Operations | 6 | SaaS management, platform ops, multi-cloud governance | | OI-500 | Financial Operations | 8 | Budgets, payments, procurement, treasury, reporting | | OI-600 | Supply Chain | 5 | Sourcing, logistics, vendor management, inventory | | OI-700 | People Operations | 6 | Hiring, onboarding, workforce management | | OI-800 | Revenue Operations | 5 | Pipeline management, deal execution, renewals | | OI-900 | Customer Experience | 5 | Support, success, satisfaction measurement | | OI-1000 | Enterprise Operations | 6 | Strategy, planning, governance, cross-functional ops | | OI-1100 | Service Delivery | 4 | Fulfillment, SLA adherence, service operations | | OI-1200 | Risk Management | 5 | Assessment, mitigation, compliance, business continuity | | OI-1300 | Product Operations | 4 | Roadmap, discovery, launch coordination, lifecycle | | OI-1400 | Asset Management | 5 | Inventory tracking, maintenance, lifecycle, disposal |

Subtotal: 80 categories across 14 digital domains.

Physical / Embodied domains (OI-1500 — OI-2800)

| Code | Domain | Categories | Description | |------|--------|-----------|-------------| | OI-1500 | Manipulation | 6 | Grasping, pick-and-place, assembly, tool use, dexterous hands | | OI-1600 | Locomotion & Mobility | 6 | Path planning, obstacle avoidance, wheeled / legged / aerial / marine motion | | OI-1700 | Sensing & Perception | 7 | Vision, LiDAR, audio, tactile, environmental, inertial, calibration | | OI-1800 | Actuation & Control | 5 | Motor, fluid power, thermal, electrical, closed-loop tuning | | OI-1900 | Manufacturing & Production | 7 | Assembly lines, CNC, additive, batch, inspection, material flow, scheduling | | OI-2000 | Autonomous Vehicles | 7 | Driving decisions, sensor fusion, mission planning, V2X, handoff, fleet ops | | OI-2100 | Aerial Systems | 6 | UAV flight, airspace, payload, BVLOS, multi-drone coordination | | OI-2200 | Surgical & Medical Robotics | 7 | Surgery, patient handling, medication, imaging, samples, sterilization, telemetry | | OI-2300 | Agricultural Operations | 6 | Field, irrigation, pest, livestock, controlled environment, yield | | OI-2400 | Construction & Excavation | 6 | Site prep, earthworks, structural, demolition, lifting, multi-machine | | OI-2500 | Hazardous Environments | 6 | Nuclear, subsea, space, contaminated sites, EOD, confined space | | OI-2600 | Energy & Utilities | 6 | Generation, grid, distribution, storage, demand response, meter ops | | OI-2700 | Mining & Resource Extraction | 5 | Drilling, hauling, beneficiation, wellfield, geotechnical | | OI-2800 | Logistics & Material Handling | 6 | Warehouse, sortation, yard, last-mile, port, cold chain |

Subtotal: 86 categories across 14 physical / embodied domains.

Safety domain (OI-2900)

| Code | Domain | Categories | Description | |------|--------|-----------|-------------| | OI-2900 | Embodied AI Safety | 7 | E-stop, geofencing, presence detection, safe motion, LOTO, collision, certifications |

Subtotal: 7 categories across 1 safety domain.

v2.1 total: 173 categories across 29 domains (80 digital · 86 physical · 7 safety).

Installation

npm install @intended-inc/open-intent

Usage

import { getDomain, getCategory, getDomainForCategory, allCategoryCodes } from "@intended-inc/open-intent";

// Look up a domain
const secops = getDomain("OI-200");
console.log(secops?.name); // "Security Operations"

const manipulation = getDomain("OI-1500");
console.log(manipulation?.name); // "Manipulation"

// Look up a category
const threatDetection = getCategory("OI-201");
console.log(threatDetection?.name); // "Threat Detection"

const eStop = getCategory("OI-2901");
console.log(eStop?.name); // "Emergency Stop"

// Find which domain a category belongs to
const domain = getDomainForCategory("OI-503");
console.log(domain?.name); // "Financial Operations"

const safetyDomain = getDomainForCategory("OI-2904");
console.log(safetyDomain?.name); // "Embodied AI Safety"

// List all category codes
const codes = allCategoryCodes();
console.log(codes.length); // 173

Access the full taxonomy

import oi from "@intended-inc/open-intent";

for (const domain of oi.domains) {
  console.log(`${domain.code} ${domain.name} (${domain.categories.length} categories)`);
  for (const cat of domain.categories) {
    console.log(`  ${cat.code} ${cat.name}`);
  }
}

Record schema (v2.1 — §5.4 intent record requirements)

As of taxonomy v2.1, every canonical category record carries the fields required by whitepaper §5.4, in addition to code / name / description. The enrichment is strictly additive — no field was removed or renamed, and existing consumers that read only code/name/description/operationType are unaffected. Records are regenerated reproducibly by scripts/enrich-taxonomy.mjs (run pnpm enrich; CI guard pnpm enrich:check).

| Field | Type | Required | Source | |-------|------|----------|--------| | safetyRelevant | boolean | yes | derived | | actorClassConstraint | OiActorClass[] | yes | derived | | disambiguationNotes | string | yes | authored | | contextualEntities | { required: string[]; optional: string[] } | yes | authored | | evidenceExpectations | string[] | yes | authored | | operationType | "read" \| "write" | optional | pre-existing |

safetyRelevant (derived)

Boolean flag (§5.4): does actuation of this intent require a signed authority token at an actuator boundary? Documented rule: true for every physical (OI-1500–OI-2800) and safety (OI-2900) intent; false for digital (OI-100–OI-1400) intents, which have no physical actuator boundary and whose audit-evidence sufficiency does not require cryptographic actuation provenance. This makes §5.5 rule 6 hold by construction (OI-2901 Emergency Stop → true). The flag is intentionally binary; graded severity scoring is a documented future extension (whitepaper §12), not part of v2.1.

actorClassConstraint (derived)

The registered actor classes permitted to invoke the intent, enforced at the authority-token issuance point (§5.4). Documented rule: derived per-domain from the hundreds-block code. Allowed tokens (OiActorClass):

software-agent, manipulator, mobile-robot, perception-system, control-system, production-system, autonomous-vehicle, aerial-system, medical-robot, field-machine, hazenv-robot, utility-system, and * (intentionally open — any registered actor class).

Digital domains → ["software-agent"]. Each physical domain maps to one primary actor class (e.g. OI-1500 Manipulation → ["manipulator"], OI-2000 Autonomous Vehicles → ["autonomous-vehicle"]). The OI-2900 safety domain is ["*"] (open), per §5.5 rule 6.

disambiguationNotes (authored)

One-line boundary note separating a category from its nearest siblings (e.g. OI-104 Deployment vs OI-102 Build vs OI-105 Change Control), grounded in each category's existing semantic definition.

contextualEntities (authored)

Entity types (not instances) that scope classification: required entities must be present; optional entities refine the classification when present.

evidenceExpectations (authored)

The artifact classes an auditor should expect as proof of the intent for downstream audit usage (e.g. a deployment record, a torque/force curve, a chain-of-custody record).

Review status

Authored (judgment) fields for the specialized, safety-regulated physical domains OI-2200 (Surgical & Medical Robotics) and OI-2500 (Hazardous Environments) are principled DRAFTS pending owner / domain-expert ratification. Digital and general-physical entries are high-confidence.

Accessors

import { isSafetyRelevant, getActorClassConstraint } from "@intended-inc/open-intent";

isSafetyRelevant("OI-1502");        // true  (physical)
isSafetyRelevant("OI-104");         // false (digital)
isSafetyRelevant("OI-UNKNOWN");     // true  (fail-safe default)
getActorClassConstraint("OI-2901"); // ["*"] (safety domain, open)

Standards crosswalk (whitepaper §8)

src/oi-crosswalk.json is a versioned interoperability mapping from OI categories to real governance, safety, and machinery framework references. It answers one question per row: when an action is classified into an OI category, which named provision of an external framework does that action implicate?

It is not a certification, attestation, or conformity claim, and it does not assert that Open Intent or any implementer is compliant with any framework. It is also distinct from the runtime, control-centric compliance export in packages/audit (which maps individual controls to live governance evidence); this crosswalk is taxonomy-centric and runtime-independent.

Each row is the five-field §8.1 record — oiCode, framework, reference (article / annex point / EHSR / standard clause), relationship (maps-to / informs / supports-evidence-for / conditional), and notes — plus a status marker and an optional evidence hint.

Status. Phase 1 is populated for the physical + safety surface only (OI-1500–OI-2900), mapped to the EU AI Act (Reg. 2024/1689), the EU Machinery Regulation (Reg. 2023/1230), 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). The digital surface (OI-100–OI-1400: SOC 2 / ISO/IEC 27001 / NIST AI RMF / CSA CCM) is defined in the schema but not yet populated. Every physical/safety row is a DRAFT pending compliance-expert / legal-counsel review; rows whose exact clause, edition, or applicability need expert verification are flagged status: "draft-needs-counsel".

import { getCrosswalkRows, oiCrosswalk } from "@intended-inc/open-intent";

getCrosswalkRows("OI-2901");     // crosswalk rows for Emergency Stop
oiCrosswalk.reviewStatus;        // the DRAFT / needs-counsel banner

Why the Open Intent?

AI agents are taking actions across every enterprise domain — from deploying code to processing payments to managing infrastructure to grasping objects to landing aircraft to dispensing medication. Without a shared taxonomy, every organization invents its own classification, making cross-system policy enforcement, regulatory mapping, and auditing impossible.

The Open Intent provides:

• Universal classification — A common language for AI agent actions whether digital, physical, or hybrid (cyber-physical) systems.
• Verification anchoring — Runtime decisions can reference stable family codes instead of brittle action strings or framework-specific verbs.
• Audit consistency — Every decision log entry maps to a stable taxonomy family that survives schema migrations.
• Cross-platform interoperability — Different AI agent frameworks (digital LLM agents, ROS2 nodes, autonomous-vehicle stacks, surgical-robot controllers) can share the same intent language at the governance layer.
• Regulatory alignment — Codes map to EU AI Act risk classifications, NIST AI RMF functions, ISO 42001 controls, and (for physical operations) IEC 61508 / ISO 13849 / ISO 26262 / ISO 10218 / ANSI/RIA R15.06 conformance evidence.

Reference Implementation

The Open Intent is used by the Intended runtime reference implementation for intent interpretation, authority routing, and audit evidence anchoring across both digital and physical-AI deployments.

License

Apache-2.0