What this block is. A read-only projection of two records the exchanger's wizard already persists on this exchange: the current identification list (exchange scope, identificationProperties, submitted or still a draft — the head line states which) and the purchase-hub outcome array (acquisition scope, finalizationStates, one {acquired, finalAmount, confirmed} entry per position). It is rendered only when normalizeExchangeVariant(exchangeType) resolves to forward_delayed, on the server and on the client alike; reverse, improvement and simultaneous files do not show it. Nothing here writes, signs, uploads or moves funds, and the disbursement table, its amounts, View purchase details and every Funds control above are unchanged.

Submission state. The head reuses the card's existing vocabulary from HubStatusBadge, preceded by a visible Identification label, grouped with the badge as one non-breaking key/value unit in normal case so the qualifier never wraps away from the pill it explains (Designer D-1 and D-6, #3344): Submitted · date (the identification hub's recorded submission date, omitted when none is recorded) or the warning pill Not yet submitted. The block renders before submission — the QI sees the draft list with its draft state — and the two empty sentences are derived from the submission flag, never from the properties array. The date drawn here is the one this mockup's Identification card already states.

Row position for assistive technology. Below a 720px container the # column (and its visually hidden Position heading) is not rendered, so the folded position digit inside the property cell is exposed to assistive technology rather than hidden — the row announces as 1 Synthetic identified property… at every width (Designer M-5, #3344).

State precedence (each state excludes the ones below it): 1 · loading; 2 · read failure on either record (alert, no rows, no totals, no submission or empty claim); 3 · outcome record not a list, or a non-empty list whose length differs from the identification list, including the zero-properties case (alert; no table or totals when there are no properties); 4 · allocated amount unavailable (a selected monetary source is not a finite number); 5 · empty identification, not yet submitted; 6 · empty identification, submitted; 7 · no confirmed outcomes; 8 · live. Mismatch outranks empty so a non-empty outcome record is never hidden behind “no properties”; this ordering is safe only because both reads fail closed in the product (a read error throws and lands in state 2).

Outcome per row. Confirmed acquired only when the entry at the same position is an object with acquired === true, confirmed === true and a finalAmount that is a native finite number greater than zero. Any other entry — missing, null, default, unconfirmed, malformed, a numeric string, zero or negative — reads Not confirmed. The block never says “Not acquired”: an absent or default entry is the absence of a recorded outcome, not a recorded non-acquisition. This predicate is deliberately stricter than the exchanger's wizard (acquired && confirmed, no amount test) and the API's 95%-rule guard (Number(finalAmount) || 0, which coerces strings); the divergence is stated and tested in the brief rather than left for two views of one record to disagree silently.

Positional constraint. The outcome record carries no property key; the wizard pairs the two arrays by index (PurchaseFinalizationList.tsx, finalizationStates[index]). This block mirrors that pairing only when the stored value is an array (Array.isArray, as the API's own reader guards) of the same length as the identification list. An absent record, a null or undefined value (the wizard itself hydrates those as “nothing persisted”), or an empty array is the no-confirmed-outcomes state — nothing has been recorded. Any other non-array value is corrupt and is reported as an entry count of unknown, never zero; it, or a non-empty array of a different length, makes the mapping unavailable (specimens above): the identified rows keep their label and allocated amount, every Outcome cell is an em dash and no confirmed amount is shown, no excess entry is shown, the confirmed total and difference are withheld, and the allocated total stays only because it is computed from the identification side alone. When a mismatch and an unreadable amount occur together, the mismatch is the state shown and the allocated total is withheld as well. The row number is the position in the list and is the render key; the label follows the card's existing propertyAddress rule (the recorded address, else the derived reference, else “Identified property N”), rendered as text only; the derived reference is carried separately as an identity and is not the label. No durable finalization identity is introduced.

Input validation. Every monetary value is accepted only as a native finite JSON number; numeric strings are not coerced. Per row the allocated amount is allocationAmount when it is present (nullish fallback only), else estimatedFMV; if the selected source is present but not a finite number the row's allocated amount is unavailable and so are the allocated total and difference. Aggregates that overflow to a non-finite value are unavailable too. Unavailable is drawn as an em dash or the word Unavailable; a manufactured zero is never drawn.

Totals, labels and sign. The totals come from the shared reconcileFinalizedAllocations helper, called on the normalized values exactly as the wizard calls it: Allocated total is the helper's idHubTotal — the wizard labels the same figure ID Hub total — and is not the identified fair-market-value total the 95%-rule check divides by; this block renders no rule figure and no rule status. Confirmed acquired total is finalizedTotal (confirmed-acquired rows' finalAmount, 0 for every other row). Difference is the helper's delta, confirmed acquired total − allocated total, printed with a true minus sign, with the helper's status as a neutral pill labelled in plain arithmetic — Matches allocated within its $1 tolerance, otherwise Above allocated or Below allocated — never the statutory Balanced/Over/Under vocabulary of the allocation-floor gate (Compliance review, #3344). When no row is confirmed acquired the pill reads No confirmed outcome recorded and the difference is an em dash: the payload may still carry the arithmetic, but the surface shows a signed figure only once at least one row is confirmed acquired, so the totals band never states a shortfall the rows refuse to state. These are recorded arithmetic facts; the block never labels a result deferred, boot, compliant or otherwise a tax outcome.

Deliberate divergences from the wizard (do not “fix” them back): the Under/Over pill is neutral slate here where the wizard paints rose and amber, because a fiduciary read surface does not colour a recorded fact as good or bad; there is no “Over by” / “Under by” phrasing; money is two-decimal dollars with a true minus where the wizard renders whole dollars; the label is Allocated total where the wizard says ID Hub total; and the confirmed-row predicate is stricter, as stated above.

Disclosures. Three separate elements, in this order: the sample-data sentence (only when the exchange's owning organization is a demo tenant — organizations.is_demo_tenant resolved server-side by the existing resolveDemoTenancy(db, {exchangeId}) after the authorized exchange lookup, returned as demoTenant: boolean on the same read; a resolution error throws), the recorded-facts sentence, and the platform's tax-advice disclaimer rendered by ComplianceDisclaimer as its own role="note" paragraph — copied here verbatim as a drawing convenience only. The live block above is the demo-tenant variant; the specimens are the real-tenant variant. No exchange-level demo flag exists and none is invented.

Loading, failure and retry. A read error on either record is shown as a failure, never converted into an empty outcome, a $0.00 total or a submission claim. The failure state's Try again is a static specimen drawn disabled because a mockup control has nothing to run; the product control is the shared ErrorBanner retry, enabled, re-running the same read, and the implementation PR must capture it enabled. This drawing carries no build-status copy.

Narrow layout. Below 720px the position column folds into the property cell as a leading number, the property cell becomes sticky at the left edge (140px, three-line clamp, ellipsized subline), the Outcome column sits immediately after it so identity and outcome are both visible before any scrolling, the two amount columns scroll with their headings wrapped to two lines so the heading of whichever amount is in view stays legible beside the sticky cell, the scroller shows edge shadows only while there is overflow, and the three totals stack. The page never scrolls sideways. Column order is the same at every width: property, outcome, allocated, confirmed.

Token prerequisites. Two consumed tokens are marked [PROPOSED] in tokens.css: --ink-4 (icons, rules and disabled glyphs only, never body text) and --surface-sunk (skeleton bars, the slate pill). Both must be declared in index.css :root and .dark before the product slice uses them. Every other token is [APP].

Fixtures. The rows are labelled Synthetic identified property — Fixture A/B/C with a Synthetic location subline: no street number, city, state or postal shape, so nothing here can be read as a real or plausible address. They are independent of the legacy disbursement fixture above; in the product both render from the same exchange record. All rows and amounts in every specimen are synthetic fixtures, not customer records.