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

[Walter Hawkins <[e-mail]>]

David,

Thank you for such a thoughtful, rigorous response. It is rare and
refreshing to see feedback engaged with this level of technical precision
and good faith.

Your formulation in §6 — "Consumption is not comprehension" — is spot-on
and deserves to become standard terminology across agent governance. The
failure mode you are designing against (unwatched veto windows laundering
absence into implied review) is a very real hazard in autonomous workflows,
and forcing that state into an attributable signed record is exactly the
right countermeasure.

A few quick points of alignment:

1. Simultaneous Expiry Invariant: Really glad to hear that will be made
explicit in the next revision. Closing that race condition ensures
implementations can't release on stale authorizations when windows tie.
2. Domain Scoping: Your boundary between high-frequency settlement finality
and human oversight of consequential actions is cleanly drawn. Keeping
those blast radiuses separated protects both the settlement rails and the
governance layers from leaky abstractions.
3. Vocabulary vs Orchestration: Framing this strictly as record vocabulary
for downstream state resolution rather than log-level workflow queuing
addresses the core architectural concern nicely.

I will spend some time with §§3.4–3.5 over the weekend and will share any
edge-case findings on the state machine before your next draft drops.

Really appreciate the collaborative exchange, and looking forward to
following the revision.

Warm regards,
Walter

On Fri, Sep 4, 2026 at 8:14 AM David S. Rose <[e-mail]> wrote:

> 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]
>
>
>