Reilly Model Routing Protocol (RMRP): A Framework for Policy-Governed, Auditable AI Model Routing
draft-reilly-rmrp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Lawrence John Reilly Jr | ||
| Last updated | 2026-04-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reilly-rmrp-00
Internet-Draft L. J. Reilly
Intended Status: Informational Independent
Expires: October 28, 2026 April 28, 2026
Reilly Model Routing Protocol (RMRP):
A Framework for Policy-Governed, Auditable AI Model Routing
draft-reilly-rmrp-00
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. 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 . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Design Principles . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
3. RMRP Architecture Overview . . . . . . . . . . . . . . . . 8
3.1. Architectural Layers . . . . . . . . . . . . . . . . . 8
3.2. Component Roles . . . . . . . . . . . . . . . . . . . . 9
3.3. Request Lifecycle . . . . . . . . . . . . . . . . . . . 10
4. Model Routing Decision (MRD) . . . . . . . . . . . . . . . 11
4.1. MRD Structure . . . . . . . . . . . . . . . . . . . . . 11
4.2. MRD Field Definitions . . . . . . . . . . . . . . . . . 12
4.3. Task Classification . . . . . . . . . . . . . . . . . . 15
4.4. Model Tier Definitions . . . . . . . . . . . . . . . . 16
4.5. Complexity Scoring . . . . . . . . . . . . . . . . . . 17
4.6. MRD Example . . . . . . . . . . . . . . . . . . . . . . 18
5. Routing Policy Document (RPD) . . . . . . . . . . . . . . . 19
5.1. RPD Structure . . . . . . . . . . . . . . . . . . . . . 19
5.2. RPD Field Definitions . . . . . . . . . . . . . . . . . 20
5.3. Rule Evaluation Order . . . . . . . . . . . . . . . . . 23
5.4. Fallback Behavior . . . . . . . . . . . . . . . . . . . 23
5.5. RPD Example . . . . . . . . . . . . . . . . . . . . . . 24
6. Routing Execution Semantics . . . . . . . . . . . . . . . . 26
6.1. Pre-Routing Validation . . . . . . . . . . . . . . . . 26
6.2. Policy Resolution . . . . . . . . . . . . . . . . . . . 26
6.3. Model Selection . . . . . . . . . . . . . . . . . . . . 27
6.4. Request Dispatch . . . . . . . . . . . . . . . . . . . 27
6.5. Response Handling . . . . . . . . . . . . . . . . . . . 28
6.6. Error and Fallback Handling . . . . . . . . . . . . . . 28
7. Audit Trail Requirements . . . . . . . . . . . . . . . . . 30
7.1. Audit Log Record (ALR) Structure . . . . . . . . . . . 30
7.2. ALR Field Definitions . . . . . . . . . . . . . . . . . 31
7.3. Audit Level Classes . . . . . . . . . . . . . . . . . . 33
7.4. Retention Requirements . . . . . . . . . . . . . . . . 33
7.5. ALR Example . . . . . . . . . . . . . . . . . . . . . . 34
8. Cost Attribution Framework . . . . . . . . . . . . . . . . 35
8.1. Cost Attribution Record (CAR) . . . . . . . . . . . . 35
8.2. CAR Field Definitions . . . . . . . . . . . . . . . . . 36
8.3. Budget Authority Chain . . . . . . . . . . . . . . . . 37
8.4. Cost Ceiling Enforcement . . . . . . . . . . . . . . . 38
8.5. CAR Example . . . . . . . . . . . . . . . . . . . . . . 38
9. Governance and Authorization . . . . . . . . . . . . . . . 39
9.1. Policy Authority Model . . . . . . . . . . . . . . . . 39
9.2. Policy Issuance and Signing . . . . . . . . . . . . . . 40
9.3. Policy Versioning . . . . . . . . . . . . . . . . . . . 41
9.4. Override Mechanisms . . . . . . . . . . . . . . . . . . 41
10. Transport Considerations . . . . . . . . . . . . . . . . . 42
10.1. HTTP Transport . . . . . . . . . . . . . . . . . . . . 42
10.2. Header Propagation . . . . . . . . . . . . . . . . . . 43
10.3. Non-HTTP Transports . . . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . 44
11.1. Policy Integrity . . . . . . . . . . . . . . . . . . . 44
11.2. MRD Tampering . . . . . . . . . . . . . . . . . . . . . 44
11.3. Audit Log Integrity . . . . . . . . . . . . . . . . . . 45
11.4. Denial of Service . . . . . . . . . . . . . . . . . . . 45
11.5. Credential Exposure . . . . . . . . . . . . . . . . . . 45
12. Privacy Considerations . . . . . . . . . . . . . . . . . . 46
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 47
14. References . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Normative References . . . . . . . . . . . . . . . . . 48
14.2. Informative References . . . . . . . . . . . . . . . . 49
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 50
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:
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.
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.
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.
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.
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.
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".
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
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.
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.
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.
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.
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.
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.
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.
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.
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:
{
"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": {}
}
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.
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.
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.
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.
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.
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
},
"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.",
"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"
}
]
}
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:
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.
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.
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.
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.
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.
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.
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.
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:
{
"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"
}
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.
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.
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.
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:
{
"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
}
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".
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.
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: <base64url-encoded JSON MRD>
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: <mrd_id value>
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.
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.
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.
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.
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.
13. IANA Considerations
This document requests the following registrations:
HTTP Header Field Registration:
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
Note to RFC Editor: This section is to be updated to reflect
actual IANA registry assignments prior to publication as an RFC.
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629,
DOI 10.17487/RFC3629, November 2003,
<https://www.rfc-editor.org/rfc/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648,
October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
May 2015,
<https://www.rfc-editor.org/rfc/rfc7515>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON)
Data Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446,
DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem
Details for HTTP APIs", RFC 9457,
DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/rfc/rfc9457>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally
Unique IDentifiers (UUIDs)", RFC 9562,
DOI 10.17487/RFC9562, May 2024,
<https://www.rfc-editor.org/rfc/rfc9562>.
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,
<https://www.rfc-editor.org/rfc/rfc3986>.
[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,
<https://www.rfc-editor.org/rfc/rfc6648>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization
Framework", RFC 6749, DOI 10.17487/RFC6749,
October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Token (JWT)", RFC 7519, DOI 10.17487/RFC7519,
May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource
Names (URNs)", RFC 8141, DOI 10.17487/RFC8141,
April 2017,
<https://www.rfc-editor.org/rfc/rfc8141>.
[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,
<https://www.rfc-editor.org/rfc/rfc8551>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J.
Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[semver] Preston-Werner, T., "Semantic Versioning 2.0.0",
2013, <https://semver.org/>.
[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,
<https://lmsys.org/blog/2024-07-01-routellm/>.
[PLPES] Reilly, L. J., "Protocol Layer Prompt Engineering
Specification (PLPES)", Internet-Draft
draft-reilly-plpes-00, April 2026,
<https://datatracker.ietf.org/doc/draft-reilly-plpes/>.
[REM] Reilly, L. J., "Reilly EternaMark (REM) Protocol:
Dual-Layer Digital Permanence for Intellectual
Property", Internet-Draft draft-reilly-rem-protocol-01,
<https://datatracker.ietf.org/doc/draft-reilly-rem-protocol/>.
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.
Author's Address
Lawrence J. Reilly Jr.
Independent
Email: lawrencejohnreilly@gmail.com