Network Working Group B. van Bussel Internet-Draft Observalytics SL Intended status: Informational 25 June 2026 Expires: 27 December 2026 Agent Capability and Profile Model (ACPM) draft-schemacommons-acpm-00 Abstract The Agent Capability and Profile Model (ACPM) is an open, vendor- neutral specification for describing what an artificial intelligence (AI) agent, the platform that runs it, a tool it calls, or the underlying large language model (LLM) actually offers, independent of how that subject is run or discovered. An ACPM document, called a capability profile, declares a subject's identity, a dot-namespaced list of supported capabilities together with a support level, an inventory of tool protocols, models, and memory backends, a trust and attestation posture, a cost structure, service-level commitments, structured delegation rules governing inbound and outbound work handoff, and a compliance posture. ACPM profiles are designed to cross-reference agent definitions and registry entries defined by other Schema Commons standards, and to be consumed by registries, marketplaces, and orchestrators that need to compare capabilities, gate on trust, and reason about cost and service levels without bespoke per-vendor parsing. This document describes the ACPM data model, field semantics, conformance levels, and the relationship of ACPM's trust and signature fields to actual verification, which ACPM deliberately does not itself perform. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 December 2026. van Bussel Expires 27 December 2026 [Page 1] Internet-Draft ACPM June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 4. ACPM Document Structure . . . . . . . . . . . . . . . . . . . 5 4.1. Subject Identity . . . . . . . . . . . . . . . . . . . . 6 4.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Tool, Model, and Memory Inventories . . . . . . . . . . . 6 4.4. Trust and Attestation . . . . . . . . . . . . . . . . . . 7 4.5. Cost Profile and Service Level . . . . . . . . . . . . . 7 4.6. Delegation Rules . . . . . . . . . . . . . . . . . . . . 8 4.7. Compliance . . . . . . . . . . . . . . . . . . . . . . . 8 5. Condition Expressions . . . . . . . . . . . . . . . . . . . . 8 6. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 9 7. Related Work and Mapping to Prior Art . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction As of mid-2026, the AI agent ecosystem has converged on two adjacent but distinct interoperability problems. The first is how to express a portable, runnable agent definition so that an agent built on one runtime can be executed on another; this is the problem the Autonomous Agent Interchange Format (AAIF) [SC-006] addresses. The second is how to discover an agent within a registry or marketplace; this is the problem the Agent Registry (AREG) addresses. Neither problem encompasses a third, equally common need: describing, comparing, and reasoning about what an agent, the platform running it, the tools it calls, or the underlying model actually offers. van Bussel Expires 27 December 2026 [Page 2] Internet-Draft ACPM June 2026 Today this information is scattered across marketing pages, ad hoc vendor-specific JSON, ASCII tables in README files, and human- readable documentation that changes shape from vendor to vendor. There is no canonical way to ask, in a machine-checkable way, whether a given subject supports a particular capability and at what fidelity, what evidence backs a trust claim about that subject, what it costs to use, what service level applies, or under what conditions it may delegate work to, or accept delegated work from, another subject. Registries and orchestrators that need this information today either write bespoke parsers per vendor or forgo capability, trust, and cost comparison entirely. This document specifies the Agent Capability and Profile Model (ACPM), a portable, vendor-neutral format for a capability profile: a standalone description of what a subject offers. ACPM is deliberately scoped to be orthogonal to, and composable with, both the runnable agent definition problem and the registry discovery problem; it does not replace either. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Scope ACPM is in scope for: subject identity (agent, platform, tool, or model); declared capability support levels using a dot-namespaced vocabulary; tool-invocation protocol, model, and memory-backend inventories; trust level and attestation evidence; sandboxing characteristics; pricing model and unit cost; service-level commitments; structured rules governing delegation of work between profiled subjects; compliance posture (data residency, certifications, personally identifiable information handling); and profile provenance. ACPM is out of scope for: the execution loop of the profiled subject; registry listing and discovery mechanics; and cryptographic enforcement or verification of any claim a profile makes. ACPM specifies the shape of a trust or signature claim; verifying that claim is the responsibility of the system consuming the profile. 2. Terminology ACPM document / profile A JSON instance conforming to the ACPM van Bussel Expires 27 December 2026 [Page 3] Internet-Draft ACPM June 2026 profile schema. Subject The agent, platform, tool, or model that a profile describes. Capability A dot-namespaced runtime feature string a subject may offer, paired with a declared support level. Producer Software or a person that publishes an ACPM profile. Consumer Software that reads an ACPM profile to make a capability- matching, trust-gating, cost, or service-level decision. Conformance level One of the five cumulative conformance levels defined in Section 6 that a profile satisfies. Condition The structured-or-string gating type used in delegation rules, reused without modification from the Autonomous Agent Interchange Format. See Section 5. 3. Design Principles ACPM is built on six design principles: 1. *Claims, not contracts.* A profile states what the subject claims to offer. ACPM does not itself verify any claim; a Consumer that requires assurance MUST perform its own verification. 2. *Vocabulary-compatible with AAIF.* Capability identifiers SHOULD use the same dot-namespaced strings as the Autonomous Agent Interchange Format's required-capability vocabulary, so an agent's declared needs and a profile's declared offerings can be compared directly. 3. *Composable, not coupled.* ACPM cross-references agent definitions and registry entries by identifier reference; it does not import or extend their schemas, so each specification can evolve independently. 4. *Comparable by construction.* Every offer-side concept — capability support, trust level, cost, service level — uses a closed, ordered, or structured vocabulary rather than free text, so two profiles can be diffed or ranked mechanically. 5. *Strict by default, extensible at the edges.* Every object disallows additional properties, with a reserved extension-key namespace at the document root for forward compatibility and vendor metadata. van Bussel Expires 27 December 2026 [Page 4] Internet-Draft ACPM June 2026 6. *Honest about enforceability.* Fields describing trust, attestation, and signature are explicitly documented as advisory unless a Consumer independently verifies them. This specification does not imply a cryptographic guarantee it does not provide. 4. ACPM Document Structure An ACPM profile is a JSON object validated against the ACPM profile schema (JSON Schema draft 2020-12 [JSON-SCHEMA]). The minimum conformant document requires only two top-level fields: { "sc_standard": "SC-014", "subject": { "subject_type": "agent", "name": "Example Agent" } } The full object model is organised as follows: CapabilityProfile (root) sc_standard "SC-014" (required) sc_version string (semver, default "1.0.0") profile_id string (UUID) subject (required) subject_type agent | platform | tool | model name / vendor / version / homepage sc_refs[] cross-references to other Schema Commons documents capabilities[] id / support / version_constraint / notes tools[] protocol / max_concurrent_calls / auth_methods[] models[] provider / model_id / context_window / modalities[] memory[] backend / scopes[] trust level untrusted | sandboxed | verified | attested | enterprise attestation issuer / method / evidence_url / issued_at / expires_at sandbox isolation / network_egress cost_profile pricing_model free | usage_based | subscription | tiered | custom currency / unit_cost / free_tier sla uptime_pct / p50_latency_ms / p99_latency_ms support_tier / incident_response delegation_rules[] direction / target / condition / action compliance data_residency[] / certifications[] / pii_handling provenance authored_by / created_at / updated_at / license / signature van Bussel Expires 27 December 2026 [Page 5] Internet-Draft ACPM June 2026 4.1. Subject Identity The subject.subject_type field MUST be one of "agent", "platform", "tool", or "model", and the subject.name field MUST be present. The subject.sc_refs array carries structured cross-references, each an object with a "standard" field (a Schema Commons standard code such as "SC-006") and an "id" field (an identifier within that standard's own document, such as an AAIF agent_id or an Agent Registry (AREG) entry identifier). These references are advisory pointers; ACPM does not require the referenced document to exist or be reachable. 4.2. Capabilities Each entry in the capabilities array declares a dot-namespaced capability identifier and a support level. The identifier SHOULD reuse the vocabulary already established by the Autonomous Agent Interchange Format's required-capability field (for example, "tool.mcp", "memory.vector", "orchestration.parallel") where the underlying concept overlaps, and MAY extend it with new namespaces such as "vision.*", "audio.*", "reasoning.*", "auth.*", or "state.*" for concepts AAIF does not enumerate. The support field MUST be one of four values: "native" (first-class, fully supported), "emulated" (achieved through a workaround or composition of other features), "partial" (supported with material limitations that SHOULD be documented in the notes field), or "none" (explicitly absent). Declaring "none" explicitly, rather than omitting the capability entirely, allows a Consumer to distinguish "known not supported" from "not yet assessed." 4.3. Tool, Model, and Memory Inventories The tools array enumerates supported tool-invocation protocols drawn from the same four-protocol vocabulary as the Autonomous Agent Interchange Format: function, MCP [MCP], HTTP, and OpenAPI. Each entry MAY declare a concurrency ceiling and a list of supported authentication methods. The models array enumerates LLMs the subject exposes or routes to (or, when subject_type is "model", describes itself), with provider, model identifier, context window, maximum output tokens, and supported modalities (text, image, audio, video, tool_use). The memory array enumerates supported storage backends and, for each, the memory scopes available on it, using the same backend and scope vocabularies as the Autonomous Agent Interchange Format's memory configuration. van Bussel Expires 27 December 2026 [Page 6] Internet-Draft ACPM June 2026 4.4. Trust and Attestation The trust.level field is an ordered, five-tier claim: "untrusted" (no claim verified), "sandboxed" (executes under some isolation boundary but claims are otherwise unverified), "verified" (claims checked, even if only by self-certification), "attested" (a named issuer has produced a dated, linkable attestation), and "enterprise" (attested, with organisational accountability typically evidenced by populated service-level and compliance fields). A profile MAY declare any trust level without external verification; this specification places no technical control in front of an inflated claim. A Consumer that gates a decision on trust.level SHOULD check trust.attestation.evidence_url and SHOULD verify that trust.attestation.expires_at, if present, has not passed before relying on an "attested" or "enterprise" claim. See Section 8. The trust.sandbox object describes the isolation boundary the subject executes within (none, process, container, or virtual machine) and its network egress policy (none, allowlist, or full). This describes isolation the subject runs under, not isolation a Consumer receives when calling the subject remotely; transport security remains the Consumer's own responsibility. 4.5. Cost Profile and Service Level The cost_profile object declares a pricing model (free, usage_based, subscription, tiered, or custom), a currency, a single unit cost (a billing dimension — request, 1000 tokens, minute, or run — paired with an amount), and an optional free tier (included units per day or month). A subject with pricing across multiple dimensions SHOULD publish the most comparable dimension, or publish one profile per pricing tier. The sla object declares uptime percentage, p50 and p99 latency in milliseconds, a support tier (community, standard, premium, or enterprise), and an incident-response commitment for Severity 1 incidents. These figures MAY represent either contractual commitments or observed historical performance; this version of ACPM does not yet distinguish the two, which is a known limitation. van Bussel Expires 27 December 2026 [Page 7] Internet-Draft ACPM June 2026 4.6. Delegation Rules The delegation_rules array governs whether the subject may hand work to ("outbound") or accept work from ("inbound") another profiled subject. Each rule MAY scope itself to a specific counterparty profile, a specific capability, a minimum counterparty trust level, and an additional Condition (see Section 5), and MUST declare an action: "allow", "deny", or "require_approval". At least one of the target fields SHOULD be present per rule, though this is authoring guidance rather than a structural requirement, so that intentionally broad direction-only rules remain expressible. When a rule's action is "require_approval", a Consumer MUST obtain explicit approval before proceeding with the delegated work; treating "require_approval" as equivalent to "allow" is a conformance violation. 4.7. Compliance The compliance object declares data residency regions (EU, US, UK, APAC, or custom), a free-form list of held certifications, and a PII- handling mode (none, redact, encrypt, or forbidden). 5. Condition Expressions The delegation_rules[].condition field accepts a Condition value, reused without modification from the Autonomous Agent Interchange Format. The structured form (RECOMMENDED) is an object naming an expression language and an expression: { "lang": "cel", "expr": "request.network_egress != 'full'" } Supported languages are jsonpath, jmespath, cel (Common Expression Language), jsonlogic, always (constant true), and never (constant false). A bare string is also accepted as a non-deterministic, natural-language hint and MUST NOT be relied upon for portable, reproducible gating. A Consumer that supports a declared lang MUST evaluate the structured form deterministically. A Consumer that does not support a declared lang MUST treat the rule as unsatisfiable-unknown and apply a conservative default — deny for an outbound rule, reject for an inbound rule — rather than silently treating it as satisfied. van Bussel Expires 27 December 2026 [Page 8] Internet-Draft ACPM June 2026 6. Conformance Levels ACPM defines five cumulative conformance levels. As with the Autonomous Agent Interchange Format, conformance is self-certified; there is no central certifying authority. +============+=========================================+ | Level | Requirements | +============+=========================================+ | Basic | Validates against the profile schema; | | | subject present. | +------------+-----------------------------------------+ | Tooled | Basic + capabilities array non-empty. | +------------+-----------------------------------------+ | Trusted | Tooled + trust.level is verified, | | | attested, or enterprise. | +------------+-----------------------------------------+ | Priced | Trusted + cost_profile present. | +------------+-----------------------------------------+ | Enterprise | Priced + sla present + compliance | | | present + provenance.signature present. | +------------+-----------------------------------------+ Table 1 A profile claiming a given level satisfies every predicate of all lower levels as well. At the time of writing, ACPM does not yet have a machine-readable conformance report schema or public test corpus comparable to those defined for the Autonomous Agent Interchange Format; level claims are presently verified by inspection against this table rather than by an automated suite. 7. Related Work and Mapping to Prior Art ACPM's overall design intent parallels the Open Cybersecurity Schema Framework: one canonical schema so that disparate parties describe the same kind of thing — there, security events; here, agent capabilities, trust, cost, and service level — in a comparable way. Three further efforts overlap with ACPM closely enough to warrant explicit discussion rather than a one-line table entry. The first is [HACP] ("HACP: A Capability-Contract Protocol for AI Agents and Edge Hardware"), an active IETF individual submission defining a JSON-RPC 2.0 protocol through which an LLM agent discovers, plans, executes, observes, and audits operations against physical edge hardware (GPIO, I2C, UART, sensors) via a security-checked daemon. Its servers register an immutable tool set at startup, each tool carrying a risk level from zero to three, and a session is capped at a configured van Bussel Expires 27 December 2026 [Page 9] Internet-Draft ACPM June 2026 maximum risk level that it MUST NOT exceed when executing a tool. This is the same underlying idea ACPM generalizes — declare what a subject can do, and at what risk or trust tier, before a consumer relies on it — but HACP is narrowly scoped to hardware control, statically declared with no dynamic capability negotiation, and organized around risk tiers rather than ACPM's combination of trust, cost, service level, and delegation. HACP is cited here as a narrow, complementary precedent for capability-contract thinking, not as a competing general-purpose effort. The second is a still-forming discovery-metadata effort within the Model Context Protocol itself. The MCP development roadmap [MCP-ROADMAP], as published 2026-03-05, lists under "Transport Evolution and Scalability" a planned "MCP Server Cards" standard: structured server metadata exposed via a well-known URL so that browsers, crawlers, and registries can discover a server's capabilities without connecting to it, attributed to a "Server Card WG" coordinating with what the roadmap calls "the broader industry AI-catalog effort." This is directly adjacent to an ACPM profile with subject_type "platform" or "tool": both are machine-readable, well-known-style capability and metadata documents intended for discovery without a live connection. The relevant framing is superset and instance, not competition: MCP Server Cards are scoped specifically to MCP servers, while ACPM is protocol-agnostic, spans agent, platform, tool, and model subjects, and additionally expresses cost, service level, trust, and delegation that a server card is not designed to carry. An ACPM profile of subject_type "tool" describing an MCP server SHOULD be designed so that its capability- and protocol-relevant fields are exportable as, or trivially mappable to, a future MCP Server Card. Because the Server Card WG appears to have only just been chartered as of the cited roadmap snapshot, this mapping is necessarily provisional; see PUBLISHING.md Section 0 for the re-check required before any concrete compatibility claim is finalized. The third is the Agent Bill of Materials (AgBOM) concept referenced by the OWASP Agent Observability Standard (AOS) project [OWASP-AOS], which proposes inventorying what an agent or system is built from — models, tools, dependencies — using existing software-supply-chain formats such as CycloneDX, SPDX, and SWID. AgBOM overlaps with ACPM's subject, tools, and models inventory fields, but its center of gravity differs: AgBOM concerns supply-chain provenance and inventory (what is inside a subject, for vulnerability and license tracking), while ACPM concerns runtime capability, trust, cost, and service- level declaration (what a subject can do, and on what trust and cost terms it can be relied upon). The two are complementary; a profile's subject.sc_refs array MAY point at a companion AgBOM document for supply-chain detail ACPM itself does not capture. van Bussel Expires 27 December 2026 [Page 10] Internet-Draft ACPM June 2026 No effort found during this review combines capability support level, trust and attestation, cost, service level, and delegation rules into a single vendor-neutral document spanning agent, platform, tool, and model subjects the way ACPM does. The closest individual pieces — HACP's risk tiers, MCP Server Cards' discovery metadata, and AgBOM's inventory model — each cover one facet of this narrowly and within a single domain. What is new in ACPM is the combination and its cross- domain generality, not any single constituent idea in isolation. van Bussel Expires 27 December 2026 [Page 11] Internet-Draft ACPM June 2026 +=================+=============+===================+===============+ | Effort |Scope | Overlap with ACPM |Relationship | +=================+=============+===================+===============+ | HACP (draft- |JSON-RPC | Capability |Narrow, | | sunyi-hacp- |capability- | declaration plus |complementary | | protocol-00) |contract | trust/risk-tier |precedent; | | |protocol for | gating, similar |hardware-only, | | |LLM agents | in spirit to |no cost/SLA/ | | |controlling | capabilities[] |delegation | | |physical edge| and trust.level. |model. | | |hardware, | | | | |with static | | | | |per-session | | | | |risk-level | | | | |caps (0-3). | | | +-----------------+-------------+-------------------+---------------+ | MCP Server |Well-known- | Discovery- |ACPM as | | Cards (planned, |hosted | oriented |superset/ | | MCP roadmap, |structured | capability/ |general case; | | 2026-03-05) |metadata for | metadata document |Server Cards | | |MCP servers, | using the same |as the MCP- | | |for discovery| well-known |specific | | |without | publication |instance. | | |connecting; | pattern as an |Still forming; | | |owned by a | ACPM tool/ |re-check | | |newly forming| platform profile. |before | | |Server Card | |finalizing | | |WG. | |compatibility | | | | |claims. | +-----------------+-------------+-------------------+---------------+ | AgBOM (OWASP |Supply-chain | Declarative |Complementary, | | Agent |inventory of | inventory overlap |different | | Observability |what an agent| with subject/ |center of | | Standard |or system is | tools[]/models[]. |gravity: AgBOM | | project; builds |built from, | |is provenance, | | on |for | |ACPM is | | CycloneDX/SPDX/ |vulnerability| |runtime | | SWID) |and license | |offering. | | |tracking. | |sc_refs[] may | | | | |point at a | | | | |companion | | | | |AgBOM | | | | |document. | +-----------------+-------------+-------------------+---------------+ Table 2: Domain-Adjacent Efforts (Informative) Open Container Initiative image manifests An OCI image manifest van Bussel Expires 27 December 2026 [Page 12] Internet-Draft ACPM June 2026 declares what is actually present in an image, not merely what was intended. ACPM's capability support levels (native, emulated, partial, none) apply the same "declare what is actually there" discipline to agent capabilities. NIST capability maturity models ACPM's four-level support axis is a simplified maturity assessment in the spirit of staged capability maturity frameworks, scoped to a single binary-leaning feature rather than an organisational process. Cloud provider service catalogs Service catalog listings (for example, marketplace entries for managed cloud services) enumerate what a service exposes and its operational limits. ACPM's tools, models, and memory inventories serve an analogous purpose for AI agent capabilities. Agent2Agent (A2A) Agent Cards An Agent Card [A2A] is a deliberately minimal discovery document advertising identity, capability tags, and an endpoint URL. ACPM extends this with an explicit trust, attestation, sandbox, cost, and service-level model that an Agent Card does not specify, while remaining compatible in spirit with the discovery use case. Model Context Protocol (MCP) capability negotiation MCP [MCP] servers and clients negotiate supported capabilities at connection time via an initialize handshake. ACPM's tools array is a static, publishable analogue of that runtime negotiation, suitable for offline comparison before a connection is ever established. 8. Security Considerations ACPM is a claims format, not a verification protocol. Every field in a profile MUST be treated by a Consumer as a self-reported claim by the subject, or by whoever published the profile on the subject's behalf, unless the Consumer independently verifies it. This specification does not provide, and does not imply, a cryptographic guarantee of any claim's accuracy. A profile MAY declare trust.level "enterprise" with no supporting evidence. A Consumer making a consequential trust decision SHOULD require a verifiable attestation (method "third_party" or "formal_audit") with a reachable evidence_url and an unexpired attestation.expires_at before relying on an "attested" or "enterprise" claim. van Bussel Expires 27 December 2026 [Page 13] Internet-Draft ACPM June 2026 Capability support claims are asserted, not tested, by this specification. A Consumer performing capability matching for a safety-relevant feature SHOULD independently probe the subject before trusting a "native" support claim for that purpose. Cost and service-level claims are point-in-time and unverified. ACPM does not currently distinguish a contractually committed figure from an observed historical one. A Consumer making a procurement or routing decision of consequence SHOULD corroborate such claims against independent monitoring. The provenance.signature field is advisory. ACPM does not mandate a signature scheme, key-distribution mechanism, or verification behaviour. A Consumer that requires provenance assurance SHOULD treat a profile lacking a signature it can independently verify as equivalent to trust.level "untrusted", regardless of what trust.level the profile itself declares. A delegation rule naming a Condition language a Consumer does not implement MUST be treated as unsatisfiable-unknown, with a conservative default applied (deny for outbound, reject for inbound). Silently treating an unsupported Condition as satisfied is a conformance violation and could permit unintended delegation. Nothing in ACPM cryptographically binds a profile document to the real-world subject it claims to describe, beyond the advisory subject.sc_refs cross-reference. A Consumer SHOULD only trust profiles obtained from a channel it already trusts (the subject's own domain, or a registry it already trusts) rather than an arbitrary, unauthenticated URL. 9. IANA Considerations This document requests no IANA actions. ACPM's capability identifiers (the dot-namespaced strings used in the capabilities array) currently form an open, convention-based vocabulary shared informally with the Autonomous Agent Interchange Format's required- capability vocabulary, with no registry operator. A future revision of this document or an accompanying document may propose a community- operated or IANA-operated registry for capability identifiers, analogous to the extension registries described for the Autonomous Agent Interchange Format, should the vocabulary's growth warrant centralised coordination. 10. References 10.1. Normative References van Bussel Expires 27 December 2026 [Page 14] Internet-Draft ACPM June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [JSON-SCHEMA] Wright, A. and H. Andrews, "JSON Schema: A Media Type for Describing JSON Documents", 2022, . 10.2. Informative References [SC-006] Schema Commons, "Autonomous Agent Interchange Format (AAIF) — SPECIFICATION", 2026, . [MCP] Anthropic, "Model Context Protocol", 2024, . [A2A] Linux Foundation (Agent2Agent Project), "Agent2Agent Protocol", 2025, . [HACP] Sun, Y., "HACP: A Capability-Contract Protocol for AI Agents and Edge Hardware", Work in Progress, Internet- Draft, draft-sunyi-hacp-protocol-00, 2026, . [MCP-ROADMAP] Model Context Protocol contributors, "Model Context Protocol Development Roadmap", 5 March 2026. [OWASP-AOS] OWASP, "Agent Observability Standard (AOS) — Agent Bill of Materials (AgBOM)", 2026. Author's Address Bob van Bussel Observalytics SL Email: bob@observalytics.com URI: https://schemacommons.org van Bussel Expires 27 December 2026 [Page 15]