The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation
draft-morrison-binding-moment-envelope-01
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 | Blake Morrison | ||
| Last updated | 2026-07-22 | ||
| 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-01
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd (~truealter)
Intended status: Informational July 2026
Expires: 23 January 2027
The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-
Principal Decision Moments with Dual-Veto Reconciliation
draft-morrison-binding-moment-envelope-01
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 [MCP] tool
result. The contribution is the delivery contract itself: a single
renderer-agnostic envelope so that the briefing an agent delivers and
the binding a principal commits back have one machine-checkable shape
across every consuming surface. The central element is the 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 [IDPRONOUNS] and the MCP tool surface of [POLICYPROV].
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 Expires 23 January 2027 [Page 1]
Internet-Draft Binding-Moment Envelope July 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 2 January 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Briefing-and-Binding Envelope . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Slot 5: Question Stem . . . . . . . . . . . . . . . . . . 9
5.6. Slot 6: Options . . . . . . . . . . . . . . . . . . . . . 9
5.7. Slot 7: Recommended Option . . . . . . . . . . . . . . . 9
5.8. Slot 8: Escape Hatches . . . . . . . . . . . . . . . . . 9
5.9. The meta Slot . . . . . . . . . . . . . . . . . . . . . . 10
6. The Envelope Digest . . . . . . . . . . . . . . . . . . . . . 10
6.1. Canonical Form . . . . . . . . . . . . . . . . . . . . . 11
6.2. Digest Computation . . . . . . . . . . . . . . . . . . . 11
6.3. Profile Bounds . . . . . . . . . . . . . . . . . . . . . 11
7. The Dual-Veto Handshake . . . . . . . . . . . . . . . . . . . 12
7.1. Agent-Side Veto . . . . . . . . . . . . . . . . . . . . . 12
7.2. Principal-Side Veto: Two Hatches . . . . . . . . . . . . 12
7.3. Resolution . . . . . . . . . . . . . . . . . . . . . . . 13
8. MCP Delivery Binding . . . . . . . . . . . . . . . . . . . . 14
8.1. Envelope Placement . . . . . . . . . . . . . . . . . . . 14
8.2. Tool-Manifest Advertisement . . . . . . . . . . . . . . . 14
8.3. Staged Adoption . . . . . . . . . . . . . . . . . . . . . 15
8.4. Single-Surface Delivery, Not Broadcast . . . . . . . . . 15
9. Renderer Contract . . . . . . . . . . . . . . . . . . . . . . 15
Morrison Expires 23 January 2027 [Page 2]
Internet-Draft Binding-Moment Envelope July 2026
9.1. Invariants . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Native Variation . . . . . . . . . . . . . . . . . . . . 16
9.3. Fallback Rendering . . . . . . . . . . . . . . . . . . . 16
10. Relationship to Companion Memos . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12.1. Synthesis Spoofing . . . . . . . . . . . . . . . . . . . 18
12.2. Recommendation as Coercion . . . . . . . . . . . . . . . 18
12.3. Hatch Suppression . . . . . . . . . . . . . . . . . . . 18
12.4. Confirmation Routing Under Concurrent Sessions . . . . . 19
12.5. Resolution Misbinding and Replay . . . . . . . . . . . . 19
12.6. Canonicalization Divergence . . . . . . . . . . . . . . 19
12.7. Malformed-Envelope Handling . . . . . . . . . . . . . . 20
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
15. Document History . . . . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.1. Normative References . . . . . . . . . . . . . . . . . . 22
16.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
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. The
consequence is twofold. First, the principal cannot acquire a stable
scanning habit, because the shape of the decision changes with every
tool. Second, and more seriously, 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 Expires 23 January 2027 [Page 3]
Internet-Draft Binding-Moment Envelope July 2026
This memo specifies a single delivery contract, the briefing-and-
binding envelope, that resolves both problems by construction. 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. One contract, many renderers.
The central innovation is the _dual-veto handshake_. A binding
moment is consensual only if both parties can refuse it. 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 stop carrying their
weight. Section 7 specifies the handshake.
This memo specifies a delivery contract and a veto handshake. It
does NOT specify a persistent log of binding moments, a signed event
history between identifiers, or any derivation of signing authority;
those concerns are out of scope and are addressed by separate work.
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.
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
Sovereign- tier ~handle as defined by [IDPRONOUNS].
Agent An artificial-intelligence runtime acting for a principal,
Morrison Expires 23 January 2027 [Page 4]
Internet-Draft Binding-Moment Envelope July 2026
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
declines 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.
Resolution The principal's response to a binding moment: selection
of an option, invocation of the answer-space hatch with an answer,
or invocation of the question-space hatch.
3. Architecture
The briefing-and-binding envelope is a payload, not a protocol. It
is 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.
Morrison Expires 23 January 2027 [Page 5]
Internet-Draft Binding-Moment Envelope July 2026
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).
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.
Morrison Expires 23 January 2027 [Page 6]
Internet-Draft Binding-Moment Envelope July 2026
{
"binding_moment": {
"synopsis": <string>,
"findings": [ <string>, ... ],
"recommendations": [ <string>, ... ],
"offer": <string>,
"question": {
"stem": <string>,
"options": [
{ "label": <string>, "reasoning": <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 (a missing REQUIRED member,
an out-of-range recommended_idx, an options list with fewer than two
entries) SHALL treat the binding moment as malformed. A malformed
binding moment SHALL NOT be 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.
Morrison Expires 23 January 2027 [Page 7]
Internet-Draft Binding-Moment Envelope July 2026
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.
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.
Morrison Expires 23 January 2027 [Page 8]
Internet-Draft Binding-Moment Envelope July 2026
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
two 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; it
caches the comparison so that the principal scans rather than
deliberates.
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; the value-absent and the two-marked cases are both
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 genuinely 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
Morrison Expires 23 January 2027 [Page 9]
Internet-Draft Binding-Moment Envelope July 2026
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
decline the question itself and reopen deliberation with the
agent. Invoking this hatch rejects the framing.
Both members SHALL default to 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 genuinely
inapplicable; the default posture is that both hatches are open.
Section 7 specifies the handshake the hatches realise.
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 honesty-line 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 10), so a
durable record of a resolved binding moment must 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.
Morrison Expires 23 January 2027 [Page 10]
Internet-Draft Binding-Moment Envelope July 2026
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.
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 that of the external-artifact hash of
[EPRECEIPTS], 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,
Morrison Expires 23 January 2027 [Page 11]
Internet-Draft Binding-Moment Envelope July 2026
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 [EPRECEIPTS] canonicalization profile,
adopted here without variation. An envelope digest and a receipt
that references it are 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.
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.
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, by construction, 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 are not redundant; they refuse two
structurally different things.
Morrison Expires 23 January 2027 [Page 12]
Internet-Draft Binding-Moment Envelope July 2026
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 proceeds. 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
genuine 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 broken handshake.
The mapping to deliberative procedure is exact. 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 not consensual; it is forced-
choice.
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; or invocation of the question-space hatch. The
consuming surface SHALL return the resolution to the agent in a form
that distinguishes which of the three 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.
{
"binding_moment_resolution": {
"envelope_digest": <string>,
"resolution": "option" | "answer" | "question",
"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.
Morrison Expires 23 January 2027 [Page 13]
Internet-Draft Binding-Moment Envelope July 2026
The member resolution is REQUIRED and distinguishes the three cases.
The value option denotes selection from slot 6; answer denotes the
answer-space hatch; question denotes the question-space hatch.
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.
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.
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
Morrison Expires 23 January 2027 [Page 14]
Internet-Draft Binding-Moment Envelope July 2026
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
the pre-paid synthesis and is the reason the binding is cheap to
resolve.
* 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.
Morrison Expires 23 January 2027 [Page 15]
Internet-Draft Binding-Moment Envelope July 2026
* 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 cached
comparison and forced the principal back into deliberation.
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 rendering differs; the eight
slots and their semantics do not.
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 Morrison-family Internet-Drafts as
follows.
[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. The two are deliberately separated: the
envelope does not itself persist.
Morrison Expires 23 January 2027 [Page 16]
Internet-Draft Binding-Moment Envelope July 2026
[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.
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 the present
author. 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, not the
confidentiality of a stored record; the envelope holds no durable
state.
Morrison Expires 23 January 2027 [Page 17]
Internet-Draft Binding-Moment Envelope July 2026
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 precisely 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 substrate 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:
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 genuinely
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].
Morrison Expires 23 January 2027 [Page 18]
Internet-Draft Binding-Moment Envelope July 2026
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. This is a binding mechanism and not a
routing one; the routing discipline of Section 12.4 continues to
apply.
12.6. 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 genuinely
resolves, 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 Expires 23 January 2027 [Page 19]
Internet-Draft Binding-Moment Envelope July 2026
12.7. Malformed-Envelope Handling
A malformed envelope (Section 4) that a renderer nonetheless 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 expected to be removed before the document advances
beyond the Independent Stream.
A reference implementation of the briefing-and-binding envelope is
operated by the present author against a production Model Context
Protocol substrate. An agent tool that surfaces the next question of
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 as specified in Section 5: the synopsis and
findings report the state of the discovery flow, the recommended
Morrison Expires 23 January 2027 [Page 20]
Internet-Draft Binding-Moment Envelope July 2026
option is selected by an information-gain heuristic over the
available answers, and the escape hatches are set per Section 5.8
with the question-space hatch open. A second tool that records a
submitted discovery answer emits a follow-on envelope soliciting
whether to continue. Consuming surfaces render the envelope to a
plain-text multiple-choice block with a visibly marked recommended
option and both escape hatches.
No claim of interoperability is made; the reference deployment is a
single substrate operated by the specification's author.
15. Document History
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.
* 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.
Morrison Expires 23 January 2027 [Page 21]
Internet-Draft Binding-Moment Envelope July 2026
* 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. References
16.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/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>.
Morrison Expires 23 January 2027 [Page 22]
Internet-Draft Binding-Moment Envelope July 2026
[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", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
pronouns/>.
16.2. Informative References
[EPRECEIPTS]
Schrock, I., "Authorization Receipts for High-Risk Agent
Actions", 2026, <https://datatracker.ietf.org/doc/draft-
schrock-ep-authorization-receipts/>.
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
via DNS TXT Records", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
discovery/>.
[IDCOMMITS]
Morrison, B., "Identity-Attributed Git Commits via Tier-
Structured Trailers", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-identity-
attributed-commits/>.
[POLICYPROV]
Morrison, B., "Policy Provision and Governance Inheritance
from an Organisational Identity Substrate", 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", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-
substrate-observation/>.
[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>.
Morrison Expires 23 January 2027 [Page 23]
Internet-Draft Binding-Moment Envelope July 2026
Acknowledgements
This memo grew out of internal design work on the structure of agent-
to-principal decision moments and the recognition that a binding
moment is consensual only when both parties are able to veto it: the
agent by declining to pose a question it cannot commit to, and the
principal by two distinct refusals. The articulation of the dual-
veto handshake as the central element of the delivery contract is the
insight behind this specification.
Contributors
Christopher Whiteside
Email: cwhiteside.engineering@gmail.com
Author's Address
Blake Morrison
Alter Meridian Pty Ltd (~truealter)
Email: blake@truealter.com
URI: alter:~blake
Morrison Expires 23 January 2027 [Page 24]