[dispatch] Re: New Draft: draft-das-accountable-autonomous-effectuation-01 — AI Safety and Accountability at the Effectuation Boundary

[Sangam Das <[e-mail]>]

Hi Iman,

Thank you — this is extremely helpful.

I agree that AEB, CAID, BCR, and the Gate conformance work should be
treated as directly relevant existing work rather than discussed only
indirectly through OAuth, RATS, WIMSE, or other upstream mechanisms.

Your distinction between provider commitment and observed real-world effect
is particularly useful. I agree that these should not be collapsed into a
single binary result. In particular, once dispatch may have crossed the
provider boundary, a local exception is not sufficient evidence of “no
effect,” and retrying on that assumption can itself create a duplicate
consequence.

I also agree with the atomicity point. I do not intend the
execution-finality model to imply atomicity between an independently
controlled local state store and an unrelated external provider. The more
precise question is what can be made atomic or serialized inside the
locally controlled effectuation domain, what must transition to an
indeterminate state once dispatch begins, and what evidence is required
before that state can safely be resolved.

A short R1–R14 crosswalk would therefore be very valuable, and I would be
glad to run an interoperability exercise against the examples in the draft.

I think the useful comparison should identify three categories:

   1.

   requirements already satisfied directly by AEB / CAID / BCR;
   2.

   requirements that can be satisfied by profiling or composing that work
   with other mechanisms; and
   3.

   any residual execution-finality requirements that remain outside those
   mechanisms.

Some of the areas I would particularly like to test in the third category
are:

   -

   whether the consequential operation is reconstructed from the actual
   native operation presented at the effectuation boundary rather than
   accepted solely from an upstream descriptor;
   -

   whether authority is bound to that exact reconstructed operation,
   destination, boundary, and current protected state;
   -

   whether alternate effect-capable paths are required to pass through the
   same boundary or an equivalent protected enforcement mechanism;
   -

   whether effectuation authority is single-use or otherwise bounded and
   consumed/reserved in conjunction with the local protected transition;
   -

   how revocation, generation/epoch changes, freshness, replay, and stale
   authorization are handled immediately before effectuation;
   -

   whether inability to establish any required predicate leaves the
   Candidate Act non-effective;
   -

   and how local admission/commitment evidence is distinguished from
   evidence that the external consequence actually occurred.

CAID also appears highly relevant to the canonicalization issue raised in
Section 17.1. Its pinned, loss-aware mapping approach looks like exactly
the kind of existing mechanism that should be compared against the draft's
ActionDescriptor requirements rather than reinvented unnecessarily.

I will add AEB, CAID, BCR, and the AEB-1 conformance work to the
related-work analysis.

Please do send the R1–R14 crosswalk. I would be very interested in testing
the two architectures against the same hostile cases and identifying
precisely where they are equivalent, composable, or materially different.

That seems much more useful than arguing terminology.

Best regards,

Sangam Das
Independent Researcher
Balasore, Odisha, India

On Wed, 23 Sept 2026 at 20:43, Iman Schrock <team=
[e-mail]> wrote:

> Hi Sangam,
>
> Thanks for putting this together. I think the effectuation boundary is
> exactly the right place to focus. The requirements also line up closely
> with work we have already made concrete in EMILIA’s AEB, CAID, and BCR
> drafts and the Gate conformance suite.
>
> One distinction may help Q7 and Q8: provider commitment and observed
> real-world effect should not collapse into one binary result. A provider
> may accept a request without the intended effect occurring, and a local
> exception cannot prove that no effect occurred. Our current profile
> therefore keeps two closed axes: provider commitment (COMMITTED,
> PROVEN_NOT_COMMITTED, or INDETERMINATE) and observed effect (
> OBSERVED_AS_REQUESTED, DIVERGED, or INDETERMINATE). Once a request
> crosses the provider boundary, unresolved state remains INDETERMINATE
> until authenticated reconciliation. It cannot safely be treated as NO
> EFFECT and retried.
>
> For Q4 and Q6, CAID lets the executor derive the material action from
> native provider inputs using pinned mappings, report semantic loss, and
> bind the result to a verifier version. AEB then consumes or reserves
> authority inside a named local atomicity domain before dispatch, keeps a
> stable native replay unit, and uses a durable DISPATCH_PENDING state for
> recovery. We deliberately do not claim atomicity across a local store and
> an unrelated provider.
>
> The relevant work is here:
>
>    - Action Evidence Boundary
>    <https://datatracker.ietf.org/doc/draft-schrock-action-evidence-boundary/>
>    - Canonical Action Identifier
>    <https://datatracker.ietf.org/doc/draft-schrock-canonical-action-identifier/>
>    - Bounded Capability Receipts
>    <https://datatracker.ietf.org/doc/draft-schrock-ep-bounded-capability-receipts/>
>    - AEB-1 runnable conformance profile and hostile cases
>    <https://github.com/emiliaprotocol/emilia-protocol/blob/main/docs/conformance/AEB-1-CONSEQUENCE-ADMISSION.md>
>
> These look like useful existing-work inputs to several questions in
> Section 19. I’d be glad to send a short R1–R14 crosswalk and run an
> interoperability exercise against your examples. Would you be open to
> adding them as related work and testing where your requirements still go
> beyond them?
>
> Best,
> Iman
>
>
> On Wed, 23 Sep 2026 17:25:42 +0530, Sangam Das <[e-mail]> wrote:
>
> Hi DISPATCH, I have submitted a new Informational Internet-Draft examining
> an effectuation-boundary problem for AI agents and autonomous systems.
> *Draft:* draft-das-accountable-autonomous-effectuation-01 *Title:* *AI
> Safety and Accountability at the Effectuation Boundary: Protocol
> Requirements for Autonomous Actions* *Datatracker:*
> https://datatracker.ietf.org/doc/draft-das-accountable-autonomous-effectuation/01/
> *The problem in 60 seconds* Autonomous and agentic systems do not
> necessarily follow a fixed execution path from initial authorization to
> final action. An agent may begin with an authorized objective, obtain new
> information, invoke additional services, change tools, re-plan, or alter a
> destination or operation several steps later. This creates a distinction
> between: *the action or authority established upstream* and *the actual
> consequential operation presented at the final execution boundary.* The
> draft calls this final non-bypassable point the *effectuation boundary*:
> the last practical point at which an action can still be withheld before
> producing an external consequence. The central question is whether a
> downstream component should be able to determine that the exact operation
> it is about to perform still corresponds to currently valid authority.
> *Questions for the IETF community* Section 20 intentionally leaves the
> standards outcome open and asks, among others: *Q1 — Is the problem
> distinct?* Is there a useful protocol distinction between general
> caller/workload authorization and verification that a particular locally
> observed consequential operation remains authorized at the point of
> effectuation? *Q11 — Is a new protocol needed at all?* Could existing
> mechanisms such as OAuth, WIMSE, RATS, COSE, Transaction Tokens, or
> application-specific profiles be composed to provide the required
> properties without defining a new protocol? The draft is therefore not
> based on the assumption that a new execution-finality protocol is required.
> A useful outcome could equally be an existing-protocol composition,
> profile, implementation guidance, or identification of work already
> covering the problem. *Canonicalization and semantic security* The -01
> revision also adds *Section 17.1, “Canonicalization, Semantic Equivalence,
> and Descriptor Interpretation.”* This addresses a security issue that
> becomes important when authority crosses implementations: two systems may
> cryptographically agree on a serialized object while assigning different
> meanings to one or more fields. The section therefore treats semantic
> agreement as part of the security boundary, including handling of: -
> duplicate fields; - type confusion; - unknown, absent, empty, and null
> values; - URI and identifier normalization; - versioning; - critical
> extensions; - deterministic encoding; and - cross-language conformance. The
> intended invariant is not merely canonical bytes, but a *canonical
> understanding of the consequence being authorized*. *Possible IETF
> relationships* The draft discusses possible relationships with: - OAuth and
> Rich Authorization Requests; - Transaction Tokens and sender-constrained
> authorization; - WIMSE and multi-hop workload context; - RATS and
> attestation of enforcement components; - COSE for protected authorization
> objects; and - emerging AgentProto work for cross-vendor agent-to-agent and
> agent-to-tool interaction. I would particularly appreciate DISPATCH
> feedback on: 1. whether the effectuation-boundary problem is sufficiently
> distinct to merit further work; 2. whether existing IETF mechanisms already
> provide the required properties when properly composed; 3. whether this
> should instead be expressed as a profile or cross-WG design exercise; and
> 4. which venue, if any, would be most appropriate. Best regards, *Sangam
> Das* Independent Researcher Balasore, Odisha, India [e-mail]
>
> _______________________________________________
> dispatch mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>