# What thresholds trigger a reconciliation tolerance-band resize?

**Date of Record:** 2026 November 2

**Scope:** Applies to automated reconciliation between two ledgers where a tolerance band determines whether a difference is auto-accepted or flagged. Does not apply to reconciliations with a legally-mandated zero tolerance, or where every difference is manually reviewed.

## Core Distinction

A tolerance band is a boundary between "auto-accept the difference" and "flag for investigation". It has two failure modes: too tight and false-positive floods drown real discrepancies; too loose and real errors are absorbed into the band and never surfaced. Both are failures of calibration, and neither is detectable from the tolerance value alone.

**Invariant.** A tolerance band is calibrated if and only if `tolerance >= noise_p99` (so false-positive rate stays bounded) AND `tolerance <= error_floor` (so real errors of the smallest meaningful size are flagged), where noise and error distributions are measured, not assumed.

**Violation.** The **Tolerance Miscalibration**. The band is set once at system build (to "seem reasonable") and never re-derived. Either the noise distribution grows (more transactions, more sources) and false-positive rate rises until the reconciliation is ignored, or the error distribution tightens (better upstream controls) and the band silently absorbs real discrepancies that used to be caught.

**Asymmetry.** The band is a single number, so a single failure it prevents or permits is invisible. The failure mode is one-sided: too tight is visible (alert fatigue, ignored reconciliation), too loose is invisible (errors absorbed silently).

**Recorded elements.** The `tolerance-value-receipt` (the current band), the `noise-distribution-signature` (the p99 of expected noise under current conditions), and the `error-floor-signature` (the smallest error size that must be caught, from audit or regulatory) together make calibration checkable.

## What Was Observed

**Signature.** Either of two shapes: (a) reconciliation alarm rate near 100% and the alarms are ignored, indicating tolerance is too tight; or (b) zero alarms over an extended period while discrepancies are later found in audit, indicating the band absorbed them. Both are calibration failures, and both are invisible from the tolerance value alone.

**Trace.** Band set to $100 at system build. Noise p99 rises to $150 as transaction volume doubles; false-positive rate becomes 100% and the operations team disables alerts rather than investigating. Alternatively, upstream controls tighten error floor to $10; band stays at $100; a $50 error is absorbed for months until external audit surfaces it.

**Why monitoring stays green.** In case (a), the tolerance is enforced — no rule is broken. In case (b), no rule is broken either. Both cases look like successful reconciliation from the reconciliation process's own point of view.

## Condition of Validity

The instance must ensure at least one holds before it treats a tolerance band as calibrated:

1. **Must re-derive at a cadence.** The band is re-derived from measured noise p99 and error floor on a schedule, not set once at build.
2. **Must measure both distributions.** Noise p99 and error floor are tracked; the band is the interval between them, not a guess at either.
3. **Must have a signal that the band has become uncalibrated.** Either false-positive rate crossing a threshold (band too tight) or zero flagged differences over a period exceeding expected error rate (band too loose) triggers re-derivation.

## Decision Boundary

- `tolerance >= noise_p99` and `tolerance <= error_floor`: calibrated.
- `tolerance < noise_p99`: band too tight; false positives will swamp.
- `tolerance > error_floor`: band too loose; errors below tolerance are absorbed.
- Neither noise nor error measured: unknown; the band is a guess, and its calibration can only be inferred from behaviour.

## Operational Effect

The invariant couples a single configuration number to two distributions that move with volume, controls, and counterparty behaviour. The instance's correct posture is to derive the band from measured distributions on a cadence, and to alert on both ends — false-positive rate and absorbed-error audit.

**Trap.** Widen the band to stop false positives. That is the correct response to a band that is too tight, but widening without re-deriving from error floor converts a visible problem into an invisible one. The band's width is derived from noise; its maximum is bounded by the error floor; a widening that crosses the floor is a miscalibration.

```python
from dataclasses import dataclass


class ToleranceMiscalibrationError(RuntimeError):
    """Raised when a reconciliation tolerance band is outside the interval defined by noise and error floor."""


@dataclass(frozen=True)
class ToleranceGate:
    tolerance: float
    noise_p99: float
    error_floor: float

    def verify(self) -> bool:
        if self.noise_p99 > 0 and self.tolerance < self.noise_p99:
            raise ToleranceMiscalibrationError(
                f"tolerance {self.tolerance} < noise p99 {self.noise_p99}: "
                "false-positive rate will swamp"
            )
        if self.error_floor > 0 and self.tolerance > self.error_floor:
            raise ToleranceMiscalibrationError(
                f"tolerance {self.tolerance} > error floor {self.error_floor}: "
                "errors below tolerance are silently absorbed"
            )
        return True


def dispatch_tolerance_mode(gate: ToleranceGate) -> str:
    try:
        gate.verify()
    except ToleranceMiscalibrationError:
        return "re-derive-from-distributions"
    return "band-calibrated"
```