Most review tools have an Approve button. Pressing it writes a row in a database saying somebody pressed it. That is not evidence of anything in particular — and the difference only becomes obvious at the exact moment you need it.
The short version
- A defensible approval carries five things: verified identity, a content fingerprint, a trusted timestamp, immutability, and portability.
- Miss one and the other four stop mattering.
- “Looks good” in an email proves someone was pleased on some day — not which version they approved.
- Stria binds every sign-off to a SHA-256 hash of the exact content: email-verified, server-timestamped, append-only, and exportable.
The five properties of a defensible approval
Most tools ship one or two of these:
| Property | The question it answers | Common failure |
|---|---|---|
| Verified identity | Who approved it? | An anonymous click on a shared link |
| Content fingerprint | What did they approve? | ”The design,” version unspecified |
| Trusted timestamp | When? | A client-side clock, or nothing |
| Immutability | Has the record changed since? | An editable row |
| Portability | Can anyone else read it? | Locked inside a tool you may stop paying for |
Miss any one and the other four stop mattering. A perfectly hashed, timestamped, immutable approval from somebody, we are not sure who settles nothing.
Identity: a click is not a person
A link that anybody can open and press Approve on establishes that a browser did something. When the file went to a marketing manager who forwarded it to two colleagues and a freelance copywriter, that is not a small gap.
The fix is unglamorous and it works: email a one-time code to the address on record and require it before the approval is written. The reviewer still needs no account, no password, and no seat — they are a client, not a user, and charging you for their presence is a pricing decision disguised as a feature. But the record now names a verified address, not an anonymous session.
Content: “the design” is not a thing you can approve
This is the property almost everyone is missing, and it is the one that decides real arguments.
Six months later, the dispute is never did they approve something. It is which version. The client remembers approving the layout with the original serif; you remember shipping the revision they asked for afterwards. Both of you are describing something true.
An approval has to be bound to a fingerprint of exactly what was on screen — in Stria’s case, a SHA-256 hash of the approved content, tied to its version number. Then the question stops being a memory test: either the current version matches the hash on the approval or it does not, and the answer is the same for both of you.
Time: whose clock?
A timestamp taken from the reviewer’s browser comes from a device whose clock they control. It is fine until it matters. Capture it server-side.
Immutability: the property that makes the rest credible
Here is the test worth applying to any tool you evaluate: can the record be edited after the fact?
If the vendor — or you — can update an approval row, then the record is an assertion about what happened, not evidence of what happened. That may be enough for internal comfort. It is not enough for a disagreement with money attached.
Two mechanisms make it real:
- Append-only writes. Sign-offs are written once. Corrections arrive as new records that supersede, not edits that overwrite.
- A linked chain. Each version’s hash includes the previous one, so removing or altering a version in the middle breaks the chain visibly. That is why Stria can render a live chain verified verdict rather than just asserting the record is intact.
Tamper-evident is the honest word, not tamper-proof. The claim is that interference shows — not that it is impossible.
Portability: evidence you cannot export is evidence you are renting
If the only place your approval history exists is inside a subscription, then your proof has a renewal date. Ask what happens to it when you leave.
Every Stria sign-off exports to a print-ready certificate: the deliverable, the client, the final version, the status, the chronology, and the version lineage with its hashes — one page you can forward to an accountant, a lawyer, or the client themselves. It reads without Stria in the room, which is the only test that counts.
What we deliberately do not claim
- We do not tell you an approval is legally binding. Enforceability depends on your jurisdiction, your contract, and the facts, and a software vendor asserting otherwise in marketing copy is answering a question it is not qualified to answer. We keep a separate page on how our sign-off model lines up with common e-signature expectations rather than compressing it into a badge.
- We do not leave the dispute window open forever. A client can contest an approval, from a defined set of grounds, inside a stated window — and then it closes. A permanent “something wrong?” prompt sounds generous and quietly undermines every approval you hold, because nothing is ever settled.
- We do not pretend approval-on-silence is the same as approval. Stria can treat an unanswered deliverable as approved after a period you set, because that is how a lot of real engagements actually work — but it is recorded as what it is (a policy you configured, applied after a notice was sent), never dressed up as an affirmative act by the client.
Why we built the sign-off first
Stria is a scope tool, and scope arguments are settled by evidence or by whoever is more stubborn. We would rather compete on the first one.
So the sign-off is not a status field bolted onto a review page. It is the artifact the rest of the product exists to produce: locked scope on one end, a verified and hashed approval on the other, and a priced change order for anything that moved in between. The reasoning behind that is worth reading: scope creep is a records problem.
Reviewers are never charged for, on any plan. Flat pricing, never per client and never per reviewer: Freelancer Solo is $19/month with two seats, Studio is $39/month with five, and the free tier carries 3 clients and 6 deliverables a month — enough to put a real approval through it before paying anyone.
Frequently asked questions
Is an email saying “looks good” enough to prove approval? It establishes that somebody was pleased with something on a particular day. It usually cannot establish which version they were looking at — the fact under dispute in almost every scope argument. An approval is only useful tied to a specific version of a specific deliverable.
What should a client sign-off record contain? Five things: a verified identity rather than an anonymous click, a fingerprint of the exact content approved, a server-captured timestamp, immutability so the record cannot be edited afterwards, and portability so it can be read outside the tool that created it.
Does a hash make an approval legally binding? No — and any vendor telling you otherwise is answering a legal question it is not qualified to answer. What a content hash does is make the record tamper-evident: it shows whether the thing approved has changed since. That is evidentiary quality, not a legal conclusion.
Should clients be able to dispute an approval after the fact? Within a stated window, yes; permanently, no. A dispute button that never closes undermines every approval you hold, because nothing is ever actually settled. A window that opens on sign-off and then closes is fair to both sides.
See what the record looks like
The honest test is simple: approve something and read the certificate.
Open the live demo and approve a sample deliverable, or start free — no card, no waitlist.