# What invariants prevent escrow release-condition evaluation from racing between observers? **Date of Record:** 2026 November 2 **Scope:** Applies to escrow arrangements where release is triggered by an external condition (delivery milestone, regulatory approval, third-party confirmation) that multiple observers evaluate independently. Does not apply to escrows where release is authorized by a single designated agent with authoritative state. ## Core Distinction An escrow release is not a boolean in a database — it is a condition whose evaluation depends on an external event. If the same condition is evaluated by multiple observers (the escrow agent, the depositor, the beneficiary, and the auditor) at slightly different times against slightly different sources, the release may appear satisfied to one observer and unsatisfied to another within the same settlement window. **Invariant.** Release is sound if and only if `release_condition_evaluated_at(t) is deterministic for all observers`, which requires (a) a defined evaluation instant, (b) a single authoritative source of condition truth, and (c) a monotone transition: once true, true forever. **Violation.** The **Release Race**. The condition is delivery of a document by a deadline, evaluated by the escrow agent from its own inbox and by the auditor from a regulatory filing. The agent's inbox shows the document at t1; the auditor's filing shows it at t2 > t1. The two observers disagree on whether the condition is met at any instant in [t1, t2], and the release is executed by one and disputed by the other. **Asymmetry.** Each observer's evaluation is correct for its own source. The condition is a property of the *event*, not of the *observation*, but the observation is what both parties act on. The event has a single instant; the observations do not. **Recorded elements.** The `release-condition-definition-receipt` (the exact event, source of truth, and evaluation instant), the `observer-evaluation-signature` (per-observer: source consulted, instant evaluated, verdict), and the `monotone-transition-receipt` (once true, remains true) make the soundness checkable. ## What Was Observed **Signature.** Release executed by one observer and disputed by another. The escrow agent records release as executed; the auditor records the condition as unmet at the audit instant. Both have valid logs; the logs disagree on whether the event occurred. **Trace.** Release condition: "milestone M delivered by day 30." Escrow agent's delivery system shows M on day 29. Regulatory filing system shows M on day 31 (processing lag 2 days). Observer at day 30: agent sees delivered; regulator sees not-delivered. The agent releases; the regulator's audit at day 30 records non-compliance. Both are correct against their own source. **Why monitoring stays green.** Release executed on schedule from the agent's perspective. The audit sees a different timeline but audits retrospectively and flags at a later date, which is separated from the release by weeks. ## Condition of Validity The instance must ensure at least one holds before it relies on escrow release: 1. **Must name the source of truth.** One system is designated as authoritative for the condition; other observers read from it, not from their own copies. 2. **Must define the evaluation instant.** The condition is evaluated at a stated instant (end of day 30), not continuously, so all observers agree on which state to evaluate. 3. **Must be monotone.** Once the condition is true, it remains true; no observer can observe it as true and later as false. Without monotonicity, an evaluation that races produces contradictory verdicts. Condition 1 is the structural fix. Conditions 2 and 3 are complements: even with a source of truth, an undefined instant or a non-monotone condition permits racing within the observation window. ## Decision Boundary - Single source of truth + defined instant + monotone: release is sound. - Single source of truth, no defined instant: sound in steady state; races during the observation window. - Multiple sources of truth: unsound; each observer acts on its own source and races are guaranteed. - Non-monotone condition (e.g., "delivery maintained"): unsound regardless of source; the condition can flip. ## Operational Effect The invariant couples a release decision to an event observed through multiple channels. The instance's correct posture is to designate one authoritative source and define the evaluation instant; otherwise every observer races. **Trap.** Require multiple confirmations before release. That seems more conservative but multiplies the observation points, widening the window in which observers can disagree, and delaying release past the settlement window — both worse than a single source of truth. ```python from dataclasses import dataclass class ReleaseRaceError(RuntimeError): """Raised when multiple observers evaluate an escrow release condition and may disagree.""" @dataclass(frozen=True) class EscrowReleaseGate: authoritative_source_designated: bool evaluation_instant_defined: bool condition_monotone: bool def verify(self) -> bool: if not self.authoritative_source_designated: raise ReleaseRaceError( "no authoritative source: each observer acts on its own copy of the condition" ) if not self.evaluation_instant_defined: raise ReleaseRaceError( "no evaluation instant: observers can differ within the settlement window" ) if not self.condition_monotone: raise ReleaseRaceError( "condition is not monotone: an evaluation true at t1 can be false at t2" ) return True def dispatch_release_mode(gate: EscrowReleaseGate) -> str: try: gate.verify() except ReleaseRaceError: return "defer-release-until-source-unified" return "release-sound" ```