Network Working Group L. J. Reilly Internet-Draft REM Technologies & Consulting, LLC Intended status: Informational 5 September 2026 Expires: 9 March 2027 Reilly Model Routing Protocol (RMRP): A Framework for Policy-Governed, Auditable AI Model Routing draft-reilly-rmrp-01 Abstract This document specifies the Reilly Model Routing Protocol (RMRP), a framework for policy-governed, auditable routing of inference requests across heterogeneous artificial intelligence (AI) model environments. RMRP defines the structural metadata, routing policy declaration, execution semantics, audit trail requirements, and cost attribution mechanisms necessary to govern how inference requests are directed to AI models in multi-model deployments. The protocol is AI-provider agnostic and operates independently of any specific model architecture, inference runtime, vendor implementation, or transport layer. RMRP addresses the absence of a standardized protocol-layer specification governing how routing decisions are declared, transmitted, logged, and enforced across AI model deployments at organizational scale. This revision is additive with respect to draft-reilly-rmrp-00. Every structure, field, value, and requirement defined in -00 is carried forward unchanged. This revision adds record canonicalization, digest, and signature mechanisms; salted field commitments and selective disclosure; complexity score attestation; chain-level and window-level budget enforcement; audit inclusion proofs, checkpoints, and completeness attestation; policy and key revocation; a threat model; conformance levels; and IANA registries for the extensible value sets that -00 defined without one. 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/. Reilly Expires 9 March 2027 [Page 1] Internet-Draft RMRP September 2026 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 9 March 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Design Principles . . . . . . . . . . . . . . . . . . . . . 6 1.4. Scope Added in This Revision . . . . . . . . . . . . . . . 7 1.5. Additional Design Principles in This Revision . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Additional Terminology Introduced in This Revision . . . . 11 2.2. Version Strings and Backward Compatibility . . . . . . . . 12 3. RMRP Architecture Overview . . . . . . . . . . . . . . . . . . 13 3.1. Architectural Layers . . . . . . . . . . . . . . . . . . . 13 3.2. Component Roles . . . . . . . . . . . . . . . . . . . . . 14 3.3. Request Lifecycle . . . . . . . . . . . . . . . . . . . . 14 3.4. Components Added in This Revision . . . . . . . . . . . . 15 4. Model Routing Decision (MRD) . . . . . . . . . . . . . . . . . 16 4.1. MRD Structure . . . . . . . . . . . . . . . . . . . . . . 16 4.2. MRD Field Definitions . . . . . . . . . . . . . . . . . . 17 4.3. Task Classification . . . . . . . . . . . . . . . . . . . 20 4.4. Model Tier Definitions . . . . . . . . . . . . . . . . . . 21 4.5. Complexity Scoring . . . . . . . . . . . . . . . . . . . . 22 4.6. MRD Example . . . . . . . . . . . . . . . . . . . . . . . 22 4.7. MRD Canonicalization, Digest, and Signature . . . . . . . 23 Reilly Expires 9 March 2027 [Page 2] Internet-Draft RMRP September 2026 4.8. Field Commitments and Selective Disclosure . . . . . . . . 25 4.9. Complexity Score Attestation . . . . . . . . . . . . . . . 27 5. Routing Policy Document (RPD) . . . . . . . . . . . . . . . . 30 5.1. RPD Structure . . . . . . . . . . . . . . . . . . . . . . 30 5.2. RPD Field Definitions . . . . . . . . . . . . . . . . . . 30 5.3. Rule Evaluation Order . . . . . . . . . . . . . . . . . . 34 5.4. Fallback Behavior . . . . . . . . . . . . . . . . . . . . 34 5.5. RPD Example . . . . . . . . . . . . . . . . . . . . . . . 35 5.6. RPD Canonicalization and Policy Digest . . . . . . . . . . 37 5.7. Policy Revocation . . . . . . . . . . . . . . . . . . . . 38 5.8. Additional Rule Fields Defined in This Revision . . . . . 40 6. Routing Execution Semantics . . . . . . . . . . . . . . . . . 41 6.1. Pre-Routing Validation . . . . . . . . . . . . . . . . . . 41 6.2. Policy Resolution . . . . . . . . . . . . . . . . . . . . 41 6.3. Model Selection . . . . . . . . . . . . . . . . . . . . . 42 6.4. Request Dispatch . . . . . . . . . . . . . . . . . . . . . 43 6.5. Response Handling . . . . . . . . . . . . . . . . . . . . 43 6.6. Error and Fallback Handling . . . . . . . . . . . . . . . 43 6.7. Deterministic Replay of Routing Decisions . . . . . . . . 44 6.8. Chain Depth, Recursion, and Escalation Damping . . . . . . 45 6.9. Additional Error Codes Defined in This Revision . . . . . 47 7. Audit Trail Requirements . . . . . . . . . . . . . . . . . . . 48 7.1. Audit Log Record (ALR) Structure . . . . . . . . . . . . . 48 7.2. ALR Field Definitions . . . . . . . . . . . . . . . . . . 48 7.3. Audit Level Classes . . . . . . . . . . . . . . . . . . . 51 7.4. Retention Requirements . . . . . . . . . . . . . . . . . . 51 7.5. ALR Example . . . . . . . . . . . . . . . . . . . . . . . 52 7.6. Additional ALR Fields and Outcome Values . . . . . . . . . 53 7.7. Merkle Construction and Inclusion Proofs . . . . . . . . . 55 7.8. Checkpoints and External Anchoring . . . . . . . . . . . . 56 7.9. Hash Migration and Bridging Records . . . . . . . . . . . 57 7.10. Routing Completeness Attestation (RCA) . . . . . . . . . 58 8. Cost Attribution Framework . . . . . . . . . . . . . . . . . . 59 8.1. Cost Attribution Record (CAR) . . . . . . . . . . . . . . 59 8.2. CAR Field Definitions . . . . . . . . . . . . . . . . . . 59 8.3. Budget Authority Chain . . . . . . . . . . . . . . . . . . 61 8.4. Cost Ceiling Enforcement . . . . . . . . . . . . . . . . . 62 8.5. CAR Example . . . . . . . . . . . . . . . . . . . . . . . 62 8.6. Chain-Level and Window-Level Budget Enforcement . . . . . 63 8.7. Cost Reconciliation Record (CRR) . . . . . . . . . . . . . 66 9. Governance and Authorization . . . . . . . . . . . . . . . . . 67 9.1. Policy Authority Model . . . . . . . . . . . . . . . . . . 67 9.2. Policy Issuance and Signing . . . . . . . . . . . . . . . 67 9.3. Policy Versioning . . . . . . . . . . . . . . . . . . . . 68 9.4. Override Mechanisms . . . . . . . . . . . . . . . . . . . 68 9.5. Key Rotation and Revocation . . . . . . . . . . . . . . . 69 Reilly Expires 9 March 2027 [Page 3] Internet-Draft RMRP September 2026 9.6. Governance Event Records (GER) . . . . . . . . . . . . . . 69 9.7. Separation of Duties . . . . . . . . . . . . . . . . . . . 71 10. Transport Considerations . . . . . . . . . . . . . . . . . . 71 10.1. HTTP Transport . . . . . . . . . . . . . . . . . . . . . 71 10.2. Header Propagation . . . . . . . . . . . . . . . . . . . 72 10.3. Non-HTTP Transports . . . . . . . . . . . . . . . . . . . 73 10.4. Header Field Naming and Structured Field Syntax . . . . . 73 10.5. MRD Reference Mode . . . . . . . . . . . . . . . . . . . 74 10.6. Caller Authentication and HTTP Semantics . . . . . . . . 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 75 11.1. Policy Integrity . . . . . . . . . . . . . . . . . . . . 75 11.2. MRD Tampering . . . . . . . . . . . . . . . . . . . . . . 76 11.3. Audit Log Integrity . . . . . . . . . . . . . . . . . . . 76 11.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 76 11.5. Credential Exposure . . . . . . . . . . . . . . . . . . . 76 11.6. Threat Model . . . . . . . . . . . . . . . . . . . . . . 77 11.7. Escalation Abuse and Score Inflation . . . . . . . . . . 78 11.8. Audit Suppression . . . . . . . . . . . . . . . . . . . . 79 11.9. Cryptographic Agility . . . . . . . . . . . . . . . . . . 79 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 80 12.1. Data Minimization and Selective Disclosure . . . . . . . 80 12.2. Retention, Erasure, and Anchored Records . . . . . . . . 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 13.1. Additional Registrations Requested in This Revision . . . 83 13.2. Requested Registries . . . . . . . . . . . . . . . . . . 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 14.1. Normative References . . . . . . . . . . . . . . . . . . 85 14.2. Informative References . . . . . . . . . . . . . . . . . 86 15. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 88 16. Prior Art Record Status . . . . . . . . . . . . . . . . . . . 90 17. Relationship to Related Work . . . . . . . . . . . . . . . . 90 18. Changes from draft-reilly-rmrp-00 . . . . . . . . . . . . . . 91 Appendix A. Worked Example at Conformance Level C4 . . . . . . . 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 96 Reilly Expires 9 March 2027 [Page 4] Internet-Draft RMRP September 2026 1. Introduction 1.1. Motivation The deployment of artificial intelligence systems at organizational scale increasingly involves multiple AI models operating in parallel or in sequence. A given application may call upon lightweight models for classification tasks, mid-tier models for summarization, and advanced models for complex multi-step reasoning, all within a single request pipeline. This operational pattern is referred to throughout this document as multi-model deployment. Despite the rapid proliferation of multi-model AI deployments, no standardized protocol exists that specifies how routing decisions between models should be declared, communicated, executed, audited, or governed. Current industry practice is characterized by ad hoc engineering decisions embedded in application code, vendor-specific gateway configurations, or informal internal policies with no interoperable representation. This absence of a protocol standard produces several systemic problems: o Routing logic is opaque and non-portable across systems and vendors. o Cost attribution for model usage cannot be reliably traced to the policy decision that produced the expenditure. o Audit records, where they exist, are inconsistent, incomplete, and not interoperable. o Governance over who may define, modify, or override routing policy is informal and unenforceable at the protocol layer. o Failure modes, escalation paths, and fallback behavior are undefined in any portable specification. The Reilly Model Routing Protocol (RMRP) addresses each of these deficiencies by defining a provider-agnostic, transport-agnostic protocol framework for AI model routing governance. 1.2. Scope This document specifies: Reilly Expires 9 March 2027 [Page 5] Internet-Draft RMRP September 2026 o The Model Routing Decision (MRD): a structured metadata object that accompanies every routed inference request, carrying the routing decision and its full governance context. o The Routing Policy Document (RPD): a declarative specification that defines the rules by which routing decisions are made. o Routing Execution Semantics: the normative procedures by which an RMRP-compliant router resolves, applies, and validates routing policy against an incoming request. o The Audit Log Record (ALR): a standardized record structure for capturing each routing event for compliance, debugging, and accountability purposes. o The Cost Attribution Record (CAR): a structure that traces the financial cost of each routed request to the policy, cost center, and budget authority that authorized it. o A Governance and Authorization model that defines how routing policy is issued, signed, versioned, and enforced. This document does not specify the internal architecture of any AI model, the machine learning logic used to assess request complexity, the commercial pricing structure of any AI provider, or any application-layer inference API. RMRP is a governance and metadata protocol layer that sits above any such systems. 1.3. Design Principles RMRP is designed according to the following principles: Provider Agnosticism: RMRP MUST NOT assume the use of any specific AI model provider, vendor API, or proprietary infrastructure. All provider-specific identifiers are treated as opaque strings within the protocol. Transport Agnosticism: RMRP metadata structures are defined as JSON objects. They may be transmitted over HTTP, message queues, RPC frameworks, or any other transport that supports structured data payloads. Auditability by Default: Every routing decision produces an auditable record. Audit logging is not optional for conformant implementations. Reilly Expires 9 March 2027 [Page 6] Internet-Draft RMRP September 2026 Policy as a First-Class Object: Routing policy is a declared, versioned, signed artifact. Inline or implicit routing logic embedded in application code does not satisfy RMRP conformance. Cost Traceability: Every routed request MUST be attributable to a cost center and budget authority. Unattributed inference costs are a conformance violation. Least-Cost Sufficiency: Routing policy SHOULD direct requests to the least capable model tier sufficient to satisfy the task requirements. Routing to a higher tier MUST be justified by policy conditions. Separation of Concerns: The routing decision layer is separate from the inference execution layer. An RMRP-compliant router makes and records a routing decision; it does not implement inference. 1.4. Scope Added in This Revision In addition to the scope stated in Section 1.2, this revision specifies: o Canonicalization, digest, and signature mechanisms that make an MRD, ALR, CAR, and RPD independently verifiable by a party that did not produce them (Sections 4.7, 5.6, and 7.6). o Salted per-field commitments and selective disclosure, so that a routing record can be proven to an auditor, a regulator, or a counterparty without exposing every attributed field (Section 4.8). o Complexity Score attestation, which binds the scoring method to the routing decision it justified (Section 4.9). o Chain-level and window-level budget enforcement, which bounds aggregate expenditure across an agentic pipeline rather than only per request (Section 8.6). o Audit inclusion proofs, checkpointing, external anchoring, and a Routing Completeness Attestation that makes the omission of a routing event detectable (Sections 7.6 through 7.9). o Revocation of policies and of signing keys, with fail-closed behavior (Sections 5.7 and 9.5). Reilly Expires 9 March 2027 [Page 7] Internet-Draft RMRP September 2026 o A threat model, conformance levels, and IANA registries for the extensible value sets defined in -00 (Sections 11.6, 15, and 13.1). This revision does not change the meaning of any field defined in -00. Fields added by this revision are OPTIONAL at the conformance level of -00 and become REQUIRED only at the higher conformance levels defined in Section 15. 1.5. Additional Design Principles in This Revision The following principles extend, and do not replace, those in Section 1.3: Verifiability by a Non-Producer: A routing record SHOULD be verifiable by a party that did not produce it and does not trust the producer. Auditability that depends on trusting the audited system is not auditability. Detectability of Omission: A conformant deployment SHOULD make the absence of a routing record detectable. A record that can be silently omitted provides no assurance about the events it does not describe. Justification Binding: Where a routing decision is justified by a computed value, the method that produced that value SHOULD be bound to the decision record. An unverifiable justification is an assertion, not a control. Aggregate Boundedness: Cost controls SHOULD bound aggregate expenditure over a pipeline and a time window, not only the expenditure of a single request. Per-request ceilings do not bound a recursive agent. Fail-Closed Governance: Where policy validity, key validity, or audit availability cannot be established, a conformant router SHOULD refuse to route rather than route without governance. 2. Terminology 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. Reilly Expires 9 March 2027 [Page 8] Internet-Draft RMRP September 2026 The following terms are defined for use in this document: AI Model: A software system that accepts a structured input (referred to herein as an inference request) and produces a structured output (referred to herein as an inference response) using a learned computational process. This definition is intentionally broad and encompasses large language models, multimodal models, embedding models, classification models, and other learned inference systems. Budget Authority: The organizational entity, role, or system identity that has been designated as responsible for approving inference expenditure within a defined cost center. Budget Authority is referenced by identifier within RMRP structures and resolved externally to the protocol. Complexity Score: A normalized floating-point value in the range [0.0, 1.0] that represents an assessment of the computational or semantic difficulty of an inference request relative to a defined task type. The method of computing the Complexity Score is outside the scope of this specification; RMRP defines only how this value is represented and used in routing decisions. Conformant Router: An RMRP Routing Engine that implements all REQUIRED behaviors specified in this document. Cost Attribution Record (CAR): A structured JSON object produced by a Conformant Router upon completion of a routed inference request, recording the financial cost of the request and attributing it to the applicable cost center, policy, and Budget Authority. Cost Center: An organizational unit, project, team, application, or other logical grouping to which the financial cost of inference requests is attributed. Fallback Model: The AI model or model tier to which a routing request is directed when the primary selected model is unavailable, returns an error, or exceeds a defined constraint. Inference Request: A structured input submitted to an AI model for processing. The content and format of the inference request are outside the scope of this specification. Reilly Expires 9 March 2027 [Page 9] Internet-Draft RMRP September 2026 Inference Response: The structured output produced by an AI model in response to an Inference Request. The content and format of the inference response are outside the scope of this specification. Model Identifier: An opaque string that uniquely identifies a specific AI model or model version within the scope of a deployment. Model Identifiers are defined and managed externally to RMRP. Model Registry: An external system or configuration artifact that maps Model Identifiers to model capabilities, tier assignments, and endpoint information. RMRP does not specify the implementation of a Model Registry but requires that a Conformant Router have access to one. Model Routing Decision (MRD): A structured JSON object produced by a Conformant Router that records the routing decision made for a specific inference request, including the selected model, the policy applied, and the full governance context. Model Tier: A categorical classification of AI models according to their relative capability and cost. This specification defines three normative tiers: LIGHT, STANDARD, and ADVANCED. Implementations MAY define additional tiers subject to the constraints in Section 4.4. Policy Authority: The organizational entity or role that has been granted the right to issue, sign, and publish Routing Policy Documents within a defined scope. Routing Engine: The software component responsible for receiving an inference request, evaluating applicable Routing Policy Documents, producing a Model Routing Decision, and dispatching the request to the selected model. Routing Policy Document (RPD): A structured, versioned, signed JSON document that declares the rules by which a Routing Engine selects a target model for a given inference request. Task Type: A categorical label that describes the nature of an inference request at the application level. RMRP defines a normative set of Task Types in Section 4.3. Implementations MAY extend this set using the extension mechanism defined therein. Reilly Expires 9 March 2027 [Page 10] Internet-Draft RMRP September 2026 Audit Log Record (ALR): A structured JSON object produced by a Conformant Router for each routing event, capturing the full decision trace, outcome, and timing of the routing operation. RMRP Version: The protocol version string identifying the version of this specification to which an MRD, RPD, ALR, or CAR conforms. The version string for this specification is "1.0". Records produced under the additional mechanisms defined in this revision use the version string "1.1" as specified in Section 2.2. 2.1. Additional Terminology Introduced in This Revision Bridging Record: A record that binds a digest computed under a retiring hash algorithm to a digest computed under a replacement algorithm over the same content, preserving verifiability across a hash migration. See Section 7.8. Budget Window Record (BWR): A record that accumulates authorized and consumed inference expenditure for a cost center over a defined time window, enabling aggregate ceiling enforcement. See Section 8.6. Canonical Form: The deterministic serialization of an RMRP record used as the input to digest and signature computation. Unless otherwise stated, the canonical form of a JSON RMRP record is its JSON Canonicalization Scheme (JCS) serialization [RFC8785]. Chain Budget Ceiling: The maximum aggregate cost authorized for all inference requests sharing a single "chain_id". Checkpoint: A signed statement over a Merkle tree head covering a contiguous range of audit records, published at intervals to bound the window in which undetected audit modification is possible. See Section 7.7. Conformance Level: A named set of requirements that an implementation satisfies, defined in Section 15. Conformance levels are cumulative. Cost Reconciliation Record (CRR): A record that compares costs recorded in CARs for a period against costs subsequently reported by a model provider, and records the variance. See Section 8.7. Reilly Expires 9 March 2027 [Page 11] Internet-Draft RMRP September 2026 Field Commitment: A salted cryptographic commitment to the value of a single field of an RMRP record, permitting that field to be disclosed and verified individually. See Section 4.8. Governance Event Record (GER): A record of a change to the governance state of a deployment, including policy issuance, amendment, revocation, authority assignment, and key rotation. See Section 9.6. Inclusion Proof: A sequence of hashes that demonstrates that a given audit record is a member of the Merkle tree committed to by a given tree head. See Section 7.6. Revocation Registry: A signed, monotonically versioned list of policy versions and signing keys that MUST NOT be relied upon, published by a Policy Authority. See Sections 5.7 and 9.5. Routing Completeness Attestation (RCA): A periodic signed statement by a Conformant Router that all routing events it processed within a stated window are represented in the Audit Store, together with the count and tree head of those records. See Section 7.9. Scorer Attestation: The set of fields that identify and bind the method used to compute the Complexity Score for a routing decision. See Section 4.9. 2.2. Version Strings and Backward Compatibility Records that conform to draft-reilly-rmrp-00 carry the "rmrp_version" value "1.0". This revision does not invalidate those records and does not change the meaning of the "1.0" value. A record that includes any field defined by this revision MUST carry the "rmrp_version" value "1.1". A record carrying "1.1" MUST satisfy every requirement that applies to "1.0" records. All fields introduced by this revision are OPTIONAL for "1.1" records except where a conformance level in Section 15 requires them. A consumer of RMRP records MUST accept both "1.0" and "1.1" values. A consumer that does not implement this revision MUST ignore fields it does not recognize rather than reject the record, consistent with the extension handling rules in Section 4.2. Reilly Expires 9 March 2027 [Page 12] Internet-Draft RMRP September 2026 A Routing Engine MUST NOT downgrade a record from "1.1" to "1.0" by omitting fields that a matched RPD rule required to be present. 3. RMRP Architecture Overview 3.1. Architectural Layers RMRP defines a governance layer that operates between the application layer and the AI model inference layer. This layer is not a transport protocol and does not replace any existing network or application protocol. It defines the metadata, policy, and audit structures that govern routing decisions. The RMRP architectural layers are as follows: +--------------------------------------+ | Application Layer | | (Caller submits inference request) | +--------------------------------------+ | v +--------------------------------------+ | RMRP Governance Layer | | | | +------------------------------+ | | | Routing Policy Document | | | | (RPD) | | | +------------------------------+ | | | | +------------------------------+ | | | Routing Engine | | | | - Evaluates RPD | | | | - Produces MRD | | | | - Writes ALR | | | | - Writes CAR | | | +------------------------------+ | +--------------------------------------+ | v +--------------------------------------+ | AI Model Inference Layer | | (Selected model processes request) | +--------------------------------------+ Figure 1: RMRP Architectural Layers Reilly Expires 9 March 2027 [Page 13] Internet-Draft RMRP September 2026 3.2. Component Roles Policy Authority: Issues, signs, and publishes RPDs. The Policy Authority is responsible for ensuring that RPDs reflect organizational cost governance, capability requirements, and compliance constraints. A Policy Authority MUST NOT be the same entity as the Routing Engine in deployments where separation of concerns is required by organizational policy, though this specification does not mandate such separation in all contexts. Routing Engine: Receives inference requests from the application layer, resolves the applicable RPD, computes a routing decision, produces an MRD, dispatches the request to the selected model, and writes an ALR and CAR upon completion. A Conformant Router MUST perform all of these functions. Model Registry: An external system consulted by the Routing Engine to resolve Model Identifiers to endpoints and validate tier assignments. RMRP does not specify the implementation of the Model Registry. Audit Store: The persistent storage system into which the Routing Engine writes ALRs and CARs. The Audit Store MUST be write-once or append-only with respect to routing records to preserve audit integrity. Implementations MAY use cryptographic mechanisms to further ensure record immutability. Budget Authority: Receives cost attribution data via CARs. Budget Authority systems are external to RMRP and consume CAR records for financial reporting and budget enforcement purposes. 3.3. Request Lifecycle The lifecycle of an inference request under RMRP is as follows: 1. The application layer submits an inference request to the Routing Engine, optionally including request metadata such as Task Type, priority class, and cost center identifier. 2. The Routing Engine performs pre-routing validation as specified in Section 6.1. 3. The Routing Engine resolves the applicable RPD as specified in Section 6.2. Reilly Expires 9 March 2027 [Page 14] Internet-Draft RMRP September 2026 4. The Routing Engine evaluates RPD rules against the request metadata and computes a Complexity Score to select a target model tier and Model Identifier. 5. The Routing Engine produces a Model Routing Decision (MRD) documenting the decision and its full governance context. 6. The Routing Engine dispatches the inference request to the selected model, attaching the MRD as specified in Section 6.4. 7. The selected model processes the request and returns an inference response. 8. The Routing Engine receives the response, records actual token consumption and latency, and updates the ALR and CAR with outcome data. 9. The Routing Engine writes the completed ALR and CAR to the Audit Store. 10. The inference response is returned to the application layer, accompanied by a reference to the MRD for correlation purposes. 3.4. Components Added in This Revision The following components extend the architecture in Section 3.2. Each is OPTIONAL at the base conformance level and REQUIRED at the levels indicated in Section 15. Revocation Registry Publisher: A service operated by or on behalf of a Policy Authority that publishes the signed Revocation Registry described in Sections 5.7 and 9.5. Routing Engines consult it before applying a cached policy or accepting a signature. Attestation Publisher: A component that publishes Merkle tree heads, Checkpoints, and Routing Completeness Attestations derived from the Audit Store, as described in Sections 7.6 through 7.9. The Attestation Publisher MUST NOT be able to modify Audit Store contents. Reilly Expires 9 March 2027 [Page 15] Internet-Draft RMRP September 2026 Budget Window Service: A component that maintains Budget Window Records as described in Section 8.6 and answers pre-dispatch queries about remaining authorized expenditure for a cost center, chain, or window. Where this component is unavailable, the Routing Engine applies the fail-closed behavior in Section 8.6. External Anchor Target: Any system, outside the administrative control of the deployment, to which Checkpoint digests are published for independent corroboration, as described in Section 7.7. RMRP does not require a specific anchor target and does not require a distributed ledger. Verifier: Any party that validates RMRP records without having produced them, including internal audit, external auditors, regulators, counterparties, and downstream automated systems. The mechanisms added in this revision exist principally to make the Verifier role possible without trusting the Routing Engine. The addition of these components does not alter the request lifecycle in Section 3.3. Steps 1 through 10 apply unchanged; the components above operate alongside or after that lifecycle. 4. Model Routing Decision (MRD) 4.1. MRD Structure The Model Routing Decision is a JSON object [RFC8259] that MUST be produced by a Conformant Router for every inference request processed. The MRD captures the routing decision and its full governance context in a portable, inspectable form. The MRD MUST contain all REQUIRED fields defined in Section 4.2. OPTIONAL fields SHOULD be included when the relevant information is available to the Routing Engine. Additional fields not defined in this specification MAY be included using the extension mechanism defined in Section 4.2. All field names are case-sensitive. All string values are UTF-8 encoded [RFC3629]. All timestamp values are ISO 8601 formatted strings in UTC with millisecond precision. Reilly Expires 9 March 2027 [Page 16] Internet-Draft RMRP September 2026 4.2. MRD Field Definitions rmrp_version (string, REQUIRED) The RMRP protocol version string. For documents conforming to this specification, the value MUST be "1.0". mrd_id (string, REQUIRED) A universally unique identifier for this MRD instance, formatted as a UUID [RFC9562]. This identifier is used to correlate the MRD with associated ALRs, CARs, and application logs. request_id (string, REQUIRED) An identifier for the inference request as assigned by the caller. If the caller does not supply a request identifier, the Routing Engine MUST generate one and return it to the caller. Format is implementation-defined but MUST be unique within the scope of the deployment. timestamp (string, REQUIRED) The UTC timestamp at which the Routing Engine produced this MRD. Format: ISO 8601 with millisecond precision. Example: "2026-04-28T17:00:00.000Z" routing_policy_id (string, REQUIRED) The unique identifier of the Routing Policy Document applied to produce this routing decision. This value MUST correspond to the "policy_id" field of the applicable RPD. routing_policy_version (string, REQUIRED) The version string of the RPD applied. This value MUST correspond to the "policy_version" field of the applicable RPD. source_system (string, REQUIRED) An identifier for the application or system component that submitted the inference request. Format is implementation- defined. This field is used for attribution, auditing, and cost allocation. task_type (string, REQUIRED) The Task Type classification of the inference request. MUST be one of the normative Task Type values defined in Section 4.3, or an extended value registered per the extension mechanism in Section 4.3. Reilly Expires 9 March 2027 [Page 17] Internet-Draft RMRP September 2026 complexity_score (number, REQUIRED) A floating-point value in the range [0.0, 1.0] representing the assessed complexity of the inference request. The method of computation is outside the scope of this specification. A value of 0.0 represents the minimum assessed complexity for the given task type; a value of 1.0 represents the maximum. selected_model_id (string, REQUIRED) The Model Identifier of the AI model selected to process this inference request. This value MUST resolve to a registered model in the Model Registry. selected_model_tier (string, REQUIRED) The model tier assignment of the selected model. MUST be one of the normative tier values defined in Section 4.4. routing_rationale (string, REQUIRED) A human-readable description of the routing decision, identifying which RPD rule was matched and why the selected model tier was chosen. This field is intended for audit inspection and operational debugging. cost_center (string, REQUIRED) The identifier of the cost center to which the financial cost of this inference request is attributed. This value MUST correspond to a valid cost center identifier in the organization's Cost Attribution framework. budget_authority_id (string, REQUIRED) The identifier of the Budget Authority that approved inference expenditure for this cost center under the applicable RPD. max_token_budget (integer, REQUIRED) The maximum number of tokens (input plus output) authorized for this inference request under the applicable RPD rule. A value of -1 indicates no token ceiling is enforced by policy for this request. Routing Engines MUST NOT route requests where the estimated token consumption exceeds this value without triggering the fallback behavior defined in Section 6.6. priority_class (string, REQUIRED) The priority classification of the inference request. MUST be one of: "CRITICAL", "HIGH", "STANDARD", "BATCH". Priority class MAY influence model selection and queuing behavior. See Section 4.5 for priority class semantics. Reilly Expires 9 March 2027 [Page 18] Internet-Draft RMRP September 2026 fallback_model_id (string, OPTIONAL) The Model Identifier of the fallback model to be used if the selected model is unavailable or returns an error. If present, this value MUST resolve to a registered model in the Model Registry. fallback_model_tier (string, OPTIONAL) The model tier assignment of the fallback model, if specified. MUST be one of the normative tier values defined in Section 4.4 if present. chain_id (string, OPTIONAL) An identifier linking this inference request to a broader multi-step request pipeline or agent chain. Used for correlating multiple MRDs produced within a single logical workflow. chain_step (integer, OPTIONAL) The ordinal position of this inference request within the chain identified by "chain_id". MUST be a non-negative integer. The first step in a chain is 0. estimated_input_tokens (integer, OPTIONAL) The estimated number of input tokens for this inference request, as assessed by the Routing Engine prior to dispatch. estimated_output_tokens (integer, OPTIONAL) The estimated number of output tokens for this inference request, as assessed by the Routing Engine prior to dispatch. audit_level (string, REQUIRED) The audit level class applied to this routing event. MUST be one of the normative audit level values defined in Section 7.3. extensions (object, OPTIONAL) A JSON object containing implementation-specific or deployment-specific fields not defined in this specification. Extension field names MUST use a reverse-DNS prefix to avoid collisions (e.g., "com.example.custom_field"). The presence of extension fields MUST NOT alter the interpretation of any normative field defined in this specification. Reilly Expires 9 March 2027 [Page 19] Internet-Draft RMRP September 2026 4.3. Task Classification RMRP defines the following normative Task Types. These values are case-sensitive and MUST be used verbatim in the "task_type" field of the MRD and in RPD rule conditions. CLASSIFICATION A request whose primary output is a categorical label or score applied to input content. Includes sentiment analysis, intent detection, content moderation, and similar tasks. Typically low complexity. EXTRACTION A request whose primary output is structured data extracted from unstructured input, including named entity recognition, key-value extraction, and table parsing. SUMMARIZATION A request whose primary output is a condensed representation of a larger input document or corpus. GENERATION A request whose primary output is novel content generated in response to a prompt, including text generation, code generation, and creative writing tasks. REASONING A request that requires multi-step logical inference, mathematical computation, or structured problem-solving. Typically high complexity. EMBEDDING A request whose primary output is a vector representation of the input content. Embedding requests SHOULD be routed to models optimized for embedding generation. RETRIEVAL A request that involves retrieval-augmented generation or query-driven document retrieval. Complexity is a function of retrieval corpus size and query ambiguity. TRANSFORMATION A request whose primary output is a transformed version of the input (e.g., translation, reformatting, normalization, or style transfer). AGENTIC A request submitted within an autonomous agent pipeline that may produce tool calls, multi-turn interactions, or sub-task decomposition. Agentic requests SHOULD be assigned higher complexity scores by default given their potential for recursive resource consumption. Reilly Expires 9 March 2027 [Page 20] Internet-Draft RMRP September 2026 MULTIMODAL A request that includes non-text input modalities such as images, audio, or video, in addition to or in place of text input. Implementations MAY define additional Task Types using the "extensions" mechanism. Extended Task Type values MUST use a reverse-DNS prefix (e.g., "com.example.CUSTOM_TASK"). RPD rules that reference extended Task Types MUST be ignored by Routing Engines that do not recognize the extended value, and fallback behavior as defined in Section 6.6 MUST be applied. 4.4. Model Tier Definitions RMRP defines three normative model tiers. Tier assignment is the responsibility of the operator and is recorded in the Model Registry. RMRP does not prescribe which specific models belong to which tier; this is a deployment-time configuration decision. LIGHT Models in the LIGHT tier are optimized for low-latency, high-throughput processing of tasks with low-to-moderate complexity. LIGHT tier models are expected to be the lowest- cost option in a deployment. LIGHT tier SHOULD be the default routing target for CLASSIFICATION, EXTRACTION, EMBEDDING, and TRANSFORMATION task types unless policy conditions require escalation. STANDARD Models in the STANDARD tier provide a balanced capability-to-cost profile. STANDARD tier is appropriate for SUMMARIZATION, GENERATION, and RETRIEVAL tasks at moderate complexity scores, and for REASONING tasks at low complexity scores. ADVANCED Models in the ADVANCED tier provide maximum available capability for high-complexity tasks. ADVANCED tier MUST only be selected when policy conditions explicitly authorize it and the request complexity or task type requires capabilities unavailable in lower tiers. Routing to ADVANCED tier without explicit RPD authorization is a conformance violation. Implementations MAY define additional tiers using the "extensions" mechanism. Extended tier values MUST NOT replace or supersede the normative tier definitions above. Reilly Expires 9 March 2027 [Page 21] Internet-Draft RMRP September 2026 4.5. Complexity Scoring The Complexity Score is a normalized floating-point value in [0.0, 1.0] that the Routing Engine assigns to each inference request prior to RPD rule evaluation. RMRP does not mandate a specific algorithm for computing the Complexity Score. Conformant implementations MUST document the method used to produce this value for audit purposes. Informative guidance for Complexity Score computation includes: o Input token count relative to model context window capacity. o Presence of multi-step instructions or chained subtasks. o Ambiguity of the input as assessed by a lightweight classifier. o Historical accuracy of lower-tier models on similar inputs. o Structural complexity indicators such as nested conditionals, mathematical expressions, or code with high cyclomatic complexity. Priority class semantics are as follows. Note: the value "STANDARD" used for priority class is distinct from the model tier "STANDARD" defined in Section 4.4. These identifiers exist in separate namespaces within the protocol and MUST NOT be conflated. CRITICAL Requests that require immediate processing. Priority class CRITICAL MUST NOT be routed to BATCH processing queues. CRITICAL requests MAY bypass certain cost ceiling constraints as defined in the applicable RPD. HIGH Requests that require low-latency processing but are not operationally critical. STANDARD Default priority for interactive workloads. BATCH Requests that are tolerant of high latency in exchange for reduced per-token cost. BATCH requests SHOULD be queued for asynchronous processing where the model provider supports it. 4.6. MRD Example The following is a non-normative example of a conformant MRD: Reilly Expires 9 March 2027 [Page 22] Internet-Draft RMRP September 2026 { "rmrp_version": "1.0", "mrd_id": "550e8400-e29b-41d4-a716-446655440000", "request_id": "req-20260428-00192", "timestamp": "2026-04-28T17:00:00.000Z", "routing_policy_id": "rpd-prod-engineering-v3", "routing_policy_version": "3.2.1", "source_system": "api-gateway.internal", "task_type": "REASONING", "complexity_score": 0.82, "selected_model_id": "provider-alpha/model-advanced-v2", "selected_model_tier": "ADVANCED", "routing_rationale": "Rule R-07 matched: task_type=REASONING, complexity_score 0.82 exceeds STANDARD tier threshold 0.75. ADVANCED tier authorized by policy for cost_center=eng-ai.", "cost_center": "eng-ai", "budget_authority_id": "ba-vp-engineering-001", "max_token_budget": 8192, "priority_class": "HIGH", "fallback_model_id": "provider-alpha/model-standard-v4", "fallback_model_tier": "STANDARD", "chain_id": "chain-pipeline-20260428-00041", "chain_step": 2, "estimated_input_tokens": 2048, "estimated_output_tokens": 1024, "audit_level": "FULL", "extensions": {} } 4.7. MRD Canonicalization, Digest, and Signature Section 4.1 defines the MRD as an inspectable record. Inspection establishes what a Routing Engine says it did. It does not establish that the record was produced at the stated time, by the stated engine, or that it has not been altered since. This subsection defines the fields that close that gap. 4.7.1. Canonical Form The canonical form of an MRD is its JSON Canonicalization Scheme (JCS) serialization [RFC8785], computed over the MRD object with the fields "mrd_digest" and "mrd_signature" removed. All other fields, including "extensions", MUST be present in the input to canonicalization exactly as they appear in the record. Reilly Expires 9 March 2027 [Page 23] Internet-Draft RMRP September 2026 Producers MUST NOT rely on key ordering, insignificant whitespace, or numeric formatting to be preserved in transit. Verifiers MUST recompute the canonical form from the parsed record rather than digesting received bytes. Floating-point values, including "complexity_score", MUST be serialized per the JCS number rules. Implementations SHOULD represent "complexity_score" with no more than six fractional digits to avoid platform-dependent serialization differences. 4.7.2. MRD Digest Fields The following fields are added to the MRD. They are OPTIONAL for "1.1" records and REQUIRED at conformance level C2 (Section 15). mrd_digest (string, OPTIONAL) The base64url encoding [RFC4648] of the digest of the canonical form of this MRD, computed as specified in Section 4.7.1. mrd_digest_algorithm (string, OPTIONAL) The algorithm used to compute "mrd_digest". REQUIRED if "mrd_digest" is present. RECOMMENDED values: "SHA-256", "SHA3-512", "BLAKE3". Implementations MUST support "SHA-256". A record that omits this field while carrying a digest MUST be treated as unverifiable. Verifiers MUST recompute the digest and compare it to the recorded value before relying on any other field of the record. A digest mismatch MUST be treated as a record integrity failure and MUST be recorded in the Audit Store as a Governance Event Record (Section 9.6). 4.7.3. MRD Signature Where non-repudiation of the routing decision is required, the Routing Engine signs the MRD. mrd_signature (string, OPTIONAL) A detached signature over the canonical form of this MRD. The value is the base64url encoding of a COSE_Sign1 structure [RFC9052] whose payload is the canonical form, or of a JWS [RFC7515] with detached payload where the deployment uses JOSE throughout. Implementations MUST support COSE_Sign1 with algorithm ES256 [RFC9053]. Reilly Expires 9 March 2027 [Page 24] Internet-Draft RMRP September 2026 signer_key_id (string, OPTIONAL) A stable identifier for the key pair used to produce "mrd_signature". REQUIRED if "mrd_signature" is present. The identifier MUST be resolvable through the same key distribution mechanism used for RPD verification (Section 9.2) and MUST be checkable against the Revocation Registry (Section 9.5). signature_timestamp (string, OPTIONAL) The UTC timestamp at which the signature was produced, where this differs materially from "timestamp". A Routing Engine signing key MUST be distinct from any Policy Authority signing key in deployments that require separation of duties under Section 9.7. A Routing Engine MUST NOT sign an MRD with a key that is also authorized to issue RPDs, because doing so would allow a single compromised key to both author the policy and attest compliance with it. Verifiers MUST reject a signature produced by a key that was revoked at the time indicated by "signature_timestamp" or, in its absence, "timestamp". Verifiers MUST NOT reject a signature solely because the key has since been rotated, provided the key was valid at the time of signing and the rotation was recorded per Section 9.5. 4.8. Field Commitments and Selective Disclosure An MRD carries organizationally sensitive fields: "cost_center", "budget_authority_id", "source_system", and "routing_rationale" may each reveal internal structure, staffing, or workload that an organization is unwilling to expose to every party that must verify a routing decision. Section 12 identifies this exposure but -00 offers only access control as a remedy, which does not help where the record must leave the organization. This subsection defines commitments that allow a record to be verified in full while disclosing only selected fields. 4.8.1. Commitment Construction For each field to be committed, the producer computes: commitment = H( salt || 0x00 || field_name || 0x00 || canonical_value ) Reilly Expires 9 March 2027 [Page 25] Internet-Draft RMRP September 2026 where H is the algorithm named in "commitment_algorithm", salt is a fresh value of at least 128 bits drawn from a cryptographically secure random source, field_name is the UTF-8 field name, and canonical_value is the JCS serialization of the field value. A salt MUST NOT be reused across fields or across records. Salt reuse permits an observer with a candidate value to confirm it across every record where the salt repeats, which defeats the purpose of the construction. Implementations MUST NOT derive salts from record identifiers, timestamps, or counters. Where the value space of a field is small and enumerable, such as "selected_model_tier" or "priority_class", a commitment does not provide meaningful confidentiality even when salted, because a verifier holding the salt can test all candidates. Producers SHOULD NOT rely on commitments alone to conceal such fields and SHOULD instead withhold the salt from parties not entitled to the value. 4.8.2. Commitment Fields commitments (object, OPTIONAL) A JSON object mapping committed field names to the base64url encoding of their commitments. Field names MUST correspond to fields present in the record. commitment_algorithm (string, OPTIONAL) The hash algorithm used for all commitments in this record. REQUIRED if "commitments" is present. Implementations MUST support "SHA-256". commitment_root (string, OPTIONAL) The base64url encoding of the Merkle root computed over the commitments in "commitments", sorted lexicographically by field name, using the leaf and interior node hashing rules of [RFC6962] as adopted in Section 7.6. The presence of "commitments" MUST NOT be interpreted as permission to omit the committed fields from the record itself. A record MAY carry both the field value and its commitment; a record intended for external disclosure MAY carry the commitment in place of the value, in which case "commitment_root" MUST be present and the record MUST be accompanied by the digest and signature fields of Section 4.7. Reilly Expires 9 March 2027 [Page 26] Internet-Draft RMRP September 2026 4.8.3. Disclosure Responses A Disclosure Response is a JSON object that reveals selected committed fields to a specific party: disclosure_id (string, REQUIRED) A UUID [RFC9562] identifying this disclosure. mrd_id (string, REQUIRED) The identifier of the record being disclosed. disclosed_fields (object, REQUIRED) A mapping of field name to an object containing "value" and "salt", where "salt" is base64url encoded. commitment_root (string, REQUIRED) The root as recorded in the source record. audience (string, OPTIONAL) An identifier for the party to whom this disclosure is made, for use in the Governance Event Record written per Section 9.6. A verifier of a Disclosure Response MUST recompute each disclosed field's commitment, MUST recompute "commitment_root" over the full commitment set from the source record, and MUST verify the source record's signature. Verification of a disclosed field alone, without the root and signature, establishes nothing. Producers MUST record the issuance of each Disclosure Response as a Governance Event Record. Disclosure is a governance act and is itself auditable. 4.9. Complexity Score Attestation The Complexity Score is the value on which tier escalation turns. Section 4.5 leaves its computation to the implementation and requires only that the method be documented. Documentation external to the record does not allow a verifier to determine which method produced a particular score, whether the method changed between two decisions, or whether the score was computed at all rather than asserted by the caller that benefits from escalation. Reilly Expires 9 March 2027 [Page 27] Internet-Draft RMRP September 2026 This subsection binds the scoring method to the decision it justified. It does not standardize scoring, which remains out of scope. 4.9.1. Scorer Attestation Fields scorer_id (string, OPTIONAL) A stable identifier for the scoring component that produced "complexity_score". scorer_version (string, OPTIONAL) The version of the scoring component. RECOMMENDED format is a semantic version string [semver]. scorer_digest (string, OPTIONAL) The base64url encoding of a digest over the scoring component's configuration, model weights identifier, rule set, or other artifact that determines its behavior. This field allows a verifier to detect that scoring behavior changed between two decisions without requiring disclosure of the scoring logic itself. scoring_method_class (string, OPTIONAL) The class of method used. MUST be one of: STATIC A fixed value assigned by configuration for the task type, with no per-request computation. HEURISTIC A deterministic rule-based computation over request features such as token count or structural indicators. CLASSIFIER A learned classifier separate from the models being routed to. LLM_JUDGE An inference call to a model, made for the purpose of scoring. Such a call is itself an inference request and MUST produce its own MRD. CALLER_ASSERTED The score was supplied by the caller and accepted without independent computation. Reilly Expires 9 March 2027 [Page 28] Internet-Draft RMRP September 2026 score_inputs_digest (string, OPTIONAL) The base64url encoding of a digest over the feature vector or derived input actually used for scoring. This value MUST NOT be computed over raw prompt content, consistent with the prohibition in Section 11.2 on including request content in RMRP records. Where the feature vector could itself reveal content, producers MUST commit to it per Section 4.8 rather than digest it directly. score_computed_at (string, OPTIONAL) The UTC timestamp at which the score was computed, where scoring occurred materially before MRD production. 4.9.2. Requirements on Caller-Asserted Scores A score with "scoring_method_class" of "CALLER_ASSERTED" MUST NOT by itself satisfy an RPD condition that authorizes ADVANCED tier selection or that raises "max_token_budget" above the value in the applicable "default_rule". A caller that can assert its own complexity can otherwise assert its way into the most expensive tier available, which makes the least-cost sufficiency principle in Section 1.3 unenforceable. An RPD rule MAY authorize escalation on a caller-asserted score where the rule also constrains "source_systems" to callers that are separately authorized for that tier. In that case the authorization derives from the source system identity, not from the asserted score. Where a Routing Engine accepts a caller-supplied score and overrides it with its own computation, both values MUST be recorded: the accepted value in "complexity_score" and the asserted value in "caller_asserted_score". caller_asserted_score (number, OPTIONAL) The complexity score supplied by the caller, where the Routing Engine computed a different value. MUST be in [0.0, 1.0]. 4.9.3. Deterministic Scoring and Replay Where "scoring_method_class" is "STATIC" or "HEURISTIC", the scoring component SHOULD be deterministic: the same inputs MUST produce the same score for a given "scorer_version" and "scorer_digest". Deterministic scoring permits the replay procedure in Section 6.7. Reilly Expires 9 March 2027 [Page 29] Internet-Draft RMRP September 2026 Where scoring is non-deterministic, including the "LLM_JUDGE" class, the Routing Engine MUST record "scoring_method_class" accurately and MUST NOT represent the resulting decision as replayable. A verifier encountering a non-deterministic scorer class can verify that a decision was consistent with the recorded score and policy, but cannot verify that the score was the correct assessment of the request. This distinction MUST be preserved in any conformance claim. 5. Routing Policy Document (RPD) 5.1. RPD Structure The Routing Policy Document is a structured, versioned JSON document that declares the rules by which a Routing Engine selects a target model for a given inference request. A conformant RPD MUST be a valid JSON object [RFC8259]. RPDs MUST be digitally signed by the issuing Policy Authority using a mechanism that allows the Routing Engine to verify authenticity and detect tampering. This specification RECOMMENDS the use of JSON Web Signatures (JWS) as defined in [RFC7515]. An RPD MUST be version-controlled. Routing Engines MUST record the specific RPD version applied to each routing decision in the MRD. Superseded RPD versions MUST be retained in the Audit Store for the retention period defined in Section 7.4. 5.2. RPD Field Definitions rmrp_version (string, REQUIRED) The RMRP protocol version string. MUST be "1.0" for this specification. policy_id (string, REQUIRED) A unique identifier for this Routing Policy Document within the deployment scope. Policy IDs MUST be stable across versions of the same policy; different versions of the same policy MUST share the same "policy_id". policy_version (string, REQUIRED) A semantic version string [semver] identifying this version of the policy. Format: MAJOR.MINOR.PATCH. A change to routing logic MUST increment MINOR or MAJOR. A change to metadata only MAY increment PATCH. Reilly Expires 9 March 2027 [Page 30] Internet-Draft RMRP September 2026 policy_name (string, REQUIRED) A human-readable name for this policy, suitable for display in audit interfaces. policy_authority_id (string, REQUIRED) The identifier of the Policy Authority that issued this document. effective_date (string, REQUIRED) The UTC timestamp from which this policy version is effective. Routing Engines MUST NOT apply a policy version prior to its effective date. expiration_date (string, OPTIONAL) The UTC timestamp after which this policy version is no longer valid. If present, Routing Engines MUST NOT apply this policy version after the expiration date and MUST trigger the fallback behavior defined in Section 5.4. scope (object, REQUIRED) Defines the set of source systems, cost centers, and task types to which this policy applies. scope.source_systems (array of strings, OPTIONAL) If present, this policy applies only to inference requests originating from the listed source system identifiers. If absent, the policy applies to all source systems unless overridden by a more specific policy. scope.cost_centers (array of strings, OPTIONAL) If present, this policy applies only to inference requests attributed to the listed cost center identifiers. scope.task_types (array of strings, OPTIONAL) If present, this policy applies only to inference requests of the listed task types. default_rule (object, REQUIRED) The routing rule applied when no other rule in the "rules" array produces a match. The default rule MUST specify at minimum a "target_tier" and a "max_token_budget". The default rule MUST NOT specify conditions. Reilly Expires 9 March 2027 [Page 31] Internet-Draft RMRP September 2026 rules (array of objects, REQUIRED) An ordered array of routing rules. MUST contain at least one rule. Rules MUST be evaluated in array order. The first rule whose conditions are satisfied by the inference request MUST be applied. Subsequent rules MUST NOT be evaluated after a match. Each rule object contains the following fields: rule_id (string, REQUIRED) A unique identifier for this rule within the RPD. Rule IDs MUST be stable across policy versions. rule_description (string, OPTIONAL) A human-readable description of the rule's intent. conditions (object, REQUIRED for non-default rules) A JSON object specifying the conditions under which this rule applies. All specified conditions MUST be satisfied for the rule to match (logical AND). If no conditions are specified, the rule matches all requests (and SHOULD only appear as the default rule). conditions.task_types (array of strings, OPTIONAL) The rule matches only if the request "task_type" is one of the listed values. conditions.complexity_min (number, OPTIONAL) The rule matches only if the request "complexity_score" is greater than or equal to this value. conditions.complexity_max (number, OPTIONAL) The rule matches only if the request "complexity_score" is less than this value. conditions.priority_classes (array of strings, OPTIONAL) The rule matches only if the request "priority_class" is one of the listed values. conditions.source_systems (array of strings, OPTIONAL) The rule matches only if the request "source_system" is one of the listed values. conditions.cost_centers (array of strings, OPTIONAL) The rule matches only if the request "cost_center" is one of the listed values. Reilly Expires 9 March 2027 [Page 32] Internet-Draft RMRP September 2026 conditions.chain_step_max (integer, OPTIONAL) The rule matches only if the request "chain_step" is less than or equal to this value. Used to constrain model tier selection in early pipeline steps. target_tier (string, REQUIRED) The model tier to which matching requests are routed. MUST be one of the normative tier values defined in Section 4.4. target_model_id (string, OPTIONAL) If present, the Routing Engine MUST route matching requests to this specific model, subject to availability. If the specified model is unavailable, fallback behavior applies. fallback_tier (string, OPTIONAL) The model tier to which the request is routed if the primary target model is unavailable. If absent, the Routing Engine MUST use the "default_rule" target as fallback. fallback_model_id (string, OPTIONAL) If present, the specific fallback model identifier. Evaluated after "fallback_tier". max_token_budget (integer, REQUIRED) The maximum total tokens (input plus output) authorized for requests matching this rule. A value of -1 indicates no ceiling is enforced by this rule. Routing Engines MUST enforce this constraint before dispatch. cost_ceiling_usd (number, OPTIONAL) The maximum estimated cost in USD authorized for a single inference request matching this rule. If present, the Routing Engine MUST reject or reroute requests whose estimated cost exceeds this value. Estimation method is implementation- defined and MUST be documented. audit_level (string, REQUIRED) The audit level class applied to routing events matching this rule. MUST be one of the normative audit level values defined in Section 7.3. allow_advanced_escalation (boolean, OPTIONAL) If true, and if the "target_tier" is STANDARD, the Routing Engine MAY escalate to ADVANCED tier if the complexity score exceeds the escalation_threshold. Default: false. Reilly Expires 9 March 2027 [Page 33] Internet-Draft RMRP September 2026 escalation_threshold (number, OPTIONAL) The complexity score threshold above which escalation to ADVANCED tier is permitted when "allow_advanced_escalation" is true. MUST be in [0.0, 1.0]. 5.3. Rule Evaluation Order A Conformant Router MUST evaluate RPD rules in the following order: 1. Filter out rules whose conditions do not match the request metadata as described in Section 5.2. 2. Apply the first matching rule in array order. 3. If no rule matches, apply the "default_rule". 4. If the "default_rule" is absent or invalid, the Routing Engine MUST reject the request and write an ALR with outcome "POLICY_ERROR". 5.4. Fallback Behavior The following conditions MUST trigger fallback behavior: o The selected model returns an HTTP 5xx error or equivalent transport-level failure. o The selected model is not resolvable in the Model Registry. o The estimated token count exceeds "max_token_budget". o The estimated cost exceeds "cost_ceiling_usd" (if present). o The RPD "expiration_date" has passed. When fallback is triggered, the Routing Engine MUST: 1. Attempt routing to the "fallback_model_id" (if specified) or the model at "fallback_tier". 2. Record the fallback event in the ALR with the original selection, the fallback target, and the reason for fallback. Reilly Expires 9 March 2027 [Page 34] Internet-Draft RMRP September 2026 3. If the fallback model also fails, the Routing Engine MUST return an error to the caller and write an ALR with outcome "ROUTING_FAILURE". 5.5. RPD Example The following is a non-normative example of a conformant RPD: { "rmrp_version": "1.0", "policy_id": "rpd-prod-engineering-v3", "policy_version": "3.2.1", "policy_name": "Engineering Production AI Routing Policy", "policy_authority_id": "pa-cto-office-001", "effective_date": "2026-04-01T00:00:00.000Z", "expiration_date": "2026-10-01T00:00:00.000Z", "scope": { "source_systems": ["api-gateway.internal", "agent-runner.internal"], "cost_centers": ["eng-ai", "eng-platform"], "task_types": null }, "default_rule": { "target_tier": "LIGHT", "max_token_budget": 2048, "audit_level": "STANDARD" }, "rules": [ { "rule_id": "R-01", "rule_description": "Batch embedding requests to LIGHT tier.", "conditions": { "task_types": ["EMBEDDING"], "priority_classes": ["BATCH"] }, "target_tier": "LIGHT", "max_token_budget": 4096, "audit_level": "MINIMAL" }, { "rule_id": "R-02", "rule_description": "Low-complexity classification to LIGHT.", "conditions": { "task_types": ["CLASSIFICATION", "EXTRACTION"], "complexity_max": 0.4 }, Reilly Expires 9 March 2027 [Page 35] Internet-Draft RMRP September 2026 "target_tier": "LIGHT", "max_token_budget": 1024, "audit_level": "MINIMAL" }, { "rule_id": "R-03", "rule_description": "Moderate generation to STANDARD tier.", "conditions": { "task_types": ["GENERATION", "SUMMARIZATION"], "complexity_min": 0.3, "complexity_max": 0.75 }, "target_tier": "STANDARD", "max_token_budget": 4096, "audit_level": "STANDARD" }, { "rule_id": "R-04", "rule_description": "CRITICAL priority requests to STANDARD minimum.", "conditions": { "priority_classes": ["CRITICAL"] }, "target_tier": "STANDARD", "fallback_tier": "ADVANCED", "max_token_budget": 8192, "audit_level": "FULL" }, { "rule_id": "R-05", "rule_description": "High-complexity AGENTIC and REASONING requests to STANDARD with escalation permitted.", "conditions": { "task_types": ["AGENTIC", "REASONING"], "complexity_min": 0.5 }, "target_tier": "STANDARD", "allow_advanced_escalation": true, "escalation_threshold": 0.75, "max_token_budget": 16384, "cost_ceiling_usd": 0.50, "audit_level": "FULL" }, { "rule_id": "R-06", "rule_description": "Multimodal requests to STANDARD tier.", Reilly Expires 9 March 2027 [Page 36] Internet-Draft RMRP September 2026 "conditions": { "task_types": ["MULTIMODAL"] }, "target_tier": "STANDARD", "max_token_budget": 8192, "audit_level": "STANDARD" }, { "rule_id": "R-07", "rule_description": "High-complexity REASONING above threshold to ADVANCED.", "conditions": { "task_types": ["REASONING"], "complexity_min": 0.75 }, "target_tier": "ADVANCED", "fallback_tier": "STANDARD", "max_token_budget": 8192, "cost_ceiling_usd": 1.00, "audit_level": "FULL" } ] } 5.6. RPD Canonicalization and Policy Digest Section 5.1 requires that an RPD be signed but does not specify the bytes over which the signature is computed. Two implementations that serialize the same policy differently will produce different signatures over the same policy, and a verifier cannot determine whether a signature failure indicates tampering or a serialization difference. The canonical form of an RPD is its JCS serialization [RFC8785] computed over the RPD object with the fields "policy_digest" and "policy_signature" removed. policy_digest (string, OPTIONAL) The base64url encoding of the digest of the canonical form of this RPD. policy_digest_algorithm (string, OPTIONAL) The algorithm used. REQUIRED if "policy_digest" is present. Implementations MUST support "SHA-256". Reilly Expires 9 March 2027 [Page 37] Internet-Draft RMRP September 2026 policy_signature (string, OPTIONAL) A detached signature over the canonical form, as a base64url encoded COSE_Sign1 structure [RFC9052] or JWS [RFC7515] with detached payload. This field carries the signature required by Section 5.1 where the deployment does not transport the RPD in an enveloping JWS. Where "policy_digest" is present, an MRD produced under that policy SHOULD record it: routing_policy_digest (string, OPTIONAL) The "policy_digest" of the RPD applied to produce this routing decision. Recording the digest, rather than only the "policy_id" and "policy_version", allows a verifier to detect that the content of a policy version changed after decisions were made under it. Version strings are assigned by the party whose behavior is being audited; digests are not. The same field MAY appear in the ALR and CAR for the same purpose. 5.7. Policy Revocation Section 9.3 permits Routing Engines to cache RPDs and bounds cache lifetime by the policy expiration date. An expiration date does not allow a Policy Authority to withdraw a policy that is found to be defective, over-permissive, or issued in error. Until the cache expires, engines continue to apply a policy the Policy Authority has repudiated. A Policy Authority SHOULD publish a Revocation Registry containing at least: registry_id (string, REQUIRED) A stable identifier for this registry. registry_version (integer, REQUIRED) A monotonically increasing version counter. A Routing Engine MUST NOT accept a registry whose version is lower than the highest version it has previously accepted, which prevents rollback to a state in which a revoked policy was still valid. published_at (string, REQUIRED) UTC timestamp of publication. Reilly Expires 9 March 2027 [Page 38] Internet-Draft RMRP September 2026 next_update_at (string, REQUIRED) The UTC timestamp by which the next registry version will be published. This value bounds how long a cached registry may be relied upon. revoked_policies (array of objects, REQUIRED) Each entry contains "policy_id", "policy_version", an OPTIONAL "policy_digest", "revoked_at", and a "reason" string. revoked_keys (array of objects, REQUIRED) Each entry contains "key_id", "revoked_at", "reason", and an OPTIONAL "not_valid_after" timestamp establishing the point from which signatures by that key MUST be rejected. See Section 9.5. registry_signature (string, REQUIRED) A signature over the canonical form of the registry, produced by the Policy Authority. A Routing Engine MUST check the Revocation Registry before applying a cached RPD and MUST NOT apply a policy version listed in "revoked_policies". A request that resolves only to a revoked policy MUST be rejected with error code RMRP-008 and an ALR written with outcome "POLICY_REVOKED". Where the registry cannot be retrieved and the cached registry has passed "next_update_at", a Routing Engine MUST apply the deployment's declared unavailability behavior, which MUST be one of: FAIL_CLOSED Reject requests with RMRP-008. RECOMMENDED, and REQUIRED at conformance level C3. FAIL_STATIC Continue to apply the last valid registry for a declared grace period not exceeding 24 hours, after which FAIL_CLOSED applies. Each request routed during the grace period MUST record "revocation_status": "STALE" in its ALR. A deployment MUST NOT silently proceed as though revocation checking had succeeded. An unchecked revocation state that is not recorded is indistinguishable in the audit trail from a checked one, which makes the control unauditable. Reilly Expires 9 March 2027 [Page 39] Internet-Draft RMRP September 2026 5.8. Additional Rule Fields Defined in This Revision The following OPTIONAL rule fields extend Section 5.2. A Routing Engine that does not implement a field MUST ignore it, and MUST NOT treat its presence as a match failure. A Policy Authority that requires enforcement of these fields SHOULD also set "min_conformance_level". chain_cost_ceiling_usd (number, OPTIONAL) The maximum aggregate cost authorized across all requests sharing a "chain_id" under this rule. Enforced per Section 8.6. chain_depth_max (integer, OPTIONAL) The maximum "chain_step" value for which this rule authorizes routing. Requests beyond this depth MUST be rejected with RMRP-009. See Section 6.8. window_budget_id (string, OPTIONAL) The identifier of the Budget Window Record against which requests matching this rule are counted. See Section 8.6. require_score_attestation (boolean, OPTIONAL) If true, the Routing Engine MUST populate the scorer attestation fields of Section 4.9.1 for requests matching this rule, and MUST NOT match this rule if it cannot. Default: false. min_scorer_class (array of strings, OPTIONAL) The set of "scoring_method_class" values acceptable for this rule. A rule authorizing ADVANCED tier SHOULD NOT include "CALLER_ASSERTED" in this set, consistent with Section 4.9.2. escalation_cooldown_seconds (integer, OPTIONAL) The minimum interval, in seconds, between successive escalations to ADVANCED tier within a single chain. See Section 6.8. max_escalations_per_chain (integer, OPTIONAL) The maximum number of ADVANCED tier escalations authorized within a single "chain_id". Reilly Expires 9 March 2027 [Page 40] Internet-Draft RMRP September 2026 min_conformance_level (string, OPTIONAL) The minimum conformance level (Section 15) a Routing Engine MUST satisfy to apply this rule. A Routing Engine that does not meet the stated level MUST NOT match the rule and MUST proceed to the next rule in array order. require_signature (boolean, OPTIONAL) If true, MRDs, ALRs, and CARs produced under this rule MUST carry the digest and signature fields of Sections 4.7, 7.6, and 8.1. Default: false. 6. Routing Execution Semantics 6.1. Pre-Routing Validation Upon receipt of an inference request, a Conformant Router MUST perform the following validation steps before proceeding: 1. Verify that a valid RPD is available and has not expired. If no valid RPD is resolvable for the request context, the Routing Engine MUST reject the request with error code RMRP-001 (Policy Not Found). 2. Verify that the "source_system" identifier is present and recognized. 3. Verify that a "cost_center" is associated with the request, either supplied by the caller or resolvable from the "source_system" identifier via configuration. 4. Verify that the "budget_authority_id" associated with the cost center is active and has not been revoked. 5. Verify that the "task_type" is a recognized value per Section 4.3 or a registered extension value. Requests that fail pre-routing validation MUST be rejected. Rejected requests MUST have an ALR written with outcome "VALIDATION_FAILURE" identifying which validation step failed. 6.2. Policy Resolution The Routing Engine MUST resolve the applicable RPD using the following procedure: Reilly Expires 9 March 2027 [Page 41] Internet-Draft RMRP September 2026 1. Identify all RPDs whose "scope" matches the request (source_system, cost_center, task_type). 2. If multiple RPDs match, apply the most specific RPD as determined by the number of scope constraints satisfied. 3. If specificity is equal across multiple matching RPDs, apply the RPD with the most recent "effective_date". 4. Record the selected "policy_id" and "policy_version" in the MRD. Implementations that maintain a single global RPD are not required to perform policy resolution but MUST still record the policy_id and policy_version in every MRD. 6.3. Model Selection After RPD resolution, the Routing Engine MUST: 1. Compute or accept a Complexity Score for the request. 2. Evaluate RPD rules in order per Section 5.3. 3. Identify the matched rule and extract "target_tier" and, if present, "target_model_id". 4. If "target_model_id" is specified, resolve it in the Model Registry and verify it is available. 5. If "target_model_id" is absent, select an available model from the Model Registry whose tier matches "target_tier". Model selection within a tier is implementation-defined. 6. Evaluate "allow_advanced_escalation" and "escalation_threshold" if present. 7. Verify that the estimated token count does not exceed "max_token_budget". 8. Verify that the estimated cost does not exceed "cost_ceiling_usd" if present. 9. Produce and record the MRD. Reilly Expires 9 March 2027 [Page 42] Internet-Draft RMRP September 2026 6.4. Request Dispatch The Routing Engine MUST dispatch the inference request to the selected model endpoint with the following requirements: o The MRD MUST be attached to the dispatched request. In HTTP transport, this MUST be accomplished via the "RMRP-MRD" header or request body attachment per Section 10.1. In other transports, attachment is per Section 10.3. o The "request_id" from the MRD MUST be forwarded to the model provider where the provider's API supports a correlation identifier. o All dispatch operations MUST be performed over encrypted transport (TLS 1.2 minimum, TLS 1.3 RECOMMENDED) per [RFC8446]. 6.5. Response Handling Upon receipt of an inference response, the Routing Engine MUST: 1. Record the actual input and output token counts from the response if available. 2. Record the end-to-end latency of the routing and inference operation. 3. Verify that actual token consumption did not exceed "max_token_budget". If it did, this MUST be recorded in the ALR as a budget overrun event. 4. Produce and finalize the ALR and CAR records. 5. Write completed ALR and CAR to the Audit Store. 6. Return the inference response to the caller with the "mrd_id" attached for correlation. 6.6. Error and Fallback Handling Error codes defined by this specification: RMRP-001 Policy Not Found. No valid RPD is resolvable for the request context. Reilly Expires 9 March 2027 [Page 43] Internet-Draft RMRP September 2026 RMRP-002 Validation Failure. The request failed pre-routing validation. Details MUST be included in the ALR. RMRP-003 Budget Exceeded. The estimated or actual token or cost consumption exceeds authorized limits. RMRP-004 Model Unavailable. The selected model is not reachable or returned a transport-level error. RMRP-005 Fallback Exhausted. All fallback options have been attempted and failed. RMRP-006 Policy Expired. The applicable RPD has passed its expiration date. RMRP-007 Audit Store Failure. The Routing Engine was unable to write the ALR or CAR to the Audit Store. This is a CRITICAL error; the Routing Engine SHOULD halt request processing until Audit Store availability is restored. All error events MUST result in an ALR record. Routing Engines MUST NOT silently suppress routing errors. 6.7. Deterministic Replay of Routing Decisions A routing decision is replayable if an independent party holding the MRD, the RPD version identified in it, and the recorded scoring inputs can recompute the same rule match and the same target tier. Replay converts the "routing_rationale" field from an assertion by the audited system into a checkable claim. A Verifier performs replay as follows: 1. Retrieve the RPD identified by "routing_policy_id" and "routing_policy_version". Where "routing_policy_digest" is present, verify that the retrieved policy produces that digest. If it does not, replay MUST fail with a policy mismatch finding. 2. Verify the RPD signature per Section 5.6 and confirm the policy version was not revoked as of the MRD "timestamp" per Section 5.7. Reilly Expires 9 March 2027 [Page 44] Internet-Draft RMRP September 2026 3. Evaluate the rules in the RPD, in array order, against the values recorded in the MRD: "task_type", "complexity_score", "priority_class", "source_system", "cost_center", and "chain_step". 4. Compare the first matching rule to the "matched_rule_id" recorded in the ALR. 5. Compare the resulting "target_tier", after applying any escalation authorized by "allow_advanced_escalation" and "escalation_threshold", to "selected_model_tier". 6. Where "scoring_method_class" is "STATIC" or "HEURISTIC" and the scoring inputs are available, recompute "complexity_score" and compare. A Conformant Router at level C2 or above MUST produce records sufficient for steps 1 through 5. Step 6 is possible only where scoring is deterministic per Section 4.9.3. Where replay produces a different rule match or a different tier than the record states, the discrepancy MUST be recorded as a Governance Event Record (Section 9.6) with event type "REPLAY_DISCREPANCY". A replay discrepancy is not by itself evidence of misconduct: policy retrieval errors, clock skew, and registry inconsistency produce the same signal. It is evidence that the routing decision is not currently accounted for, which is the condition an audit is meant to detect. 6.8. Chain Depth, Recursion, and Escalation Damping Section 4.3 notes that AGENTIC requests carry potential for recursive resource consumption, and Section 5.2 provides "chain_step_max" as a condition. Neither bounds what an agent actually does: a pipeline that issues one thousand requests, each individually within "max_token_budget" and "cost_ceiling_usd", satisfies every per-request control in -00 while consuming one thousand times the intended budget. A Conformant Router MUST apply the following controls to requests carrying a "chain_id". Reilly Expires 9 March 2027 [Page 45] Internet-Draft RMRP September 2026 6.8.1. Depth Bounding Where the matched rule specifies "chain_depth_max", the Routing Engine MUST reject requests whose "chain_step" exceeds that value with error code RMRP-009 and an ALR with outcome "CHAIN_LIMIT_EXCEEDED". Where no rule specifies a depth limit, the Routing Engine MUST apply a deployment-wide default. An unbounded default is a conformance violation at level C1 and above. The default value is implementation-defined and MUST be documented. A Routing Engine MUST NOT accept a "chain_step" value from the caller without validation where the deployment can determine the step independently. Where the step is caller-supplied, the Routing Engine MUST count observed requests per "chain_id" and MUST use the greater of the observed count and the asserted step for limit enforcement. A caller that can reset its own step counter can defeat depth bounding entirely. 6.8.2. Escalation Damping Where the matched rule specifies "escalation_cooldown_seconds", the Routing Engine MUST NOT escalate a request in the same chain to ADVANCED tier within that interval of a prior escalation in that chain. A request that would escalate during the cooldown MUST be routed at the rule's "target_tier" instead, and the suppression MUST be recorded in the ALR field "escalation_suppressed". Where the matched rule specifies "max_escalations_per_chain", the Routing Engine MUST reject or downgrade further escalations once the count is reached, and MUST record which action it took. Escalation controls SHOULD apply hysteresis: where a chain has escalated and subsequently returns scores below the escalation threshold, the Routing Engine SHOULD require the score to fall materially below that threshold before treating the chain as de-escalated, rather than oscillating at the boundary. A deployment SHOULD document the hysteresis band it applies. 6.8.3. Chain Fields Added to Records escalation_suppressed (boolean, OPTIONAL) Present in the ALR. True where an escalation authorized by the matched rule was withheld by a control in this subsection. Reilly Expires 9 March 2027 [Page 46] Internet-Draft RMRP September 2026 chain_escalation_count (integer, OPTIONAL) The number of ADVANCED tier escalations recorded for this "chain_id" prior to this request. chain_observed_step (integer, OPTIONAL) The step count observed by the Routing Engine, where it differs from the caller-asserted "chain_step". chain_root_request_id (string, OPTIONAL) The "request_id" of the first request in the chain. Recording the root allows an auditor to reconstruct a pipeline whose intermediate steps were routed by different engines. 6.9. Additional Error Codes Defined in This Revision The following error codes extend Section 6.6. The codes defined in -00 retain their meanings unchanged. RMRP-008 Policy Revoked. The applicable RPD version appears in the Revocation Registry, or revocation state could not be established under FAIL_CLOSED behavior. See Section 5.7. RMRP-009 Chain Limit Exceeded. The request exceeds "chain_depth_max" or "max_escalations_per_chain" for the matched rule. See Section 6.8. RMRP-010 Attestation Required. The matched rule sets "require_score_attestation" or "require_signature" and the Routing Engine cannot satisfy it. See Sections 4.9 and 5.8. RMRP-011 Chain Budget Exceeded. Aggregate expenditure for the "chain_id" exceeds "chain_cost_ceiling_usd". See Section 8.6. RMRP-012 Window Budget Exceeded. Aggregate expenditure for the applicable Budget Window Record exceeds its authorized ceiling. See Section 8.6. RMRP-013 Key Revoked. A signature required for policy or record verification was produced by a key listed in the Revocation Registry as of the relevant time. See Section 9.5. RMRP-014 Verification Failure. A digest or signature over an RMRP record or policy did not verify. See Sections 4.7 and 5.6. Reilly Expires 9 March 2027 [Page 47] Internet-Draft RMRP September 2026 All error events MUST result in an ALR record, including those introduced by this revision. Where an error occurs before a policy is resolved, the ALR MUST still be written with the fields available, and "matched_rule_id" MUST be absent or null as specified in Section 7.2. 7. Audit Trail Requirements 7.1. Audit Log Record (ALR) Structure A Conformant Router MUST produce one Audit Log Record for each routing event. The ALR is a JSON object [RFC8259]. Each ALR MUST be written to the Audit Store before the inference response is returned to the caller. ALRs MUST be immutable after writing. The Audit Store MUST be append-only or equivalent with respect to routing records. Implementations MAY use cryptographic hash chaining, blockchain anchoring, or other mechanisms to provide tamper-evidence for the ALR sequence. 7.2. ALR Field Definitions rmrp_version (string, REQUIRED) RMRP protocol version. MUST be "1.0". alr_id (string, REQUIRED) A UUID [RFC9562] uniquely identifying this ALR. mrd_id (string, REQUIRED) The "mrd_id" of the MRD associated with this routing event. request_id (string, REQUIRED) The "request_id" of the inference request. timestamp_routing_start (string, REQUIRED) UTC timestamp at which the Routing Engine began processing the request. timestamp_dispatch (string, REQUIRED) UTC timestamp at which the Routing Engine dispatched the request to the selected model. Reilly Expires 9 March 2027 [Page 48] Internet-Draft RMRP September 2026 timestamp_response (string, OPTIONAL) UTC timestamp at which the Routing Engine received the inference response. Absent if the request failed before a response was received. timestamp_alr_written (string, REQUIRED) UTC timestamp at which the ALR was committed to the Audit Store. routing_policy_id (string, REQUIRED) The "policy_id" of the RPD applied. routing_policy_version (string, REQUIRED) The "policy_version" of the RPD applied. matched_rule_id (string, REQUIRED) The "rule_id" of the RPD rule that matched this request. MUST be "default_rule" if the default rule was applied. MUST be absent or null if outcome is "VALIDATION_FAILURE" or "POLICY_ERROR". source_system (string, REQUIRED) The source system identifier from the MRD. task_type (string, REQUIRED) The task type from the MRD. complexity_score (number, REQUIRED) The complexity score from the MRD. priority_class (string, REQUIRED) The priority class from the MRD. cost_center (string, REQUIRED) The cost center from the MRD. budget_authority_id (string, REQUIRED) The budget authority from the MRD. selected_model_id (string, REQUIRED) The Model Identifier selected. selected_model_tier (string, REQUIRED) The model tier selected. Reilly Expires 9 March 2027 [Page 49] Internet-Draft RMRP September 2026 fallback_triggered (boolean, REQUIRED) True if fallback routing was triggered during this event. fallback_reason (string, OPTIONAL) The reason fallback was triggered. REQUIRED if "fallback_triggered" is true. fallback_model_id (string, OPTIONAL) The Model Identifier used for fallback. REQUIRED if "fallback_triggered" is true. outcome (string, REQUIRED) The outcome of the routing event. MUST be one of: "SUCCESS", "FALLBACK_SUCCESS", "VALIDATION_FAILURE", "POLICY_ERROR", "ROUTING_FAILURE", "BUDGET_EXCEEDED", "POLICY_EXPIRED". error_code (string, OPTIONAL) The RMRP error code (e.g., "RMRP-004") if outcome is not "SUCCESS" or "FALLBACK_SUCCESS". error_detail (string, OPTIONAL) A human-readable description of the error. actual_input_tokens (integer, OPTIONAL) Actual input token count from the inference response. actual_output_tokens (integer, OPTIONAL) Actual output token count from the inference response. actual_total_tokens (integer, OPTIONAL) Sum of actual_input_tokens and actual_output_tokens. budget_overrun (boolean, REQUIRED) True if actual_total_tokens exceeded max_token_budget. latency_routing_ms (integer, OPTIONAL) Duration in milliseconds from routing start to dispatch. latency_inference_ms (integer, OPTIONAL) Duration in milliseconds from dispatch to response receipt. latency_total_ms (integer, OPTIONAL) Total duration in milliseconds from routing start to ALR write. Reilly Expires 9 March 2027 [Page 50] Internet-Draft RMRP September 2026 audit_level (string, REQUIRED) The audit level class applied to this event. chain_id (string, OPTIONAL) Chain identifier, if applicable. chain_step (integer, OPTIONAL) Chain step, if applicable. previous_alr_id (string, OPTIONAL) The "alr_id" of the immediately preceding ALR in the Audit Store. Used for hash chaining. RECOMMENDED for implementations that implement tamper-evident audit logs. alr_hash (string, OPTIONAL) A cryptographic hash of the canonical serialization of this ALR, computed prior to writing the "alr_hash" field itself. Hash algorithm MUST be identified in the "alr_hash_algorithm" field if present. alr_hash_algorithm (string, OPTIONAL) The hash algorithm used to compute "alr_hash". RECOMMENDED values: "SHA-256", "SHA3-512", "BLAKE3". 7.3. Audit Level Classes MINIMAL Required for low-risk, high-volume routing events such as batch EMBEDDING tasks. ALR MUST include all REQUIRED fields. Token and latency fields are OPTIONAL. STANDARD Default audit level for interactive workloads. ALR MUST include all REQUIRED fields and all timing fields. FULL Required for ADVANCED tier routing, CRITICAL priority requests, high-cost requests, and any request where "allow_advanced_escalation" is true. ALR MUST include all defined fields. Implementations SHOULD compute and record "alr_hash" for FULL-level records. 7.4. Retention Requirements ALRs and CARs MUST be retained for a minimum of 90 days. Implementations operating in regulated environments SHOULD retain records for a minimum of 7 years or the applicable regulatory retention period, whichever is longer. Reilly Expires 9 March 2027 [Page 51] Internet-Draft RMRP September 2026 Superseded RPD versions MUST be retained for the same period as the ALRs that reference them. Audit Store implementations MUST support retrieval of ALRs by "mrd_id", "request_id", "chain_id", "cost_center", "routing_policy_id", and date range. 7.5. ALR Example The following is a non-normative example of a conformant ALR: Reilly Expires 9 March 2027 [Page 52] Internet-Draft RMRP September 2026 { "rmrp_version": "1.0", "alr_id": "7f3b2c1a-0001-4d2e-9f8b-112233445566", "mrd_id": "550e8400-e29b-41d4-a716-446655440000", "request_id": "req-20260428-00192", "timestamp_routing_start": "2026-04-28T17:00:00.000Z", "timestamp_dispatch": "2026-04-28T17:00:00.032Z", "timestamp_response": "2026-04-28T17:00:02.187Z", "timestamp_alr_written": "2026-04-28T17:00:02.201Z", "routing_policy_id": "rpd-prod-engineering-v3", "routing_policy_version": "3.2.1", "matched_rule_id": "R-07", "source_system": "api-gateway.internal", "task_type": "REASONING", "complexity_score": 0.82, "priority_class": "HIGH", "cost_center": "eng-ai", "budget_authority_id": "ba-vp-engineering-001", "selected_model_id": "provider-alpha/model-advanced-v2", "selected_model_tier": "ADVANCED", "fallback_triggered": false, "outcome": "SUCCESS", "actual_input_tokens": 2041, "actual_output_tokens": 987, "actual_total_tokens": 3028, "budget_overrun": false, "latency_routing_ms": 32, "latency_inference_ms": 2155, "latency_total_ms": 2201, "audit_level": "FULL", "chain_id": "chain-pipeline-20260428-00041", "chain_step": 2, "alr_hash_algorithm": "SHA-256", "alr_hash": "e3b0c44298fc1c149afb4c8996fb92427ae41e4649b934ca495991b7852b855" } 7.6. Additional ALR Fields and Outcome Values The outcome values enumerated in Section 7.2 remain valid and unchanged. The following additional values are defined for the "outcome" field, corresponding to the error codes added in Section 6.9: Reilly Expires 9 March 2027 [Page 53] Internet-Draft RMRP September 2026 "POLICY_REVOKED" The applicable policy version was revoked, or revocation state could not be established under FAIL_CLOSED. "CHAIN_LIMIT_EXCEEDED" A chain depth or escalation limit was reached. "ATTESTATION_REQUIRED" A rule required attestation or signature the Routing Engine could not provide. "VERIFICATION_FAILURE" A digest or signature check failed. A consumer that does not recognize an outcome value MUST treat the record as a non-success outcome rather than discarding it. Discarding unrecognized failure records suppresses exactly the events an audit exists to surface. The following additional ALR fields are defined: alr_digest (string, OPTIONAL) The base64url encoding of the digest over the canonical form of this ALR, computed per Section 4.7.1 with the fields "alr_digest" and "alr_signature" removed. Where both "alr_hash" as defined in -00 and "alr_digest" are present, they MUST be computed over the same content, and a verifier MUST treat a disagreement between them as a verification failure. alr_signature (string, OPTIONAL) A detached signature over the canonical form of this ALR. signer_key_id (string, OPTIONAL) The key identifier used for "alr_signature". REQUIRED if "alr_signature" is present. revocation_status (string, OPTIONAL) One of "CHECKED", "STALE", or "UNAVAILABLE", recording the state of revocation checking at the time of routing per Section 5.7. mrd_digest (string, OPTIONAL) The "mrd_digest" of the associated MRD, binding the audit record to the exact decision record it describes. Recording the "mrd_id" alone binds the ALR to an identifier, not to content. Reilly Expires 9 March 2027 [Page 54] Internet-Draft RMRP September 2026 routing_policy_digest (string, OPTIONAL) The digest of the applied policy, per Section 5.6. scorer_id, scorer_version, scorer_digest, scoring_method_class (strings, OPTIONAL) The scorer attestation fields from Section 4.9.1, copied from the MRD. Copying them into the ALR allows an auditor querying only the Audit Store to detect a change in scoring behavior. 7.7. Merkle Construction and Inclusion Proofs Section 7.2 provides "previous_alr_id" and "alr_hash" for hash chaining. A linear chain permits verification of the whole sequence by a party that holds the whole sequence. It does not permit a party holding one record to verify that record's membership without retrieving everything written since. For an Audit Store holding hundreds of millions of routing events, that is not a practical verification path. A Conformant Router at level C4, and any deployment publishing Checkpoints, MUST commit ALRs to a Merkle tree constructed per [RFC6962]: o Leaf hash: H(0x00 || canonical_form_of_ALR) o Interior hash: H(0x01 || left_subtree_hash || right_subtree_hash) where H is the algorithm named in the tree head, and the canonical form is computed per Section 4.7.1 with signature fields removed. The domain separation prefixes are REQUIRED; omitting them permits a leaf to be presented as an interior node. A Tree Head is a JSON object with fields "tree_size" (integer), "root_hash" (base64url), "hash_algorithm" (string), "published_at" (timestamp), and "signature". An Inclusion Proof is a JSON object with fields "alr_id", "leaf_index" (integer), "tree_size" (integer), "audit_path" (array of base64url hashes), and "root_hash". A verifier recomputes the root from the leaf and the audit path and compares it to a Tree Head it obtained independently. Reilly Expires 9 March 2027 [Page 55] Internet-Draft RMRP September 2026 Implementations SHOULD support consistency proofs between two tree sizes so that a verifier holding an earlier Tree Head can confirm the later tree is an append-only extension of it. Where a deployment issues Tree Heads at high frequency, batching techniques for subtree proofs MAY be applied [BULK-SUBTREE-PROOFS]. The Merkle construction supplements, and does not replace, the "previous_alr_id" chaining in Section 7.2. Deployments MAY maintain both. 7.8. Checkpoints and External Anchoring A tree head signed by the same operator that controls the Audit Store bounds nothing that operator could not also alter. Value comes from publishing the head where the operator cannot retroactively change it. A Checkpoint is a Tree Head that has been published to one or more targets outside the administrative control of the deployment. A Checkpoint record contains the Tree Head fields together with: checkpoint_id (string, REQUIRED) A UUID identifying this checkpoint. anchor_targets (array of objects, REQUIRED) Each entry contains "target_type", "target_reference", and "anchor_state". "target_type" is an opaque string naming the class of target, such as a timestamping service, a transparency log, an archival deposit, or a distributed ledger. RMRP does not require any particular target and does not require a distributed ledger. anchor_state (string, REQUIRED per target) One of "PENDING" or "ATTESTED". A checkpoint whose anchor has been submitted but not yet confirmed MUST be recorded as "PENDING" and MUST NOT be presented as attested. Presenting a pending anchor as complete overstates the assurance actually held. checkpoint_interval_seconds (integer, RECOMMENDED) The interval at which checkpoints are published. This value bounds the window in which undetected modification of the Audit Store is possible, and SHOULD be stated in any conformance claim, because the assurance provided is a function of that window. Reilly Expires 9 March 2027 [Page 56] Internet-Draft RMRP September 2026 Where a deployment publishes to more than one target, a verifier MUST treat the checkpoint as attested only for targets in the "ATTESTED" state. Anchoring to multiple independent targets raises the cost of a successful retroactive alteration; it does not eliminate it, and MUST NOT be described as making records immutable. 7.9. Hash Migration and Bridging Records Audit records retained for seven years or longer will outlive the hash algorithms used to commit to them. A deployment that simply re-hashes its archive under a new algorithm loses the binding between the new digests and the anchors published under the old one. A Bridging Record preserves that binding: bridging_record_id (string, REQUIRED) A UUID identifying this record. covered_range (object, REQUIRED) The range of records covered, expressed as a leaf index range or a timestamp range. legacy_algorithm (string, REQUIRED) The retiring algorithm. legacy_root_hash (string, REQUIRED) The root over the covered range under the retiring algorithm. replacement_algorithm (string, REQUIRED) The replacement algorithm. replacement_root_hash (string, REQUIRED) The root over the same covered range under the replacement algorithm. bridged_at (string, REQUIRED) UTC timestamp of the bridging computation. signature (string, REQUIRED) A signature over the canonical form of the bridging record. Reilly Expires 9 March 2027 [Page 57] Internet-Draft RMRP September 2026 A Bridging Record MUST be produced while the retiring algorithm is still considered sound. A bridge computed after the retiring algorithm is broken proves only that someone computed two roots, not that the covered records are the ones originally committed. Deployments SHOULD anchor Bridging Records per Section 7.8. 7.10. Routing Completeness Attestation (RCA) Every mechanism above protects records that exist. None of them detects a routing event that was executed and never recorded. Selective omission is the most economical way to defeat an audit of AI expenditure, because the omitted records are exactly the ones that would show the policy being bypassed. A Conformant Router at level C3 and above MUST periodically produce a Routing Completeness Attestation: rca_id (string, REQUIRED) A UUID identifying this attestation. window_start, window_end (strings, REQUIRED) The UTC bounds of the attested window. engine_id (string, REQUIRED) The identifier of the Routing Engine making the attestation. routing_event_count (integer, REQUIRED) The total number of routing events the engine processed in the window, including rejected and failed events. alr_count (integer, REQUIRED) The number of ALRs written to the Audit Store for the window. Where this differs from "routing_event_count", the difference MUST be explained in "discrepancy_note". counts_by_outcome (object, REQUIRED) A mapping of outcome value to count. counts_by_tier (object, REQUIRED) A mapping of model tier to count. Tier counts allow an auditor to compare declared ADVANCED tier usage against provider billing without inspecting individual records. tree_head (object, REQUIRED) The Tree Head covering the window per Section 7.7. Reilly Expires 9 March 2027 [Page 58] Internet-Draft RMRP September 2026 previous_rca_id (string, REQUIRED after the first attestation) The identifier of the preceding attestation, so that a missing window is detectable as a gap in the attestation sequence rather than only as an absence of records. discrepancy_note (string, OPTIONAL) A description of any difference between processed events and written records. signature (string, REQUIRED) A signature over the canonical form of the attestation, using a Routing Engine key distinct from any Policy Authority key. An RCA is a statement by the audited system about its own completeness. It does not prove completeness. Its value is that it converts silent omission into a false signed statement, which is a materially different act with materially different consequences, and it makes a gap in the attestation sequence visible without access to the underlying records. RCAs MUST be retained for the retention period in Section 7.4 and SHOULD be anchored per Section 7.8. 8. Cost Attribution Framework 8.1. Cost Attribution Record (CAR) A Conformant Router MUST produce one Cost Attribution Record for each routing event that results in an inference response, whether successful or via fallback. CARs MUST NOT be produced for requests that fail before dispatch. The CAR is a JSON object [RFC8259]. CARs MUST be written to the Audit Store concurrently with or immediately following the associated ALR. 8.2. CAR Field Definitions rmrp_version (string, REQUIRED) RMRP protocol version. MUST be "1.0". car_id (string, REQUIRED) A UUID [RFC9562] uniquely identifying this CAR. mrd_id (string, REQUIRED) The "mrd_id" of the associated MRD. Reilly Expires 9 March 2027 [Page 59] Internet-Draft RMRP September 2026 alr_id (string, REQUIRED) The "alr_id" of the associated ALR. request_id (string, REQUIRED) The inference request identifier. timestamp (string, REQUIRED) UTC timestamp of CAR production. cost_center (string, REQUIRED) The cost center to which this expenditure is attributed. budget_authority_id (string, REQUIRED) The Budget Authority identifier. routing_policy_id (string, REQUIRED) The RPD policy identifier. routing_policy_version (string, REQUIRED) The RPD policy version. matched_rule_id (string, REQUIRED) The rule that authorized this expenditure. model_provider (string, OPTIONAL) An opaque identifier for the AI model provider. This field is for organizational attribution and does not affect protocol behavior. selected_model_id (string, REQUIRED) The Model Identifier selected. selected_model_tier (string, REQUIRED) The model tier used for this request. actual_input_tokens (integer, OPTIONAL) Actual input token count. actual_output_tokens (integer, OPTIONAL) Actual output token count. actual_total_tokens (integer, OPTIONAL) Total actual token count. Reilly Expires 9 March 2027 [Page 60] Internet-Draft RMRP September 2026 estimated_cost_usd (number, OPTIONAL) The estimated cost in USD at the time of routing, as computed by the Routing Engine. Estimation method is implementation-defined and MUST be documented. actual_cost_usd (number, OPTIONAL) The actual cost in USD as reported by the model provider or computed from actual token counts and known pricing. cost_computation_method (string, OPTIONAL) A description of the method used to compute cost figures. MUST be present if either "estimated_cost_usd" or "actual_cost_usd" is present. authorized_cost_ceiling_usd (number, OPTIONAL) The "cost_ceiling_usd" from the matched RPD rule, if any. ceiling_exceeded (boolean, REQUIRED) True if "actual_cost_usd" exceeds "authorized_cost_ceiling_usd". False if no ceiling was defined. chain_id (string, OPTIONAL) Chain identifier, if applicable. chain_step (integer, OPTIONAL) Chain step, if applicable. 8.3. Budget Authority Chain The Budget Authority Chain is the traceable sequence of authorization that links an inference expenditure to the organizational entity responsible for it. In RMRP, this chain is represented implicitly through the combination of: o The "cost_center" field, which identifies the organizational unit incurring the cost. o The "budget_authority_id" field, which identifies the entity that approved inference expenditure for that cost center. o The "routing_policy_id" and "routing_policy_version" fields, which identify the policy document that authorized the specific routing decision. o The "policy_authority_id" field in the RPD, which identifies the entity that issued the policy. Reilly Expires 9 March 2027 [Page 61] Internet-Draft RMRP September 2026 External budget management systems consuming CAR records MUST be able to reconstruct the full authorization chain from these fields. RMRP does not specify the implementation of budget management systems. 8.4. Cost Ceiling Enforcement When a "cost_ceiling_usd" is defined in the matched RPD rule, the Routing Engine MUST: 1. Compute or obtain an estimated cost for the request before dispatch. 2. Compare the estimated cost to the "cost_ceiling_usd". 3. If the estimated cost exceeds the ceiling, the Routing Engine MUST attempt to reroute to the "fallback_tier" or "fallback_model_id" as specified in Section 5.4. 4. If fallback also exceeds the ceiling, the Routing Engine MUST reject the request with error code RMRP-003 and write an ALR with outcome "BUDGET_EXCEEDED". Cost ceiling enforcement based on estimated cost is a pre-dispatch control. Post-dispatch overruns MUST be recorded in the CAR as "ceiling_exceeded: true" but do not retroactively fail the completed request. 8.5. CAR Example The following is a non-normative example of a conformant CAR: Reilly Expires 9 March 2027 [Page 62] Internet-Draft RMRP September 2026 { "rmrp_version": "1.0", "car_id": "ab12cd34-5678-4ef0-9012-abcdef012345", "mrd_id": "550e8400-e29b-41d4-a716-446655440000", "alr_id": "7f3b2c1a-0001-4d2e-9f8b-112233445566", "request_id": "req-20260428-00192", "timestamp": "2026-04-28T17:00:02.205Z", "cost_center": "eng-ai", "budget_authority_id": "ba-vp-engineering-001", "routing_policy_id": "rpd-prod-engineering-v3", "routing_policy_version": "3.2.1", "matched_rule_id": "R-07", "model_provider": "provider-alpha", "selected_model_id": "provider-alpha/model-advanced-v2", "selected_model_tier": "ADVANCED", "actual_input_tokens": 2041, "actual_output_tokens": 987, "actual_total_tokens": 3028, "estimated_cost_usd": 0.38, "actual_cost_usd": 0.41, "cost_computation_method": "provider_api_reported", "authorized_cost_ceiling_usd": 1.00, "ceiling_exceeded": false, "chain_id": "chain-pipeline-20260428-00041", "chain_step": 2 } 8.6. Chain-Level and Window-Level Budget Enforcement Section 8.4 defines a per-request control. A per-request control does not bound a pipeline. Under -00 alone, an agentic workflow that issues requests within every individual ceiling can exhaust an annual budget in an afternoon without triggering a single BUDGET_EXCEEDED outcome, and every record of that expenditure will be conformant. This subsection defines aggregate enforcement. 8.6.1. Budget Window Record (BWR) window_budget_id (string, REQUIRED) A stable identifier for this budget window definition. cost_center (string, REQUIRED) The cost center to which the window applies. Reilly Expires 9 March 2027 [Page 63] Internet-Draft RMRP September 2026 budget_authority_id (string, REQUIRED) The Budget Authority that authorized the window ceiling. window_start, window_end (strings, REQUIRED) The UTC bounds of the window. authorized_ceiling_usd (number, REQUIRED) The maximum aggregate expenditure authorized for the window. consumed_usd (number, REQUIRED) The aggregate expenditure recorded against the window at the time this record was produced. reserved_usd (number, OPTIONAL) Expenditure for requests dispatched but not yet reconciled. Reservations prevent concurrent routers from each observing the same remaining headroom and collectively exceeding it. soft_threshold_pct (number, OPTIONAL) A percentage of the ceiling at which the Routing Engine SHOULD emit a Governance Event Record but continue routing. overrun_policy (string, REQUIRED) One of "REJECT", "DOWNGRADE", or "ALERT_ONLY". REJECT Requests that would exceed the ceiling are rejected with RMRP-012. DOWNGRADE Requests are routed at the lowest tier available for the task type, and "escalation_suppressed" is recorded. ALERT_ONLY Requests proceed and a Governance Event Record is written. This value MUST NOT be used for windows whose ceiling represents a hard financial authorization, and its use MUST be recorded in any conformance claim. signature (string, OPTIONAL) A signature over the canonical form of the record. 8.6.2. Enforcement Procedure Where the matched rule specifies "window_budget_id" or "chain_cost_ceiling_usd", the Routing Engine MUST, before dispatch: Reilly Expires 9 March 2027 [Page 64] Internet-Draft RMRP September 2026 1. Obtain the current "consumed_usd" and "reserved_usd" for the applicable window, and the aggregate recorded cost for the "chain_id" where a chain ceiling applies. 2. Add the estimated cost of the current request. 3. Where the sum exceeds "chain_cost_ceiling_usd", apply RMRP-011 with outcome "BUDGET_EXCEEDED". Where the sum exceeds "authorized_ceiling_usd", apply the window's "overrun_policy" and, where that policy is REJECT, apply RMRP-012. 4. Reserve the estimated cost against the window before dispatch, and reconcile the reservation to actual cost when the CAR is written. Where the Budget Window Service is unavailable, the Routing Engine MUST apply the deployment's declared unavailability behavior. Where that behavior permits routing to continue, each affected ALR MUST record "budget_state": "UNVERIFIED". A control that silently stops enforcing is worse than no control, because the audit trail continues to imply enforcement. 8.6.3. Fields Added to the CAR window_budget_id (string, OPTIONAL) The window against which this expenditure was counted. window_consumed_after_usd (number, OPTIONAL) The window's consumed total after this expenditure was applied, providing a per-record view of aggregate consumption without requiring the verifier to sum every record. chain_consumed_after_usd (number, OPTIONAL) The chain's aggregate cost after this expenditure. car_digest, car_signature, signer_key_id (strings, OPTIONAL) Integrity and signature fields for the CAR, computed per Section 4.7 with the digest and signature fields removed from the canonical form. Reilly Expires 9 March 2027 [Page 65] Internet-Draft RMRP September 2026 8.7. Cost Reconciliation Record (CRR) Both "estimated_cost_usd" and "actual_cost_usd" in Section 8.2 are computed or reported through the same system whose spending is being governed. Where "cost_computation_method" is "provider_api_reported", the value is what the provider's API returned at request time, which is not the same as what the provider invoiced. A deployment SHOULD periodically produce a Cost Reconciliation Record: crr_id (string, REQUIRED) A UUID identifying this record. period_start, period_end (strings, REQUIRED) The UTC bounds of the reconciled period. cost_center (string, REQUIRED) The cost center reconciled. model_provider (string, REQUIRED) The provider whose charges are reconciled. car_count (integer, REQUIRED) The number of CARs included. recorded_cost_usd (number, REQUIRED) The sum of "actual_cost_usd" across the included CARs. provider_reported_cost_usd (number, REQUIRED) The cost reported by the provider for the same period and scope. variance_usd (number, REQUIRED) The difference between the two figures. unattributed_cost_usd (number, OPTIONAL) Provider-reported cost for which no CAR exists. A non-zero value indicates inference expenditure that bypassed the governance layer entirely, which is the condition the Cost Traceability principle in Section 1.3 exists to prevent. variance_explanation (string, OPTIONAL) A description of known causes, such as provider rounding, cached-token pricing, or committed-use discounts. Reilly Expires 9 March 2027 [Page 66] Internet-Draft RMRP September 2026 signature (string, OPTIONAL) A signature over the canonical form of the record. A non-zero "unattributed_cost_usd" MUST be recorded as a Governance Event Record with event type "UNATTRIBUTED_SPEND". Reconciliation is the only control in this specification capable of detecting inference performed entirely outside the Routing Engine, because every other mechanism operates on records the Routing Engine itself produced. 9. Governance and Authorization 9.1. Policy Authority Model RMRP defines a two-role authorization model for routing policy governance: Policy Authority (PA): The entity authorized to issue, sign, update, and revoke Routing Policy Documents within a defined scope. A Policy Authority MUST be identified by a stable "policy_authority_id" and MUST possess a cryptographic signing key pair. Budget Authority (BA): The entity authorized to approve inference expenditure for one or more cost centers. A Budget Authority is referenced by "budget_authority_id" in RPDs and MRDs. The relationship between Budget Authorities and cost centers is defined externally to RMRP. A single organizational entity MAY hold both Policy Authority and Budget Authority roles. Implementations MAY define additional roles using the "extensions" mechanism. 9.2. Policy Issuance and Signing RPDs MUST be signed by the Policy Authority using a digital signature mechanism before they are made available to Routing Engines. This specification RECOMMENDS JWS [RFC7515] with algorithm RS256 or ES256. Routing Engines MUST verify the RPD signature before applying any policy. Routing Engines MUST reject unsigned or invalidly signed RPDs and write an ALR with outcome "POLICY_ERROR". Reilly Expires 9 March 2027 [Page 67] Internet-Draft RMRP September 2026 The public key or certificate used to verify RPD signatures MUST be provisioned to Routing Engines through a mechanism outside the scope of this specification. Key management practices SHOULD follow [RFC8551] or applicable organizational PKI policy. 9.3. Policy Versioning RPD versions MUST follow semantic versioning. The full version string MUST be recorded in every MRD, ALR, and CAR produced under that policy version. This enables precise reconstruction of the routing governance context for any historical event. When a Policy Authority issues a new RPD version, the new version MUST specify an "effective_date" in the future to allow Routing Engines time to load and validate the updated policy before it takes effect. A transition period of not less than 15 minutes between publication and "effective_date" is RECOMMENDED. Routing Engines MAY cache active RPDs. Cached policies MUST be revalidated against the Policy Authority's signing key upon each cache refresh. Cache TTL is implementation-defined but MUST NOT exceed the RPD "expiration_date". 9.4. Override Mechanisms RMRP does not define a general-purpose override mechanism that permits callers to bypass routing policy. All routing decisions MUST be governed by a valid, signed RPD. If a deployment requires the ability for privileged callers to escalate routing decisions (e.g., an operations team requesting ADVANCED tier for a specific task), this capability MUST be implemented as an explicit RPD rule with appropriate conditions, not as an out-of-band bypass. Emergency override conditions, if required by an organization, MUST be defined in a dedicated RPD with a named Policy Authority and a "FULL" audit level for all events processed under that policy. Emergency RPDs MUST have short expiration windows. Reilly Expires 9 March 2027 [Page 68] Internet-Draft RMRP September 2026 9.5. Key Rotation and Revocation Section 9.2 requires signature verification but does not define what happens when a signing key is compromised. Without revocation, a compromised Policy Authority key permits an attacker to issue policies that every Routing Engine will accept as authentic, and the audit trail will record those routings as fully governed. A Policy Authority MUST publish key state in the Revocation Registry defined in Section 5.7. Each entry in "revoked_keys" MUST carry a "not_valid_after" timestamp where signatures produced before that time remain acceptable, or MUST omit it where all signatures by that key are repudiated. Routing Engines MUST reject a policy whose signature was produced by a revoked key as of the relevant time, with error code RMRP-013. Key rotation SHOULD be routine rather than exceptional. A Policy Authority SHOULD rotate signing keys on a defined schedule and SHOULD publish the new key identifier before it is first used, so that the appearance of an unknown key identifier is a detectable anomaly rather than an expected event. Each rotation and each revocation MUST be recorded as a Governance Event Record. Where a key is revoked for compromise, the deployment SHOULD identify every policy version signed by that key and every routing decision made under those versions, and SHOULD record the scope of the affected set. Records remain valid history; what changes is the assurance that can be claimed for them. 9.6. Governance Event Records (GER) Routing decisions are recorded in detail. Changes to the governance state that produces those decisions are recorded nowhere in -00. An auditor can see every routing decision made under a policy but cannot see when the policy changed, who changed it, or who granted the authority to change it. A Conformant Router or Policy Authority at level C2 and above MUST write a Governance Event Record for each of the following event types: Reilly Expires 9 March 2027 [Page 69] Internet-Draft RMRP September 2026 POLICY_ISSUED, POLICY_AMENDED, POLICY_REVOKED, POLICY_EXPIRED, AUTHORITY_ASSIGNED, AUTHORITY_WITHDRAWN, KEY_ROTATED, KEY_REVOKED, BUDGET_CEILING_CHANGED, OVERRIDE_POLICY_ACTIVATED, DISCLOSURE_ISSUED, REPLAY_DISCREPANCY, VERIFICATION_FAILURE, UNATTRIBUTED_SPEND, AUDIT_STORE_UNAVAILABLE. A GER contains: ger_id (string, REQUIRED) A UUID identifying this record. event_type (string, REQUIRED) One of the values above, or an extension value using a reverse-DNS prefix. timestamp (string, REQUIRED) UTC timestamp of the event. actor_id (string, REQUIRED) The identity that performed or triggered the event. subject_ref (object, REQUIRED) A reference to the affected object, such as a policy identifier and version, a key identifier, or a window budget identifier. prior_state, new_state (objects, OPTIONAL) Digests or summaries of the governance state before and after the event. Recording digests rather than full state keeps the record small while preserving the ability to detect an undeclared intermediate change. justification (string, OPTIONAL) A human-readable reason for the change. approval_ref (string, OPTIONAL) A reference to an out-of-band approval record. signature (string, OPTIONAL) A signature over the canonical form of the record. GERs MUST be written to the Audit Store, MUST be committed to the same Merkle structure as ALRs where Section 7.7 applies, and MUST be retained for the period in Section 7.4. Reilly Expires 9 March 2027 [Page 70] Internet-Draft RMRP September 2026 9.7. Separation of Duties Section 3.2 states that a Policy Authority MUST NOT be the same entity as the Routing Engine where organizational policy requires separation, and leaves the requirement conditional. This subsection states the cryptographic consequence of that choice. Where a single key can both issue an RPD and sign the MRDs, ALRs, and RCAs produced under it, the holder of that key can author a permissive policy, route under it, and attest to the result. No verifier can distinguish that from correct operation, and the audit trail will be internally consistent throughout. Accordingly: o A Routing Engine signing key MUST NOT be authorized to sign RPDs at conformance level C3 and above. o A Routing Completeness Attestation MUST be signed by a key distinct from the Policy Authority key whose policies it attests routing under. o Where a deployment cannot separate these roles, it MUST record that fact in its conformance claim, and MUST NOT claim level C3 or above. Separation of duties in RMRP is a claim about keys, not about job titles. Two roles held by the same person with two distinct keys provides weaker assurance than two people; it still produces a distinguishable record, which no shared key does. 10. Transport Considerations 10.1. HTTP Transport When RMRP is used in conjunction with HTTP-based inference APIs, the following conventions APPLY: The MRD SHOULD be attached to outbound inference requests using a custom HTTP header: RMRP-MRD: Reilly Expires 9 March 2027 [Page 71] Internet-Draft RMRP September 2026 Where base64url encoding is as defined in [RFC4648]. Note: This header field name does not use the "X-" prefix, consistent with the guidance in [RFC6648] deprecating the "X-" convention for newly defined header fields. If the MRD exceeds HTTP header size limits, it MAY be included as a JSON object in the request body under the reserved key "_rmrp_mrd", provided the inference API accepts JSON request bodies. The "mrd_id" SHOULD be returned in the inference response using a custom HTTP header: RMRP-MRD-ID: HTTP responses from the Routing Engine to the caller SHOULD include the "mrd_id" and "request_id" for correlation. RMRP error responses in HTTP transport SHOULD use the Problem Details format defined in [RFC9457] with the following fields: type: A URI identifying the RMRP error class. title: A human-readable RMRP error code (e.g., "RMRP-004"). status: The applicable HTTP status code. detail: A human-readable error description. instance: A URI reference to the specific routing event. 10.2. Header Propagation In multi-hop deployments where inference requests pass through intermediate systems before reaching the Routing Engine, the following APPLY: o The "X-RMRP-MRD" header MUST be propagated unchanged through intermediate systems. o Intermediate systems MUST NOT modify or strip the "X-RMRP-MRD" header. o If an intermediate system performs its own routing, it MUST produce a new MRD and chain it to the original using the "chain_id" mechanism. Reilly Expires 9 March 2027 [Page 72] Internet-Draft RMRP September 2026 10.3. Non-HTTP Transports RMRP metadata structures are transport-agnostic. For non-HTTP transports (e.g., gRPC, AMQP, Kafka): o The MRD MUST be attached as a structured metadata object in the transport envelope. o The transport-specific mechanism for attaching metadata is implementation-defined but MUST be documented by the implementation. o All other normative requirements of this specification apply regardless of transport. 10.4. Header Field Naming and Structured Field Syntax Section 10.1 defines the header field name "RMRP-MRD" and states the rationale for not using an "X-" prefix. Section 10.2 refers to the same field as "X-RMRP-MRD". Both spellings appear in -00 and both are retained here without removal, so that implementations built against either text can identify their behavior in this specification. The normative field name is "RMRP-MRD". An implementation conforming to this revision: o MUST emit "RMRP-MRD". o MUST propagate "RMRP-MRD" unchanged through intermediate systems, and MUST NOT modify or strip it, as Section 10.2 requires for the prefixed spelling. o SHOULD accept "X-RMRP-MRD" on receipt for compatibility with implementations built against Section 10.2 of -00, and SHOULD treat it as equivalent. o MUST NOT emit both spellings with differing values in the same request. Where both are received with differing values, the request MUST be rejected with RMRP-002, because a mismatch between two governance headers is not a condition in which either can be relied upon. RMRP header field values are Structured Field values [RFC9651]: Reilly Expires 9 March 2027 [Page 73] Internet-Draft RMRP September 2026 o "RMRP-MRD" is an Item of type Byte Sequence containing the canonical JSON serialization of the MRD. o "RMRP-MRD-ID" is an Item of type String. o "RMRP-MRD-Digest" is an Item of type Byte Sequence containing the digest defined in Section 4.7.2, with an "alg" parameter naming the algorithm. Implementations SHOULD parse these fields with a Structured Fields parser rather than ad hoc string handling, so that values containing base64url padding or commas are not silently truncated. 10.5. MRD Reference Mode Section 10.1 provides a body attachment fallback for MRDs that exceed header size limits, which requires that the inference API accept a JSON body and tolerate an unrecognized key. Where neither holds, or where the MRD contains fields the operator does not wish to transmit to the model provider, a Routing Engine MAY dispatch a reference instead of the record: RMRP-MRD-ID: RMRP-MRD-Digest: ::; alg="SHA-256" In reference mode the full MRD MUST still be produced and written to the Audit Store before dispatch. Reference mode changes what is transmitted, not what is recorded. A Routing Engine MUST NOT use reference mode as a means of avoiding MRD production. Where the receiving system is another Routing Engine rather than a model provider, reference mode MUST NOT be used unless the receiving engine can resolve the reference, since it would otherwise lose the governance context it needs to chain its own decision per Section 10.2. 10.6. Caller Authentication and HTTP Semantics RMRP governs which model serves a request. It does not define how the caller of the Routing Engine is authenticated, and -00 leaves the question open. Every cost attribution in Section 8 rests on the accuracy of "source_system" and "cost_center", so a caller able to name its own cost center without authentication can attribute its expenditure to any budget in the organization. Reilly Expires 9 March 2027 [Page 74] Internet-Draft RMRP September 2026 A Routing Engine MUST authenticate callers before accepting a "source_system" or "cost_center" assertion. Where the deployment uses HTTP, requests and responses follow the semantics defined in [RFC9110]. Where it uses token-based authorization, [RFC6749] and [RFC7519] are applicable, and the following constraints hold: o The Routing Engine MUST derive "source_system" from the authenticated identity, or MUST verify that a caller-supplied value is one that identity is authorized to assert. A rule that constrains "source_systems" under Section 4.9.2 provides no control if the value can be asserted freely. o Access tokens, their claims, and any credential material MUST NOT be copied into RMRP records, per Section 11.5. A subject identifier MAY be recorded only where it does not constitute personal data under Section 12.1; otherwise it SHOULD be committed per Section 4.8 rather than recorded in the clear. o Where an authorization lapses partway through a chain, the Routing Engine MUST NOT continue routing subsequent chain steps on the strength of the original grant. Chains outlive the requests that start them, and Section 6.8 bounds their depth but not their authorization lifetime. URI values used in RMRP error responses, including the "type" and "instance" members described in Section 10.1, MUST conform to [RFC3986]. The "instance" URI SHOULD reference the routing event by "mrd_id" and MUST NOT embed request content. 11. Security Considerations 11.1. Policy Integrity RPDs define the governance of all inference expenditure and model selection in a deployment. Unauthorized modification of an RPD could result in unauthorized use of high-cost model tiers, bypass of cost controls, or suppression of audit records. Implementations MUST enforce RPD signature verification as specified in Section 9.2. RPDs MUST be stored and transmitted in a manner that prevents unauthorized modification. Reilly Expires 9 March 2027 [Page 75] Internet-Draft RMRP September 2026 11.2. MRD Tampering A tampered MRD could be used to misattribute inference costs or falsify audit records. In deployments with high-assurance requirements, Routing Engines SHOULD produce a cryptographic signature over each MRD using the Policy Authority's signing key or a dedicated Routing Engine signing key. Receiving systems SHOULD verify this signature. MRDs MUST NOT contain inference request content, prompt text, or user-supplied data. MRDs are governance metadata only. 11.3. Audit Log Integrity ALR and CAR records MUST be written to a system that prevents modification or deletion by the Routing Engine itself or by operators without separate authorization. Implementations SHOULD implement hash chaining over the ALR sequence as described in Section 7.2, using the "previous_alr_id" and "alr_hash" fields. Implementations MAY anchor ALR hash roots to external immutable systems (e.g., transparency logs, public blockchains) for enhanced tamper-evidence. 11.4. Denial of Service A malicious or malfunctioning caller could submit high-volume requests designed to maximize ADVANCED tier routing and exhaust budget ceilings. Routing Engines SHOULD implement rate limiting per source system and per cost center. Rate limiting thresholds are outside the scope of this specification. The Routing Engine itself is a critical component. Its unavailability prevents all inference processing. Deployments SHOULD implement redundant Routing Engine instances. Routing Engines SHOULD implement circuit breakers for Audit Store connectivity, with defined behavior for the case where audit records cannot be written (see RMRP-007). 11.5. Credential Exposure RMRP records MUST NOT contain AI provider API keys, secrets, tokens, or authentication credentials. Model Identifiers in RMRP records are opaque strings and MUST NOT embed credentials. Authentication with model providers is a separate concern handled outside the RMRP governance layer. Reilly Expires 9 March 2027 [Page 76] Internet-Draft RMRP September 2026 11.6. Threat Model The threats below are stated with the adversary, the capability assumed, and the mechanism that addresses each. The mechanisms in -00 address T-1 through T-4. This revision addresses the remainder. Where a threat is only partially addressed, that is stated rather than implied to be closed. T-1 External modification of a policy in transit or at rest. Adversary: a party without Policy Authority keys. Addressed by RPD signature verification (Section 9.2) and canonical digests (Section 5.6). T-2 Modification of an MRD between the Routing Engine and the model provider. Adversary: an intermediate system. Addressed by MRD signature (Section 4.7.3) and by header propagation requirements (Sections 10.2 and 10.4). T-3 Modification of audit records after the fact. Adversary: an operator with Audit Store write access. Addressed by append-only storage (Section 3.2), Merkle commitment (Section 7.7), and external anchoring (Section 7.8). Partially addressed: anchoring bounds the window of undetected modification to the checkpoint interval; it does not prevent modification within that interval. T-4 Budget exhaustion by request volume. Adversary: a malfunctioning or hostile caller. Addressed by rate limiting (Section 11.4) and aggregate ceilings (Section 8.6). T-5 Escalation by score inflation. Adversary: a caller, or a component that benefits from higher-tier routing. Addressed by scorer attestation (Section 4.9) and the constraint on caller-asserted scores (Section 4.9.2). See Section 11.7. T-6 Selective omission of audit records. Adversary: the Routing Engine operator. Addressed by Routing Completeness Attestation (Section 7.10) and reconciliation against provider billing (Section 8.7). Partially addressed: an operator willing to sign a false attestation is not prevented, only exposed to a different category of liability. Reilly Expires 9 March 2027 [Page 77] Internet-Draft RMRP September 2026 T-7 Continued use of a repudiated policy. Adversary: an operator relying on a cached policy after revocation. Addressed by the Revocation Registry and fail-closed behavior (Section 5.7). T-8 Compromise of a signing key. Adversary: any party obtaining key material. Addressed by key revocation (Section 9.5) and by separation of duties (Section 9.7), which bounds what a single compromised key can accomplish. T-9 Self-authorization, where one party writes the policy, routes under it, and attests the result. Adversary: an insider holding all roles. Addressed by Section 9.7. Partially addressed: RMRP can require distinct keys; it cannot compel an organization to place them in distinct hands. T-10 Inference performed entirely outside the governance layer. Adversary: any team calling a provider API directly. Addressed only by reconciliation (Section 8.7). No record-level mechanism can detect an event that produced no record; detection requires comparison against an independent source, which is what provider billing is. T-11 Inference of sensitive organizational structure from governance metadata. Adversary: any party receiving records for verification. Addressed by field commitments and selective disclosure (Section 4.8) and by Section 12.1. T-12 Rollback of the Revocation Registry to a state in which a revoked policy or key was valid. Adversary: a party able to serve stale registry versions. Addressed by the monotonic "registry_version" requirement and "next_update_at" bound in Section 5.7. 11.7. Escalation Abuse and Score Inflation The Complexity Score determines cost. Any party that can influence it can influence spending, and in most deployments the party best positioned to influence it is the application team whose workload benefits from a more capable model. Reilly Expires 9 March 2027 [Page 78] Internet-Draft RMRP September 2026 Deployments SHOULD monitor the distribution of complexity scores per source system over time. A distribution that drifts upward without a corresponding change in workload is the observable signature of score inflation, whether deliberate or the result of a scorer change nobody recorded. Recording "scorer_digest" (Section 4.9.1) distinguishes these two cases. RPD rules authorizing ADVANCED tier SHOULD constrain "source_systems" in addition to complexity thresholds, so that escalation requires both a score and an identity authorized to receive it. 11.8. Audit Suppression An operator who can decline to write a record can produce a clean audit trail by omission. Nothing in a set of records testifies to the records that are absent from it. Section 7.10 addresses this by requiring periodic signed counts, Section 8.7 by requiring comparison against provider billing, and Section 7.7 by making the record sequence itself verifiable. A deployment claiming audit assurance without at least one of these mechanisms is claiming assurance over a set it controls the membership of, and SHOULD describe its claim in those terms. Where the Audit Store is unavailable, RMRP-007 already directs the Routing Engine to halt. This revision adds that the halt itself MUST be recorded as a Governance Event Record with type "AUDIT_STORE_UNAVAILABLE" once the store returns, including the interval affected and the count of requests processed or rejected during it. 11.9. Cryptographic Agility Implementations MUST support SHA-256 and ES256. Support for SHA3-512 and BLAKE3 as digest algorithms is RECOMMENDED. All records that carry a digest MUST name the algorithm, so that a verifier never infers the algorithm from digest length. Deployments SHOULD plan for algorithm migration using the Bridging Records defined in Section 7.9 rather than re-hashing archives in place. Nothing in this specification requires a post-quantum algorithm; deployments with long retention horizons SHOULD evaluate whether their retention period exceeds the expected sound lifetime of the algorithms they have chosen. Reilly Expires 9 March 2027 [Page 79] Internet-Draft RMRP September 2026 12. Privacy Considerations RMRP governance records (MRDs, ALRs, CARs) are operational metadata about routing decisions. They do not, and MUST NOT, contain the content of inference requests or responses. However, the "source_system", "cost_center", and "task_type" fields in RMRP records may be sufficient to infer information about organizational activities or individual user behavior in certain deployment contexts. Implementations SHOULD apply access controls to the Audit Store consistent with the sensitivity of the operational data it contains. In deployments subject to data residency requirements, implementations MUST ensure that ALR and CAR records are stored in jurisdictions consistent with applicable regulations. RMRP does not specify geographic constraints on record storage. The "request_id" field, if it can be linked to an individual user, may constitute personal data under applicable privacy regulations. Organizations MUST assess whether RMRP records are subject to data subject rights obligations under applicable law and implement appropriate controls. 12.1. Data Minimization and Selective Disclosure Access control protects records held inside the organization. It does not help where a record must be shown to an auditor, a regulator, a customer under a contractual audit right, or a counterparty in a dispute. In those cases the choice under -00 is between disclosing the whole record and disclosing nothing. Deployments SHOULD apply the following minimization practices: o Commit to "source_system", "cost_center", "budget_authority_id", and "routing_rationale" per Section 4.8, disclosing values only to parties entitled to them. o Treat "routing_rationale" as the highest-risk field for inadvertent content disclosure. It is a free-text field written by implementers, and implementations have a standing tendency to include an excerpt of the request to explain the decision. Section 11.2 prohibits this. Implementations SHOULD constrain the field to rule identifiers, field names, and threshold values. Reilly Expires 9 March 2027 [Page 80] Internet-Draft RMRP September 2026 o Avoid embedding user identifiers in "request_id". Where a caller-supplied identifier may carry personal data, the Routing Engine SHOULD generate its own identifier and maintain the correlation outside the Audit Store. 12.2. Retention, Erasure, and Anchored Records Section 7.4 requires retention for 90 days and recommends far longer in regulated environments. Section 7.8 permits anchoring digests to systems outside the deployment's control. These two requirements interact with erasure obligations under applicable privacy law, and the interaction MUST be designed for rather than discovered. A digest or commitment is not the value it commits to. A deployment SHOULD therefore anchor and publish only digests, commitments, and roots, and MUST NOT anchor field values that may constitute personal data. Where a record subject to erasure is removed from the Audit Store, the deployment SHOULD: o Retain the leaf digest necessary to preserve the Merkle structure and the validity of previously issued proofs. o Record the erasure as a Governance Event Record identifying the affected leaf index or record identifier, the legal basis, and the timestamp, without reproducing the erased content. o Preserve the salt destruction as part of the erasure where field commitments were used, since destroying the salt renders the commitment computationally unopenable while leaving the structure intact. This yields records whose existence and sequence remain verifiable while their content is unrecoverable. A deployment MUST NOT represent anchored digests as erasable, and MUST NOT anchor content it may later be required to erase. 13. IANA Considerations This document requests the following registrations: HTTP Header Field Registration: Reilly Expires 9 March 2027 [Page 81] Internet-Draft RMRP September 2026 Header Field Name: RMRP-MRD Status: Provisional Reference: This document, Section 10.1 Change Controller: IETF Header Field Name: RMRP-MRD-ID Status: Provisional Reference: This document, Section 10.1 Change Controller: IETF Media Type Registration: Type name: application Subtype name: rmrp+json Required parameters: none Optional parameters: version Encoding considerations: binary (UTF-8 encoded JSON) Security considerations: See Section 11 Interoperability considerations: none Published specification: This document Applications: AI model routing governance Additional information: none Contact: See Author's Address Intended usage: COMMON Change controller: IETF URN Namespace for RMRP Error Types: This document requests registration of a URN sub-namespace under "urn:ietf:params" per the process defined in [RFC8141] for use as "type" values in RMRP error responses per Section 10.1: urn:ietf:params:rmrp:error: Requested initial error type URNs pending IANA assignment: urn:ietf:params:rmrp:error:policy-not-found urn:ietf:params:rmrp:error:validation-failure urn:ietf:params:rmrp:error:budget-exceeded urn:ietf:params:rmrp:error:model-unavailable urn:ietf:params:rmrp:error:fallback-exhausted urn:ietf:params:rmrp:error:policy-expired urn:ietf:params:rmrp:error:audit-store-failure Reilly Expires 9 March 2027 [Page 82] Internet-Draft RMRP September 2026 Note to RFC Editor: This section is to be updated to reflect actual IANA registry assignments prior to publication as an RFC. 13.1. Additional Registrations Requested in This Revision The registrations requested in Section 13 are unchanged. The following are added. Additional HTTP Header Field Registration: Header Field Name: RMRP-MRD-Digest Status: Provisional Structured Type: Item Reference: This document, Sections 10.4 and 10.5 Change Controller: IETF Additional Media Type Registration: Type name: application Subtype name: rmrp+cbor Required parameters: none Optional parameters: version Encoding considerations: binary (CBOR [RFC8949]) Security considerations: See Section 11 Interoperability considerations: Records in this representation carry the same fields and semantics as "application/rmrp+json". Digests and signatures are computed over the canonical JSON form per Section 4.7.1 regardless of transport representation, so that a record converted between representations verifies identically. Published specification: This document Applications: AI model routing governance in constrained or COSE-native deployments Contact: See Author's Address Intended usage: COMMON Change controller: IETF Additional Error Type URNs: urn:ietf:params:rmrp:error:policy-revoked urn:ietf:params:rmrp:error:chain-limit-exceeded urn:ietf:params:rmrp:error:attestation-required urn:ietf:params:rmrp:error:chain-budget-exceeded urn:ietf:params:rmrp:error:window-budget-exceeded urn:ietf:params:rmrp:error:key-revoked urn:ietf:params:rmrp:error:verification-failure Reilly Expires 9 March 2027 [Page 83] Internet-Draft RMRP September 2026 13.2. Requested Registries Sections 4.3, 4.4, 6.6, and 7.3 define value sets that implementations are invited to extend, without providing a mechanism by which an extension becomes known to anyone else. Reverse-DNS prefixing prevents collisions; it does not produce interoperability, because no implementation can discover what another has defined. This revision requests registries for those value sets. Each registry below is requested with registration policy Specification Required [RFC8126], with the exception of the error code registry, which is requested as Expert Review to permit timely allocation during incident response. RMRP Task Type Registry: Fields: Task Type value, description, reference, change controller. Initial contents: the ten values in Section 4.3. Values MUST be uppercase ASCII. Registered values MUST NOT duplicate the semantics of an existing entry solely to change its name. RMRP Model Tier Registry: Fields: Tier value, relative capability position, description, reference. Initial contents: LIGHT, STANDARD, ADVANCED per Section 4.4. Registrations MUST state the tier's position relative to the three normative tiers, since routing policy expressed in terms of an unordered tier set cannot be evaluated for least-cost sufficiency. RMRP Audit Level Registry: Fields: Audit level value, required field set, description, reference. Initial contents: MINIMAL, STANDARD, FULL per Section 7.3. RMRP Outcome Value Registry: Fields: Outcome value, success or failure classification, description, reference. Initial contents: the seven values in Section 7.2 and the four added in Section 7.6. RMRP Error Code Registry: Fields: Error code, corresponding URN, description, reference. Initial contents: RMRP-001 through RMRP-007 from Section 6.6 and RMRP-008 through RMRP-014 from Section 6.9. Registration policy: Expert Review. Reilly Expires 9 March 2027 [Page 84] Internet-Draft RMRP September 2026 RMRP Scoring Method Class Registry: Fields: Class value, determinism property, description, reference. Initial contents: the five values in Section 4.9.1. Registrations MUST state whether the class is deterministic, since Section 6.7 replay depends on that property. 14. References 14.1. 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, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Reilly Expires 9 March 2027 [Page 85] Internet-Draft RMRP September 2026 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . 14.2. Informative References [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Reilly Expires 9 March 2027 [Page 86] Internet-Draft RMRP September 2026 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the 'X-' Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [semver] Preston-Werner, T., "Semantic Versioning 2.0.0", 2013, . [ROUTELLM] Ong, I., Almahairi, A., Wu, V., Chiang, W., Wu, T., Gonzalez, J., Kadous, M., and I. Stoica, "RouteLLM: Learning to Route LLMs with Preference Data", LMSYS Blog, July 2024, . Reilly Expires 9 March 2027 [Page 87] Internet-Draft RMRP September 2026 [PLPES] Reilly, L. J., "Protocol Layer Prompt Engineering Specification (PLPES)", Internet-Draft draft-reilly-plpes-01, September 2026, . [REM] Reilly, L. J., "Reilly EternaMark (REM) Protocol: Dual-Layer Digital Permanence for Intellectual Property", Internet-Draft draft-reilly-rem-protocol-02, . [AIGOV] Reilly, L. J., "Verifiable AI Governance and Data Privacy Records", Internet-Draft draft-reilly-aigov-00, August 2026, . [CBPI] Reilly, L. J., "Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents", Internet-Draft draft-reilly-cbpi-00, July 2026, . [WEB4] Reilly, L. J., "Web4: A Verifiable, Agent-Native Architecture for the World Wide Web", Internet-Draft draft-reilly-web4-00, August 2026, . [BULK-SUBTREE-PROOFS] Reilly, L. J., "Bulk Subtree Consistency Proofs for Merkle Tree Certificates", Internet-Draft draft-reilly-plants-bulk-subtree-proofs-01, July 2026, . [USC-35-102] United States Code, "Conditions for patentability; novelty", 35 U.S.C. 102(a)(1). 15. Conformance Levels -00 defines a single class, the Conformant Router, comprising all REQUIRED behaviors. That is sufficient to state whether an implementation follows the specification. It is not sufficient to state what assurance a deployment provides, which is the question an auditor, a regulator, or a purchaser actually asks. Reilly Expires 9 March 2027 [Page 88] Internet-Draft RMRP September 2026 This section defines five cumulative levels. An implementation claiming a level MUST satisfy every requirement of that level and all lower levels, and MUST state the level in any conformance claim. A claim without a stated level SHOULD be read as C1. C0 Declarative. Produces MRDs, ALRs, and CARs with all fields REQUIRED by -00. Routing policy is expressed as a signed RPD rather than in application code. This level establishes that routing is governed; it establishes nothing about whether the records are accurate. C1 Auditable. C0, plus: all error events produce ALRs (Sections 6.6 and 6.9); retention per Section 7.4; retrieval by the keys in Section 7.4; a bounded chain depth default (Section 6.8.1); and documented complexity scoring (Section 4.5). C2 Verifiable. C1, plus: canonical form, digest, and signature over MRDs, ALRs, and CARs (Sections 4.7, 7.6, 8.6.3); policy digest recorded in every record (Section 5.6); Governance Event Records (Section 9.6); and sufficient recorded state for the replay procedure of Section 6.7, steps 1 through 5. C3 Attested. C2, plus: scorer attestation (Section 4.9); Revocation Registry consultation with FAIL_CLOSED behavior (Section 5.7); key rotation and revocation (Section 9.5); separation of Routing Engine and Policy Authority keys (Section 9.7); aggregate budget enforcement (Section 8.6); and periodic Routing Completeness Attestation (Section 7.10). C4 Anchored. C3, plus: Merkle commitment of audit records per Section 7.7; inclusion proofs available to verifiers; Checkpoints published to at least one target outside the deployment's administrative control (Section 7.8) with a stated checkpoint interval; Bridging Records planned for hash migration (Section 7.9); and periodic Cost Reconciliation Records against provider billing (Section 8.7). Reilly Expires 9 March 2027 [Page 89] Internet-Draft RMRP September 2026 A conformance claim SHOULD state, alongside the level: the checkpoint interval where C4 is claimed, the scoring method classes in use, the revocation unavailability behavior, whether any Budget Window Record uses "ALERT_ONLY", and whether Routing Engine and Policy Authority keys are held by distinct parties. Each of these materially changes the assurance the level represents. 16. Prior Art Record Status This document, and the revision history of this document on the IETF Datatracker, constitute a printed publication for the purposes of 35 U.S.C. 102(a)(1) [USC-35-102]. The mechanisms specified here, including the Model Routing Decision, the Routing Policy Document, the Audit Log Record, the Cost Attribution Record, the Budget Window Record, the Cost Reconciliation Record, the Routing Completeness Attestation, the scorer attestation fields, and the conformance levels in Section 15, are published for defensive purposes and are available for implementation. Publication as an Internet-Draft establishes the date on which this material became publicly available. It does not confer any patent right, does not constitute a patent application, and does not state a position on the patentability of any related subject matter. Any IPR disclosures applicable to this document are recorded through the IETF IPR disclosure process referenced in the Status of This Memo section. 17. Relationship to Related Work RMRP addresses the governance layer above model routing. The research literature on routing itself, including [ROUTELLM], addresses which model should serve a request. RMRP addresses how that decision is declared, bounded, recorded, and verified. The two are complementary: a routing policy expressed under RMRP may be derived from any routing research, and RMRP takes no position on which method is correct. Within the author's protocol suite, the following relationships hold. Each is a citation, not a dependency; RMRP is implementable without any of them. o [PLPES] governs the descriptor and tier enforcement for prompt construction. Where both are deployed, a PLPES tier decision and an RMRP routing decision describe adjacent stages of the same request, and SHOULD share a correlation identifier. Reilly Expires 9 March 2027 [Page 90] Internet-Draft RMRP September 2026 o [CBPI] governs the behavioral provenance of autonomous agents. The chain controls in Section 6.8 bound what an agent may spend; CBPI addresses how an agent's behavior is recorded and assessed over time. o [AIGOV] defines the AI System Record and register-level attestations. An RMRP deployment is an AI system for the purposes of that document, and the Routing Completeness Attestation in Section 7.10 follows the same completeness pattern. o [REM] defines the dual-layer permanence approach on which the anchoring in Section 7.8 draws. o [BULK-SUBTREE-PROOFS] defines proof batching applicable to the Merkle structures in Section 7.7 at high issuance rates. o [WEB4] defines a conformance profile across the suite. The levels in Section 15 are scoped to RMRP and do not depend on that profile. 18. Changes from draft-reilly-rmrp-00 This revision is additive. No section, field, value, requirement, or example present in -00 has been removed, renumbered, or changed in meaning. Section 4.2 continues to specify "1.0" as the version value for records conforming to -00, and Section 2.2 defines "1.1" for records using fields added here. Added in Section 1: scope and design principles for this revision (Sections 1.4 and 1.5). Added in Section 2: terminology for the structures added here (Section 2.1); version string and compatibility rules (Section 2.2). Added in Section 3: the Revocation Registry Publisher, Attestation Publisher, Budget Window Service, External Anchor Target, and Verifier components (Section 3.4). Added in Section 4: canonicalization, digest, and signature for the MRD (Section 4.7); salted field commitments, commitment roots, and Disclosure Responses (Section 4.8); complexity score attestation, constraints on caller-asserted scores, and determinism requirements (Section 4.9). Reilly Expires 9 March 2027 [Page 91] Internet-Draft RMRP September 2026 Added in Section 5: RPD canonicalization and policy digest (Section 5.6); the Revocation Registry and fail-closed behavior (Section 5.7); eleven optional rule fields covering chain ceilings, depth, window budgets, scorer requirements, escalation damping, minimum conformance level, and signature requirements (Section 5.8). Added in Section 6: the replay procedure (Section 6.7); chain depth bounding, escalation damping and hysteresis, and the associated record fields (Section 6.8); error codes RMRP-008 through RMRP-014 (Section 6.9). Added in Section 7: additional ALR fields and four additional outcome values (Section 7.6); RFC 6962 Merkle construction, Tree Heads, and inclusion proofs (Section 7.7); Checkpoints, external anchoring, and pending versus attested anchor state (Section 7.8); Bridging Records for hash migration (Section 7.9); the Routing Completeness Attestation (Section 7.10). Added in Section 8: Budget Window Records and aggregate chain and window enforcement (Section 8.6); the Cost Reconciliation Record and unattributed spend detection (Section 8.7). Added in Section 9: key rotation and revocation (Section 9.5); Governance Event Records (Section 9.6); separation of duties stated as a key requirement (Section 9.7). Added in Section 10: header naming reconciliation between Sections 10.1 and 10.2, and Structured Field syntax (Section 10.4); MRD reference mode (Section 10.5); caller authentication requirements and HTTP semantics (Section 10.6). Added in Section 11: a twelve-entry threat model with partial coverage stated explicitly (Section 11.6); escalation abuse and score inflation (Section 11.7); audit suppression (Section 11.8); cryptographic agility (Section 11.9). Added in Section 12: data minimization and selective disclosure (Section 12.1); retention, erasure, and anchored records (Section 12.2). Added in Section 13: additional header, media type, and error URN registrations (Section 13.1); six requested registries for the extensible value sets defined in -00 (Section 13.2). Reilly Expires 9 March 2027 [Page 92] Internet-Draft RMRP September 2026 Added after Section 14: conformance levels (Section 15); prior art record status (Section 16); relationship to related work (Section 17); this section; and a worked example (Appendix A). Editorial: the header field name discrepancy between Sections 10.1 and 10.2 of -00 is reconciled in Section 10.4 without removing either occurrence. Appendix A. Worked Example at Conformance Level C4 This appendix is non-normative. It shows the records produced for a single ADVANCED tier routing decision at level C4, extending the example in Section 4.6. Values are abbreviated for readability. A.1. MRD with Attestation and Commitments Reilly Expires 9 March 2027 [Page 93] Internet-Draft RMRP September 2026 { "rmrp_version": "1.1", "mrd_id": "550e8400-e29b-41d4-a716-446655440000", "request_id": "req-20260905-00192", "timestamp": "2026-09-05T17:00:00.000Z", "routing_policy_id": "rpd-prod-engineering-v3", "routing_policy_version": "3.4.0", "routing_policy_digest": "9Xk2...c1", "source_system": "agent-runner.internal", "task_type": "AGENTIC", "complexity_score": 0.81, "caller_asserted_score": 0.95, "scorer_id": "scorer-heuristic-01", "scorer_version": "2.1.0", "scorer_digest": "b7Aa...9f", "scoring_method_class": "HEURISTIC", "score_inputs_digest": "44Tz...0e", "selected_model_id": "provider-alpha/model-advanced-v2", "selected_model_tier": "ADVANCED", "routing_rationale": "Rule R-05 matched; escalation authorized at threshold 0.75; escalation 1 of 3 for chain.", "cost_center": "eng-ai", "budget_authority_id": "ba-vp-engineering-001", "window_budget_id": "bw-eng-ai-2026-09", "max_token_budget": 16384, "priority_class": "HIGH", "chain_id": "chain-pipeline-20260905-00041", "chain_step": 4, "chain_observed_step": 4, "chain_escalation_count": 0, "audit_level": "FULL", "commitments": { "cost_center": "Qm9x...aa", "budget_authority_id": "T1pk...bb", "source_system": "Zk3v...cc" }, "commitment_algorithm": "SHA-256", "commitment_root": "R00t...dd", "mrd_digest": "D1ge...ee", "mrd_digest_algorithm": "SHA-256", "signer_key_id": "re-key-2026-09", "mrd_signature": "0oRD...ff" } Reilly Expires 9 March 2027 [Page 94] Internet-Draft RMRP September 2026 The caller asserted 0.95; the heuristic scorer computed 0.81. Both are recorded. Under Section 4.9.2 the asserted value could not have authorized escalation on its own. A.2. Routing Completeness Attestation { "rca_id": "c0ffee00-1111-4222-8333-444455556666", "window_start": "2026-09-05T17:00:00.000Z", "window_end": "2026-09-05T18:00:00.000Z", "engine_id": "router-us-east-03", "routing_event_count": 41207, "alr_count": 41207, "counts_by_outcome": { "SUCCESS": 40988, "FALLBACK_SUCCESS": 173, "BUDGET_EXCEEDED": 31, "CHAIN_LIMIT_EXCEEDED": 15 }, "counts_by_tier": { "LIGHT": 33110, "STANDARD": 7702, "ADVANCED": 395 }, "tree_head": { "tree_size": 2841993, "root_hash": "T33h...11", "hash_algorithm": "SHA-256", "published_at": "2026-09-05T18:00:04.000Z", "signature": "0oRD...22" }, "previous_rca_id": "bead0000-1111-4222-8333-444455556665", "signature": "0oRD...33" } The 395 ADVANCED tier events in this window are the figure an auditor compares against the provider invoice under Section 8.7. A material excess of provider-reported ADVANCED tier usage over this count indicates either omitted records or inference outside the governance layer. A.3. Verification Sequence A verifier holding the MRD above, a Tree Head obtained from a Checkpoint, and the RPD proceeds as follows: Reilly Expires 9 March 2027 [Page 95] Internet-Draft RMRP September 2026 1. Recompute the MRD canonical form and digest; compare to "mrd_digest". 2. Verify "mrd_signature" with the key named by "signer_key_id"; confirm that key was not revoked as of "timestamp". 3. Confirm the RPD retrieved for version 3.4.0 produces "routing_policy_digest". 4. Replay rule evaluation per Section 6.7 and confirm rule R-05 and ADVANCED tier. 5. Recompute "complexity_score" from the recorded inputs, the scorer being HEURISTIC and therefore deterministic. 6. Request an inclusion proof for the corresponding ALR and verify it against the Tree Head. 7. Confirm the Tree Head appears in a Checkpoint whose anchor state is ATTESTED at a target outside the deployment. Steps 1 through 5 establish that the decision was consistent with a policy that existed. Steps 6 and 7 establish that the record of it has not been altered since the checkpoint. Neither establishes that the score was a correct assessment of the request, which no protocol can establish and which Section 4.9.3 requires implementers not to claim. Acknowledgments The author acknowledges the foundational research contributions of the LLM routing research community, whose work establishing cost-quality trade-off frameworks for model selection provided essential context for this protocol-layer specification. This document addresses the governance and standardization layer above that body of research. The verification mechanisms added in this revision draw on the Certificate Transparency design [RFC6962] and on the broader body of work on transparency logs and append-only data structures. Author's Address Lawrence J. Reilly Jr. REM Technologies & Consulting, LLC Email: lawrencejohnreilly@gmail.com Reilly Expires 9 March 2027 [Page 96]