Solutions · Approvals and signature
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
- Who does it today
- The record’s author, when they finish and send it.
- What is left
- 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
- Who does it today
- The approver whose turn it is, confirming their identity when signing.
- What is left
- 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
- Who does it today
- Whoever reviews and finds something missing.
- What is left
- 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
- Who does it today
- Nobody: the server detects it by comparing the hash.
- What is left
- 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
- Who does it today
- Whoever doubts, from the request’s own record.
- What is left
- 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 a signature has to be able to prove
An approval gets argued over years later, and the argument is always the same: who, when and over which exact text. Here is what frames those three questions, and also what PAIR is not.
| What the regulation requires | What evidence PAIR produces |
|---|---|
| Law 19.799 arts. 3 and 5 Electronic signature and evidential value Acts signed with an electronic signature are as valid as those executed in writing on paper (art. 3). Private instruments with an advanced electronic signature do not attest to their date unless it is recorded in an electronic timestamp from an accredited provider (art. 5). | The signature time is set by the server clock; the device’s is stored separately and labelled. The text accepted when signing calls itself a simple electronic signature under Law 19.799. It is not an advanced signature nor an accredited provider’s timestamp. |
| ISO 9001 cl. 7.5 Documented information Control documented information: identification, format, review, approval, change control and retention. | The seal stores the hash of the content and of the template it was filled against, because a question renamed afterwards turns a «Yes» into the answer to something else. If the record changes after approval, the change is written down and the approval becomes superseded. |
| Law 20.393 art. 4 Crime prevention model The crime prevention model needs evidence that the controls were executed, not only that they exist. | Every authorisation stays as an event with its author, the server time and the text that was accepted, in a collection where no application user can create, edit or delete. Each event carries the hash of the previous one, so a touch-up from outside is detected. |
The bodies named are the regulators. PAIR neither represents them nor carries their endorsement.
What gets written down, piece by piece
These are not forms to fill in: they are what the procedure produces, and what gets shown the day somebody asks who authorised this.
- 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
- PDF of the frozen record —when it could be generated and uploaded—, with its own hash; the seal’s authority does not depend on it
- Event trail: seal, approval, rejection, return and content modified
- The company’s consent text, with its version and its hash
- Daily anchoring of the trail, by email to the company’s administrators
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.
- Still have questions? Check the FAQ.