]> Alter Meridian Pty Ltd (~truealter)

blake@truealter.com alter:~blake

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 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 and the MCP tool surface of .

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. 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 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 and is not constrained here.

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 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 .

Agent

An artificial-intelligence runtime acting for a principal, identified by an Instrument-tier ~handle per . 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.

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 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).

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 object with exactly the members specified below. , "findings": [ , ... ], "recommendations": [ , ... ], "offer": , "question": { "stem": , "options": [ { "label": , "reasoning": }, ... ], "recommended_idx": , "hatches": { "free_text": , "dialogue": } }, "meta": { "decision_class": , ; OPTIONAL "calibration_note": ; 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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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 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 , references the envelope by digest.

Canonical Form The envelope is delivered as a JSON object (Section 4). Its canonical form is the JSON Canonicalization Scheme 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.

Digest Computation The envelope digest is the SHA-256 digest of the canonical form, presented as the string sha256: followed by exactly 64 lowercase hexadecimal characters. The string form is that of the external-artifact hash of , so a receipt referencing an envelope carries the value verbatim and neither memo transforms the other's material at the boundary.

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, 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.

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.

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.

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. 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.

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 semantics already in force. It is a JSON object with exactly the members specified below. , "resolution": "option" | "answer" | "question", "option_idx": , ; "option" only "answer": ; "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 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.

MCP Delivery Binding The briefing-and-binding envelope is delivered as a structured field of a Model Context Protocol tool result. This section specifies the binding.

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.

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.

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.

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.

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.

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.
• 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.

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.

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.

Relationship to Companion Memos This memo composes with the Morrison-family Internet-Drafts as follows. 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. 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; specifies the durable audit channel. The two are deliberately separated: the envelope does not itself persist. 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 . This memo does not place attribution slots in the envelope itself; attribution is a property of any durable record, not of the transient payload. supplies the discovery mechanism by which a consuming surface locates the MCP server whose tools emit envelopes. This memo introduces no new discovery surface. 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.

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.

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.

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 session, and an implementation SHOULD authenticate the tool surface (for example via the cryptographic identity envelope of ) so that the principal's agent is interacting with the substrate it intends.

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.

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 .

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 and .

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.

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.

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.

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 , 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 requires.

Implementation Status This section records implementation experience in the spirit of 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 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.

Document History draft-morrison-binding-moment-envelope-01 (July 2026):

• Adds the envelope digest (Section 6): JCS canonical form, SHA-256 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 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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. National Institute of Standards and Technology Agentic AI Foundation Alter Meridian Pty Ltd Informative References EMILIA Protocol, Inc. Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

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

cwhiteside.engineering@gmail.com