## Summary
Stage 37 (`ee8973a60b3f4dcd4a7bda75664142c6d506012924607e722df3b47b9e43fd9a`, confirmed in `index.jsonl`) closes the Stage-36 reservation-result, restart, and sole-owner gaps. The plan fails closed for every persisted delivery attempt whose provider outcome is uncertain and makes the diagnostic host the sole public path capable of creating fresh provider authority.

## Claims
- `stage-37-revision.md`, “Closed reservation decision algebra,” changes `reserve_and_verify` to a sealed three-result union and permits provider start only for `VerifiedDiagnosticReservation`.
- The existing-dedupe matrix explicitly converts started/consumed-but-unterminalized evidence to `DiagnosticUnknownNoSend`, and returns a stable `DiagnosticDuplicateNoSend` for completed/terminal evidence.
- The startup-recovery paragraph requires that same matrix before diagnostic revalidation, so restart never re-authorizes a persisted reservation.
- “Mechanical host-only reservation ownership” rejects diagnostic-bound runtimes at the first line of every public ordinary delivery/reservation entry point, before a store append or provider call; the only diagnostic reservation writer is the authority’s private host-token path.

## Analysis
### Stage 1 — Spec compliance
The previous ambiguity around what `reserve_and_verify` returns for an existing reservation is removed: the exhaustive result algebra distinguishes fresh authority from duplicate and uncertain no-send outcomes. `DiagnosticHost.deliver` immediately pattern-matches this union, with only the fresh variant reaching provider-start verification and the frozen transport.

The restart contract is also complete at the decision boundary. A crash after `delivery_attempt_started`, or after a consumed row without sufficient terminal evidence, resolves durably to `delivery_unknown` and cannot become provider authority on recovery. Existing receipt/terminal chains remain stable no-send outcomes. The stated row/provider-delta tests cover the relevant safety property.

The ownership rule is mechanically located at the ordinary public entry points and helpers rather than relying only on coordinator convention. The diagnostic mode binding, private host token, explicit no-bypass statement, and AST assertion that diagnostic `delivery_attempt_started` is emitted only by `DiagnosticDeliveryAuthority.reserve_and_verify` together close the alternate-writer route.

### Stage 2 — Architecture
The design deliberately prefers at-most-once delivery evidence over automatic retry after an uncertain provider outcome. That is the correct boundary for this isolated diagnostic channel: delivery may have occurred, so a retry would violate the safety contract. Separating stable no-send result objects from fresh authority also gives callers an auditable outcome without accidentally exposing a reusable reservation capability.

### Antithesis and synthesis
A more availability-oriented design could retry an orphaned started reservation after restart. It cannot prove that the provider did not receive the message, however, and would reintroduce duplicate delivery. Stage 37 correctly chooses terminal unknown; later reconciliation must remain a separately authorized capability, as specified, rather than a hidden retry branch.

## Root Cause
Stage 36 still left the return/result semantics for persisted reservations and the exclusive reservation writer insufficiently explicit. A restart or alternate ordinary coordinator path could otherwise be interpreted as fresh delivery authority. Stage 37 turns both into closed, fail-closed contracts.

## Findings
None.

## Recommendations
1. Implement the sealed result union as an exhaustively checked type and keep all non-fresh variants structurally incapable of reaching `verify_provider_start` or transport.
2. Preserve the specified matrix and startup ordering in focused row/provider-delta tests, including crash-after-started and each terminal-chain variant.
3. Keep the AST/callsite ownership test in CI so future ordinary delivery helpers cannot regain diagnostic reservation authority.

## Architectural Status
CLEAR

## Code Review Recommendation
APPROVE

## Tradeoffs
- **Terminal unknown after uncertain evidence (chosen):** preserves at-most-once safety; may require separately authorized reconciliation.
- **Automatic retry after restart (rejected):** improves liveness but cannot distinguish a lost receipt from a delivered message and risks duplicate customer delivery.