Before you start

  • A saved summary version. With no version there is nothing to review, and the screen says so rather than showing an empty checklist.
  • Every requirement met: the version current, evidence attached and cited, and the evidence still current. Each unmet requirement is listed with the reason it is unmet.

What you provide

  • Your decision to approve, which binds this exact version and makes it immutable.
  • The delivery channel and the recipient.

What you can do

  • Read the preview, which is a projection of the stored version and nothing else.
  • Approve the version, or go back and change it first.
  • Deliver it, and read the delivery’s state afterwards.
  • Start a correction if something needs to change after delivery.

What you get

  • An approval recorded against one exact version.
  • A delivery whose state you can see, and which the client can open.
  • A history in which the version a client received is never rewritten.

Common problems

A requirement is unmet and the reason is not obvious
Each requirement carries its own reason code, and the ones that matter most are that a newer calculation has changed what the version rests on, or that the version cites evidence from more than one engine. The first needs a fresh look at the workspace; the second cannot be approved at all, because a single summary may not mix provenance.
The delivery was refused
The refusal names its own cause: an exhausted allowance, an expired entitlement, or a deployment with no email configured. The first two are billing, and the third is a deployment setting no screen can change. The summary stays approved either way, so nothing is lost by the refusal.
The client says the email never arrived
A send is evidence that the mail server accepted the message, not that it reached an inbox. Ask them to check their spam folder, and re-send if needed — an already-issued link can be renewed without spending a second allowance unit.

Where to go next