The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation
draft-morrison-binding-moment-envelope-04
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) | |
|---|---|---|---|
| Authors | Blake Morrison , Christopher Whiteside | ||
| Last updated | 2026-10-12 | ||
| 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-morrison-binding-moment-envelope-04
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational C. Whiteside
Expires: 16 April 2027 Independent
13 October 2026
The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-
Principal Decision Moments with Dual-Veto Reconciliation
draft-morrison-binding-moment-envelope-04
Abstract
This memo specifies the briefing-and-binding envelope: a delivery
contract for the wire-level structure by which an artificial-
intelligence agent surfaces a consequential decision to the human
principal it acts for, and by which the principal commits, declines,
amends, or rejects that decision. The envelope carries eight named
slots (a synopsis, findings, recommendations, an offer of detail, a
question stem, a set of options each marked with its own reasoning, a
single recommended option, and a pair of escape hatches) and is
emitted as a structured field of a Model Context Protocol tool
result. The envelope is renderer-agnostic, so the briefing an agent
delivers and the binding a principal commits back have one machine-
checkable shape across every consuming surface. The memo also
specifies a dual-veto handshake: one escape hatch lets the principal
revise the answer space while accepting the question; the other lets
the principal reject the question itself and reopen deliberation.
Either party may veto. The memo defines a content digest over the
envelope, canonicalized under JCS and hashed with SHA-256, so that a
resolution names the exact envelope it resolves and an external
receipt can reference that envelope by digest. The memo is
Informational. No new transport is introduced; the envelope composes
with the handle namespace of draft-morrison-identity-pronouns and the
MCP tool surface of draft-morrison-org-alter-policy-provision.
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/.
Morrison & Whiteside Expires 16 April 2027 [Page 1]
Internet-Draft Binding-Moment Envelope October 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 16 April 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Briefing-and-Binding Envelope . . . . . . . . . . . . . . 7
5. Slot Grammar . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Slot 1: Synopsis . . . . . . . . . . . . . . . . . . . . 8
5.2. Slot 2: Findings . . . . . . . . . . . . . . . . . . . . 8
5.3. Slot 3: Recommendations . . . . . . . . . . . . . . . . . 8
5.4. Slot 4: Offer . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Slot 5: Question Stem . . . . . . . . . . . . . . . . . . 9
5.6. Slot 6: Options . . . . . . . . . . . . . . . . . . . . . 9
5.7. Slot 7: Recommended Option . . . . . . . . . . . . . . . 10
5.8. Slot 8: Escape Hatches . . . . . . . . . . . . . . . . . 10
5.9. The meta Slot . . . . . . . . . . . . . . . . . . . . . . 11
6. The Envelope Digest . . . . . . . . . . . . . . . . . . . . . 11
6.1. Canonical Form . . . . . . . . . . . . . . . . . . . . . 11
6.2. Digest Computation . . . . . . . . . . . . . . . . . . . 12
6.3. Profile Bounds . . . . . . . . . . . . . . . . . . . . . 12
6.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. The Dual-Veto Handshake . . . . . . . . . . . . . . . . . . . 14
7.1. Agent-Side Veto . . . . . . . . . . . . . . . . . . . . . 15
7.2. Principal-Side Veto: Two Hatches . . . . . . . . . . . . 15
7.3. Resolution . . . . . . . . . . . . . . . . . . . . . . . 16
8. MCP Delivery Binding . . . . . . . . . . . . . . . . . . . . 17
8.1. Envelope Placement . . . . . . . . . . . . . . . . . . . 17
8.2. Tool-Manifest Advertisement . . . . . . . . . . . . . . . 18
8.3. Staged Adoption . . . . . . . . . . . . . . . . . . . . . 18
8.4. Single-Surface Delivery, Not Broadcast . . . . . . . . . 18
Morrison & Whiteside Expires 16 April 2027 [Page 2]
Internet-Draft Binding-Moment Envelope October 2026
9. Renderer Contract . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Invariants . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Native Variation . . . . . . . . . . . . . . . . . . . . 19
9.3. Fallback Rendering . . . . . . . . . . . . . . . . . . . 19
10. Relationship to Companion Memos . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12.1. Synthesis Spoofing . . . . . . . . . . . . . . . . . . . 21
12.2. Recommendation as Coercion . . . . . . . . . . . . . . . 21
12.3. Hatch Suppression . . . . . . . . . . . . . . . . . . . 22
12.4. Confirmation Routing Under Concurrent Sessions . . . . . 22
12.5. Resolution Misbinding and Replay . . . . . . . . . . . . 22
12.6. Option-Map Substitution . . . . . . . . . . . . . . . . 23
12.7. Canonicalization Divergence . . . . . . . . . . . . . . 23
12.8. Malformed-Envelope Handling . . . . . . . . . . . . . . 24
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
15. Document History . . . . . . . . . . . . . . . . . . . . . . 25
16. Normative References . . . . . . . . . . . . . . . . . . . . 27
17. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
An artificial-intelligence agent operated on behalf of a human
principal periodically reaches a point at which it has synthesised a
position and must obtain the principal's commitment before acting:
whether to release a scoped view of the principal's data to a third
party, whether to accept or decline a delegated action, whether to
acknowledge a recommendation, whether to proceed with a step that
changes external state. This memo names that point a _binding
moment_ and specifies the wire-level structure through which a
binding moment is delivered and resolved.
In current practice the structure of a binding moment is per-tool ad
hoc. One agent tool returns a free-text question; another returns a
list of options with no synthesis; a third returns a state dump and
leaves the principal to perform the synthesis themselves. This has
two effects. The principal cannot acquire a stable scanning habit,
because the shape of the decision changes with every tool. The more
serious effect is that an agent that returns a bare menu of options
has pushed the cost of deliberation back onto the principal. The
agent has measured but not committed, and the interface has become
soft-coercive: the principal must either pick from a frame they did
not author or abandon the interaction.
Morrison & Whiteside Expires 16 April 2027 [Page 3]
Internet-Draft Binding-Moment Envelope October 2026
This memo specifies a single delivery contract, the briefing-and-
binding envelope, that addresses both problems. The envelope has a
fixed eight-slot grammar. The first four slots are the _briefing_: a
pre-synthesised, scannable account of what the agent observed and
what it concluded. The last four slots are the _binding_: a
quantised decision, a recommended path, and two escape hatches. The
envelope is emitted as a structured field of a Model Context Protocol
[MCP] tool result, and any consuming surface (a command-line client,
a mobile consent sheet, a desktop notifier, an agent-runtime hook)
renders the same eight slots into its native user interface.
A binding moment is consensual only if both parties can refuse it.
The _dual-veto handshake_ gives each party a way to do so. The agent
refuses by declining to emit a binding moment at all when it cannot
commit to a position: a binding moment with a hedged synopsis is
malformed. The principal refuses through two distinct escape
hatches: one revises the _answer space_ (the principal accepts the
question but answers on their own terms), the other revises the
_question space_ (the principal rejects the question itself and
reopens deliberation). Without both hatches the envelope degrades to
a forced-choice interface and the briefing slots no longer inform a
free choice. Section 7 specifies the handshake.
This memo specifies a delivery contract and a veto handshake and
nothing further. The envelope is a transient payload: it is emitted,
rendered, resolved, and the resolution is returned. What an
implementation durably records of that exchange, and under what
attribution, is a matter for the audit-signal mechanism of
[POLICYPROV] and is not constrained here.
Cognitive processing of any request or response is likewise out of
scope, and the onus lies with the entities themselves. This memo
constrains the structure of what is delivered and how it is resolved.
It does not constrain, and makes no claim about, how an agent reaches
the position it synthesises or how a principal reaches the answer
they give.
2. Conventions and Definitions
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 the purposes of this document.
Principal The human on whose behalf an agent acts, identified by a
Morrison & Whiteside Expires 16 April 2027 [Page 4]
Internet-Draft Binding-Moment Envelope October 2026
Sovereign-tier ~handle as defined by [IDPRONOUNS].
Agent An artificial-intelligence runtime acting for a principal,
identified by an Instrument-tier ~handle per [IDPRONOUNS]. The
agent is the party that emits a briefing-and-binding envelope.
Binding moment A point in an agent's operation at which it has
synthesised a position and requires the principal's commitment,
decline, amendment, or rejection before proceeding.
Briefing-and-binding envelope The eight-slot structured payload
defined by this memo, emitted by an agent at a binding moment as a
field of an MCP tool result.
Briefing slots The first four slots of the envelope (synopsis,
findings, recommendations, offer). Pre-synthesised material the
principal scans.
Binding slots The last four slots of the envelope (question stem,
options, recommended option, escape hatches). The quantised
decision the principal resolves.
Escape hatch A binding-slot affordance through which the principal
answers outside the enumerated options or rejects the question as
posed. Two are defined: the _answer-space hatch_, which accepts
the question and revises the answer; and the _question-space
hatch_, which rejects the question and reopens deliberation.
Dual veto The property that a binding moment may be refused by
either party: the agent by withholding a malformed binding moment,
the principal by invoking either escape hatch.
Consuming surface A client that receives an MCP tool result carrying
a briefing-and-binding envelope and renders the eight slots into a
native user interface.
Verifier A party that checks a resolution against the envelope it
names before acting on it. The agent may be the verifier.
Relying party A party other than the principal that acts on a
resolution, or on a record of one. The agent may be the relying
party.
Resolution The principal's response to a binding moment: selection
of an option, invocation of the answer-space hatch with an answer,
invocation of the question-space hatch, or a decline.
Morrison & Whiteside Expires 16 April 2027 [Page 5]
Internet-Draft Binding-Moment Envelope October 2026
Where this memo writes a principal's or an agent's handle in prose as
an identifier, the identifier is an alter: URI as defined in
[ALTER-URI], for example alter:~alice. The envelope and the
resolution carry no handle. A handle carried as a wire-format value
by a companion memo keeps the bare form that memo defines; the value
~alice corresponds to the URI alter:~alice.
3. Architecture
The briefing-and-binding envelope is a payload carried by the
existing request/response semantics of the Model Context Protocol
[MCP] and introduces no new transport, no new handle category, and no
new discovery mechanism.
The arrangement has three roles and one round trip.
The _agent_ reaches a binding moment in the course of operating for
its principal. Instead of returning an ad hoc question, it
constructs a briefing-and-binding envelope and emits it as a
structured field of the MCP tool result.
The _consuming surface_ receives the tool result, detects the
envelope field, and renders the eight slots into its native
interface. The consuming surface performs no synthesis: the briefing
slots are rendered as written; the binding slots are rendered as the
interactive decision element the surface natively supports.
The _principal_ observes the rendered briefing, resolves the binding,
and the resolution is returned to the agent as the input to the next
tool invocation.
The round trip is therefore: agent emits envelope -> surface renders
-> principal resolves -> resolution returns to agent. No state is
held between trips by the envelope itself. An envelope is valid only
for the single resolution it solicits; an agent that requires a
further commitment emits a further envelope.
This memo specifies the envelope (Section 4), the slot grammar
(Section 5), the envelope digest (Section 6), the dual-veto handshake
(Section 7), the MCP delivery binding (Section 8), and the renderer
contract (Section 9).
Morrison & Whiteside Expires 16 April 2027 [Page 6]
Internet-Draft Binding-Moment Envelope October 2026
4. The Briefing-and-Binding Envelope
An agent at a binding moment SHALL emit a briefing-and-binding
envelope as a structured field, named binding_moment, of the MCP tool
result it returns. The field's value is a JSON [RFC8259] object with
exactly the members specified below. In the block below, <string>,
<integer> and <boolean> each stand for a value of that type, "..."
stands for further entries of the same form, and text after a
semicolon is a comment. The block is a type sketch and does not
parse as JSON; Section 6.4 gives a complete envelope.
{
"binding_moment": {
"synopsis": <string>,
"findings": [ <string>, ... ],
"recommendations": [ <string>, ... ],
"offer": <string>,
"question": {
"stem": <string>,
"options": [
{ "label": <string>,
"reasoning": <string>,
"action_digest": <string> },
...
],
"recommended_idx": <integer>,
"hatches": {
"free_text": <boolean>,
"dialogue": <boolean>
}
},
"meta": {
"decision_class": <string>, ; OPTIONAL
"calibration_note": <string> ; OPTIONAL
}
}
}
The members synopsis, findings, recommendations, offer, and question
are REQUIRED. The member meta is OPTIONAL; when present, both of its
members are individually OPTIONAL.
A consuming surface that receives a tool result with a binding_moment
field that is not a well-formed envelope (for example, a missing
REQUIRED member, a member of the wrong type, a member not defined by
this memo, an out-of-range recommended_idx, or an options list with
fewer than two or more than four entries) SHALL treat the binding
moment as malformed. A malformed binding moment SHALL NOT be
Morrison & Whiteside Expires 16 April 2027 [Page 7]
Internet-Draft Binding-Moment Envelope October 2026
rendered as a decision; the surface SHOULD instead render the
underlying tool result in its fallback non-envelope form
(Section 9.3) and SHOULD surface a diagnostic indicating the envelope
was discarded.
The eight slots referenced throughout this memo are: (1) synopsis,
(2) findings, (3) recommendations, (4) offer, (5) question stem, (6)
options with per-option reasoning, (7) the recommended option, and
(8) the escape hatches. Slots 1 through 4 are the briefing slots;
slots 5 through 8 are the binding slots.
5. Slot Grammar
This section specifies the content contract for each slot. The
contract is partly machine-checkable (cardinality, type) and partly a
construction discipline the agent SHALL observe for the envelope to
be well-formed in the sense Section 4 requires.
5.1. Slot 1: Synopsis
synopsis is a string carrying a single sentence that states the
agent's position answer-first. The synopsis SHALL commit to a
position. A synopsis that hedges (one that defers the decision
rather than stating it) renders the envelope malformed: if the agent
cannot commit, the binding moment is premature and the agent SHOULD
instead return non-binding-moment material that surfaces state and
requests permission to deliberate further. The synopsis is the slot
that carries the decision if the principal scans nothing else.
5.2. Slot 2: Findings
findings is a JSON array of strings. Each string is one terse
observation on which the synopsis rests. An array of three to six
entries is RECOMMENDED. Each finding SHALL add an observation the
synopsis does not itself carry; a finding that restates the synopsis
or recapitulates the principal's prior input is filler and SHOULD be
omitted.
5.3. Slot 3: Recommendations
recommendations is a JSON array of strings. Each string is one
concrete move: an action that would change state if taken. An array
of two to four entries is RECOMMENDED. A recommendation that names a
consideration rather than an action ("weigh the trade-offs") does not
satisfy the slot.
Morrison & Whiteside Expires 16 April 2027 [Page 8]
Internet-Draft Binding-Moment Envelope October 2026
5.4. Slot 4: Offer
offer is a string offering the principal bounded, on-demand
elaboration of any briefing item (for example, "Ask for detail on any
item."). The offer is a bounded-pull affordance: depth is available
when the principal requests it and is never pushed into the briefing.
5.5. Slot 5: Question Stem
question.stem is a string carrying a single neutral, plain-language
sentence that poses the decision. The stem SHALL NOT be leading: it
SHALL NOT embed the agent's recommendation, and it SHALL NOT be
phrased to make one option the path of least resistance. The agent's
lean is carried by slot 7, on the option, never by the stem.
5.6. Slot 6: Options
question.options is a JSON array of objects. The array SHALL contain
at least two and at most four entries. Each entry is an object with
three REQUIRED string members:
label A short, action-shaped statement of the option.
reasoning A single line stating why the principal might choose this
option. The reasoning lives on the option, not in the stem; the
principal can read the comparison without working it out.
action_digest The digest of the action this option authorises, in
the string form of Section 6.2.
This memo does not define the action or its canonical bytes. The
action is an external artifact, and the profile that carries it
defines both. Where that profile pins JCS [RFC8785], the digest is
computed as in Section 6.2 over the action in place of the envelope,
and the profile bounds of Section 6.3 apply to it.
The digest is computed over the action itself. A verifier holding
the action it is about to perform recomputes the digest and compares
(Section 7.3). It does not resolve an identifier, consult a table,
or ask a relying party what the index meant.
Where the same action is also covered by an authorization receipt of
[EPRECEIPTS], that memo's action hash is its own identifier and is
not assumed to equal an action_digest (Section 3 of [EPRECEIPTS]). A
relying party that compares the two does so under the mapping that
memo requires, and this memo adds nothing to it.
Morrison & Whiteside Expires 16 April 2027 [Page 9]
Internet-Draft Binding-Moment Envelope October 2026
An option SHALL carry the digest of exactly one action, and an
action_digest not in the form of Section 6.2 makes the envelope
malformed (Section 4). An option that authorises no action is not a
slot 6 entry. A response that reopens deliberation is the question-
space hatch (Section 5.8), and a response that refuses to act is a
decline (Section 7.3).
The options enumerate the substantive answers to the question. They
do not include the escape hatches; the hatches are slot 8 and are not
members of the options array.
5.7. Slot 7: Recommended Option
question.recommended_idx is an integer: the zero-based index, into
the options array, of the option the agent recommends. Exactly one
option SHALL be marked. recommended_idx SHALL be present, SHALL be
non-negative, and SHALL be strictly less than the length of the
options array; an absent value is malformed.
The recommended option is the agent's committed synthesis offered as
a contestable position; the principal validates it or vetoes it.
Where the agent's analysis ties two options, the agent SHALL still
mark exactly one: the synopsis names the tie, and the mark SHALL fall
on the option that minimises the cost of being wrong.
5.8. Slot 8: Escape Hatches
question.hatches is a JSON object with two REQUIRED boolean members:
free_text The _answer-space hatch_. When true, the consuming
surface SHALL render an affordance through which the principal may
submit a free-form answer instead of selecting an option.
Invoking this hatch accepts the question as posed and revises the
answer.
dialogue The _question-space hatch_. When true, the consuming
surface SHALL render an affordance through which the principal may
reject the question itself and reopen deliberation with the agent.
Invoking this hatch rejects the framing.
Both members are normally true. An agent that emits a binding moment
with either hatch set to false removes a veto path and SHALL do so
only where the corresponding revision is inapplicable. Section 7
specifies the handshake the hatches realise.
Morrison & Whiteside Expires 16 April 2027 [Page 10]
Internet-Draft Binding-Moment Envelope October 2026
5.9. The meta Slot
meta, when present, MAY carry two members. decision_class is a
string naming the category of the decision (for example, a consent
decision, a permission-delta decision, a recompute decision); a
consuming surface MAY use it to select a rendering style.
calibration_note is a string carrying a short correcting preface,
included only when the agent's prior framing in the session now reads
as materially understating what the agent has since concluded. The
note is a costly signal and SHALL NOT be emitted ritually; an
implementation SHOULD monitor the rate at which calibration_note is
populated and treat a persistently high rate as a defect in the
agent's earlier framing rather than as normal operation.
6. The Envelope Digest
A binding moment is a decision, and a decision that cannot afterwards
be named cannot be audited, contested, or carried into any durable
record. The envelope does not itself persist (Section 3 and
Section 13), so a durable record of a resolved binding moment has to
reference the envelope rather than contain it. This section defines
that reference: a content digest over the envelope, computed
identically by every implementation.
The digest has three consumers. A resolution names the envelope it
resolves (Section 7.3). An audit signal recorded through the durable
channel of [POLICYPROV] names the envelope a principal was shown. An
external receipt that binds a named human approver to an action, such
as the authorization receipt of [EPRECEIPTS], references the envelope
by digest.
6.1. Canonical Form
The envelope is delivered as a JSON [RFC8259] object (Section 4).
Its canonical form is the JSON Canonicalization Scheme [RFC8785]
applied to the value of the binding_moment member. That value alone
is canonicalized, not the enclosing tool result, whose other members
are outside the scope of this memo.
JCS is defined over the JSON data model the envelope already
inhabits, so a verifier that can read the envelope can check its
digest without acquiring a second codec. An implementation MUST NOT
canonicalize the envelope by any other scheme.
Morrison & Whiteside Expires 16 April 2027 [Page 11]
Internet-Draft Binding-Moment Envelope October 2026
6.2. Digest Computation
The envelope digest is the SHA-256 [FIPS180-4] digest of the
canonical form, presented as the string sha256: followed by exactly
64 lowercase hexadecimal characters.
envelope-digest = "sha256:" 64HEXDIGLOWER
; over JCS(binding_moment)
The string form is the form [EPRECEIPTS] uses for its hash members
(sha256: followed by 64 lowercase hexadecimal characters), so a
receipt referencing an envelope carries the value verbatim and
neither memo transforms the other's material at the boundary.
6.3. Profile Bounds
Any divergence between two implementations' canonicalization
behaviour is a divergence in the digest, and therefore a misbinding
hazard: the two parties disagree about which envelope a resolution
names. An implementation MUST reject the following inputs rather
than normalise them, and MUST reject them identically.
Duplicate member names An object whose member names collide after
escape decoding. An implementation that silently retains one of
the two digests material its peer did not send. A verifier handed
an already-parsed value cannot observe this class at all, so the
check MUST be applied at the parse boundary.
Unpaired surrogates A string carrying a UTF-16 surrogate code point
without its pair. Such a string has no UTF-8 encoding, and
implementations differ in whether they substitute, drop, or
reject.
Numbers outside the integer profile A number that is not an integer,
or an integer of magnitude greater than 2^53-1. The only number
the envelope grammar carries is recommended_idx (Section 5.7), a
small non-negative integer, so this bound costs the grammar
nothing. It removes the floating-point formatting rules that are
the main source of canonicalization divergence between
implementations in practice.
Excessive nesting A container nested more deeply than 64. The
envelope grammar is of fixed and shallow depth, so this bound
reaches only pathological input.
These bounds are those of the canonicalization profile in
Section 13.12 of [EPRECEIPTS] (revision -13), adopted here without
variation. An envelope digest and a receipt that references it are
Morrison & Whiteside Expires 16 April 2027 [Page 12]
Internet-Draft Binding-Moment Envelope October 2026
checked by the same verifier, and a verifier obliged to hold two
canonicalization profiles at once is a defect in the pair of memos
rather than in the verifier.
6.4. Example
The two options authorise these two actions. They are illustrative:
the profile that carries an action defines it (Section 5.6), and here
each action's digest is computed as in Section 6.2 over the action
shown.
{
"disclose": ["travel_dates"],
"recipient": "booking.example"
}
{
"disclose": ["passport_number", "travel_dates"],
"recipient": "booking.example"
}
Their action digests are the string sha256: followed by, in order,
these 64 hexadecimal characters:
ff91e3166e64b892004d4b43b05ad6ed7ff0819463da80c72f27f47039c033fa
49be14ae6e74b950c0c7b790fa22538d45fb4853bb0f3b242b28204bee232945
The following is the value of a binding_moment member that offers
them. It is shown with whitespace added for reading, and each
action_digest is cut to its first 12 hexadecimal characters and "..."
to fit the line. With the full values in place, its canonical form
(Section 6.1) is 895 bytes long.
Morrison & Whiteside Expires 16 April 2027 [Page 13]
Internet-Draft Binding-Moment Envelope October 2026
{
"synopsis":
"Share the travel dates and withhold the passport number.",
"findings": [
"The booking service asks for dates and passport number.",
"Dates are enough to hold the reservation.",
"The passport number is only needed at check-in."
],
"recommendations": [
"Release the travel dates now.",
"Withhold the passport number until check-in."
],
"offer": "Ask for detail on any item.",
"question": {
"stem": "What should be shared with the booking service?",
"options": [
{
"label": "Share dates only",
"reasoning":
"Holds the booking and keeps the passport number private.",
"action_digest": "sha256:ff91e3166e64..."
},
{
"label": "Share dates and passport number",
"reasoning": "Avoids a second request at check-in.",
"action_digest": "sha256:49be14ae6e74..."
}
],
"recommended_idx": 0,
"hatches": { "free_text": true, "dialogue": true }
}
}
Its envelope digest is the string sha256: followed by these 64
hexadecimal characters:
0db384ab1b682c115d79babfefa91f014ad80c007d00c79119d748f32be232d1
7. The Dual-Veto Handshake
The defining property of a binding moment, as opposed to a
notification, is that either party may refuse it. This section
specifies the handshake.
Morrison & Whiteside Expires 16 April 2027 [Page 14]
Internet-Draft Binding-Moment Envelope October 2026
7.1. Agent-Side Veto
The agent's veto is exercised by _not emitting a binding moment_. An
agent reaches many points at which a principal-facing question would
be premature: the agent has not yet synthesised a position, or the
available options do not yet partition the decision, or the agent
needs to deliberate further before it can commit. At such a point
the agent SHALL NOT emit a briefing-and-binding envelope. It SHOULD
instead return material that surfaces its current state and requests
the principal's permission to continue deliberating. Emitting an
envelope with a hedged synopsis (Section 5.1) is the failure this
rule forbids: it presents the appearance of a committed decision
while pushing the synthesis cost back to the principal.
The agent-side veto is therefore a precondition on emission: a well-
formed envelope is one the agent has not vetoed.
7.2. Principal-Side Veto: Two Hatches
The principal's veto is exercised through the two escape hatches of
slot 8. The two hatches refuse different things.
The _answer-space hatch_ (free_text) refuses the _quantisation_ while
accepting the _frame_. The principal agrees the agent has asked the
right question but holds an answer not among the enumerated options.
Invoking this hatch returns a free-form answer. The agent
incorporates the answer, and where the answer calls for an action,
emits a further envelope whose option carries that action's digest.
The frame stands; the option set is treated as non-exhaustive.
The _question-space hatch_ (dialogue) refuses the _frame_ itself.
The principal judges that the agent has asked the wrong question, or
has asked a question that rests on a premise the agent does not have
grounds for, or that the decision is not ripe. Invoking this hatch
does not return an answer; it returns the binding moment to
deliberation. The agent SHALL treat a question-space veto as a
reopening: it SHALL NOT respond by re-emitting the same question, and
it SHALL NOT respond by emitting a further forced-choice envelope
without first incorporating the principal's objection. A question-
space hatch that leads only to another menu is a failure of the
handshake.
The handshake maps onto deliberative procedure. Selecting an option
is a vote. The answer-space hatch is an amendment to the motion.
The question-space hatch is a motion to refer the question back. An
interface that offers only the vote is forced-choice.
Morrison & Whiteside Expires 16 April 2027 [Page 15]
Internet-Draft Binding-Moment Envelope October 2026
7.3. Resolution
A binding moment is resolved by exactly one of: selection of an
option from slot 6; invocation of the answer-space hatch with a free-
form answer; invocation of the question-space hatch; or decline. The
consuming surface SHALL return the resolution to the agent in a form
that distinguishes which of the four occurred, because the agent's
correct continuation differs in each case. The resolution is carried
as the argument to the agent's next tool invocation under the [MCP]
semantics already in force. It is a JSON [RFC8259] object with
exactly the members specified below, in the notation of Section 4;
"|" separates the permitted values of a member.
{
"binding_moment_resolution": {
"envelope_digest": <string>,
"resolution": "option" | "answer" | "question"
| "declined",
"option_idx": <integer>, ; "option" only
"answer": <string> ; "answer" only
}
}
The member envelope_digest is REQUIRED. It carries the digest
(Section 6.2) of the envelope being resolved.
The member resolution is REQUIRED and distinguishes the four cases.
The value option denotes selection from slot 6; answer denotes the
answer-space hatch; question denotes the question-space hatch;
declined denotes the principal's negative answer to the question as
put.
The member option_idx carries the zero-based index into slot 6 of the
selected option. It is REQUIRED when resolution is option, MUST be
absent otherwise, and MUST be within range for the resolved
envelope's option list.
The member answer carries the principal's free-form answer. It is
REQUIRED when resolution is answer and MUST be absent otherwise.
The question-space hatch carries no further member. Its content is
the refusal itself, and the agent's continuation is to reopen
deliberation rather than to read a value.
The declined and question resolutions are distinct, and an
implementation SHALL NOT collapse them. The question-space hatch
rejects the question or its premises, and the agent's continuation is
to reopen deliberation. A decline accepts the question as well put
Morrison & Whiteside Expires 16 April 2027 [Page 16]
Internet-Draft Binding-Moment Envelope October 2026
and answers it in the negative. The question does not reopen, and
the agent's continuation is to stop. A decline recorded as an option
selection that happens to mean no can no longer be told apart from a
selection.
A declined resolution carries no further member. Its content is the
refusal itself, the agent reads no value to continue, and
envelope_digest names what was declined. A decline records that the
principal answered the question as put in the negative, and it
authorises no action. Because it names its envelope, it refuses that
envelope only and cannot be applied to another.
A verifier presented with a resolution of option SHALL, before
treating it as authority for an action, recompute the digest of the
action it is about to perform and compare it to the action_digest of
the option at option_idx in the envelope that envelope_digest names,
after confirming that the envelope it holds has that digest. Where
the two differ, the resolution remains a record that the principal
selected that option, and is not authority for the action performed.
A resolution of any other kind is not authority for any action.
An agent SHALL discard a resolution whose envelope_digest does not
match an envelope it emitted and has not already resolved. A
resolution naming an unknown envelope, or naming one already
resolved, is not a decision, and an agent that acts on one has acted
without its principal's commitment.
8. MCP Delivery Binding
The briefing-and-binding envelope is delivered as a structured field
of a Model Context Protocol [MCP] tool result. This section
specifies the binding.
8.1. Envelope Placement
An agent tool that surfaces a binding moment SHALL include, in the
tool result, a top-level member named binding_moment whose value is
the envelope object of Section 4. The remainder of the tool result,
the tool's ordinary domain payload, is unaffected: the binding_moment
field is additive. A tool result MAY therefore carry both its
conventional payload and a binding_moment envelope; a consuming
surface that does not understand the envelope ignores the field and
renders the conventional payload, and a surface that does understand
it renders the envelope.
Morrison & Whiteside Expires 16 April 2027 [Page 17]
Internet-Draft Binding-Moment Envelope October 2026
8.2. Tool-Manifest Advertisement
A tool that may emit a binding_moment envelope SHOULD advertise the
fact in its entry in the MCP tools/list manifest, by carrying a
boolean annotation (a RECOMMENDED name is emits_binding_moment). The
annotation lets a consuming surface decide, before any invocation,
whether to prepare its envelope renderer. The annotation is
advisory: a surface SHALL still inspect each tool result for the
binding_moment field, because a tool that sometimes emits an envelope
and sometimes does not is conformant.
8.3. Staged Adoption
A binding-moment-emitting tool MAY be introduced behind an
implementation-defined feature flag, so that the envelope and the
tool's conventional payload are emitted side by side during a
migration window and the conventional payload is the fallback. This
memo places no requirement on the flag mechanism; it notes only that
the additive placement of Section 8.1 makes such staged adoption
possible without a flag day.
8.4. Single-Surface Delivery, Not Broadcast
The briefing-and-binding envelope is delivered to the principal's own
consuming surface as the result of a tool the principal's agent
invoked. It is a one-to-one delivery between an agent and its
principal. The envelope is not a broadcast format: a payload that
informs or persuades a population, rather than soliciting one
principal's resolution of one decision, is outside the scope of this
memo and SHALL NOT be carried as a binding_moment envelope.
9. Renderer Contract
A consuming surface renders the eight slots into its native
interface. This section specifies what the rendering SHALL preserve
and what it MAY vary.
9.1. Invariants
A conforming renderer SHALL preserve the following across every
surface:
* All four briefing slots are rendered. A renderer SHALL NOT drop
the findings or the recommendations to save space; the briefing is
what allows the binding to be resolved quickly.
Morrison & Whiteside Expires 16 April 2027 [Page 18]
Internet-Draft Binding-Moment Envelope October 2026
* The recommended option (slot 7) is rendered as visibly
distinguished from the other options. The principal SHALL be able
to see, without acting, which option the agent recommends.
* Both escape hatches whose slot-8 boolean is true are rendered as
invocable affordances. A renderer SHALL NOT omit a hatch on the
grounds that the option set appears exhaustive; the hatches are
the principal's veto and their availability is not the renderer's
to withdraw.
* The per-option reasoning (slot 6) is rendered with, or made
immediately available from, each option. A renderer that shows
option labels but hides the reasoning has removed the comparison
and left the principal to deliberate unaided.
* An affordance to decline is rendered with the options. A decline
is a resolution of its own (Section 7.3), and a renderer SHALL NOT
leave the principal to express it by selecting an option that
means no or by invoking the question-space hatch.
9.2. Native Variation
Within the invariants of Section 9.1, a renderer MAY map the slots to
whatever native element it supports. A command-line client may
render the binding as an arrow-key picker with the escape hatches
bound to distinct keys. A mobile client may render it as a consent
sheet with chip-style options and the recommended chip styled
distinctly. A desktop notifier may render the synopsis as a
notification title and defer the full envelope to an expanded view.
An agent-runtime hook may render the envelope as plain text with a
labelled multiple-choice block. The eight slots and their semantics
are the same on every surface.
9.3. Fallback Rendering
A consuming surface that does not implement the envelope renderer, or
that has received a malformed envelope per Section 4, SHALL fall back
to rendering the tool result's conventional payload. Because the
binding_moment field is additive (Section 8.1), the conventional
payload is always present and the fallback is always available. A
surface SHOULD NOT fail an interaction solely because it could not
render an envelope.
10. Relationship to Companion Memos
This memo composes with the following Internet-Drafts.
Morrison & Whiteside Expires 16 April 2027 [Page 19]
Internet-Draft Binding-Moment Envelope October 2026
[IDPRONOUNS] supplies the ~handle namespace and the Sovereign /
Instrument trust-tier taxonomy. The principal is a Sovereign-tier
handle and the agent an Instrument-tier handle; this memo introduces
no new handle category.
[POLICYPROV] supplies the Model Context Protocol tool surface over an
identity substrate from which an agent retrieves policy and to which
it emits audit signals. The briefing-and-binding envelope is carried
by a tool result on that same surface; a binding moment and its
resolution are among the runtime events an implementation MAY record
through the audit-signal mechanism that memo specifies. This memo
specifies the transient delivery contract; [POLICYPROV] specifies the
durable audit channel. They are separate because the envelope does
not itself persist.
[IDCOMMITS] supplies the attribution grammar. Where an
implementation records a resolved binding moment, the attribution of
that record (the Sovereign-tier handle that resolved it and the
Instrument-tier handle that drafted the envelope) follows the trailer
grammar of [IDCOMMITS]. This memo does not place attribution slots
in the envelope itself; attribution is a property of any durable
record, not of the transient payload.
[MCPDNS] supplies the discovery mechanism by which a consuming
surface locates the MCP server whose tools emit envelopes. This memo
introduces no new discovery surface.
[SUBSTRATE] supplies the coordination posture for the case in which a
principal operates several agent sessions concurrently. A binding
moment emitted by one session and a binding moment emitted by another
are independent payloads; this memo does not coordinate them, and an
implementation that surfaces concurrent binding moments deconflicts
them under the substrate-observation posture of that memo rather than
through any mechanism specified here.
11. IANA Considerations
This memo requests no IANA action.
Morrison & Whiteside Expires 16 April 2027 [Page 20]
Internet-Draft Binding-Moment Envelope October 2026
The structured-field name binding_moment (Section 4) and the tool-
manifest annotation name emits_binding_moment (Section 8.2) are
illustrative of the reference implementation operated by one of the
authors. They are member names within a Model Context Protocol tool
result and tool manifest respectively; they are not protocol
identifiers requiring registration. A conforming implementation MAY
name these fields by any convention consistent with its MCP tool
schema. If a future revision of this memo, or a companion
specification, proposes a registry for canonical tool-result field
names, that revision will request the corresponding IANA action.
No new transport, port number, URI scheme, media type, or DNS record
type is introduced by this memo.
12. Security Considerations
The briefing-and-binding envelope is a delivery contract for
decisions a principal makes about an agent's behaviour. Its security
considerations concern the integrity of the decision; the envelope
holds no durable state to keep confidential.
12.1. Synthesis Spoofing
An agent, or a compromised tool impersonating one, may emit an
envelope whose briefing slots misrepresent what the agent observed,
inducing the principal to validate a recommendation grounded in
falsified findings. The envelope cannot prevent this; the briefing
is the agent's own account. Mitigation is twofold. First, the offer
slot (slot 4) and the answer-space hatch exist so the principal may
interrogate any finding or supply an answer the agent did not
anticipate; a renderer that drops the offer or the hatch
(Section 9.1) removes this defence. Second, the binding moment is a
tool result delivered over the [MCP] session, and an implementation
SHOULD authenticate the tool surface (for example via the
cryptographic identity envelope of [MCPDNS]) so that the principal's
agent is interacting with the server it intends.
12.2. Recommendation as Coercion
The recommended option (slot 7) carries the agent's lean. An agent
that consistently recommends the option most favourable to the
agent's operator, rather than to the principal, turns the envelope
into a manipulation surface. The structural mitigations are the
leading-stem prohibition (Section 5.5), which keeps the lean visibly
confined to the option rather than smuggled into the question, and
the question-space hatch, which lets the principal reject a frame
whose options are all skewed. An implementation SHOULD additionally
monitor the rate at which principals invoke the question-space hatch:
Morrison & Whiteside Expires 16 April 2027 [Page 21]
Internet-Draft Binding-Moment Envelope October 2026
a persistently high rate against a particular agent or decision class
is evidence that the option grammar is systematically mis-framed.
12.3. Hatch Suppression
An agent or a renderer that disables an escape hatch removes a veto
path. Disabling the question-space hatch in particular converts a
consensual binding moment into a forced choice. An agent SHALL set a
hatch to false only where the corresponding revision is inapplicable
(Section 5.8), and a renderer SHALL NOT omit a hatch the envelope
marks true (Section 9.1). An implementation SHOULD treat a binding
moment that disables a hatch as an event worth recording, so that
systematic hatch suppression is detectable by post-hoc audit through
the mechanism of [POLICYPROV].
12.4. Confirmation Routing Under Concurrent Sessions
Where a principal operates several agent sessions concurrently, a
binding moment that delegates a consequential action SHOULD be
rendered on a surface bound to the principal's own handle, so that an
agent session in possession of the principal's session credential
cannot resolve the binding moment on the principal's behalf. The
envelope itself does not route; routing is a property of the
consuming surface and of the session-credential discipline of
[POLICYPROV] and [SUBSTRATE].
12.5. Resolution Misbinding and Replay
A resolution that did not name its envelope could be applied to the
wrong one. Two hazards follow. A resolution captured from one
binding moment could be replayed against a later one, so that a
principal's assent to a small action becomes assent to a large one.
A resolution produced for one concurrent session could be applied by
another (Section 12.4), and because two envelopes need not order slot
6 alike, an index chosen against one selects a different option under
the other.
The envelope_digest member (Section 7.3) closes both. It names one
envelope, including its option ordering and its recommended option,
so a resolution is meaningful against exactly that envelope and is
discarded against every other. Two byte-identical envelopes share a
digest. An agent that poses the same question more than once, and
needs the resolutions kept apart, has to make the envelopes differ,
for example in the synopsis or findings. The digest binds a
resolution to an envelope; it does not route it, and the routing
discipline of Section 12.4 still applies.
Morrison & Whiteside Expires 16 April 2027 [Page 22]
Internet-Draft Binding-Moment Envelope October 2026
12.6. Option-Map Substitution
Where an option index carries no binding to an action, a verifier has
to be told which action the index meant, and that telling comes from
the relying party. A relying party that is compromised, or merely
mistaken, can then make an authentic selection authorise an action
the principal did not choose. The selection is real and the index is
correct. Only the meaning attached to the index is wrong, so nothing
the principal committed to contradicts it.
The action_digest member of Section 5.6 closes this by carrying the
meaning in the envelope the resolution names by digest. The verifier
recomputes the action's digest itself and compares it with the one
the principal was shown, so no outside map is consulted. The
envelope-digest binding of Section 12.5 continues to apply to the
resolution as a whole.
This memo defines no signature over a resolution. The binding is
therefore only as strong as whatever protects the resolution in
transit and at rest, for example an authorization receipt of
[EPRECEIPTS].
The member has two costs. It appears once per option, so an envelope
carrying the maximum four options grows by four digest strings, which
the slot grammar's own cap bounds. And the agent must know each
option's action digest when it constructs the envelope, so an
envelope cannot offer an option whose action is still being drafted.
Where an action is not yet settled, the agent asks instead a question
whose options select among ways of settling it.
12.7. Canonicalization Divergence
Every use of the envelope digest rests on two implementations
agreeing on the canonical bytes of one envelope. Where they
disagree, a resolution is discarded against the envelope it was
produced for, or accepted against one it does not. The profile
bounds of Section 6.3 are therefore normative, and they are
rejections rather than repairs. An implementation that normalises a
duplicate member name, substitutes an unpaired surrogate, or rounds
an out-of-profile number produces a digest over material no other
implementation reproduces, and the disagreement surfaces as a
misbinding rather than as a parse error.
Morrison & Whiteside Expires 16 April 2027 [Page 23]
Internet-Draft Binding-Moment Envelope October 2026
12.8. Malformed-Envelope Handling
A malformed envelope (Section 4) that a renderer still attempts to
render as a decision risks presenting the principal with a decision
whose options or recommendation are incoherent. A renderer SHALL
discard a malformed envelope and fall back to the conventional
payload (Section 9.3) rather than render a partial or repaired
decision.
13. Privacy Considerations
The briefing-and-binding envelope is a transient payload. It is
emitted, rendered, resolved, and discarded; this memo specifies no
durable store of envelopes and no log of resolutions. An
implementation that does record resolved binding moments does so
through the audit-signal mechanism of [POLICYPROV], and the privacy
considerations of that mechanism (significance-predicate scope,
argument redaction) apply to such records. This memo adds two
considerations specific to the envelope.
First, the briefing slots may contain, in the agent's findings, an
account of observations the agent has made about the principal or
about third parties. An agent SHOULD construct the findings slot to
the minimum needed for the principal to validate the decision, and
SHOULD NOT use the findings slot as an incidental disclosure channel
for material unrelated to the binding moment at hand.
Second, the principal's resolution, including a free-form answer
submitted through the answer-space hatch, is principal-authored
content returned to the agent. An implementation SHALL treat an
answer-space response with the same care as any other principal input
and SHALL NOT persist it beyond what the audit-signal significance
predicate of [POLICYPROV] requires.
14. Implementation Status
This section records implementation experience in the spirit of
[RFC7942] and is to be removed before publication as an RFC.
A reference implementation of the briefing-and-binding envelope is
operated by one of the authors against a production Model Context
Protocol server. An agent tool that records a submitted answer to a
conversational identity-discovery flow emits the envelope as an
additive binding_moment field of its tool result, behind a feature
flag, alongside the tool's conventional payload. The envelope's
eight slots are populated following Section 5 as it stood before this
revision: the synopsis and findings report the state of the discovery
flow, the follow-on question asks whether to continue while discovery
Morrison & Whiteside Expires 16 April 2027 [Page 24]
Internet-Draft Binding-Moment Envelope October 2026
questions remain, and the escape hatches are set per Section 5.8 with
the question-space hatch open and the free-text hatch closed.
Consuming surfaces render the envelope to a plain-text multiple-
choice block with a visibly marked recommended option and the open
hatch.
The recommended option is marked positionally in the reference
deployment rather than derived from an analysis of the options, so
the committed-synthesis property Section 5.7 requires of the mark is
not exercised by it.
The reference deployment predates the action_digest member of
Section 5.6 and the declined resolution of Section 7.3. Its options
carry no action_digest, and it does not handle a declined resolution.
Once no discovery questions remain, its envelope offers a single
option, below the minimum of two in Section 5.6. Its envelopes
therefore do not conform to this revision.
No claim of interoperability is made; the reference deployment is a
single deployment operated by one of the authors.
15. Document History
Section numbers in each entry are those of that revision.
draft-morrison-binding-moment-envelope-04 (October 2026):
* Adds the action_digest member to each option (Section 5.6), the
digest of the action the option authorises, and requires a
verifier to compare it with the action being performed before
treating a selection as authority for that action (Section 7.3).
Envelopes without it are now malformed.
* Adds declined as a fourth resolution (Section 7.3), distinct from
the question-space hatch, and requires a renderer to offer it
(Section 9.1). A decline authorises no action and stays bound to
its envelope.
* Adds Section 12.6 (option-map substitution). Canonicalization
divergence and malformed-envelope handling are now Sections 12.7
and 12.8.
* Adds an example envelope, the actions its options authorise, and
its digest (Section 6.4), and states that the blocks in Sections 4
and 7.3 are type sketches.
* Adds to Section 12.5 that two byte-identical envelopes share a
digest.
Morrison & Whiteside Expires 16 April 2027 [Page 25]
Internet-Draft Binding-Moment Envelope October 2026
* States in Section 2 that a handle written in prose as an
identifier is an alter: URI, and adds [ALTER-URI].
* Cites the canonicalization profile of [EPRECEIPTS] by section, and
gives each Internet-Draft reference its revision and date.
* Marks the malformed-envelope cases in Section 4 as examples and
adds the cases Sections 4 and 5.6 already imply.
* Corrects the cross-reference in Section 6 and the -01 and -02
entries of this history.
* Removes the default from the two hatch members in Section 5.8,
which are required and so always present.
* Removes the Acknowledgements. Editorial changes throughout.
draft-morrison-binding-moment-envelope-03 (September 2026):
* Corrects the Implementation Status to describe the single emitting
tool the reference deployment carries, and records that the
recommended option is marked positionally rather than derived from
an analysis of the options.
* Names the companion drafts in the Abstract by draft name in place
of citations.
* Editorial changes in Sections 1, 5.6, 7.2, 9.1 and 12.7, and in
the Acknowledgements.
draft-morrison-binding-moment-envelope-02 (September 2026):
* Adds Christopher Whiteside as co-author.
* Adds the out-of-scope statement on cognitive processing
(Section 1).
* Shortens the Acknowledgements.
draft-morrison-binding-moment-envelope-01 (July 2026):
* Adds the envelope digest (Section 6): JCS [RFC8785] canonical
form, SHA-256 [FIPS180-4] over it, and the sha256: string
presentation. The -00 bound no digest to the envelope, so a
resolution, an audit signal, or an external receipt had no way to
name the envelope it referred to.
Morrison & Whiteside Expires 16 April 2027 [Page 26]
Internet-Draft Binding-Moment Envelope October 2026
* Adopts the [EPRECEIPTS] canonicalization profile without variation
(Section 6.3), so that an envelope digest and a receipt
referencing it are checkable by one verifier holding one profile.
* Specifies the wire form of the resolution (Section 7.3), which -00
left unmandated. The resolution now names its envelope by digest.
* Adds Section 12.5 (resolution misbinding and replay) and
Section 12.6 (canonicalization divergence) to the security
considerations.
* Removes the hand-authored "Status of This Memo" section. The RFC
formatter emits that boilerplate from the document's own
attributes, so -00 carried it twice, and the duplicate was
numbered as Section 1. Every cross-reference in -00 was therefore
off by one against the rendered document: "the envelope
(Section 4)" resolved to "Architecture". All cross-references are
corrected here.
* Corrects the fallback-rendering cross-reference in Section 4,
which cited the native-variation subsection rather than the
fallback subsection.
draft-morrison-binding-moment-envelope-00 (May 2026):
* Initial submission.
* Specifies the eight-slot briefing-and-binding envelope
(Section 4): synopsis, findings, recommendations, offer, question
stem, options with per-option reasoning, recommended option, and
dual escape hatches.
* Specifies the per-slot grammar and construction discipline
(Section 5), including the no-hedge rule on the synopsis and the
leading-stem prohibition.
* Specifies the dual-veto handshake (Section 7): the agent-side veto
by withheld emission and the two principal-side escape hatches
refusing the answer space and the question space respectively.
* Specifies the MCP delivery binding (Section 8): additive
binding_moment field, tool-manifest advertisement, staged
adoption, single-surface delivery.
* Specifies the renderer contract (Section 9): rendering invariants,
permitted native variation, and fallback rendering.
16. Normative References
Morrison & Whiteside Expires 16 April 2027 [Page 27]
Internet-Draft Binding-Moment Envelope October 2026
[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/info/rfc2119>.
[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/info/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/info/rfc8259>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[FIPS180-4]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>.
[MCP] Agentic AI Foundation, "Model Context Protocol
Specification", 2026, <https://modelcontextprotocol.io>.
[IDPRONOUNS]
Morrison, B., "Identity Pronouns: A Reference-Axis
Extension to ~handle Identity Systems", Work in Progress,
Internet-Draft, draft-morrison-identity-pronouns-04, 10
October 2026, <https://datatracker.ietf.org/doc/draft-
morrison-identity-pronouns/>.
17. Informative References
[EPRECEIPTS]
Schrock, I., "Authorization Receipts for High-Risk Agent
Actions", Work in Progress, Internet-Draft, draft-schrock-
ep-authorization-receipts-13, 11 September 2026,
<https://datatracker.ietf.org/doc/draft-schrock-ep-
authorization-receipts/>.
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
via DNS TXT Records", Work in Progress, Internet-Draft,
draft-morrison-mcp-dns-discovery-08, 8 October 2026,
<https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
discovery/>.
Morrison & Whiteside Expires 16 April 2027 [Page 28]
Internet-Draft Binding-Moment Envelope October 2026
[IDCOMMITS]
Morrison, B., "Identity-Attributed Git Commits via Tier-
Structured Trailers", Work in Progress, Internet-Draft,
draft-morrison-identity-attributed-commits-03, 8 October
2026, <https://datatracker.ietf.org/doc/draft-morrison-
identity-attributed-commits/>.
[POLICYPROV]
Morrison, B., "Policy Provision and Governance Inheritance
from an Organisational Identity Substrate", Work in
Progress, Internet-Draft, draft-morrison-org-alter-policy-
provision-05, 10 October 2026,
<https://datatracker.ietf.org/doc/draft-morrison-org-
alter-policy-provision/>.
[SUBSTRATE]
Morrison, B., "Substrate-Observation as an Alternative to
Envelope Coordination for Concurrent Sessions", Work in
Progress, Internet-Draft, draft-morrison-substrate-
observation-03, 11 October 2026,
<https://datatracker.ietf.org/doc/draft-morrison-
substrate-observation/>.
[ALTER-URI]
Morrison, B., "The 'alter' URI Scheme for Dispatchable
~handle References", Work in Progress, Internet-Draft,
draft-morrison-alter-uri-scheme-04, 8 October 2026,
<https://datatracker.ietf.org/doc/draft-morrison-alter-
uri-scheme/>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
Authors' Addresses
Blake Morrison
Alter Meridian Pty Ltd
Email: blake@truealter.com
URI: alter:~blake
Christopher Whiteside
Independent
Email: cwhiteside.engineering@gmail.com
Morrison & Whiteside Expires 16 April 2027 [Page 29]