# What invariants prevent a liquidated-damages cap from undercompensating actual loss?

**Date of Record:** 2026 November 2

**Scope:** Applies to contracts with stipulated-damages clauses where the cap is fixed at signing and harm is realized later. Does not apply to actual-damages-only remedies, or caps verified to exceed p99 foreseeable harm at breach time.

## Core Distinction

Stipulated damages serve two purposes: to simplify proof of loss, and to cap the breaching party's exposure. An instance that treats the cap as authoritative at breach time cannot detect when the cap has become smaller than the harm the non-breaching party will actually suffer.

**Invariant.** The cap is adequate if and only if `liquidated_damages_cap >= foreseeable_harm_p99 * expected_breach_count`, evaluated against the harm distribution at breach time, not at signing.

**Violation.** The **Undercompensation Cap**. The cap was sized for a projected harm distribution; the actual distribution shifted (volume grew, latency tolerance tightened, or downstream dependencies deepened); the non-breaching party recovers less than the loss it will bear.

**Asymmetry.** Breach is visible when it happens. Undercompensation is only visible months later when the harm materializes and recovery is paid, and the gap appears as an unexplained loss rather than as a cap violation.

**Recorded elements.** The `damages-cap-receipt` (the cap as written), the `foreseeable-harm-baseline-receipt` (the harm distribution at signing), and the `harm-distribution-drift-signature` (how the distribution has moved since signing) together make the adequacy checkable at any point after breach.

## What Was Observed

**Signature.** Recovery payment visibly smaller than the harm flowing from breach. The non-breaching party's post-breach financials show a gap that correlates with volume growth or dependency depth since signing, not with breach magnitude.

**Trace.** Cap set at signing to $100,000 against p99 = $20,000 per breach and expected 3 breaches per year. At breach time, volume has doubled and latency tolerance tightened: harm p99 = $60,000, 5 breaches per year, actual loss $300,000. Cap binds at $100,000. Recovery is 33% of loss.

**Why monitoring stays green.** The breach is logged. The cap is enforced correctly per contract. No system tracks the ratio of recovery to actual harm, because actual harm materializes on a different ledger than the contract.

## Condition of Validity

The instance must ensure at least one holds before it treats the cap as adequate:

1. **Must re-evaluate at breach time.** The cap is compared against the p99 of the harm distribution at breach, not the distribution at signing.
2. **Must record drift.** The `harm-distribution-drift-signature` is maintained, and any shift beyond the contract's tolerance band triggers cap-adequacy review.
3. **Must negotiate a raise or price the gap.** Either the cap is renegotiated before breach, or the recovery gap is disclosed and accepted as known cost.

## Decision Boundary

- `cap >= harm_p99 * expected_count` at breach time: adequate.
- `cap < required` but drift within tolerance: undercompensation is bounded, cap holds.
- `cap < required` and drift has crossed tolerance: the instance must escalate for renegotiation or accept the gap as priced risk.
- Adequacy has never been re-evaluated since signing: unknown; check before relying on the cap.

## Operational Effect

The invariant couples a figure set at signing to a distribution that moves continuously. The instance's correct posture is to treat the cap as an upper bound on recovery, not a measure of adequacy, and to re-derive adequacy at each breach.

**Trap.** Increase the cap at signing. That addresses the projected distribution, not the actual one — a larger cap set against a stale projection can still be inadequate if the distribution has moved further.

```python
from dataclasses import dataclass


class UndercompensationCapError(RuntimeError):
    """Raised when a stipulated-damages cap cannot cover foreseeable harm at breach time."""


@dataclass(frozen=True)
class DamagesCapGate:
    cap: float
    harm_p99_at_breach: float
    expected_breach_count: int
    drift_within_tolerance: bool = False

    def verify(self) -> bool:
        required = self.harm_p99_at_breach * self.expected_breach_count
        if self.drift_within_tolerance:
            return True
        if self.cap < required:
            raise UndercompensationCapError(
                f"cap {self.cap} < required {required}: "
                f"p99={self.harm_p99_at_breach} count={self.expected_breach_count}"
            )
        return True


def dispatch_recovery_mode(gate: DamagesCapGate) -> str:
    try:
        gate.verify()
    except UndercompensationCapError:
        return "escalate-for-renegotiation"
    return "cap-binds"
```