For Florida law firms
Execution evidence: each instrument's signing pinned to the approved version, its steps as facts, and a record that completes only on its evidence
firm lane · Deterministic — no model call
Current availability
ShippedConfigured and enabled: a firm's staff on the firm's estate-plan matters; a signing is prepared only on a version approved by the firm's recorded review decision.
- Where it lives
- The firm's estate-plan workstation (/admin/estate-plans/[id], Signing) · the client's plan page (/estate-plan/[id], Your signing) · /api/admin/estate-plans/signing · /api/estate-plan/signing
- What unlocks it
- the firm's staff keep the record of their firm's estate-plan matters; the matter's client reads their own signings' state, time and place
Status is evaluated against this deployment's configuration by the capability-status service at build time; the catalogue's facts were last reviewed on the date shown.
Capabilities
- ShippedPreparing a signing pins the plan's approved version (its SHA-256) and the instrument's own print copy (its SHA-256 and its counted pages) — the database reads both hashes itself, and they never change: a different version is a withdrawal, with its reason, and a new preparation.
- ShippedOne open signing per instrument; when a newer version is approved, an open signing says it stays on its own version — it is never switched.
- ShippedThe steps are recorded as facts: scheduled (when, where, who is expected, the firm's own logistics), signed (the day, the place, the people as they signed and what each is to the plan), notarized (the notarial act as its certificate states it), and the signed copy.
- ShippedThe signed copy comes through the matter's own document ingress — past its safety check — and its bytes are re-hashed and its pages counted against the print copy's.
- ShippedA record completes only on its evidence: the signing, a signer and the witnesses the ceremony script names, the notarization the script requires (the power of attorney), the ceremony layer's role check on the people as they signed, and the signed copy with every page — fewer pages keep it open; more need a note saying what they are. A checkbox never completes it.
- ShippedCompleting writes the chained execution record: its evidence hashes are the version's, the print copy's and the signed copy's, inside the ledger's digest; a re-execution supersedes the instrument's earlier one.
- ShippedThe state is generated from the recorded facts, so it cannot disagree with them; what the record still needs is listed, in the database's own words and order.
- ShippedThe client sees each instrument's state, when and where it is to be signed, and the steps' dates — never the people's names, their relation to the plan, the firm's logistics or a hash.
Limits
- Wet ink only: a provider's electronic envelope is a separate integration and never completes a signing record here; electronic execution is not recorded.
- The instruments a ceremony script governs — the will, the revocable trust, the durable power of attorney and the health care directive; the HIPAA release has no script, so its signing is not recorded here.
- Firm matters only: the self-help service's packet carries the signing guide and keeps no signing record.
- A complete record says the evidence is complete; whether a signing met Florida's formalities stays the supervising attorney's judgment.
- Pages are counted, not compared page by page; times are Eastern time, the platform's home zone.
What EstateDraftFL refuses
| Reason code | HTTP | What it means |
|---|---|---|
| auth_required | 401 | The signing record needs a signed-in member of the firm's staff (the client's view needs the plan's own client). |
| invalid | 400 | A field could not be read — the instrument, a date (a signing on or after the version's approval day and not after today; a notarization on or after the signing), the place, the people, the notary's certificate facts, the copy, or a reason — nothing was recorded. |
| forbidden | 403 | The firm's staff keep the signing record. |
| not_found | 404 | The plan or the signing is not in the firm's view. |
| not-approved | 409 | The current version is not approved and released — a signing is prepared only on the approved version. |
| already-open | 409 | The instrument already has an open signing — withdraw it, with its reason, to prepare another. |
| incomplete | 409 | The record does not complete: what it still needs is listed (the signing, the witnesses, the notarization, the copy, its pages, the people's roles). |
| closed | 409 | The signing is complete or withdrawn — it does not change. |
| copy-in-use | 409 | That copy is attached to another signing — each instrument's signed copy is its own file. |
| matter_archived | 409 | The matter is archived — its records can be read, not added to. |
| unavailable | 503 | The plan, the signing, the version or the copy could not be read — or the step could not be written — just now; nothing was recorded. |
Evidence
- supabase/migrations/20261001060000_phase13_execution_evidence.sql
- src/lib/signing/model.ts
- src/lib/signing/request.ts
- src/lib/signing/prepare.ts
- src/lib/signing/server.ts
- src/lib/artifacts/approved-estate.ts
- src/app/api/admin/estate-plans/signing/route.ts
- src/app/api/estate-plan/signing/route.ts
- src/components/signing/SigningPanel.tsx
- src/components/signing/SigningCard.tsx
- src/components/signing/SigningForms.tsx
- src/components/signing/ClientSigningCard.tsx
- src/lib/estate/ceremony.ts
- docs/security/MASTER-PLAN-PHASE13-PART4-2026-10-01.md
Last reviewed 2026-10-01