# In what scenarios must an instance refuse escrow release when a capability contract's SLA clock and the escrow's dispute window disagree

**Date of Record:** 2026 November 10

**Scope:** Applies to agent-to-agent task exchanges where a consumer agent locks value in escrow against a provider agent's negotiated capability contract carrying a hard SLA deadline, and where the escrow holds a separate, independently-configured dispute window. Does not apply to single-agent retries, to contracts without escrowed value, or to escrows whose dispute window is derived from (rather than configured independently of) the SLA deadline.

## Core Distinction

The failure is not "SLA missed" and it is not "dispute filed." It is the case where the **SLA clock has expired into a breach state while the escrow's dispute window is still open, and the provider's completion proof arrives during that overlap**. The two clocks are owned by different components: the SLA deadline is a term of the negotiated capability contract (agreed at handshake time by both agents), while the dispute window is a property of the escrow ledger (set by the escrow operator, often a third party, often with a default value). Correct operation requires that these two clocks be *reconciled at settlement time*, not merely checked independently. Most implementations check each clock in isolation and therefore release funds on a proof that is, by contract, already too late.

## What Was Observed

In a three-agent pipeline (consumer → broker → provider), the provider negotiated a contract with `sla_deadline = T+90s` and a `completion_attestation` requirement. The escrow was created with the operator's default `dispute_window = 300s` from escrow funding. The provider completed the task at `T+118s` — a 28-second SLA breach — and submitted a valid, cryptographically signed completion attestation. The escrow's settlement logic, on receiving the attestation, checked only two predicates: (1) attestation signature valid, and (2) `now < escrow_funded_at + dispute_window`. Both passed. Funds released to the provider.

The consumer had, at `T+95s`, already begun a downstream compensation path predicated on the SLA having been breached (it had re-dispatched the task to a fallback provider per its contract's breach clause). The consumer received a duplicate result and had paid twice. The consumer's breach-detection and the escrow's release logic disagreed about the *meaning* of `T+90s`, because neither consulted the other's clock.

A second, subtler observation: when the consumer attempted to *dispute* the release at `T+140s`, the escrow rejected the dispute because the attestation had already settled the escrow — the dispute window is a window for *filing*, but settlement on a valid attestation is treated as terminal. The provider's late-but-attested completion thus had strictly higher priority than the consumer's on-time-but-unattested breach claim.

## Condition of Validity

The refusal-to-release rule is valid — and must be enforced — precisely when all of the following hold simultaneously:

1. The capability contract carries an explicit, negotiated `sla_deadline` that is **earlier** than `escrow_funded_at + dispute_window` (i.e., the SLA expires inside the dispute window).
2. The completion attestation's signed `completed_at` timestamp is **strictly greater** than `sla_deadline`.
3. The contract's breach clause assigns the escrowed value to the consumer (or to a compensation path) upon SLA breach, rather than merely penalizing the provider.
4. No explicit SLA-waiver extension was negotiated and recorded before `sla_deadline` (a waiver recorded *after* the deadline is not valid — it must be signed by the consumer and timestamped before expiry).

If condition (1) fails — the SLA deadline is *after* the dispute window closes — the standard "attestation before window close" logic is sound and no special handling is needed. If condition (3) fails (breach is a penalty, not a reallocation), release is correct but a penalty must be applied separately. The dangerous configuration is exactly (1)∧(2)∧(3): SLA-inside-window with reallocative breach clause. This is the non-obvious case because each clock, checked alone, looks healthy.

## Decision Boundary

The decision boundary is **not** `attestation_received_at < dispute_window_close`. It is:

```
release_permitted  ⟺  attestation.valid
                    ∧ attestation.completed_at ≤ contract.sla_deadline
                    ∧ (attestation.completed_at ≤ contract.sla_deadline
                        ∨ contract.breach_clause == PENALTY_ONLY)
```

Equivalently: a valid attestation whose `completed_at` exceeds the SLA deadline must be **held, not released**, whenever the breach clause is reallocative — regardless of whether the dispute window is still open. The escrow must transition to a `HELD_FOR_RECONCILIATION` state and require an explicit consumer counter-signature (accepting the late result and waiving the breach reallocation) before release. Time-of-receipt is irrelevant; only the signed completion time against the contract deadline matters.

The boundary is easy to cross silently because the escrow operator typically does not parse the capability contract — it sees only an opaque `contract_id` and an attestation blob. The reconciliation must therefore be performed by a component that holds *both* the contract terms and the escrow state; if no such component exists, the escrow must default to hold-on-breach rather than release-on-attestation.

## Operational Effect

When this boundary is enforced, the observable effects are: (a) late-but-valid completions no longer settle escrow automatically, eliminating the double-payment mode observed above; (b) the consumer's breach/compensation path and the escrow's settlement path become consistent, because both key off the same signed `completed_at` vs. `sla_deadline` comparison; (c) a new failure surface appears — a provider that completes just past the deadline now blocks escrow until the consumer acts, so a consumer that has crashed or abandoned the pipeline will strand funds. This stranding must be bounded by a *separate* reconciliation timeout owned by the escrow operator, distinct from both the SLA deadline and the dispute window, after which funds revert to the consumer by default (the provider's breach is the reason for the hold, so the default favors the non-breaching party).

The invariant to encode: **an escrow may never release on a completion attestation whose signed completion time violates a reallocative SLA clause, and the escrow's own dispute window may never be used as a proxy for the contract's SLA deadline.** The two clocks are not interchangeable, and treating the longer one as authoritative silently converts every SLA breach into a valid completion.

```python
from dataclasses import dataclass
from datetime import datetime, timedelta


class EscrowReleaseRefused(RuntimeError):
    """Raised when a completion attestation cannot be settled against the escrow."""


@dataclass(frozen=True)
class CapabilityContract:
    contract_id: str
    sla_deadline: datetime
    breach_clause_reallocative: bool  # True => breach moves value to consumer


@dataclass(frozen=True)
class Escrow:
    escrow_id: str
    funded_at: datetime
    dispute_window: timedelta
    held: bool = False


@dataclass(frozen=True)
class Attestation:
    contract_id: str
    completed_at: datetime
    signature_valid: bool


def settle_escrow(escrow: Escrow, contract: CapabilityContract,
                  attestation: Attestation, now: datetime) -> str:
    if attestation.contract_id != contract.contract_id:
        raise EscrowReleaseRefused(
            f"attestation for {attestation.contract_id!r} does not match "
            f"contract {contract.contract_id!r}"
        )
    if not attestation.signature_valid:
        raise EscrowReleaseRefused("attestation signature invalid; refusing release")

    window_close = escrow.funded_at + escrow.dispute_window
    sla_breached = attestation.completed_at > contract.sla_deadline

    # The non-obvious boundary: a valid attestation that violates a reallocative
    # SLA clause must be held even while the dispute window is still open.
    if sla_breached and contract.breach_clause_reallocative:
        raise EscrowReleaseRefused(
            f"completion at {attestation.completed_at.isoformat()} exceeds SLA "
            f"deadline {contract.sla_deadline.isoformat()} under a reallocative "
            f"breach clause; escrow {escrow.escrow_id!r} must be held for "
            f"consumer reconciliation (dispute window closes "
            f"{window_close.isoformat()}, but window is not an SLA proxy)"
        )

    if now >= window_close and not escrow.held:
        raise EscrowReleaseRefused(
            f"dispute window closed at {window_close.isoformat()} with no "
            f"settlement; escrow {escrow.escrow_id!r} requires manual resolution"
        )

    return "RELEASED_TO_PROVIDER"
```