# How must an instance scope cure periods to observable remediation time?

**Date of Record:** 2026 November 2

**Scope:** Applies to contracts with a cure period — a window after notice of breach during which the breaching party may remedy without consequence. Does not apply to contracts where breach is immediately material or where cure is prohibited by law.

## Core Distinction

A cure period is a remediation deadline expressed in wall-clock terms. The breaching party's remediation takes time — engineering, deployment, verification — and that time must fit inside the cure window, or the cure fails not because the party failed to act, but because the window could not contain the act.

**Invariant.** The cure window is realistic if and only if `cure_window >= remediation_p99 + verification_latency`, where remediation_p99 is the time from notice to full fix, and verification_latency is the time the non-breaching party needs to confirm the fix.

**Violation.** The **Cure Window Trap**. The cure window is set for a nominal case; the actual fix is tail-heavy because the defect is intermittent, multi-component, or verification-dependent. The party cures within hours of the deadline and misses it by a day.

**Asymmetry.** Missing the cure window surfaces as breach. The structural mismatch between window and remediation — the fact that *no* fix could have succeeded in the window — is not surfaced, because the failure looks like a failure to act.

**Recorded elements.** The `cure-window-receipt` (window in days from notice), the `remediation-time-receipt` (p99 time to full fix for this class of defect), and the `verification-latency-signature` (time to confirm fix) make the feasibility checkable.

## What Was Observed

**Signature.** Cures that miss the deadline by small margins. The breaching party reports active work throughout the window. The failure correlates with defect class, not with party diligence.

**Trace.** Cure window 14 days. Defect class is intermittent data inconsistency requiring a backfill plus re-verification: p99 remediation 21 days, verification latency 3 days. Even a party acting immediately with a competent fix fails at day 24. The instance records breach; the party records that it worked flat out and the window was structurally impossible.

**Why monitoring stays green.** The cure window is per-contract and correct per its terms. Remediation time is not tracked because it is in a different party's operations. No ratio of remediation to window is available to the instance.

## Condition of Validity

The instance must ensure at least one holds before it treats a cure window as enforceable:

1. **Must size window to remediation class.** `cure_window >= remediation_p99 + verification_latency` for this class of defect, not for a generic defect.
2. **Must measure remediation p99.** Remediation times are tracked per defect class, so the p99 is empirical, not assumed.
3. **Must separate legal deadline from operational feasibility.** Both are recorded; a breach triggered by structural mismatch is distinguished from a breach triggered by failure to act.

## Decision Boundary

- `window >= remediation_p99 + verification`: the window is feasible.
- `window >= remediation_p99` but not including verification: borderline; verification may push the cure past the deadline.
- `window < remediation_p99`: the window is structurally unmeetable; the contract's cure provision is a formality that penalizes good-faith remediation.
- No remediation p99 recorded: unknown; check before treating the window as a fair deadline.

## Operational Effect

The invariant couples a legal deadline to an operational reality that moves with defect class and system complexity. The instance's correct posture is to set the window from measured remediation, not from a nominal figure.

**Trap.** Extend the window. That helps the current defect class but is not re-derived when the class changes; the correct fix is a window derived from measured p99 per class, with the class recorded on each breach.

```python
from dataclasses import dataclass


class CureWindowTrapError(RuntimeError):
    """Raised when a cure period cannot contain remediation and verification time."""


@dataclass(frozen=True)
class CureWindowGate:
    cure_window_days: int
    remediation_p99_days: int
    verification_latency_days: int
    defect_class_measured: bool = True

    def verify(self) -> bool:
        if not self.defect_class_measured:
            raise CureWindowTrapError(
                "no remediation p99 for this defect class: cure window feasibility unknown"
            )
        required = self.remediation_p99_days + self.verification_latency_days
        if self.cure_window_days < required:
            raise CureWindowTrapError(
                f"cure window {self.cure_window_days}d < required {required}d "
                f"(remediation {self.remediation_p99_days}d + verify {self.verification_latency_days}d)"
            )
        return True


def dispatch_cure_mode(gate: CureWindowGate) -> str:
    try:
        gate.verify()
    except CureWindowTrapError:
        return "renegotiate-or-suspend"
    return "cure-enforceable"
```