[agent2agent] Re: [Agentproto] Re: Re: Fwd: New Version Notification for draft-agentic-ai-usecases-requirements-02.txt

[Anton Sokolov <[e-mail]>]

Hi Vernon, Henri, E.P., all,

Vernon, the delegation gap is real and the fix belongs in the row, as you
put it. The point I would add is why B3-10 does not already close it:
attributing a transformation to the hop that carried it out says who acted,
not that the two acts were one action instance. Provenance answers a
different question than identity, so the derivation sentence is doing work
that B3-10 is not.

On the error type, two things, and I want to separate them because I do not
think they are settled together.

Placement is the smaller one. My view is that it stays with CMN-5 rather
than being carried into CMN-11: CMN-11 states a property a recipient must
have, CMN-5 enumerates the structured errors, and on your reading CMN-4
already extended that set once with a scope-violation type, so adding a
duplicate-action type in the same place keeps the requirement about the
property and the error set in one location. Tiru, that is your call and I
will follow whichever placement you take.

The substance I do not think is settled, and I should flag that rather than
let it pass. My proposal counts effects rather than response codes, which
leaves an implementation free either to refuse the second presentation or
to answer it from what it recorded the first time; either way the action is
performed once, and that is what a mechanism-neutral vector can observe. A
mandatory typed refusal removes the second option. I am not against it, and
your argument for it is a real one, but it is a narrowing of what I
proposed and it should be adopted as such rather than folded in as agreed.
It also does not follow from the retry concern on its own: answering from
the recorded result resolves the instructing party's ambiguity just as well
as a refusal does. If the working group wants the typed refusal, the CMN-11
test wording needs to say response behaviour is constrained, not only that
effects are counted.

Henri, the separation of refusal from freshness is the same discrimination
reached from the other side, and it sharpens what a vector has to report. A
consumed action instance stays consumed however stale the recipient's
consumed-artifact set is, so staleness may weaken a negative answer but
never erase one already held. That is a stronger statement than the
reporting discipline in Section 11 of the composition draft: it is not only
that a boolean cannot diagnose, it is that a boolean forces a wrong answer
on this case. If a vector reports which layer refuses, what the relying
party decides, and the freshness of the state the refusal rests on as
separate fields, both discriminations stay observable.

E.P., yes, please extract them. Two notes on scope so the vectors claim
only what they demonstrate. Both cases sit under the first discrimination,
same artifact and same action instance, action performed once; your own
caveat that the first is single-process in-memory and the second a
deterministic same-team scenario should travel with them rather than be
dropped in extraction. And as you and Vernon both note, the
different-recipient negative is still uncovered: an artifact bound to one
intended use presented for another, a different recipient or a different
action instance, and refused while the artifact is still inside its
validity window. That case needs a vector written for it, and with Vernon's
derivation sentence in the row there is a third: a derived artifact
presented at a later hop for an action instance already performed upstream.
Whether any of them go into -03 is Gaowei's and Tiru's call.

Gaowei, Tiru, the -03 ask is unchanged in shape: one new row in Table 1,
CMN-11, carrying the recipient-side clause, the retention sentence and now
the derivation sentence, and CMN-11 added to the Section 5 list of
requirements expected to be handled in OAuth and WIMSE. The open question
for you is whether the row constrains the response as well as the effect.

Best,
Anton Sokolov
Tyche Institute, Tallinn, Estonia

On Thu, Sep 03, 2026 12:31 AM, Vernon Wharff <[e-mail]> wrote:

> I am only now getting around to this. Since the discussion has concluded
> in the time since, I will limit myself to the two gaps I still notice in
> the CMN-11 text and how the latest messages have affected them. I agree
> with the minimal course suggested: one entry in Table 1, CMN-11 to be
> included in the list in Section 5, and two amendments to be carried out.
>
> The first gap is that the proposed text associates each artifact with its
> recipient, with one action instance, and with a validity period. Section
> 4.4.3 includes multi-hop delegation chains, in which a delegate that
> reauthorises subsequent work generates new artifacts from the one it
> received. The text does not state whether the action instance identity must
> be preserved during this derivation. B3-10 requires a provenance record to
> attribute each transformation to the hop that carried it out, but it does
> not require the hops to refer to a single action instance. Without that
> requirement, each hop can ensure freshness with respect to its own artifact
> while the chain as a whole carries out the action twice and all the hops
> are successful. One sentence in the text for the CMN-11 row resolves this
> issue: an artifact derived from another inherits the action instance
> identity of the artifact from which it was derived, so the once-performed
> property is enforced for the chain as a whole rather than at each hop. This
> preserves the two-edit path since that sentence is included in the row and
> not added as an extra row.
>
> The second gap is smaller and Henri's result reinforces this point. CMN-5
> identifies authentication failure, authorization failure, timeout, and
> internal error as the various types of structured error. None of these
> informs the party giving the instruction that the action has already been
> carried out. A detected replay must be met with an explicit refusal rather
> than silence, since the instructing party must be made aware that a retry
> would be unsafe. Henri's work on revocation draws the same conclusion from
> the other side: a refusal which the recipient already has must not be
> discarded, and staleness must only weaken the negative answer. Since the
> action instance remains consumed regardless of the freshness of the set of
> consumed artifacts, the refusal and the freshness must be separate fields,
> which is a reason for using a typed duplicate-action refusal rather than a
> simple boolean or an untyped error. CMN-4 had already added a
> scope-violation type to the error set in the same way; the duplicate-action
> type is just one line.
>
> Tiru, the same question is: should the new requirement include that error
> type or should the error set remain where CMN-5 has placed it?
>
> Regarding E.P.'s examples: they are useful and deserve to be adopted as
> mechanism-neutral CMN-11 vectors, with the single exception that E.P.
> herself makes clear. In both cases the first kind of discrimination
> applies: it is the same artifact and the same action instance with the
> action carried out once. The second discrimination—where the artifact is
> presented to a different recipient or where a different action instance
> occurs—is one that a bounded validity interval never picks up on, and it
> stays open in both the single-process and the same-team situations. When
> the vectors are extracted, they should include the reporting discipline
> that Anton describes rather than merely the vocabulary; since each vector
> specifies which layer is refusing and what the relying party has decided,
> there is no need for a single boolean 'valid' to stand in for diagnosing
> problems across different implementations.
>
> The lack of a gap has no effect on the following step. The two amendments
> remain as suggested; the delegation sentence can go in the text of the
> CMN-11 row and the error type is Tiru's call.
>
> Vernon
> Sigil Open Framework
>
> On Wed, Sep 2, 2026 at 1:52 PM Iman Schrock <team=
> [e-mail]> wrote:
>
>> Anton, Guigui, Henri,
>>
>> I like the minimal CMN-11 path. Its effect-count wording is testable
>> as written. I reran two open reference cases at public commit 1fe510b:
>>
>> - 50 concurrent presentations of one action-bound evidence chain
>> produced one callback entry and 49 replay refusals.
>> - After callback entry and response loss, a new executor instance over
>> the same reference backend state refused the retry; the callback count
>> stayed one and the outcome remained indeterminate.
>>
>> The first is a single-process in-memory test. The second is a
>> deterministic same-team scenario, not evidence of database
>> linearizability or exactly-once physical effect. They support the
>> recipient-side replay observable, not yet the different-recipient
>> negative.
>>
>> If useful, I can extract them as mechanism-neutral CMN-11 vectors for -03.
>>
>> Tests:
>>
>> https://github.com/emiliaprotocol/emilia-protocol/blob/1fe510bc5be3709f654dc6783f4749ca09913e8a/tests/aec-execution-gate.test.ts#L42-L54
>>
>> https://github.com/emiliaprotocol/emilia-protocol/blob/1fe510bc5be3709f654dc6783f4749ca09913e8a/tests/aec-execution-fleet-assurance.test.ts#L143-L154
>>
>> Best,
>> E.P
>>
>> _______________________________________________
>> agent2agent mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>