The four questions a signed document has to answer

We built eFirma's evidence model backwards, from the argument rather than from the technology. If a document ends up disputed, what will be said about it? In practice the objections are remarkably few, and they are always one of four.

1. Integrity — is this the document that was signed?

The most common failure is not fraud. It is drift: three versions in three inboxes, one of which was edited after the meeting with everyone's blessing and never re-signed. Six months later nobody can say which file the parties agreed to.

The fix is a fingerprint. A SHA-256 hash is computed over the exact bytes of the completed document; change a comma, a figure or a date and the fingerprint changes entirely. Because the fingerprint is stored in the sealed record, anyone holding a file can recompute it and see in a second whether they are holding the document or a document.

2. Identity — was it them?

A name typed into a box proves nothing. What raises the bar is that the signer had to demonstrate control of something before the page would open: a phone number or an email address that had been agreed in advance, confirmed by a one-time passcode at the moment of signing.

This is not identity in the sense a national ID card means it, and we are careful not to say otherwise. It is control of a channel, recorded at a moment. In a commercial dispute that is usually the material fact — the counterparty's own finance director's number received the code and used it — and it is recorded in a way that can be produced rather than asserted.

3. Time — when?

Timing decides more cases than people expect: whether a notice landed inside a cure period, whether an offer was accepted before it lapsed, whether a resignation preceded a dismissal. A timestamp taken from the signer's own device is worth very little, because a device clock is a setting.

eFirma stamps events from a time source outside the signing session and records them in Ethiopian time alongside UTC, so that a document read in Addis and a document read abroad are being read against the same instant.

4. History — what happened in between?

The first three answers are snapshots. The fourth is the film: created, sent, opened, verified, signed, sealed — each event with an actor, a time and an address. On its own a list of events is only as trustworthy as the database it sits in, so each event is hashed together with the one before it, making the trail append-only in practice as well as in intent.

Remove an event and the chain no longer recomputes. Reorder two and it no longer recomputes. Backdate one and it no longer recomputes. The point is not that tampering is impossible; it is that tampering is visible, including to someone who does not trust us.

The test we hold ourselves to

A useful way to judge any signing platform, ours included: could a stranger, holding only the file, answer all four questions without contacting the vendor?

• Integrity — recompute the fingerprint from the bytes in front of them.
• Identity — read which check each signer passed, and against which channel.
• Time — read an independent timestamp, not a device clock.
• History — replay the hash-linked trail and see that nothing is missing.

If any of those requires a support ticket, the evidence is hostage to a company staying in business. That is the reason the verification page needs no account, no fee and no relationship with us — and the reason it will stay that way.