What one capability unlocks
When I use an e-signature API, what's mine to keep and what's theirs?
Sign documents — the audit trail you keep, not the envelope they keep
An e-signature provider gives you back an envelope: a completed document, a record that it was signed, a certificate you can download. It is easy to treat that envelope as the whole record. It is not. The envelope is the provider's account of what happened, kept on the provider's systems, for as long as the provider's plan says it will be. The thing you actually need — proof you can produce on your own, years later, regardless of who you are paying that month — is something you have to keep yourself. This note is about the seam between what the provider holds and what you do, because a signing feature that gets that seam wrong looks complete and is quietly hollow.
Rent the ceremony — that part is theirs, correctly
Give the provider its due and then be exact about where its job ends. Collecting an electronic signature is genuinely specialist work: the consent flow, the identity steps, compliance with electronic-signature law across regions, the cryptography of the signature itself. That is a domain where the provider's whole business is staying lawful, and renting it is the right call — the same way you rent a model rather than train one. You will not do this part better than a company that does only this, and the signing ceremony is not where your product lives anyway.
What the provider gives back, though, is an account of the event written by the party with the most interest in it being tidy and the least obligation to keep it forever. That is fine for the ceremony. It is not enough for the proof.
Keep the proof — three things the envelope is not
Three things have to be yours, held in your own storage and your own database, independent of the provider.
The document bytes. The exact content that was signed — not a link to it on the provider's servers, the actual file, in storage you control. If your only copy of a signed agreement is a URL into someone else's system, you do not have the agreement; you have permission to view it, revocable on their schedule.
The binding. Which real party is which signer, and what they were shown. The provider knows an email address clicked a button; it does not know that this email address is your customer of record, signing this version of this contract. That mapping — identity to party, signature to the precise content and version it agreed to — is yours to record, and it is the difference between a file and evidence.
The tamper-evident trail. A fingerprint of the document taken at the moment of signing, kept somewhere it cannot be quietly rewritten, plus an append-only log of every event in the document's life — sent, viewed, signed, sealed. The envelope the provider returns is their account of all this; the fingerprint and the log are how you confirm it yourself, without having to take their word or keep paying them to vouch for you. That independent check is the capability the whole thing turns on, and no envelope hands it to you ready-made.
A note on honesty here: this is a capability Smallbox has mapped but not shipped, so treat the shape as reasoning rather than war story. The instinct behind it, though, is one the foundation already lives elsewhere — files whose bytes you keep and whose access you gate yourself are the same move, and an append-only operational log is ordinary infrastructure. The parts are familiar; it is their combination into something that stays defensible when an agreement is later questioned that is the work.
What breaks when it's hacked in
The failure is the one every capability in this set shares, in its signing-shaped form: the provider becomes the only thing the proof is anchored to. Wire the signature in the quick way — call the API, store the link it returns, move on — and everything still demos perfectly. Documents get signed, certificates download, nobody notices anything missing.
Then the seam shows. The provider changes its retention policy and old envelopes age out — your proof was on a clock you did not set. You move to a cheaper competitor and discover your signed history does not come with you, because you kept links, not records. A document is questioned and you reach for independent proof that the file is unaltered, and find you never took the fingerprint, so all you can say is "the provider says it's fine" — which is exactly the assurance a determined challenger is trying to break. In every version the signature worked flawlessly the whole time. That is what makes the gap invisible until the day it is the only thing that matters.
Where it shows up
It shows up wherever an agreement has to outlive the deal — and the document-signing build idea is the sharpest case, where the entire product is the defensibility of the record rather than the act of signing. One layer down it is the same instinct as the rest of this set: rent the capability, keep the meaning. Own the bytes, the binding, and the trail; let the provider own the ceremony. That is part of the foundation for the same reason the payment record and the file index are — the provider executes the moment, but the proof that the moment happened, exactly as recorded, is yours to keep or yours to lose.
Articles describe the Foundation. The Foundation Map is the thing itself — accounts, admin, email, logging, and deployment, with one real workflow running through them.