Network Working Group L. Zhang Internet-Draft W. Qiao Intended status: Informational W. Zhang Expires: 6 May 2027 H. Yang Y. Li AsiaInfo Technologies (China) Inc. 2 November 2026 Verifiable Usage Accounting for Internet of Agents draft-zhang-ioa-usage-accounting-01 Abstract This document describes a usage accounting and evidence framework for the Internet of Agents (IoA). In cross-domain agent collaboration, agents may attach to gateways, discover capabilities, delegate subtasks, invoke tools, consume model or compute resources, and produce auditable outcomes. Existing application logs or platform- specific billing interfaces are insufficient for interoperable accounting across agents, gateways, and administrative domains. This document defines requirements and a common object model for verifiable usage accounting, including Accounting Contexts, Metering Profiles, Measurement Dimensions, Usage Event Records, and Accounting Evidence References. These objects are intended to support interoperable recording, correlation, export, verification, correction, and dispute handling for agent collaboration events. This document does not define pricing, charging policy, token issuance, financial settlement, revenue-sharing rules, invoices, or business support system interfaces. It focuses on protocol-visible accounting records and evidence objects that may be used by other systems. The framework distinguishes unavailable measurements from measured zero, defines non-overlapping aggregation and correction requirements, and separates record integrity from verification of usage values or outcomes. These requirements constrain accounting behavior without prescribing a new transport or settlement mechanism. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Zhang, et al. Expires 6 May 2027 [Page 1] Internet-Draft Verifiable Usage Accounting for IoA November 2026 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 6 May 2027. 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 6 4. Architectural Context . . . . . . . . . . . . . . . . . . . . 7 5. Accounting Object Model . . . . . . . . . . . . . . . . . . . 9 5.1. Accounting Context . . . . . . . . . . . . . . . . . . . 9 5.2. Metering Profile . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Profile Structure . . . . . . . . . . . . . . . . . . 11 5.2.2. Measurement Dimensions . . . . . . . . . . . . . . . 12 5.2.3. Content Recording and Export Behavior . . . . . . . . 13 5.3. Usage Event Record . . . . . . . . . . . . . . . . . . . 14 5.4. Accounting Evidence Reference . . . . . . . . . . . . . . 15 6. Usage Event Categories . . . . . . . . . . . . . . . . . . . 16 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Accounting Context Establishment . . . . . . . . . . . . 17 7.2. Usage Event Generation . . . . . . . . . . . . . . . . . 18 7.3. Evidence Binding . . . . . . . . . . . . . . . . . . . . 18 7.4. Cross-Domain Export . . . . . . . . . . . . . . . . . . . 18 7.5. Correction and Dispute Handling . . . . . . . . . . . . . 19 7.6. Measurement Availability and Incomplete Coverage . . . . 20 Zhang, et al. Expires 6 May 2027 [Page 2] Internet-Draft Verifiable Usage Accounting for IoA November 2026 7.7. Aggregation Boundaries and Delegated Work . . . . . . . . 20 7.8. Retries, Duplicates, and Record Identity . . . . . . . . 21 7.9. Verification Claims and Evidence Limits . . . . . . . . . 22 8. Relationship to Agent Run Metrics and Other Work . . . . . . 22 9. Illustrative JSON Objects . . . . . . . . . . . . . . . . . . 23 9.1. Accounting Context Example . . . . . . . . . . . . . . . 23 9.2. Metering Profile Example . . . . . . . . . . . . . . . . 23 9.3. Model Inference Usage Event Record Example . . . . . . . 25 9.4. Usage Event Record Example . . . . . . . . . . . . . . . 26 9.5. Unavailable Measurement Is Not Zero . . . . . . . . . . . 27 9.6. Delegated Aggregation without Overlap . . . . . . . . . . 28 9.7. Replacement Correction . . . . . . . . . . . . . . . . . 29 9.8. Transport Duplicate and Execution Retry . . . . . . . . . 29 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. Normative References . . . . . . . . . . . . . . . . . . . . 32 14. Informative References . . . . . . . . . . . . . . . . . . . 32 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction The Internet of Agents (IoA) envisions large-scale collaboration among autonomous or semi-autonomous agents across domains, vendors, networks, and execution environments. Agents may act on behalf of users, services, organizations, or other agents. They may also interact through Agent Gateways, agent-to-agent session protocols, capability directories, task protocols, tool invocation interfaces, and model services. Once agents collaborate across administrative domains, a system needs a common way to record what occurred during the collaboration. A task may be decomposed into subtasks, delegated to several agents, routed through gateways, and completed by invoking models, tools, data services, or network functions. The resulting usage information is useful for resource accounting, cost allocation, audit, operational analysis, quota control, accountability, and dispute handling. Existing application logs, local billing records, or platform- specific usage APIs do not provide a common cross-domain accounting view. They often lack stable task correlation, gateway provenance, signed evidence references, usage-category semantics, measurement- dimension declarations, privacy-controlled export, and correction semantics. In addition, coarse-grained records such as "API request count" or "total input/output tokens" do not distinguish between Zhang, et al. Expires 6 May 2027 [Page 3] Internet-Draft Verifiable Usage Accounting for IoA November 2026 orchestration, execution, tool invocation, delegated subtasks, reasoning or inference cost, gateway mediation, and result verification. This document defines a protocol-visible object model for verifiable usage accounting in IoA. It is inspired by existing Internet accounting and measurement work, including accounting management concepts [RFC2975], network access accounting [RFC2866], and flow information export [RFC7011]. However, the objects defined here are intended for agent collaboration rather than packet flows or network access sessions. The key design principle is separation between accounting facts and business charging. This document defines usage accounting contexts, metering profiles, measurement dimensions, event records, and evidence references. It does not define prices, tariffs, token economics, revenue sharing, invoices, or financial settlement. In this document, verifiable means that a receiver can evaluate explicitly identified accounting claims using declared measurement rules, provenance, and evidence. It does not imply that every reported value is independently measured, that every event has been observed, or that a signed record proves that a task succeeded or a payment occurred. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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. Agent An autonomous or semi-autonomous software entity that can perform tasks, invoke tools, interact with other agents, or act on behalf of a user, service, or organization. Agent Gateway A gateway that mediates agent attachment, registration, discovery handoff, policy enforcement, routing, accounting, or interconnection between agents or domains. Accounting Context A scoped object that binds accounting-relevant identifiers, policies, metering profiles, and evidence requirements for a task, invocation, session, or gateway-mediated collaboration. Zhang, et al. Expires 6 May 2027 [Page 4] Internet-Draft Verifiable Usage Accounting for IoA November 2026 Metering Profile A description of supported usage categories, measurement dimensions, aggregation behavior, privacy constraints, and evidence requirements for a capability, agent, gateway, or accounting domain. Measurement Dimension A declaration of what is measured, which unit is used, the applicable usage category or modality, and how the value is obtained and aggregated. Usage Event Record A structured record describing an observed accounting-relevant event, such as task start, delegation, tool invocation, model inference, workflow step completion, or task result verification. Accounting Evidence Reference A reference to integrity-protected evidence that supports a Usage Event Record, such as a signature, receipt, hash, authorization reference, execution trace, result attestation, or human confirmation record. Usage Unit A unit used by a Measurement Dimension to express measured values. Examples include token, byte, millisecond, second, frame, pixel, request, operation, step, and standard-compute-unit. Standard Compute Unit (SCU) A normalized Usage Unit used by a Measurement Dimension to express compute resource consumption across heterogeneous models, tools, or execution environments. This document treats SCU as a profile- defined unit and does not define its calibration, exchange rate, or pricing model. Verified Result Event A record indicating that a task outcome has been verified according to a declared policy, such as successful ticket closure, approved transaction completion, or confirmed network fault localization. Accounting Domain An administrative domain responsible for generating, validating, exporting, or retaining accounting records. Exporter An entity that exports Usage Event Records or accounting summaries to another entity. Zhang, et al. Expires 6 May 2027 [Page 5] Internet-Draft Verifiable Usage Accounting for IoA November 2026 Collector An entity that receives Usage Event Records or accounting summaries from an Exporter. Measurement Availability Whether a dimension has a reported value, is unavailable, is not applicable, or is withheld under policy. This is separate from the task result and the method used to obtain a value. Coverage The declared population, interval, invocations, or child tasks covered by a record or summary, and whether that view is complete within its declared boundary. Record Retransmission Delivery again of the same immutable accounting assertion; it does not represent another execution attempt. Execution Attempt A distinct attempt to invoke a service or execute work, even when it retries the same logical operation. 3. Scope and Non-Goals This document specifies: * a common object model for verifiable usage accounting in IoA deployments; * requirements for Accounting Contexts, Metering Profiles, Measurement Dimensions, Usage Event Records, and Accounting Evidence References; * usage event categories suitable for task, invocation, delegation, model, tool, gateway, workflow, and result events; * requirements for event correlation, evidence binding, cross-domain export, correction, and dispute handling; and * privacy and security considerations for accounting records. This document does not specify: * pricing, tariffs, rating algorithms, charging policy, invoices, revenue sharing, token issuance, token exchange, or financial settlement; Zhang, et al. Expires 6 May 2027 [Page 6] Internet-Draft Verifiable Usage Accounting for IoA November 2026 * a general-purpose business support system, online charging system, payment protocol, or financial ledger; * a discovery query protocol, routing algorithm, task orchestration protocol, or agent-to-agent message exchange protocol; * a complete identity, credential issuance, or trust framework; * a mandatory serialization format or transport protocol in this version; or * a normative definition of SCU calibration, VPT calculation, model pricing, or business-result valuation. 4. Architectural Context An IoA deployment may contain Requesting Agents, Serving Agents, Agent Gateways, Accounting Exporters, Accounting Collectors, and Evidence Verifiers. The accounting model can be used with gateway- mediated interaction, direct agent-to-agent interaction, or a combination of both. A gateway is a common observation and enforcement point, but the object model does not require every event to be observed by the same gateway. The core relationship among the accounting objects is shown in Figure 1. An Accounting Context defines the scope of accounting for a task, session, invocation, or collaboration. A Metering Profile defines how usage is measured and what evidence is required. Usage Event Records describe individual accounting-relevant events within that context. Accounting Evidence References bind records to signatures, hashes, receipts, authorization references, trace evidence, result attestations, or human confirmations. Zhang, et al. Expires 6 May 2027 [Page 7] Internet-Draft Verifiable Usage Accounting for IoA November 2026 +------------------------------------------------------+ | Accounting Context | | - task/session/invocation identifiers | | - accounting domain and observation scope | | - policy, privacy, and evidence requirements | +---------------------------+--------------------------+ | | references v +------------------------------------------------------+ | Metering Profile | | - usage categories and measurement dimensions | | - aggregation, privacy, and export behavior | | - required evidence and correction behavior | +---------------------------+--------------------------+ | | applies to v +------------------------------------------------------+ | Usage Event Records | | - task, delegation, model, tool, gateway events | | - usage measurements, result status, sequence | +---------------------------+--------------------------+ | | supported by v +------------------------------------------------------+ | Accounting Evidence References | | - signatures, hashes, receipts | | - authorization, trace, result, confirmation | +------------------------------------------------------+ Figure 1: Core Accounting Object Relationships Figure 2 illustrates how these objects are used during a cross-domain collaboration. The accounting context is normally established before or during task/session setup. Usage event records are generated as the collaboration proceeds. Evidence references are attached when records require later verification. Exporters can then send records or summaries to collectors according to the Metering Profile and privacy policy. Zhang, et al. Expires 6 May 2027 [Page 8] Internet-Draft Verifiable Usage Accounting for IoA November 2026 Requesting Agent Gateway A Gateway B Serving Agent | Exporter Collector | | | | | | 1. setup / invocation handoff | |----------------->|--------------->|------------->| | | | | | 2. establish Accounting Context and profile | |<---------------->|<-------------->|<------------>| | | | | | 3. task execution, delegation, model/tool use | |----------------->|--------------->|------------->| | | | | | 4. generate Usage Event Records | | |<---observe---->| | | | | | | 5. bind Evidence References | | |---sign/hash--->| | | | | | | 6. export records or summaries | | |--------------->| | | | | | | 7. correction or dispute evidence, if needed | | |<-------------->| | Figure 2: Accounting Flow in Cross-Domain Agent Collaboration The accounting model is not required to expose agent internals or raw prompt content. A gateway or platform may generate summary records, privacy-preserving digests, or evidence references according to local policy. For example, an exported record can indicate that a result was verified and signed by a gateway without disclosing the raw ticket, prompt, tool output, or business data used to make that determination. 5. Accounting Object Model 5.1. Accounting Context An Accounting Context defines the scope within which Usage Event Records are correlated and interpreted. An Accounting Context MAY be established during agent attachment, capability registration, discovery handoff, task creation, session establishment, or invocation setup. An Accounting Context SHOULD contain the following fields: * accounting-context-id: a stable identifier for the accounting context; Zhang, et al. Expires 6 May 2027 [Page 9] Internet-Draft Verifiable Usage Accounting for IoA November 2026 * accounting-domain-id: the domain that asserts or manages the context; * gateway-id: the gateway that created or accepted the context, when applicable; * agent-id or agent-did: the agent identifier associated with the context, when available; * task-id, session-id, invocation-id, or trace-id: identifiers used for correlation; * subject-ref: a reference to the user, organization, service, or agent on whose behalf the task is performed, when policy permits; * policy-ref: a reference to applicable policy, quota, authorization, or consent information; * metering-profile-ref: a reference to the Metering Profile that applies to the context; * evidence-policy: requirements for signatures, receipts, retention, redaction, or result verification; * validity: start time, expiration time, and freshness constraints; and * privacy-scope: constraints on disclosure, aggregation, and export. An Accounting Context MUST be unambiguous within the accounting domain that asserts it. If a context is propagated across domains, each receiving entity MUST be able to determine the asserting entity, the validity of the context, and the applicable disclosure constraints. Cross-domain correlation SHOULD include a namespaced origin, context identifier, and, when used, parent and root context references. A reference MUST identify its asserting domain or namespace so that similarly named local tasks cannot be silently merged. These links identify accounting relationships; they do not prove delegation authorization or causality. 5.2. Metering Profile A Metering Profile describes the accounting behavior supported or required by an agent, capability, gateway, service, or accounting domain. Zhang, et al. Expires 6 May 2027 [Page 10] Internet-Draft Verifiable Usage Accounting for IoA November 2026 A Metering Profile MAY be referenced by a gateway capability directory entry, capability advertisement, task object, handoff reference, session setup message, or policy object. If multiple profiles apply, the effective profile MUST be determined according to local policy and MUST be auditable. A record used for cross-domain reconciliation MUST identify the Metering Profile and its version. A receiver MUST NOT reinterpret historical records under a later profile merely because their dimension names are unchanged. A dimension used in an aggregate MUST have an unambiguous namespace, unit, method, coverage boundary, and combination rule. Unknown required rules leave the affected aggregate unresolved. 5.2.1. Profile Structure A Metering Profile SHOULD specify: * profile-id and version; * supported usage categories; * supported measurement dimensions, such as token usage, multimodal generation or processing parameters, latency, gateway routing attributes, and quota state; * required measurement methods; * required evidence types; * aggregation behavior, such as per-event, per-task, per-session, per-window, or summary-only; * correction behavior, such as whether corrected records can be emitted and how they reference original records; * privacy behavior, including redaction, pseudonymization, minimization, and selective disclosure; and * export behavior, including push, pull, batch, streaming, or local- only retention. Zhang, et al. Expires 6 May 2027 [Page 11] Internet-Draft Verifiable Usage Accounting for IoA November 2026 5.2.2. Measurement Dimensions A Metering Profile MAY declare one or more measurement dimensions. A measurement dimension identifies what is measured, the unit used for the measurement, the applicable modality or usage category, and how the value is obtained and aggregated. Measurement dimensions provide a common way to describe text-token usage, model inference usage, multimodal processing usage, gateway usage, quota state, workflow usage, and verified-result usage. A measurement dimension SHOULD contain: * dimension-id: a stable identifier for the dimension; * dimension-name: a human-readable name; * usage-category: the usage category to which the dimension applies; * modality: text, image, video, audio, speech, multimodal, or another modality when applicable; * unit: the unit of measurement, such as token, byte, millisecond, second, frame, pixel, request, operation, step, or standard- compute-unit; * value-type: integer, decimal, boolean, string, enumeration, or structured value; * measurement-method: observed, provider-reported, estimated, sampled, aggregated, normalized, derived, corrected, or verified; a verified value additionally identifies the verifier, checked claim, method, and evidence; * aggregation-scope: per-request, per-output, per-inference, per- tool-call, per-task, per-session, per-time-window, or summary- only; * normalization-reference: a reference to a normalization profile when the dimension uses a normalized unit such as SCU; and * privacy-class: an indication of whether the dimension is usage- only metadata, pseudonymous metadata, sensitive metadata, content- derived metadata, or subject to stricter disclosure policy. Examples of measurement dimensions include input-token-count, output- token-count, total-token-count, cached-token-count, reasoning-token- count, processing-time-ms, request-count, transferred-bytes, quota- used, quota-limit, image-count, image-pixel-count, image-quality- Zhang, et al. Expires 6 May 2027 [Page 12] Internet-Draft Verifiable Usage Accounting for IoA November 2026 level, video-duration-seconds, frame-rate, audio-duration-seconds, sample-rate, channel-count, tool-call-count, workflow-step-count, delegation-count, verified-result-count, and standard-compute-usage. The usage-category of each Measurement Dimension SHOULD be one of the supported usage categories declared by the Metering Profile, unless the dimension is explicitly marked as extension-specific. Reasoning or chain-of-thought resource consumption can be represented as a measurement dimension, such as reasoning-token-count or reasoning-compute-duration. This document only accounts for the resource usage of such reasoning processes; it does not require or encourage disclosure of chain-of-thought content. Measurement dimensions are accounting metadata. They do not define a pricing model, charging rule, tariff, or business valuation method. Dimension labels do not establish comparability. Token counts MUST identify the applicable model/tokenizer or provider counting convention, whether cached input is included, and whether reasoning tokens are included in output. A total-token dimension MUST declare its formula and the overlap relationships among component counters. A cached or reasoning subset MUST NOT be added again to a total that already includes it. Normalized units such as SCU require an identified normalization profile and version, including calibration assumptions and input units. Equal SCU labels alone do not make two reports comparable. Values produced by incompatible counting or normalization conventions MUST NOT be combined as a single comparable total without an explicitly declared conversion and its provenance. 5.2.3. Content Recording and Export Behavior A Metering Profile SHOULD specify content recording behavior. Supported behavior can include disabled, digest-only, metadata-only, excerpt-only, or full-content recording under explicit policy. Full- content recording MUST NOT be the default behavior for cross-domain export. A Metering Profile SHOULD also specify export behavior, including whether records are retained locally, exported as per-event records, exported as summaries, exported in batches, streamed to a collector, or exported only through evidence references. Export behavior MUST be evaluated together with the privacy behavior and evidence requirements of the profile. Zhang, et al. Expires 6 May 2027 [Page 13] Internet-Draft Verifiable Usage Accounting for IoA November 2026 5.3. Usage Event Record A Usage Event Record describes an observed accounting-relevant event. It is not required to contain all raw operational data. It SHOULD contain enough information to support correlation, aggregation, verification, correction, and dispute handling. A Usage Event Record SHOULD contain the following fields: * record-id: a unique identifier for the record; * accounting-context-id: the Accounting Context to which the record belongs; * event-type: the event type, such as task-start, tool-call, or task-complete; * event-time: the asserted occurrence time, when known; observation- time and received-time are distinct values and MUST NOT silently replace an unknown occurrence time; * observation-point: the gateway, agent, tool adapter, or platform component that observed the event; * request-metadata: request identifier, start time, completion time, client address or pseudonymous client reference, path, method, consumer reference, API key reference, or equivalent metadata, subject to privacy policy; * route-service-info: route name, backend cluster, model identifier, provider identifier, modality, or service binding reference; * actor-ref: the agent, gateway, user, or service that performed or initiated the event, subject to privacy policy; * target-ref: the agent, model, tool, service, resource, or task object affected by the event, subject to privacy policy; * usage-category: a category such as orchestration, execution, tool- invocation, model-inference, gateway-forwarding, workflow, or result-verification; * usage-measurements: one or more measured values keyed by measurement dimension identifiers declared in the applicable Metering Profile; Zhang, et al. Expires 6 May 2027 [Page 14] Internet-Draft Verifiable Usage Accounting for IoA November 2026 * quota-state: rate-limit decision, rate-limit status code, throttling state, or rejection reason when the event is affected by quota or rate-limit policy; * content-ref: a reference, digest, redacted excerpt, or policy- controlled pointer to request or response content when content recording is enabled; * result-status: started, in-progress, completed, failed, cancelled, degraded, corrected, disputed, or verified; * sequence-info: ordering or deduplication information; * evidence-ref: one or more Accounting Evidence References; and * signature or integrity-ref: a signature, MAC, hash, or reference to integrity protection. A Usage Event Record that is exported across administrative domains MUST include enough provenance information for the receiver to identify the asserting gateway, platform, or accounting domain. The receiver MUST NOT treat a record as verified solely because it is syntactically valid. For cross-domain records subject to retransmission or reconciliation, the asserting origin and record-id MUST identify an immutable assertion. The applicable context, profile version, operation/ attempt reference, and measurement availability and coverage information MUST be supplied directly or by an unambiguous reference when required to interpret the measurements. Bare numeric values are permitted only where the profile fixes their method, availability convention, and coverage. Source assertions and collector findings MUST be distinguishable. A receiver SHOULD retain its validation result, evaluation time, policy/profile version, and reason for any unresolved or rejected finding without overwriting the source statement. 5.4. Accounting Evidence Reference An Accounting Evidence Reference links a Usage Event Record to evidence that supports the record. This document does not require a particular evidence format. Implementations may use existing mechanisms such as JOSE [RFC7515], COSE [RFC9052], JWT [RFC7519], CWT [RFC8392], or selective disclosure mechanisms where appropriate. An Accounting Evidence Reference SHOULD contain: Zhang, et al. Expires 6 May 2027 [Page 15] Internet-Draft Verifiable Usage Accounting for IoA November 2026 * evidence-id; * evidence-type: signature, receipt, trace-hash, authorization-ref, consent-ref, result-attestation, human-confirmation, policy- decision, downgrade-decision, correction, or dispute-reference; * evidence-location: embedded, local, URI, digest-only, or unavailable due to policy; * digest and digest-algorithm, when evidence is not embedded; * asserting-entity; * verification-method; * validity or retention period; and * disclosure-policy. Evidence references MUST NOT require disclosure of raw prompts, tool results, personal data, or sensitive operational data unless such disclosure is allowed by policy and necessary for the accounting purpose. 6. Usage Event Categories The following initial usage event categories are defined for interoperability. Future specifications may extend this list. orchestration Usage associated with intent interpretation, planning, task decomposition, routing decisions, state management, or coordination prompts. execution Usage associated with an agent or sub-agent performing a concrete task step. tool-invocation Usage associated with invoking an external tool, function, API, database, network function, or resource server. model-inference Usage associated with model invocation, including input units, output units, reasoning units, compute duration, or normalized compute units. Zhang, et al. Expires 6 May 2027 [Page 16] Internet-Draft Verifiable Usage Accounting for IoA November 2026 multimodal-processing Usage associated with image, video, audio, speech, or other non- text modality generation or processing. quota-control Usage or decision events associated with quota consumption, rate- limit checks, throttling, or rejection. gateway-forwarding Usage associated with gateway mediation, forwarding, policy checks, protocol translation, or cross-domain handoff. workflow Usage associated with workflow steps, task-state changes, retries, cancellation, fallback, pause, resume, or escalation. result-verification Usage associated with verification of task results, human confirmation, external validation, or business-outcome confirmation. correction A record that corrects or supersedes a previous record. dispute A record that indicates an accounting dispute, dispute evidence submission, or dispute resolution status. These categories describe accounting semantics and do not imply any particular pricing or charging rule. 7. Procedures 7.1. Accounting Context Establishment An Accounting Context MAY be established when an agent attaches to a gateway, a gateway accepts or creates a capability directory entry, a task is created or accepted, an invocation handoff is returned, a session or collaboration group is established, or a policy decision requires accounting or audit. The entity establishing the context MUST determine the applicable Metering Profile and evidence policy before usage events are exported across administrative domains. If no compatible profile exists, the gateway or platform MAY reject the interaction, fall back to local- only accounting, or export only a minimal summary according to policy. Zhang, et al. Expires 6 May 2027 [Page 17] Internet-Draft Verifiable Usage Accounting for IoA November 2026 Accounting Context establishment SHOULD be associated with the applicable authentication and authorization decisions. A context identifier, parent/child link, or authorization reference does not itself grant authority. Authorization evidence must be validated by the appropriate security mechanism for the current operation; accounting correlation MUST NOT substitute for that check. 7.2. Usage Event Generation A gateway or platform component SHOULD generate a Usage Event Record when an accounting-relevant event is observed. The granularity of event generation depends on the Metering Profile. Implementations SHOULD support at least task-start and task-complete or task-failed records, delegation records, tool-invocation records, model-inference or compute-usage records, and correction records. A Usage Event Record MUST include ordering or deduplication information if it can be retransmitted, corrected, or exported through multiple gateways or platforms. 7.3. Evidence Binding A Usage Event Record SHOULD be bound to evidence according to the applicable evidence policy. Evidence binding MAY be achieved by embedding evidence, including a digest, including a URI, or referencing a protected evidence store. Evidence binding SHOULD support integrity verification of the record, provenance verification of the asserting gateway or domain, correlation with authorization, consent, policy, or task context, result verification when a record asserts a verified outcome, and later dispute handling without exposing more data than necessary. If evidence is unavailable due to privacy, retention, or policy constraints, the record MUST indicate that evidence is unavailable and SHOULD include the reason class. 7.4. Cross-Domain Export Gateways or platforms MAY export Usage Event Records or summaries to other gateways, platforms, or collectors. Export behavior MUST follow the Metering Profile and privacy-scope constraints associated with the Accounting Context. Zhang, et al. Expires 6 May 2027 [Page 18] Internet-Draft Verifiable Usage Accounting for IoA November 2026 Cross-domain export SHOULD support record authentication and integrity protection, replay protection, duplicate detection, batch and streaming export models, summary export when raw event export is not allowed, correction records, and receiver-side validation of provenance and freshness. A receiving entity MUST apply local policy before accepting exported accounting data for operational decisions. A receiving entity SHOULD retain the source identifier, received time, verification status, and any transformation performed on the record. 7.5. Correction and Dispute Handling Accounting records may require correction because of delayed events, clock skew, aggregation errors, task cancellation, gateway failures, or later result verification. A correction record MUST reference the original record or record set that it corrects. It MUST indicate whether it replaces, amends, reverses, or annotates the original record. A dispute record SHOULD reference the disputed records, the accounting context, the asserting entity, the dispute reason, evidence references submitted by the disputing entity, and the dispute status. This document defines only protocol-visible dispute references and evidence objects. It does not define arbitration rules, legal process, liability, compensation, or financial settlement. Corrections MUST be separate assertions with their own originating domain and record identifier, an exact target reference, and an explicit operation. Original records MUST remain available within the applicable retention policy. An authorized replacement supplies the effective value for its declared target scope instead of adding that value to the original. An annotation or dispute alone MUST NOT change a numerical total. A collector MUST validate the correction authority and deduplicate retransmitted corrections. A binding supporting amendments or reversals MUST define whether they carry deltas or replacement values, which dimensions they affect, their ordering basis, and how conflicting correction branches are handled. A received-time timestamp alone does not establish authority or a global revision order. Correction chains and aggregates derived from them MUST identify the effective revision or cutoff; unresolved conflicts MUST remain visible. Zhang, et al. Expires 6 May 2027 [Page 19] Internet-Draft Verifiable Usage Accounting for IoA November 2026 7.6. Measurement Availability and Incomplete Coverage A measured zero is a value, not a default for an unavailable measurement. Producers and collectors MUST distinguish a reported value from unavailable, not-applicable, and policy-withheld measurements. A missing report, absent field, timeout, or inaccessible evidence MUST NOT be converted to a numeric zero. A serialization binding MUST define whether these states use omitted values, explicit status fields, or another unambiguous representation; null alone does not identify the reason. Availability is independent of measurement method and assurance. A provider-reported or estimated value can be available without being independently verified. A completed task can still have unavailable usage measurements. A rejected invocation can consume metering, orchestration, or gateway resources and MUST NOT be assigned zero solely because execution was rejected. A summary MUST identify its coverage boundary, observation interval where relevant, and any known missing contributors. Completeness is assessed against a declared or otherwise established expected set, not just the records that happened to arrive. Without that basis, a collector MUST NOT claim a globally complete task tree. Disclosure restrictions MAY limit the externally visible contributor list, but MUST NOT turn an incomplete view into an unqualified complete one. A partial sum MAY be reported as a lower bound only for additive non- negative dimensions with compatible scopes and no overlapping contributions. This interpretation does not apply automatically to balances, ratios, durations of overlapping work, or signed adjustments. Incomplete coverage does not erase a contradiction already established by the available evidence. 7.7. Aggregation Boundaries and Delegated Work Every aggregate MUST state whether it covers local work only, an identified set of events, or a task subtree including descendants. A collector MUST NOT add an inclusive parent/subtree summary to the child records already included in it. A parent delegation event can describe dispatch or locally consumed orchestration resources, but MUST NOT silently copy child resource usage into local-only totals. Zhang, et al. Expires 6 May 2027 [Page 20] Internet-Draft Verifiable Usage Accounting for IoA November 2026 The aggregation rule MUST define the contribution identity and distinguish raw observations from summaries of those observations. Reports from two observation points describing the same invocation are not automatically two independent quantities to be added. Conversely, the same context or trace identifier does not prove that two distinct execution attempts are duplicates. If overlap cannot be resolved, retain the observations and flag the affected aggregate as unresolved rather than silently choosing or summing them. Parent/root references provide correlation only. Before accepting a cross-domain attachment, the collector MUST validate namespace ownership and the accounting association under local policy or accepted evidence. An unvalidated child claim MUST NOT move usage into another tenant or principal's account. Rejected attachment does not justify destroying the separately attributable source report. Additivity is dimension-specific. Counts with disjoint contribution scopes may be summed; end-to-end latency, gauges, quota balances and sampled estimates require profile-defined rules. A collector MUST retain estimated, sampled and incomplete status through aggregation rather than presenting the result as an exact measured total. 7.8. Retries, Duplicates, and Record Identity Retransmission of the same assertion MUST preserve its originating domain and record identifier. Receiving an identical assertion more than once MUST NOT increase accounted usage. The same origin and identifier with different content is a conflict that MUST be recorded and resolved before using either version as a uniquely accepted assertion; arrival order alone is not a sufficient resolution rule. Distinct execution attempts MUST have distinguishable attempt references even when they share a logical request identifier or idempotency key. If a service confirms that repeated requests refer to one execution, the binding SHOULD supply a stable execution reference for reconciliation. A timeout does not prove that execution failed or that consumption was zero. Accounting collection MUST NOT itself retry a potentially consequential operation merely to obtain a measurement. Streaming updates and cumulative usage snapshots from one invocation MUST NOT be summed as separate consumptions. The profile MUST define whether a report is a delta, an immutable final snapshot, or a superseding assertion, and specify how overlapping windows and late arrivals are handled. A transport acknowledgment indicates delivery only unless the binding explicitly assigns stronger acceptance semantics. Zhang, et al. Expires 6 May 2027 [Page 21] Internet-Draft Verifiable Usage Accounting for IoA November 2026 7.9. Verification Claims and Evidence Limits A verifier MUST identify the claim checked, the asserting entity, the evidence and profile revisions used, and the applicable verification method. Its findings MUST distinguish a completed successful check, a completed failed check, and a check that could not be completed. Integrity, provenance, measurement consistency, coverage completeness, authorization and result validation are separate checks; success on one MUST NOT imply success on the others. A signature binds protected bytes to a signing key under its validation assumptions. A digest can bind a record to particular bytes when compared against a trusted reference. Neither mechanism alone proves that usage counters are accurate, an observation point was complete, an action occurred, a business result is correct, or a payment was settled. A hash chain can reveal some interior gaps given trusted sequencing information, but does not by itself prove that no final records were omitted. Completeness requires a declared expected set or other explicit coverage evidence. Evidence retrieval MUST be subject to local access policy, allowed destinations, bounded reference depth, time and size limits, and cycle/redirect handling. References MUST NOT be automatically trusted or fetched without these controls. A reference that cannot be resolved, has expired, or is withheld under policy leaves the affected claim unverified; it does not prove that the claimed event did not occur. Detailed outward error disclosure MAY be limited for privacy while retaining the internal finding. A verified result event MUST state the verification policy, verifier, outcome claim, and supporting evidence or the reason verification could not be completed. Human confirmation is a scoped assertion, not a universal correctness guarantee. The framework records verification and dispute findings but does not define legal responsibility or financial settlement. 8. Relationship to Agent Run Metrics and Other Work Agent Run Metrics describes a JSON interchange format for run/step resource reports, including delegated-run attribution [AGENT-RUN-METRICS]. It can supply source measurements for this framework. A mapping MUST preserve its counting conventions, local versus subtree scope, reporter namespace, and missing-report status; no lossless or implemented mapping is claimed here. This document instead focuses on cross-domain contexts, evidence, export, collector findings and correction/dispute relationships, without mandating that format. Zhang, et al. Expires 6 May 2027 [Page 22] Internet-Draft Verifiable Usage Accounting for IoA November 2026 Accounting context and parent/root references are distinct from dialog lifecycle management and do not grant operation authority. Directory visibility and semantic compatibility may help establish accounting context, but cannot verify a measured value. This framework can consume those inputs without redefining discovery, authorization, task execution, or settlement protocols. 9. Illustrative JSON Objects The following examples are illustrative and are not a normative serialization profile. All added fields and status values below are logical illustrations, not a mandatory serialization or registered code set. Evidence locations marked unavailable are explicit limitations; these examples do not contain real signatures or claim completed verification. 9.1. Accounting Context Example { "accounting_context_id": "acctx-20260507-001", "accounting_domain_id": "example.net", "gateway_id": "agw-east-1", "task_id": "task-5gc-fault-1192", "session_id": "sess-71d1", "trace_id": "trace-88b7", "policy_ref": "policy://example.net/ioa/accounting/basic", "metering_profile_ref": "profile://example.net/scu-v1", "evidence_policy": { "signature_required": true, "result_evidence_required": true, "raw_prompt_export": false }, "validity": { "not_before": "2026-05-07T06:00:00Z", "not_after": "2026-05-07T12:00:00Z" }, "metering_profile_version": "1.1" } Figure 3 9.2. Metering Profile Example Zhang, et al. Expires 6 May 2027 [Page 23] Internet-Draft Verifiable Usage Accounting for IoA November 2026 { "profile_id": "profile://example.net/scu-v1", "version": "1.1", "supported_usage_categories": [ "tool-invocation", "model-inference", "multimodal-processing" ], "measurement_dimensions": [ { "dimension_id": "input-token-count", "usage_category": "model-inference", "modality": "text", "unit": "token", "value_type": "integer", "measurement_method": "provider-reported", "aggregation_scope": "per-inference", "privacy_class": "usage-only" }, { "dimension_id": "output-token-count", "usage_category": "model-inference", "modality": "text", "unit": "token", "value_type": "integer", "measurement_method": "provider-reported", "aggregation_scope": "per-inference", "privacy_class": "usage-only" }, { "dimension_id": "standard-compute-usage", "usage_category": "tool-invocation", "unit": "standard-compute-unit", "value_type": "decimal", "measurement_method": "normalized", "aggregation_scope": "per-tool-call", "privacy_class": "usage-only", "normalization_reference": "https://example.net/metering/scu-v1" }, { "dimension_id": "reasoning-token-count", "usage_category": "model-inference", "modality": "text", "unit": "token", "value_type": "integer", "measurement_method": "provider-reported", "aggregation_scope": "per-inference", Zhang, et al. Expires 6 May 2027 [Page 24] Internet-Draft Verifiable Usage Accounting for IoA November 2026 "privacy_class": "usage-only" }, { "dimension_id": "total-token-count", "usage_category": "model-inference", "modality": "text", "unit": "token", "value_type": "integer", "measurement_method": "derived", "aggregation_scope": "per-inference", "privacy_class": "usage-only" }, { "dimension_id": "processing-time-ms", "usage_category": "tool-invocation", "unit": "millisecond", "value_type": "integer", "measurement_method": "observed", "aggregation_scope": "per-tool-call", "privacy_class": "usage-only" } ], "dimension_namespace": "https://example.net/ioa/dimensions/v1", "token_counting": { "convention_ref": "https://example.net/metering/token-v1", "reasoning_in_output": false, "cached_input_in_input": true, "total_formula": "input + output + reasoning" } } Figure 4 For these examples only, the token convention defines input, visible output and reasoning as disjoint counters, while cached input is a subset of input. Thus 1832 + 412 + 960 = 3204; a provider that already includes reasoning in output requires a different convention or an explicit mapping. The SCU reference is an illustrative profile identifier, not a calibration defined or validated by this draft. 9.3. Model Inference Usage Event Record Example Zhang, et al. Expires 6 May 2027 [Page 25] Internet-Draft Verifiable Usage Accounting for IoA November 2026 { "record_id": "uer-20260507-0038", "accounting_context_id": "acctx-20260507-001", "event_type": "model-inference", "event_time": "2026-05-07T06:12:45Z", "observation_point": "agw-east-1", "actor_ref": "agent:core-network-diagnosis", "target_ref": "model:diagnosis-llm-v1", "usage_category": "model-inference", "usage_measurements": { "input-token-count": 1832, "output-token-count": 412, "reasoning-token-count": 960, "total-token-count": 3204 }, "result_status": "completed", "sequence_info": { "sequence": 38 }, "evidence_ref": [ { "evidence_id": "ev-0038", "evidence_type": "receipt", "evidence_location": "unavailable due to policy" } ], "metering_profile_version": "1.1", "asserting_domain": "example.net", "metering_profile_ref": "profile://example.net/scu-v1", "coverage_scope": "single-attempt", "attempt_id": "attempt-0038", "measurement_status": { "input-token-count": "available", "output-token-count": "available", "reasoning-token-count": "available", "total-token-count": "available" } } Figure 5 9.4. Usage Event Record Example Zhang, et al. Expires 6 May 2027 [Page 26] Internet-Draft Verifiable Usage Accounting for IoA November 2026 { "record_id": "uer-20260507-0037", "accounting_context_id": "acctx-20260507-001", "event_type": "tool-call", "event_time": "2026-05-07T06:12:43Z", "observation_point": "agw-east-1", "actor_ref": "agent:core-network-diagnosis", "target_ref": "tool:amf-log-analysis", "usage_category": "tool-invocation", "usage_measurements": { "standard-compute-usage": 1200, "processing-time-ms": 1840 }, "result_status": "completed", "sequence_info": { "sequence": 37 }, "evidence_ref": [ { "evidence_id": "ev-0037", "evidence_type": "trace-hash", "evidence_location": "unavailable due to policy" } ], "metering_profile_version": "1.1", "asserting_domain": "example.net", "metering_profile_ref": "profile://example.net/scu-v1", "coverage_scope": "single-attempt", "attempt_id": "attempt-0037", "measurement_status": { "standard-compute-usage": "available", "processing-time-ms": "available" } } Figure 6 9.5. Unavailable Measurement Is Not Zero The task completed, but the source counter cannot be established. No zero is inserted and an exact total requiring this counter is unavailable. Zhang, et al. Expires 6 May 2027 [Page 27] Internet-Draft Verifiable Usage Accounting for IoA November 2026 { "record_id": "m-1", "asserting_domain": "example.net", "result_status": "completed", "usage_measurements": {}, "measurement_status": { "input-token-count": "unavailable" }, "reason_class": "provider-meter-unreachable" } 9.6. Delegated Aggregation without Overlap Assume a validated association, one counting convention, and two disjoint local contributions. Use either the parent subtree total or the two local contributions, never both. If the child report is missing, the known local 100 is partial; the asserted summary 140 remains a separate claim whose coverage is not independently established. { "context": "task-1", "dimension": "input-token-count", "profile_version": "1.1", "local_records": [ { "ref": "example.net/p-1", "value": 100 }, { "ref": "example.org/c-1", "value": 40 } ], "parent_summary": { "value": 140, "scope": "subtree", "includes": [ "example.net/p-1", "example.org/c-1" ] }, "expected_total": 140 } Zhang, et al. Expires 6 May 2027 [Page 28] Internet-Draft Verifiable Usage Accounting for IoA November 2026 9.7. Replacement Correction Under the preceding example and a validated correction authority, the child contribution becomes 35 and the effective total is 100 + 35 = 135. The old subtree assertion 140 is not silently rewritten; derived views must reference the correction or mark that summary stale. Redelivery of corr-1 does not subtract or add the correction again. { "record_id": "corr-1", "asserting_domain": "example.org", "operation": "replace", "target_ref": "example.org/c-1", "replacement_measurements": { "input-token-count": 35 }, "expected_task_total": 135 } 9.8. Transport Duplicate and Execution Retry Assume additive compatible units and two confirmed distinct attempts. The retransmitted r-1 is counted once; the distinct retry a-2 contributes its own consumption. If execution identity cannot be established, the overlap remains unresolved. Zhang, et al. Expires 6 May 2027 [Page 29] Internet-Draft Verifiable Usage Accounting for IoA November 2026 { "deliveries": [ { "origin": "example.net", "record_id": "r-1", "attempt_id": "a-1", "value": 10 }, { "origin": "example.net", "record_id": "r-1", "attempt_id": "a-1", "value": 10 }, { "origin": "example.net", "record_id": "r-2", "attempt_id": "a-2", "value": 7 } ], "expected_total": 17 } 10. Privacy Considerations Usage accounting records can reveal sensitive information about users, organizations, agents, tasks, capabilities, tools, business workflows, network operations, and resource consumption. Implementations MUST minimize disclosure according to the accounting purpose. Accounting records exported across domains SHOULD avoid raw prompts, raw tool outputs, personal data, confidential business data, and detailed operational logs unless explicitly authorized and necessary. Privacy-preserving summaries, pseudonymous identifiers, redaction, selective disclosure, and digest-only evidence references SHOULD be used where possible. A Metering Profile SHOULD state whether records are event-level, aggregated, sampled, or summary-only. It SHOULD also state retention expectations and disclosure constraints. The ability to correlate records across gateways or sessions can improve audit and dispute handling, but it can also enable tracking. Accounting Context identifiers and trace identifiers SHOULD be scoped, rotated, or pseudonymized according to policy. Zhang, et al. Expires 6 May 2027 [Page 30] Internet-Draft Verifiable Usage Accounting for IoA November 2026 Even content-free counters, timing, parent links and evidence locations can expose workload structure and tenant relationships. Exporters SHOULD minimize graph linkage, use scope-limited identifiers, and declare whether redaction changes coverage. A privacy-limited view MUST NOT be represented as a complete global view. Collectors SHOULD retain only evidence and linkage needed for the declared purpose. 11. Security Considerations Accounting records may influence quota decisions, audit findings, operational analysis, and downstream business systems. Attackers may attempt to forge, modify, replay, suppress, duplicate, delay, or selectively disclose records. Implementations SHOULD provide integrity protection, source authentication, replay protection, freshness validation, and duplicate detection for exported records. Existing mechanisms such as TLS [RFC8446], JOSE [RFC7515], COSE [RFC9052], JWT [RFC7519], and CWT [RFC8392] may be used as appropriate. A receiving entity MUST NOT treat a Usage Event Record as trustworthy only because it is syntactically valid. The receiving entity SHOULD validate the asserting domain, signature status, freshness, evidence references, and applicable policy. Records that contain usage values may be manipulated to inflate, suppress, or shift apparent usage. Implementations SHOULD support correction records, evidence references, and audit trails for changes to accounting state. Result-verification records are especially sensitive because they may assert that a task outcome occurred. Such records SHOULD be bound to evidence, policy, and verification method. If human confirmation is used, the record SHOULD indicate the confirmation reference without exposing unnecessary personal data. Accounting data loss can affect auditability. Implementations SHOULD consider reliable export, local buffering, non-volatile storage, acknowledgements, or retransmission where archival accounting is required by deployment policy. Zhang, et al. Expires 6 May 2027 [Page 31] Internet-Draft Verifiable Usage Accounting for IoA November 2026 A record asserting a parent task, correction target or metering profile can redirect usage attribution across tenants. Receivers MUST validate the asserting namespace, permitted association, and correction authority before changing an accepted account view. Source authentication cannot establish that a meter was honest or complete. Unavailable measurements or evidence MUST remain distinguishable from measured zero and verified absence. 12. IANA Considerations This document requests no IANA actions in this version. Future versions may request creation of registries for IoA Usage Event Types, IoA Usage Categories, IoA Measurement Dimensions, IoA Usage Units, IoA Measurement Methods, IoA Accounting Evidence Types, and IoA Accounting Result Status Values. 13. Normative References [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, . 14. Informative References [AGENT-RUN-METRICS] Arsentev, E., "Agent Run Metrics: A JSON Interchange Format for Resource Accounting of Language-Model Agent Runs", Work in Progress, Internet-Draft, draft-arsentev- agent-run-metrics-02, 1 November 2026, . [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, . [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, . Zhang, et al. Expires 6 May 2027 [Page 32] Internet-Draft Verifiable Usage Accounting for IoA November 2026 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Appendix A. Change Log RFC Editor: Please remove this appendix before publication. A.1. Changes from -00 to -01 * Distinguished unavailable, withheld and not-applicable measurements from measured zero, and required explicit coverage limitations. * Specified non-overlapping delegated aggregation, namespaced attribution, dimension comparability and token overlap rules. * Separated retransmission from execution retry and clarified cumulative snapshots, replacement corrections and collector findings. * Scoped verification claims and evidence retrieval; clarified that signatures, digests and sequence chains do not establish accuracy or complete observation. Zhang, et al. Expires 6 May 2027 [Page 33] Internet-Draft Verifiable Usage Accounting for IoA November 2026 * Added worked accounting examples and a relationship to Agent Run Metrics; retained Informational status and financial-settlement non-goals. Authors' Addresses Lianhua Zhang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: zhanglh2@asiainfo.com Wen Qiao AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: qiaowen@asiainfo.com Wei Zhang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: zhangwei41@asiainfo.com Huiling Yang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: yanghl10@asiainfo.com Yun Li AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: liyun9@asiainfo.com Zhang, et al. Expires 6 May 2027 [Page 34]