Summary

  • The 5 September revision of the individual RMRP Internet-Draft adds a signed Routing Completeness Attestation, or RCA, that compares processed routing events with written audit records for a defined window. It is work in progress, not an IETF standard or deployment record.
  • RMRP states the crucial limit plainly: an RCA is the audited system's claim about itself and does not prove completeness. Merkle proofs and external checkpoints protect records that exist; they cannot hash a call that was executed but never logged.
  • Independent reconciliation supplies the missing denominator. Provider billing can reveal spend without a matching routing record, but its scope and timing must be aligned before a variance can be treated as evidence rather than noise.

At 10:00, an enterprise AI gateway says it routed 100 requests. Its audit store contains 100 records. The records form a valid Merkle tree. The tree head was signed and published to an external archive. Every inclusion proof checks out.

Did the gateway route exactly 100 requests?

The evidence proves much less than the dashboard suggests. It can show that a particular record belongs to a particular committed set and that the set was not quietly rewritten after the checkpoint. It cannot reveal a 101st call that bypassed record creation. There is no leaf to inspect, no broken hash to find and no signature to reject.

That missing-event problem is the most consequential addition in revision 01 of the Reilly Model Routing Protocol. L. J. Reilly's individual Internet-Draft, dated 5 September and intended as Informational, proposes policy, routing, audit and cost records for multi-model AI systems. Its Datatracker state is I-D Exists. It is not an RFC, IETF consensus, implementation claim or certification scheme.

The 01 text is much larger than revision 00. It adds signatures, field commitments, score attestations, aggregate budgets, Merkle proofs, outside checkpoints, revocation, conformance levels and cost reconciliation. The useful news is not that a new acronym can govern AI. It is that the revision tries to distinguish four questions that audit programmes routinely collapse: was a record altered, was it included, was every event recorded, and does another system agree with the total?

Integrity starts after an event becomes a record

RMRP's Audit Log Record captures the routing decision, policy, model tier, outcome and related identifiers. Canonicalization and a signature make later changes detectable. RFC 8785 provides deterministic JSON representation; RFC 7515 supplies the signature envelope. Those tools answer a precise question: do the verified bytes match what the holder of this key signed?

A hash chain can show a discontinuity in a sequence already being checked. A Merkle tree, following the construction associated with Certificate Transparency, lets a verifier test whether one audit record is a member of the committed tree without retrieving the whole store. A consistency proof can show that a later tree extends an earlier tree rather than replacing it.

None of these primitives sees the execution path before record creation. If the routing engine performs an inference call and suppresses both its Audit Log Record and its Cost Attribution Record, the cryptography can remain perfectly valid. The surviving tree is an authentic commitment to an incomplete set.

This is not a cryptographic defect. It is a denominator problem. Integrity asks whether recorded facts changed. Completeness asks whether the population of recorded facts matches the population of relevant events. The second question needs a count or trace from somewhere that did not depend on the same record-creation decision.

An outside checkpoint protects history, not population

Revision 01 is unusually candid about operator custody. A tree head signed by the same operator that controls the audit store, it says, bounds nothing the operator could not also alter. RMRP therefore defines a checkpoint: publish the signed tree head to a target outside the deployment's administrative control, such as a timestamp service, transparency log or archival deposit.

That makes retroactive editing harder. A checkpoint marked PENDING must not be sold as attested. Multiple independent targets raise the cost of altering history, but the draft warns against calling the result immutable. The checkpoint interval also matters: a daily external anchor gives a different exposure window from a five-minute one.

External anchoring still begins with the tree the routing engine chose to build. If an unlogged call never contributed a leaf, publishing the root more widely reproduces the same omission with stronger evidence that the remaining set was preserved. The witness is independent with respect to custody of the root, not necessarily with respect to enumeration of the underlying calls.

The distinction should appear in every assurance claim. “Externally anchored” means the committed history has an outside timestamp or witness. It does not mean the witness observed every AI request.

The RCA makes lying more attributable

At RMRP conformance level C3, a router must periodically issue a Routing Completeness Attestation. The RCA names a time window and routing engine. It declares the number of routing events processed, the number of audit records written, counts by outcome and model tier, the covering tree head and the preceding RCA. If event and record counts differ, a discrepancy note is required. The link to the previous RCA makes a missing attestation window visible.

The signature is meant to use a Routing Engine key distinct from a Policy Authority key. That prevents one credential from silently standing in for two roles. It does not guarantee that two people, teams or legal entities control those keys. The draft's own threat model says protocol rules can demand key separation but cannot force organisational separation.

Most importantly, the document does not pretend the RCA closes the loop. It calls the RCA a statement by the audited system about its own completeness and says it “does not prove completeness.” An operator willing to omit an event and sign falsely is not technically prevented. What changes is attribution: a silent absence becomes inconsistent with a signed, time-bounded declaration.

That difference can be valuable. A vague dashboard can later be explained as a software defect, a query boundary or an undocumented exclusion. A signed RCA fixes the claimed scope, count, engine and sequence. It creates a durable object that an auditor, counterparty or board can compare with other evidence. But it is evidence to appraise, not an appraisal result. RFC 9334's attestation architecture is useful here: evidence, appraisal policy and the resulting trust decision are separate objects.

Provider billing supplies an independent count—within limits

RMRP's strongest answer appears in the Cost Reconciliation Record. The routing system periodically totals its Cost Attribution Records and compares them with cost reported by the model provider for the same provider, cost centre, period and scope. A field for unattributed cost captures provider-reported spend for which no routing cost record exists.

The draft says reconciliation is the only control it specifies that can detect inference performed entirely outside the routing engine. That is the right causal claim. A provider ledger is produced on the far side of the API call, so it may contain evidence of execution even when the internal router produced nothing.

It is not an oracle. Invoice windows may close in another timezone. Retries, cached tokens, free tiers, rounding, committed-use discounts, delayed usage records and shared credentials can all produce variance. A dollar total may identify missing spend without identifying the exact prompt, policy or human actor. The provider itself can have measurement or reporting errors.

Reconciliation therefore needs matching dimensions, not just two totals. Compare request counts as well as cost where available. Bind provider account, credential, model, region, cost centre and UTC window. Preserve raw provider evidence and the transformation that maps it to internal records. Define tolerances before the variance appears. A mismatch is an investigation trigger; it is not, by itself, proof of fraud.

Conformance labels compress different kinds of assurance

RMRP defines cumulative levels. C2 signs records. C3 adds RCA, key separation, revocation and aggregate budgets. C4 adds Merkle inclusion proofs, outside checkpoints, hash-migration planning and provider-bill reconciliation.

Those labels are useful procurement shorthand only if their operating parameters travel with them. A C4 claim without its checkpoint interval, anchor custody, reconciliation interval, provider-account scope, error tolerance and exception history tells a leader which controls are nominally present but not what they could actually detect.

Heng Lu's Reality Layers gives the right discipline. A protocol document, conformance declaration, signed RCA, committed audit tree, provider account and observed completed task occupy different evidence layers. Their agreement increases confidence. No layer acquires the powers of the others merely because a cryptographic seal connects two of them.

Running-Code Primacy sharpens the test: the decisive fact is the executed request and its observed cost and outcome, not the elegance of the record format. A draft can specify the receipt. Only independently reconciled operation can show what the receipt covered.