What the verification artefact actually proves.

PAdES — PDF Advanced Electronic Signatures — is a European Telecommunications Standards Institute (ETSI) standard family (EN 319 142) that defines how to embed cryptographic signatures inside a PDF byte stream. The "B-T" profile specifies a baseline signature with a trusted timestamp.

The South African ECTA references international electronic signature norms; PAdES-B-T is the closest globally-standardised shape of an "advanced electronic signature" as the act contemplates it. The legal weight of the signature does not depend on ContractGen continuing to exist — only on the PDF and the verification tooling (Adobe Reader, open-source verifiers, ETSI's own validation tools).

A signature without a trusted timestamp says "someone with key K signed bytes B". Critically, it does not say when. Without a timestamp, the holder of K could in principle have signed the bytes at any point.

RFC 3161 timestamps are tokens issued by a Timestamping Authority (TSA) — for ContractGen, DigiCert (with FreeTSA as fallback). The TSA signs the hash of the signed bytes together with a precise timestamp. That creates a third-party attestation that those exact bytes existed in that form at that moment. The TSA, not ContractGen, is what anchors "when" in court.

Every signing event — page acknowledgement, signature submitted, envelope sealed — is recorded in a SHA-256-chained log. Each entry includes the hash of the previous entry. Post-hoc tampering with any event invalidates the whole chain from that point forward.

The chain head is embedded in the sealed PDF metadata. Altering any earlier event requires (a) a new chain with consistent hashes, (b) a re-sealed PDF with the new chain head, and (c) a replayed cryptographic seal — which requires the ContractGen signing key. Compromising the key compromises everything downstream of it. That is why the key is held outside the database and rotated independently.

South Africa's Electronic Communications and Transactions Act (Act 25 of 2002) — ECTA for short — establishes the legal framework for electronic signatures.

Section 13 makes electronic signatures legally recognised: "where the signature of a person is required by law and such law does not specify the type of signature, that requirement in relation to a data message is met only if an advanced electronic signature is used." For most commercial contracts, this section does not apply (the law does not require a specific signature type), and any electronic signature suffices under section 13(2).

Section 14 addresses originality. Section 15 addresses admissibility of data messages as evidence — the court must give due weight to factors including the reliability of the manner in which the data message was generated, stored, and communicated, and the reliability of the manner in which the integrity of the information was maintained.

ContractGen's seal — PAdES-B-T with an audit chain — is a concrete answer to each of those reliability questions.

Cryptography proves that specific bytes were sealed at time T by the holder of certificate C. It does not prove the human at the other end of the signing URL was who they said they were.

ContractGen captures additional evidentiary signals: source IP, browser user-agent, typed full name matched against the party record, the signature image (drawn by the signer, or generated from their typed name), and a per-page acknowledgement with the time spent viewing each page. These are useful for a court reconstructing whether a signer was on notice — but they are not identity assurance.

Identity assurance proper — OTP-to-verified-mobile, ID document verification, biometric — is your application's responsibility, not ContractGen's. We are explicit about this because pretending otherwise is the opposite of trustworthy.

One last honest note. The signing URL is a path-based credential. It will appear in browser history, the Referer header if the signer navigates to a link that opens off-origin, corporate proxy access logs, and any CDN that sits in front of our deployment. ContractGen's own server logs hash the token before recording it, but we cannot reach further upstream than that. The token stays valid until the envelope expires and rotates on every resend, but if a signing URL is forwarded to a different person, that person can sign.