[SCITT] Re: New I-D: Evidence Requirements for Agent Control Delivery and Outcome Reconciliation (draft-abak-agent-control-delivery-evidence-00)

[Ali Toygar Abak <[e-mail]>]

Hi Iman,

Thank you. I agree that the target-multiplicity case exposes a real gap in -00.

The current text preserves a target or resolution input on the issuer side and a receiver identity on the receiver side, but it does not make the reconciliation unit explicit when one instruction resolves to more than one required enforcement target.

As you point out, that allows one matching receiver observation to satisfy an instruction-level CONFIRMED result while another required path remains open. Section 9.3 acknowledges the operational failure mode, but Sections 5 and 6 do not currently prevent that stronger delivery claim.

I think your description — existential evidence accidentally satisfying a universal delivery claim — captures the problem precisely.

My current preference is the second contract you suggest rather than requiring a new instruction identifier for every target:

an instruction that resolves to multiple required enforcement targets binds a closed required-target set, or a verifiable reference that resolves to such a set under the declared profile;

reconciliation assigns a disposition to each instruction-target obligation;

a receiver observation can satisfy only the target identity and boundary to which it is verifiably bound;

the parent instruction can be reported as fully confirmed only if every required instruction-target obligation is CONFIRMED; and

an open, unresolved, or otherwise non-closed required-target population cannot support a complete-delivery or PASS claim.


That also suggests conserving target obligations separately from parent instructions when target multiplicity exists, rather than allowing instruction-level population conservation to hide an uncovered path.

I also agree with the freeze race. APPLIED for the freeze must not retroactively relabel an operation that was already consumed or in flight before the freeze took effect, nor establish that an external effect already produced by that operation was reversed. I would like to add a conformance case covering that composition boundary while leaving the exact execution and consequential-effect semantics to the adjacent action-evidence work.

Your references to draft-schrock-ep-revocation-statement and draft-schrock-ep-outcome-binding are useful here. Tiago Pinto has also just pointed out a narrower composition seam with draft-pinto-agent-authz-contestability-00: its effect model deliberately separates acceptance of a declared effect policy, authenticated triggering, ordering, and claimed application. I am going to compare these adjacent models carefully before -01 so the control-delivery draft composes with existing boundaries rather than restating them.

And yes, please send the exact fixture if you are willing. I would prefer to test the -01 wording against your case rather than reconstruct a weaker version of it.

Thanks — this is exactly the kind of adversarial review I was hoping for.

Best,

Ali Toygar Abak



Phionyx

https://phionyx.ai








From: Iman Schrock <team=[e-mail]>
To: <[e-mail]>
Date: Mon, 31 Aug 2026 22:05:16 +0300
Subject: [SCITT] Re: New I-D: Evidence Requirements for Agent Control Delivery and Outcome Reconciliation (draft-abak-agent-control-delivery-evidence-00)



Ali, all, 
 
The lifecycle separation is useful, and Section 13 draws the boundary 
with AEB correctly: AEB follows a consequential action toward its 
effect; this draft follows a stop or revoke instruction toward the 
runtime constraint. 
 
My first failure is target multiplicity at reconciliation. R-CD-4 
requires a target or resolution input, R-CD-5 requires a receiver 
identity, and CONFIRMED then requires a matching instruction 
identifier and content binding. I do not see a normative step that 
binds the resolved target to that receiver, or an accounting unit that 
prevents one receiver observation from satisfying a control that 
resolves to several enforcement paths. 
 
For example: 
 
- ctrl-1 resolves to EP-A and EP-B. 
- A reads and applies it. 
- B produces no receiver observation and remains able to dispatch. 
- Under Section 6.1, ctrl-1 can be CONFIRMED. The issuer population in 
Section 6.3 still conserves. Section 9.3 says the control may 
nevertheless be ineffective. 
 
That is existential evidence for a universal delivery claim. 
 
I think the model needs one of two contracts: every intended path gets 
its own instruction identifier and disposition, or the instruction 
binds a closed target set and reconciliation produces one 
sub-disposition per target before the parent can be CONFIRMED. An open 
or unresolved target population should preclude PASS. R-CD-4 and 
R-CD-5 should also require exact agreement between the resolved target 
and the receiver identity and boundary, so the right instruction at 
the wrong enforcement point cannot confirm delivery. 
 
Two adjacent drafts may help define the composition seam. 
draft-schrock-ep-revocation-statement-01 defines the upstream signed 
control object and says explicitly that it proves the revoker acted, 
not that anyone received the revocation. 
draft-schrock-ep-outcome-binding-00 separates accepted dispatch from 
independently observed effect and keeps missing or unauthenticated 
required observations indeterminate. With AEB, the chain is revocation 
statement, control delivery and enforcement evidence, 
consequential-action boundary evidence, and effect reconciliation. No 
link implies the next. 
 
One race would be useful in the conformance set: O1 crosses provider 
entry, then a freeze commits, and O2 is blocked. O1 remains consumed 
or in flight and requires outcome reconciliation. Delivery or APPLIED 
status for the freeze cannot relabel O1 or prove that an external 
effect was reversed. The vector should bind the control epoch, closed 
target population, effect predicate, and observation window. 
 
I can contribute an exact fixture if useful. 
 
Best, 
Dr. Iman 
 
-- 
SCITT mailing list -- mailto:[e-mail] 
To unsubscribe send an email to mailto:[e-mail]