Approving is leaving written what the document said when you said yes.
An approval by email does not say which version the person approving had in front of them. Here the content is frozen before the signature, the time is set by the server and, if somebody edits afterwards, the approval is marked as superseded.
What happens when the go-ahead lives in an email
- «Ok, approved» arrives by email and does not say which version the person writing it was looking at. Months later, that is exactly the question.
- The document keeps being edited while three people review it. The first one’s signature covers something the third one never saw.
- When somebody asks who authorised this, the answer depends on a mailbox that the authoriser themselves can empty.
Five things that change with the first request
- 01
The record locks when it is sent for approval
- Today
- The author emails the document and keeps editing it while it is under review.
- With PAIR
- From the moment it is sealed —the very act of sending it for approval— the record admits no edit or deletion while the request stays open. The database rule prevents it, not the screen.
- 02
The signature is taken with the server’s time
- Today
- The approver replies «Ok, approved» by email, without saying which version they saw or when.
- With PAIR
- The event with the server time, the IP the server observed and the consent text that was accepted, with its version and its hash. The phone’s clock is stored separately and labelled as reference only.
- 03
Sending it back forces you to say to which stage and why
- Today
- Whoever reviews sends the document back by email, without recording to which stage or why.
- With PAIR
- The comment, the destination stage and the list of signatures that fall, inside the signed event itself. Everyone who lost their signature gets a notice that does not wait for the digest.
- 04
Editing an already approved record does not move the signature
- Today
- Nobody notices: the document is edited after approval and the signature still seems to stand.
- With PAIR
- The record moves to «Approved · content modified», the change enters the trail with the fields that moved, and the signatories are notified. The earlier signature still stands over what was signed, not over the new content.
- 05
The check is not done by the server that signed
- Today
- Whoever doubts searches the approver’s mailbox, which the approver can empty.
- With PAIR
- The seal and the chain are recomputed in the viewer’s browser, with a second implementation that does not call the Function that signed: if the server lied, the screen would say the same. It distinguishes intact, broken —with the link number— and could not be verified here.
What gets written down, piece by piece
- Approval request with its stages, its approvers and its deadline
- Content seal, with the hash of the record and of the template it was filled against
- Event trail: seal, approval, rejection, return and content modified
And many more, built around your operation. Ask us.
Demo
Bring us something that gets approved by email today
A record that today goes through two or three sign-offs: in thirty minutes you see it with its stages, locked before signing and with the seal time in view.
- Would you rather look at the plans first? See pricing.