A real Certificate of Completion, and the three copies of a signed record

FeatureESigService
Shipped
September 9, 2026 at 10:20 PM UTC
Author
Kamo
Commit
42336fa

What the flatten pipeline appended was one page per signature carrying seven lines: name, email, member id, timestamp, capture method, IP, user agent. No routing, no consent record, no delivery or view timeline, no signed-document hash, no page numbers — so a reader could not tell whether they were holding all of it — and it existed only INSIDE the executed PDF, where a party who wanted the evidence on its own could not get at it. `EsignCertificateRenderer` draws the certificate: the envelope and both fingerprints, the parties in routing order, and then per party the whole story — role, signing order, status, HOW they were authenticated, the timeline from invitation to signature, IP, device, capture method, and which consent disclosure they accepted in which language. It is used in BOTH places: the flatten pipeline appends these pages to the executed document, and `EsignCertificateService` serves the same pages as a standalone PDF. One renderer on purpose — a second implementation is a second set of audit statements that can disagree with the first, and the one thing an audit record may never do is contradict itself. The certificate is REGENERATED, never stored. Every fact on it is already durable in the recipient and signature rows, so a stored copy would only be a second thing that can go stale; it also means an envelope signed before today gets a full certificate the first time anyone asks. **************** on four surfaces — the signer's session, a staff member's own copy, the sender's dashboard and the internal API — with `both` as a zip. `/signed-document` stays beside it because it is already linked from delivered mail and serialised into other services. Two things the tests caught that would have been live defects: - `Map.of` throws NullPointerException on a null VALUE, and the one request with a null value is the one that branch exists for: an envelope that is not complete has no executed PDF, so `?what=both` on an in-flight envelope would have been a 500 instead of a zip holding the certificate. It degrades to whichever half exists now — somebody chasing a stalled signature is exactly who needs the audit record. - The zip is STORED rather than deflated (both members are already-compressed PDFs) with entries sorted, so the same inputs produce the same bytes and whoever receives it can checksum it. The test parses both members as PDFs rather than counting them: a STORED entry with a wrong CRC unzips to garbage that still looks like a file. (it has no spaces in it, so a word-only wrapper runs it off the edge), states an absent timestamp as an explicit em dash rather than omitting the line — "Signed: —" and no line at all are different statements, and only one of them is evidence — and stamps "Page n of m" after the body, because until the body is finished nobody knows what m is. Consent now carries the locale it was rendered in, so the record says which of the twenty-two translations of the § 7001(c) disclosure the signer actually read.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing