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

["David S. Rose" <[e-mail]>]

Walter,

Thanks for your comments — the feedback is really helpful.

Taking your three points in order:

> a monitor asserting it ingested a byte stream is fundamentally
> decoupled from asserting semantic non-objection

Agreed, and the attached spec is emphatic about it — §6 (Non-claims):
"Consumption is not comprehension: the attestation does not certify
that the monitor evaluated the action correctly, or at all." Attested
consumption is offered as a necessary condition for admitting silence
as evidence, never a sufficient one. The construct's claim is narrower
than the one you're arguing against: an unwatched veto window
manufactures records in which absence reads as review, and the
attestation makes that specific laundering impossible without a signed
falsehood attributable to its signer.

On lag, skew, and partition "collapsing the system back into a
fail-closed gate": yes — deliberately. That is §3.5's normative
behavior ("when in doubt, degrade"), and the spec prices it plainly: a
non-consuming monitor costs availability, never safety. A monitor that
goes silent to dodge accountability has not vetoed anything — it has
converted holds to explicit-approval gates and triggered the
stalled-monitor alert to the principal (§3.5), which is a visible,
attributable event. And explicit signed approval is not an alternative
to this construct; it is the other half of it. Critical actions take
that path unconditionally. The staged path exists for the volume
regime where demanding a human signature per action decays into
rubber-stamping — the failure mode the construct was built against.

> SCITT is an evidentiary transparency layer, not an active workflow
> queue

Agreed again, and nothing proposed puts orchestration in the log. §5
(Composition): the staged record, the attestation, the objection, and
the adjudication "are payloads any signed-record system can carry."
No polling states, no interim mutation of receipts. What is offered is
record vocabulary — so that your "subsequent attested statement
referencing the subject artifact" has defined semantics, and, more
importantly, so the *absence* of one at expiry does. That absence is
the case the permit profile currently leaves open: `challenge` is a
decision value with no stated downstream semantics, which is the gap
this responds to. Whether the vocabulary lands in the family, in a
companion profile, or as application guidance is genuinely the group's
call — the offer stands for whichever the group prefers.

On your three questions:

1. Override vs. approval at the payload layer: semantics first,
encodings per the family's conventions. In my running system this is
an adjudication enum (approve / reject / modify / cancel / defer /
timeout / preempted) plus an override marking recorded as its own
fact — an approval over a standing objection is never representable
as an ordinary approve. I'm happy to draft a COSE claim-set mapping
against the permit-profile conventions if there's interest.

2. Replay and forgery of the attested position: the coverage
predicate is the defense (§2). An attestation covers a hold window only
if its signing time is at or after that window's close AND its attested
position is at or beyond the window's staged record — so a replayed
older attestation fails the signing-time leg for any later window by
construction. Deployments MUST reject attestations that are unsigned,
unattributed, replayed, or bound to positions the stream does not
contain (§4). A compromised monitor signing a false position is not
prevented — it is converted into attributable signed fraud, which is
the designed property, and the drill discipline in §4 exists to catch
the consuming-but-not-evaluating case from the outside.

3. Simultaneous expiry of the veto window and the underlying
authorization: release requires both legs live at the release
instant — a covering attestation AND a currently-valid authorization.
A tie resolves to no-release; the action re-enters as a fresh
proposal under whatever authorization then holds. You're right that
the current text leaves this composition invariant implicit; the next
revision will state it explicitly. Thanks for surfacing it.

One scoping note, since your invariance results come from
high-frequency settlement rails: that regime is explicitly outside
this construct's silence-release scope. Actions in the
irreversible/high-impact class never release on expiry under any
attestation state (§3.2) — they stage and gate. The construct
addresses human oversight of consequential agent actions, not
settlement finality, and makes no claims into your domain.

The full state machine and failure behavior are §§3.4–3.5 of the
attached spec; I'd genuinely welcome findings against them.

-David

> On Sep 4, 2026, at 6:08 AM, Walter Hawkins <[e-mail]> wrote:
> 
> 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]