Public Draft v0.8

RFC-0509: Receiving-Boundary Reliance Grammar

Proof attributes meet receiver requirements before local reliance can attach.

RFC-0509 is a public, neutral HTTP-compatible grammar for consequential actions where proof created by one system must be evaluated by another independently governed receiving domain.

Download Public Draft PDF Download v0.8 Version Note Read the summary

Controlling premise

Better proof is supply. Receiver need is demand. RFC-0509 is the grammar that lets them meet at the boundary.

The receiver still decides whether the proof fits this action, under this rulebook, now.

Summary

Standardize the boundary, not the proof object.

AI and agentic systems increasingly generate consequential actions and associated proof objects: logs, attestations, receipts, credentials, traces, approvals, policy checks, model records, runtime records, execution evidence, and compliance artifacts.

Those proof objects will not converge into one universal format. A proof object can explain what happened upstream. It does not, by itself, tell a receiving domain whether it can rely on that proof here, for this action, under this rulebook, now.

Version v0.8 hardens the draft around receiver-side outcome vocabulary, receiver-signed local outcome records, object-verifiable versus attested attributes, argument-commitment posture, interested-receiver risk, and receiver-side conformance.

Document status
Public Draft v0.8
Scope
Neutral public boundary grammar only.
Submission status
Not an IETF submission.
Implementation status
No protected implementation mechanics.
Version note
Download the v0.8 Version Note

Why this exists

The market is producing more proof than receivers can safely use.

Without a receiving-boundary grammar, every receiving domain must implement bespoke interpretation logic for every upstream proof engine, governance platform, compliance framework, credential system, payment mechanism, agent runtime, attestation system, or audit package. That does not scale in an agentic environment.

Proof is proliferating

Every governance engine, audit system, credential issuer, policy platform, agent runtime, and proof engine can create proof.

Receivers remain sovereign

Each receiving domain has its own rulebook, current state, liability posture, consequence model, and local outcome formation.

Badges flatten the decision

A badge may improve legibility, but it cannot replace receiver-local judgment or create receiver-side reliance by itself.

What RFC-0509 does

It makes proof attributes and receiver requirements legible.

RFC-0509 gives proof suppliers a way to present proof-side attributes and gives receiving domains a way to express or reference receiver-side requirements.

In v0.8, the normative boundary outcome vocabulary is narrowed to ACCEPT, HOLD, NARROW, and REFUSE. Escalation, manual review, override, reconstruction, and notification are receiver-internal process states, not boundary outcomes.

Proof-side attributes
Trace completeness, freshness, custody posture, replayability, argument commitments, evidence links, and other inspectable inputs.
Receiver-side requirements
Receiver-declared needs, thresholds, action context, risk posture, rulebook, state requirements, verification classes, and outcome options.
Boundary outcomes
ACCEPT, HOLD, NARROW, and REFUSE describe what the receiver decided at the proof boundary.

What RFC-0509 is not

It is not a proof standard, badge, certification, or reliance authority.

RFC-0509 deliberately preserves receiver-side judgment. It does not certify proof objects, make evidence actionable by itself, decide reliance, allocate liability, compute economics, define legal effect, or disclose protected implementation architecture.

No universal proof object

Proof vendors and governance engines may create different proof objects. RFC-0509 does not force convergence.

No universal pass

Parsing RFC-0509 fields, mapping a proof-side profile, or issuing a signed record is not enough to create receiver-side reliance.

No protected mechanics

The public draft excludes private formation, enforcement, reliance-object, consequence-attachment, and economic implementation mechanics.

Core model

Proof supply meets receiver demand.

RFC-0509 is organized around one chain. The grammar supports the chain, but does not decide the values inside it.

1. Proof attributesWhat does the proof claim or demonstrate?

2. Receiver requirementsWhat does the receiver need for this action, under this rulebook, now?

3. FitDo the attributes satisfy the receiver’s requirement strongly enough?

4. Boundary outcomeDid the receiver ACCEPT, HOLD, NARROW, or REFUSE?

5. Local outcome recordWhat receiver-side evidence preserves reason, scope, and consequence?

HTTP/2 428 Precondition Required
receiver-requirements: <reference-or-envelope>
accept-proof: application/rfc0509-presentment+json
rfc0509-outcomes: ACCEPT, HOLD, NARROW, REFUSE

What v0.8 adds

v0.8 hardens the receiver-side boundary.

Verification classes

Separates object-verifiable attributes from custody-posture or deployment claims that require separate attestation.

Outcome records

Distinguishes proof-side presentment from receiver-signed local outcome records.

Outcome vocabulary

Uses ACCEPT, HOLD, NARROW, and REFUSE for boundary outcomes; internal process states remain receiver sovereign.

Argument commitments

Recognizes whole-payload, field-level, and selective-disclosure commitment postures.

Receiver conformance

Defines tests to distinguish real receiver-side reliance formation from field parsing or vendor-side evaluation.

Receiver posture

Treats interested-receiver or self-confirmation posture as a trust consideration, not an independence-certification regime.

Adjacent mechanisms

Useful inputs are not the receiver’s decision.

Authentication, authorization, credentials, attestations, receipts, logs, observability systems, concept dictionaries, audit packets, and settlement systems can all matter. RFC-0509 clarifies what they do not do: decide receiver-local reliance for every downstream consequence.

Authentication Authorization Credentials Attestations Receipts Audit logs Observability Concept dictionaries Settlement systems

Conformance is not reliance.
A system may use RFC-0509 vocabulary and still fail a receiver’s local requirement for a particular action.

Receiver-side conformance

Conformance is not parsing.

RFC-0509 receiver-side conformance requires preservation of receiver-controlled requirement expression, receiver-local fit, explicit boundary outcome, reason-code preservation, bounded scope and consequence, and an inspectable local outcome record.

The decisive questions are: Who owns the requirement? Who owns the outcome? Who bears the consequence?

Not sufficient
Field parsing, proof-side mapping, vendor-side scoring, or issuing a signed record alone.
Required posture
Receiver-controlled requirements and receiver-local outcomes.
Anti-capture rule
A vendor must not substitute its own criteria and market the result as receiver-side reliance formation.

Download

RFC-0509 Public Draft v0.8

The public draft is available for review, implementation discussion, interoperability research, proof-side profile mapping, and receiver-boundary design. The v0.8 Version Note summarizes the major changes from v0.7.1.

Download v0.8 PDF Download v0.8 Version Note Discuss RFC-0509