Replacement purchase & close-out

1 · The exchanger is never in the money path. No surface, dialog, row or button may place the exchanger in a fund-movement approval or initiation role. Release of qualified-escrow funds is authorized by two authorized officers, and the approver is never the proposer. An exchanger approval right over escrowed funds is constructive receipt under Treas. Reg. §1.1031(k)-1(g)(6) and ends the deferral. The exchanger's acts are rendered as records: a payee confirmation and a written direction, both explicitly non-authorizing and non-gating. In the markup, an authorization slot is solid and a non-authorizing slot is dashed — they may never be styled alike. An authorization slot that is merely unfilled stays solid with its fill drained (.slot.is-awaiting), so "waiting for an approver" can never be mistaken for "this person has no approval role".
2 · A proposal is not an approval. The proposer's own submission is never rendered or counted as an approval. The counter reads “Approvals recorded: none yet · one required, from an officer who is not the proposer” — it does not read “1 of 2”. MultiPartyApprovalPanel.tsx today falls back to latestProposal.proposedByRole when approvedByRole is absent, which prints a proposal in the approval slot; that fallback must be deleted, not re-labelled.
3 · Payee confirmation is a fraud control, not an authorization. It is drawn and captioned as a second pair of eyes on the destination. It does not start the wire, does not unlock another party's step, and its absence holds the wire rather than blocking a gate the exchanger owns. Any post-confirmation change to payee, bank, routing or account voids the confirmation, stops the wire, and triggers an out-of-band callback on a number already on file. Never accept changed wire instructions from an inbound message alone.
4 · KYC is always the first gate, and it is never cleared by proxy. Identity verification is the first row of the gate list and states who performed it and when. No affordance anywhere lets a coordinator, an officer, or the exchanger's representative mark identity verified on someone's behalf.
5 · A signature requires the signer's own intent. There is no “sign on behalf” affordance in this product. The seller's acknowledgement of the assignment notice is drawn as waiting on the seller with chase actions only, and the row says out loud that neither Open1031 nor the exchanger may sign it (eSign Act / UETA).
6 · Status derives from evidence, never from one flag. Each leg's headline is computed from settlement dates, escrow receipts, recorded signatures with timestamps, screening results and identified-property counts. The shipped hubs read a single hubStatus.submitted boolean, which is the exchanger's progress through their own forms — never the state of the leg. A leg holding $1.29M of received escrow must never read “Not yet submitted”.
7 · Waiting-on attribution on every leg and every document row. Four values only: Waiting on you, Waiting on <named party>, Nothing for you to do, Blocked. The chip always names the party, so colour is never the only signal. Ambient anxiety on this product comes from not knowing whose move it is.
8 · Exactly one next step. One filled primary control on the surface, and it lives inside the section that owns the work — never in a summary strip that dumps the user on an overview to hunt. The directive line at the top names it and links to it; it is a text link, not a competing button. Never zero, never two.
9 · An overdue statutory deadline never renders as satisfied, met, or green. The 45-day clock reads “Met” only because it was met, and it prints the evidence (3 properties, Jun 18, signed notice). A passed 180-day clock turns the clock card, the window gate and the release path red and keeps them red regardless of what else is complete.
10 · Money is written precisely and sourced. Two decimals everywhere, tabular numerals, and every figure carries who recorded it and when. Full account and routing numbers are never shown to the exchanger — last four only. Estimated tax figures are labelled estimated in the value itself, not only in a footnote, and every screen carrying them repeats that Open1031 gives no tax or legal advice. One exchange number carries one set of money facts. Escrow balance, relinquished-closing date, funding wire and depository resolve from the exchange record, so two exchanger-facing surfaces on the same file can never print two balances or two sale dates; a surface that needs a different stage of the lifecycle takes its own exchange number and its own exchanger rather than a second version of someone else's file — which is why this page is EX-2026-000106 and not the dashboard's EX-2026-000147.
11 · Tokens, both themes, real states. Every colour resolves through docs/mockups/tokens.css; no literal survives to packages/web-app/src/index.css. Hub hues are wayfinding (which leg), status stays on good/warn/bad with a label and an icon. Text on a filled control takes the flipping foreground — the primary button fills with --hub-disbursement-ink, not --hub-disbursement, which is 3.4:1 against white and fails on a label. --ink-4 is icons, rules and disabled glyphs only. Hover, :focus-visible, active, disabled, skeleton loading, teaching empty states and recoverable error states all ship. Motion runs at --duration-fast on colour, border and width only, and prefers-reduced-motion is honoured.
12 · Provenance is stated, not implied. Simulated capabilities carry the dashed Simulated extraction pill; unbuilt ones carry a dashed Proposed pill and are named in the banner at the top. The corrected authorization model on this surface contradicts three shipped components (MultiPartyApprovalPanel.tsx, DisbursementSignGate.tsx, ConstructiveReceiptNotice.tsx) and that contradiction is stated in the banner rather than quietly drawn over.
Light and dark are both designed here. All names, addresses, amounts, dates, account fragments and file references are synthetic demo data.