[SCITT] Re: Escalation and hold-window semantics — a companion layer for draft-munoz-scitt-permit-profile

[Walter Hawkins <[e-mail]>]

Hi David,

A quick technical observation on this proposal, having spent considerable
engineering time implementing deterministic pre-execution invariants and
post-settlement transparency receipts in this exact domain
(draft-hawkins-scitt-attested-agent-payment,
draft-munoz-scitt-permit-profile, and the receipt-invariant/1 production
suite).

While the intent to model downstream escalation is understandable, the
mechanics described in your note introduce several severe protocol
ambiguities that SCITT’s architectural model was specifically designed to
avoid:

1. The Fallacy of "Attested Stream Consumption" for Vetoes:
You state: "releases on expiry only when an independent monitor's attested
last-processed stream position shows it actually consumed the proposal
before the window closed — silence as no-objection only when the objector
was demonstrably reading."

>From an attestation and state-machine perspective, a monitor asserting it
ingested a byte stream is fundamentally decoupled from asserting semantic
non-objection. It introduces an undefined failure mode: network lag, clock
skew, or log partitioning immediately collapses the system back into a
fail-closed gate. In adversarial multi-agent environments, an objector who
wishes to veto without accountability can simply halt its stream ack or
delay heartbeat attestation. Silence cannot be made safe by merely proving
observation; safety requires explicit, signed cryptographic assertions
(such as COSE_Sign1 claims or bounded pre-authorizations).

2. Boundary Confusion with draft-munoz-scitt-permit-profile:
The permit profile (draft-munoz-scitt-permit-profile-01) intentionally
bounds itself to the verifiable decision record. The moment you introduce
human hold-windows, arbitrary veto timeouts, and asynchronous escalation
into the SCITT envelope, you are conflating immutable ledger receipts with
stateful orchestration/workflow engines. SCITT is an evidentiary
transparency layer, not an active workflow queue. If an escalation results
in an override, the resolution is simply recorded as a subsequent attested
statement referencing the subject artifact — there is no need to bloat the
core receipt schema with interim "awaiting approver" polling states.

3. Reconciliation Invariants and Replay Vulnerability:
Under production conditions (e.g. high-frequency autonomous agent
settlement), "hold windows" with asymmetrical timeout defaults create
severe race conditions between authorization expiry and settlement
finality. In our formal invariance testing across live rails, any model
that relies on time-decay release without cryptographic two-phase locking
(receipt-invariant/1 / RFC 8785 canonical vectors) reliably breaks under
network partitions, resulting in unauthorized double-releases or orphaned
authorizations.

If you intend to propose formal companion semantics for the permit-profile
family, could you clarify:
- How does your proposed schema represent the distinction between an
override and an approval at the CBOR/COSE payload layer?
- What canonical structure guarantees that the "attested stream position"
cannot be replayed or forged by a compromised monitor?
- What are the concrete state-transition invariants when the veto window
and the underlying authorization epoch expire simultaneously?

Without rigorous, deterministic state definitions, informal hold windows
belong in application-level runtime orchestration (such as local policy
agents), rather than the IETF SCITT standards track.

Regards,

Walter Hawkins
Corrente Labs, Inc.
Author, draft-hawkins-x402-dns-discovery /
draft-hawkins-scitt-attested-agent-payment
ashlar.blue | correntelabs.com

On Thu, Sep 3, 2026 at 11:47 PM David S. Rose <[e-mail]>
wrote:

> Hi all,
>
> I'm David S. Rose. I build and operate a governed personal-AI-agent
> deployment, and I've been following the agent-drafts discussion here
> with interest.
>
> The permit profile (draft-munoz-scitt-permit-profile-01) scopes itself
> to the pre-execution decision record, and — as far as I can see —
> escalation workflows, hold windows, and monitor constructs appear
> nowhere in it: "challenge" is a decision value whose downstream
> semantics the document leaves open. The CHAP discussion in August
> was circling the same ground from the human-authority side.
>
> I have been operating a construction for exactly that layer and would
> like to contribute its semantics:
>
> - Two escalation shapes with opposite timeout defaults: an approver
>   gate that fails closed (expiry -> deny), and a veto window that
>   releases on expiry only when an independent monitor's attested
>   last-processed stream position shows it actually consumed the
>   proposal before the window closed — silence as no-objection only
>   when the objector was demonstrably reading — with degradation to
>   gate semantics otherwise.
>
> - An adjudication vocabulary that records an approval-over-objection
>   as an override, rather than an ordinary approve.
>
> - A deliberate distinction between "awaiting an approver" and "staged
>   pending conditions" — different pauses with different safe defaults.
>
> A short standalone specification of the release interlock ("Attested
> Staged Release", v0.1 draft) is attached for discussion. Offered for
> incorporation into the permit-profile family or as a companion
> profile, whichever the group prefers.
>
> -David
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>