The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation

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

5.5. Slot 5: Question Stem

question.stem is a string carrying a single neutral, plain-language sentence that poses the decision. The stem SHALL NOT be leading: it SHALL NOT embed the agent's recommendation, and it SHALL NOT be phrased to make one option the path of least resistance. The agent's lean is carried by slot 7, on the option, never by the stem.¶

5.6. Slot 6: Options

question.options is a JSON array of objects. The array SHALL contain at least two and at most four entries. Each entry is an object with three REQUIRED string members:¶

label

A short, action-shaped statement of the option.¶

reasoning

A single line stating why the principal might choose this option. The reasoning lives on the option, not in the stem; the principal can read the comparison without working it out.¶

action_digest

The digest of the action this option authorises, in the string form of Section 6.2.¶

This memo does not define the action or its canonical bytes. The action is an external artifact, and the profile that carries it defines both. Where that profile pins JCS [RFC8785], the digest is computed as in Section 6.2 over the action in place of the envelope, and the profile bounds of Section 6.3 apply to it.¶

The digest is computed over the action itself. A verifier holding the action it is about to perform recomputes the digest and compares (Section 7.3). It does not resolve an identifier, consult a table, or ask a relying party what the index meant.¶

Where the same action is also covered by an authorization receipt of [EPRECEIPTS], that memo's action hash is its own identifier and is not assumed to equal an action_digest (Section 3 of [EPRECEIPTS]). A relying party that compares the two does so under the mapping that memo requires, and this memo adds nothing to it.¶

An option SHALL carry the digest of exactly one action, and an action_digest not in the form of Section 6.2 makes the envelope malformed (Section 4). An option that authorises no action is not a slot 6 entry. A response that reopens deliberation is the question-space hatch (Section 5.8), and a response that refuses to act is a decline (Section 7.3).¶

The options enumerate the substantive answers to the question. They do not include the escape hatches; the hatches are slot 8 and are not members of the options array.¶

5.7. Slot 7: Recommended Option

question.recommended_idx is an integer: the zero-based index, into the options array, of the option the agent recommends. Exactly one option SHALL be marked. recommended_idx SHALL be present, SHALL be non-negative, and SHALL be strictly less than the length of the options array; an absent value is malformed.¶

The recommended option is the agent's committed synthesis offered as a contestable position; the principal validates it or vetoes it. Where the agent's analysis ties two options, the agent SHALL still mark exactly one: the synopsis names the tie, and the mark SHALL fall on the option that minimises the cost of being wrong.¶

5.8. Slot 8: Escape Hatches

question.hatches is a JSON object with two REQUIRED boolean members:¶

free_text

The answer-space hatch. When true, the consuming surface SHALL render an affordance through which the principal may submit a free-form answer instead of selecting an option. Invoking this hatch accepts the question as posed and revises the answer.¶

dialogue

The question-space hatch. When true, the consuming surface SHALL render an affordance through which the principal may reject the question itself and reopen deliberation with the agent. Invoking this hatch rejects the framing.¶

Both members are normally true. An agent that emits a binding moment with either hatch set to false removes a veto path and SHALL do so only where the corresponding revision is inapplicable. Section 7 specifies the handshake the hatches realise.¶

5.9. The meta Slot

meta, when present, MAY carry two members. decision_class is a string naming the category of the decision (for example, a consent decision, a permission-delta decision, a recompute decision); a consuming surface MAY use it to select a rendering style. calibration_note is a string carrying a short correcting preface, included only when the agent's prior framing in the session now reads as materially understating what the agent has since concluded. The note is a costly signal and SHALL NOT be emitted ritually; an implementation SHOULD monitor the rate at which calibration_note is populated and treat a persistently high rate as a defect in the agent's earlier framing rather than as normal operation.¶

6.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 the form [EPRECEIPTS] uses for its hash members (sha256: followed by 64 lowercase hexadecimal characters), so a receipt referencing an envelope carries the value verbatim and neither memo transforms the other's material at the boundary.¶

6.3. Profile Bounds

Any divergence between two implementations' canonicalization behaviour is a divergence in the digest, and therefore a misbinding hazard: the two parties disagree about which envelope a resolution names. An implementation MUST reject the following inputs rather than normalise them, and MUST reject them identically.¶

Duplicate member names

An object whose member names collide after escape decoding. An implementation that silently retains one of the two digests material its peer did not send. A verifier handed an already-parsed value cannot observe this class at all, so the check MUST be applied at the parse boundary.¶

Unpaired surrogates

A string carrying a UTF-16 surrogate code point without its pair. Such a string has no UTF-8 encoding, and implementations differ in whether they substitute, drop, or reject.¶

Numbers outside the integer profile

A number that is not an integer, or an integer of magnitude greater than 2^53-1. The only number the envelope grammar carries is recommended_idx (Section 5.7), a small non-negative integer, so this bound costs the grammar nothing. It removes the floating-point formatting rules that are the main source of canonicalization divergence between implementations in practice.¶

Excessive nesting

A container nested more deeply than 64. The envelope grammar is of fixed and shallow depth, so this bound reaches only pathological input.¶

These bounds are those of the canonicalization profile in Section 13.12 of [EPRECEIPTS] (revision -13), adopted here without variation. An envelope digest and a receipt that references it are checked by the same verifier, and a verifier obliged to hold two canonicalization profiles at once is a defect in the pair of memos rather than in the verifier.¶

6.4. Example

The two options authorise these two actions. They are illustrative: the profile that carries an action defines it (Section 5.6), and here each action's digest is computed as in Section 6.2 over the action shown.¶

{
  "disclose": ["travel_dates"],
  "recipient": "booking.example"
}

{
  "disclose": ["passport_number", "travel_dates"],
  "recipient": "booking.example"
}

Their action digests are the string sha256: followed by, in order, these 64 hexadecimal characters:¶

ff91e3166e64b892004d4b43b05ad6ed7ff0819463da80c72f27f47039c033fa
49be14ae6e74b950c0c7b790fa22538d45fb4853bb0f3b242b28204bee232945

The following is the value of a binding_moment member that offers them. It is shown with whitespace added for reading, and each action_digest is cut to its first 12 hexadecimal characters and "..." to fit the line. With the full values in place, its canonical form (Section 6.1) is 895 bytes long.¶

{
  "synopsis":
    "Share the travel dates and withhold the passport number.",
  "findings": [
    "The booking service asks for dates and passport number.",
    "Dates are enough to hold the reservation.",
    "The passport number is only needed at check-in."
  ],
  "recommendations": [
    "Release the travel dates now.",
    "Withhold the passport number until check-in."
  ],
  "offer": "Ask for detail on any item.",
  "question": {
    "stem": "What should be shared with the booking service?",
    "options": [
      {
        "label": "Share dates only",
        "reasoning":
          "Holds the booking and keeps the passport number private.",
        "action_digest": "sha256:ff91e3166e64..."
      },
      {
        "label": "Share dates and passport number",
        "reasoning": "Avoids a second request at check-in.",
        "action_digest": "sha256:49be14ae6e74..."
      }
    ],
    "recommended_idx": 0,
    "hatches": { "free_text": true, "dialogue": true }
  }
}

Its envelope digest is the string sha256: followed by these 64 hexadecimal characters:¶

0db384ab1b682c115d79babfefa91f014ad80c007d00c79119d748f32be232d1

7.1. Agent-Side Veto

The agent's veto is exercised by not emitting a binding moment. An agent reaches many points at which a principal-facing question would be premature: the agent has not yet synthesised a position, or the available options do not yet partition the decision, or the agent needs to deliberate further before it can commit. At such a point the agent SHALL NOT emit a briefing-and-binding envelope. It SHOULD instead return material that surfaces its current state and requests the principal's permission to continue deliberating. Emitting an envelope with a hedged synopsis (Section 5.1) is the failure this rule forbids: it presents the appearance of a committed decision while pushing the synthesis cost back to the principal.¶

The agent-side veto is therefore a precondition on emission: a well-formed envelope is one the agent has not vetoed.¶

7.2. Principal-Side Veto: Two Hatches

The principal's veto is exercised through the two escape hatches of slot 8. The two hatches refuse different things.¶

The answer-space hatch (free_text) refuses the quantisation while accepting the frame. The principal agrees the agent has asked the right question but holds an answer not among the enumerated options. Invoking this hatch returns a free-form answer. The agent incorporates the answer, and where the answer calls for an action, emits a further envelope whose option carries that action's digest. The frame stands; the option set is treated as non-exhaustive.¶

The question-space hatch (dialogue) refuses the frame itself. The principal judges that the agent has asked the wrong question, or has asked a question that rests on a premise the agent does not have grounds for, or that the decision is not ripe. Invoking this hatch does not return an answer; it returns the binding moment to deliberation. The agent SHALL treat a question-space veto as a reopening: it SHALL NOT respond by re-emitting the same question, and it SHALL NOT respond by emitting a further forced-choice envelope without first incorporating the principal's objection. A question-space hatch that leads only to another menu is a failure of the handshake.¶

The handshake maps onto deliberative procedure. Selecting an option is a vote. The answer-space hatch is an amendment to the motion. The question-space hatch is a motion to refer the question back. An interface that offers only the vote is forced-choice.¶

7.3. Resolution

A binding moment is resolved by exactly one of: selection of an option from slot 6; invocation of the answer-space hatch with a free-form answer; invocation of the question-space hatch; or decline. The consuming surface SHALL return the resolution to the agent in a form that distinguishes which of the four occurred, because the agent's correct continuation differs in each case. The resolution is carried as the argument to the agent's next tool invocation under the [MCP] semantics already in force. It is a JSON [RFC8259] object with exactly the members specified below, in the notation of Section 4; "|" separates the permitted values of a member.¶

{
  "binding_moment_resolution": {
    "envelope_digest": <string>,
    "resolution":      "option" | "answer" | "question"
                       | "declined",
    "option_idx":      <integer>,  ; "option" only
    "answer":          <string>    ; "answer" only
  }
}

The member envelope_digest is REQUIRED. It carries the digest (Section 6.2) of the envelope being resolved.¶

The member resolution is REQUIRED and distinguishes the four cases. The value option denotes selection from slot 6; answer denotes the answer-space hatch; question denotes the question-space hatch; declined denotes the principal's negative answer to the question as put.¶

The member option_idx carries the zero-based index into slot 6 of the selected option. It is REQUIRED when resolution is option, MUST be absent otherwise, and MUST be within range for the resolved envelope's option list.¶

The member answer carries the principal's free-form answer. It is REQUIRED when resolution is answer and MUST be absent otherwise.¶

The question-space hatch carries no further member. Its content is the refusal itself, and the agent's continuation is to reopen deliberation rather than to read a value.¶

The declined and question resolutions are distinct, and an implementation SHALL NOT collapse them. The question-space hatch rejects the question or its premises, and the agent's continuation is to reopen deliberation. A decline accepts the question as well put and answers it in the negative. The question does not reopen, and the agent's continuation is to stop. A decline recorded as an option selection that happens to mean no can no longer be told apart from a selection.¶

A declined resolution carries no further member. Its content is the refusal itself, the agent reads no value to continue, and envelope_digest names what was declined. A decline records that the principal answered the question as put in the negative, and it authorises no action. Because it names its envelope, it refuses that envelope only and cannot be applied to another.¶

A verifier presented with a resolution of option SHALL, before treating it as authority for an action, recompute the digest of the action it is about to perform and compare it to the action_digest of the option at option_idx in the envelope that envelope_digest names, after confirming that the envelope it holds has that digest. Where the two differ, the resolution remains a record that the principal selected that option, and is not authority for the action performed. A resolution of any other kind is not authority for any action.¶

An agent SHALL discard a resolution whose envelope_digest does not match an envelope it emitted and has not already resolved. A resolution naming an unknown envelope, or naming one already resolved, is not a decision, and an agent that acts on one has acted without its principal's commitment.¶

8.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 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.1. Invariants

A conforming renderer SHALL preserve the following across every surface:¶

• All four briefing slots are rendered. A renderer SHALL NOT drop the findings or the recommendations to save space; the briefing is what allows the binding to be resolved quickly.¶

• The recommended option (slot 7) is rendered as visibly distinguished from the other options. The principal SHALL be able to see, without acting, which option the agent recommends.¶

• Both escape hatches whose slot-8 boolean is true are rendered as invocable affordances. A renderer SHALL NOT omit a hatch on the grounds that the option set appears exhaustive; the hatches are the principal's veto and their availability is not the renderer's to withdraw.¶

• The per-option reasoning (slot 6) is rendered with, or made immediately available from, each option. A renderer that shows option labels but hides the reasoning has removed the comparison and left the principal to deliberate unaided.¶

• An affordance to decline is rendered with the options. A decline is a resolution of its own (Section 7.3), and a renderer SHALL NOT leave the principal to express it by selecting an option that means no or by invoking the question-space hatch.¶

9.2. Native Variation

Within the invariants of Section 9.1, a renderer MAY map the slots to whatever native element it supports. A command-line client may render the binding as an arrow-key picker with the escape hatches bound to distinct keys. A mobile client may render it as a consent sheet with chip-style options and the recommended chip styled distinctly. A desktop notifier may render the synopsis as a notification title and defer the full envelope to an expanded view. An agent-runtime hook may render the envelope as plain text with a labelled multiple-choice block. The eight slots and their semantics are the same on every surface.¶

9.3. Fallback Rendering

A consuming surface that does not implement the envelope renderer, or that has received a malformed envelope per Section 4, SHALL fall back to rendering the tool result's conventional payload. Because the binding_moment field is additive (Section 8.1), the conventional payload is always present and the fallback is always available. A surface SHOULD NOT fail an interaction solely because it could not render an envelope.¶

12.1. Synthesis Spoofing

An agent, or a compromised tool impersonating one, may emit an envelope whose briefing slots misrepresent what the agent observed, inducing the principal to validate a recommendation grounded in falsified findings. The envelope cannot prevent this; the briefing is the agent's own account. Mitigation is twofold. First, the offer slot (slot 4) and the answer-space hatch exist so the principal may interrogate any finding or supply an answer the agent did not anticipate; a renderer that drops the offer or the hatch (Section 9.1) removes this defence. Second, the binding moment is a tool result delivered over the [MCP] session, and an implementation SHOULD authenticate the tool surface (for example via the cryptographic identity envelope of [MCPDNS]) so that the principal's agent is interacting with the server it intends.¶

12.2. Recommendation as Coercion

The recommended option (slot 7) carries the agent's lean. An agent that consistently recommends the option most favourable to the agent's operator, rather than to the principal, turns the envelope into a manipulation surface. The structural mitigations are the leading-stem prohibition (Section 5.5), which keeps the lean visibly confined to the option rather than smuggled into the question, and the question-space hatch, which lets the principal reject a frame whose options are all skewed. An implementation SHOULD additionally monitor the rate at which principals invoke the question-space hatch: a persistently high rate against a particular agent or decision class is evidence that the option grammar is systematically mis-framed.¶

12.3. Hatch Suppression

An agent or a renderer that disables an escape hatch removes a veto path. Disabling the question-space hatch in particular converts a consensual binding moment into a forced choice. An agent SHALL set a hatch to false only where the corresponding revision is inapplicable (Section 5.8), and a renderer SHALL NOT omit a hatch the envelope marks true (Section 9.1). An implementation SHOULD treat a binding moment that disables a hatch as an event worth recording, so that systematic hatch suppression is detectable by post-hoc audit through the mechanism of [POLICYPROV].¶

12.4. Confirmation Routing Under Concurrent Sessions

Where a principal operates several agent sessions concurrently, a binding moment that delegates a consequential action SHOULD be rendered on a surface bound to the principal's own handle, so that an agent session in possession of the principal's session credential cannot resolve the binding moment on the principal's behalf. The envelope itself does not route; routing is a property of the consuming surface and of the session-credential discipline of [POLICYPROV] and [SUBSTRATE].¶

12.5. Resolution Misbinding and Replay

A resolution that did not name its envelope could be applied to the wrong one. Two hazards follow. A resolution captured from one binding moment could be replayed against a later one, so that a principal's assent to a small action becomes assent to a large one. A resolution produced for one concurrent session could be applied by another (Section 12.4), and because two envelopes need not order slot 6 alike, an index chosen against one selects a different option under the other.¶

The envelope_digest member (Section 7.3) closes both. It names one envelope, including its option ordering and its recommended option, so a resolution is meaningful against exactly that envelope and is discarded against every other. Two byte-identical envelopes share a digest. An agent that poses the same question more than once, and needs the resolutions kept apart, has to make the envelopes differ, for example in the synopsis or findings. The digest binds a resolution to an envelope; it does not route it, and the routing discipline of Section 12.4 still applies.¶

12.6. Option-Map Substitution

Where an option index carries no binding to an action, a verifier has to be told which action the index meant, and that telling comes from the relying party. A relying party that is compromised, or merely mistaken, can then make an authentic selection authorise an action the principal did not choose. The selection is real and the index is correct. Only the meaning attached to the index is wrong, so nothing the principal committed to contradicts it.¶

The action_digest member of Section 5.6 closes this by carrying the meaning in the envelope the resolution names by digest. The verifier recomputes the action's digest itself and compares it with the one the principal was shown, so no outside map is consulted. The envelope-digest binding of Section 12.5 continues to apply to the resolution as a whole.¶

This memo defines no signature over a resolution. The binding is therefore only as strong as whatever protects the resolution in transit and at rest, for example an authorization receipt of [EPRECEIPTS].¶

The member has two costs. It appears once per option, so an envelope carrying the maximum four options grows by four digest strings, which the slot grammar's own cap bounds. And the agent must know each option's action digest when it constructs the envelope, so an envelope cannot offer an option whose action is still being drafted. Where an action is not yet settled, the agent asks instead a question whose options select among ways of settling it.¶

12.7. Canonicalization Divergence

Every use of the envelope digest rests on two implementations agreeing on the canonical bytes of one envelope. Where they disagree, a resolution is discarded against the envelope it was produced for, or accepted against one it does not. The profile bounds of Section 6.3 are therefore normative, and they are rejections rather than repairs. An implementation that normalises a duplicate member name, substitutes an unpaired surrogate, or rounds an out-of-profile number produces a digest over material no other implementation reproduces, and the disagreement surfaces as a misbinding rather than as a parse error.¶

12.8. Malformed-Envelope Handling

A malformed envelope (Section 4) that a renderer still attempts to render as a decision risks presenting the principal with a decision whose options or recommendation are incoherent. A renderer SHALL discard a malformed envelope and fall back to the conventional payload (Section 9.3) rather than render a partial or repaired decision.¶