Customer Sign-Off Tied to a Report Version: What It Proves | JobProof

The short answer

Handing a customer a PDF is not the same as having them accept it, and the second is where disputes live. JobProof records the customer's name, their acknowledgement, and an optional handwritten signature against one exact report version — the one that was in front of them when they signed — and keeps that record in the same archive as the delivery.

Because a correction produces a new version instead of overwriting one already delivered, the sign-off stays attached to the content it refers to. It is not identity verification and not a substitute for a contract. It is a durable local record of what was presented, to whom, and when.

Why you are actually here

This query is usually one of two questions in the same coat. Either you have already had the argument — "I showed you the panel was replaced, you said it was fine" — and want something that survives a change of mind three weeks later. Or you are choosing a tool now and want to know whether a signature captured on a phone is worth anything.

Both reduce to one test. A signature is worth something only if the document underneath it cannot quietly change afterwards. A wet-ink signature on a PDF you can still edit is decoration: it attests to a version that may no longer exist, and both parties know it. Any claim about "e-signatures" that skips this point is selling you the decoration. So the useful question is not "does the app collect a signature" — plenty do — but what happens to the document after the signature, and whether the record binds to the content or merely sits next to it.

What a sign-off record actually contains

JobProof treats a sign-off as a structured record rather than a sticker on a page. Saving one stores the report version identifier, that version's content hash, the job-content revision it was frozen from, the signer's name and role, the signature image, the acknowledgement text, and the time of signing. All of it folds into a single canonical hash under a versioned, domain-separated label (jobproof.customer-sign-off.v1), and the agreement text is hashed on its own, so a stored acknowledgement cannot quietly be swapped for a different one.

The signature screen is deliberately plain about its scope. It opens as an optional acknowledgement, shows which version it is bound to, and carries the statement "I acknowledge that the work shown in [this report] was presented to me" — followed by the line that does the real work: this acknowledgement applies only to the exact report version shown above.

Two consequences follow. The signed PDF is a different artefact from the unsigned one — signing regenerates the report with a signature page carrying signer name, role, sign time and acknowledgement text, and that file gets its own hash. And the signature image is stored as its own content-addressed artefact owned by that version, so it cannot later be mistaken for a job-site photo. The binding is not a label either: a version is frozen at preflight, and editing the job afterwards does not touch v1 — it creates v2.

The rules that make "tied to the version" mean something

Three rules make the binding enforced rather than claimed.

Only the current version can be signed. A sign-off aimed at a superseded version is refused. If the job has moved on since v1 was generated, you cannot sign v1 — you sign the current version, or create a new one and sign that. The alternative, allowing a sign-off against any historical version, would let two materially different reports carry the same apparent authority.

One sign-off per version. A version that already carries a sign-off will not take another for the same content. This is what stops a record accumulating competing acknowledgements on identical evidence, and it is why a signed version has to be superseded rather than amended.

A new version requires a material change. You cannot simply regenerate an identical v2 to reset the signing slate: JobProof checks that the job details or the shot plan actually changed and refuses otherwise. That check is what gives the version numbers in the archive meaning — each one is a real difference in content, not an artefact of tapping Generate twice.

What fails, and why it fails

• The job changes while the customer is signing. Signing is a compare-and-swap against the job's revision, checked when the signature screen opens and again when the sign-off is saved. If the job was edited in between, the save fails rather than binding an acknowledgement to a view that no longer reflects the job. You reload and sign again. This is the failure you are most likely to hit in the field, and it fails in the safe direction.
• An empty signature pad. A sign-off requires at least one stroke of actual ink, so a pad that was tapped and dismissed is rejected rather than becoming a blank signature on a record claiming one.
• Clock granularity. The sign time is normalised to whole milliseconds before it enters the canonical hash, so the digest stays stable across encodings. Sub-second precision is not kept.
• A signed version, then a correction. You cannot edit v1. You edit the job, generate v2, and sign v2 — if the customer is there to sign again. If they are not, v1 and its sign-off stay exactly as delivered, and v2 goes out unsigned. That asymmetry cuts both ways, and JobProof will not back-sign a correction the customer never saw.

What the delivery history adds

The sign-off tells you what was acknowledged. The delivery record tells you what actually left your hands, and JobProof keeps both on the job: every report version, the acknowledgement state on each, the delivery time, and the delivery method — either the iOS share sheet or a PDF export. It does not record that the customer opened the file, and it should not pretend to.

Two details matter more than they look. Re-sharing a job you have already delivered, and generating later versions of it, do not consume another of your three included jobs — only the first delivery of a new unique job counts. And eligibility is checked when you share, not when you create the report: creating a report is always included, and Pro is only required to deliver a new job. A job photographed on the free allowance therefore stays deliverable after the allowance is spent.

If a dispute arrives, the archive answers the questions in the order they actually get asked: which version, signed or not, sent when, and through which channel. The report list also accepts a hash in its search box if you have one.

Paper, email, or this

The alternatives are free.

• A paper form cannot be edited after signing, which is its real strength. But it photographs badly, separates from the job record, and leaves nothing you can search.
• Emailing a PDF produces no acknowledgement at all: proof of sending, not proof of receipt, and no record of what was agreed. For a small, uncontroversial job that is honestly fine.
• A dedicated e-signature service produces a stronger artefact on the legal axis — third-party timestamping, identity checks, an audit trail held by someone else who can be called on it. It also costs per envelope and pushes your customer's address and job photos through someone else's servers.

JobProof is the opposite trade: nothing per signature, nothing leaves the device unless you hand it over yourself, and a record that cannot drift from the document it refers to. For a contractor settling a dispute with a customer directly, that is the right weight.

What JobProof does differently, honestly

The differentiator is that version-binding is enforced by the data model rather than asserted in copy: the sign-off cannot point at anything but one report version's identifier, content hash and source revision, and the archive is append-only. JobProof's own words on the sign-off screen are the right posture to hold it to:

JobProof records what was presented and when. It does not verify identity or certify the quality of the work.

The limits are the mirror image.

• Everything lives on one device. No account, no app-managed cloud sync, no server copy. Job photos, customer details, signatures and reports stay on your phone unless you export or share them. Excellent for privacy; a genuine risk if the phone is lost, because the archive goes with it.
• A local hash is self-attesting. It shows the record is internally consistent and unchanged since it was written. It does not show that a third party vouches for it. Whoever holds the device is presenting the evidence, which is exactly the trust boundary that matters in an adversarial dispute.
• Nothing here is timestamped by an authority or notarised. If a disagreement escalates to litigation, insurance, or a warranty claim needing third-party attestation, a contractor-to- customer record will not be what settles it.

The decision you can now make

If your disputes are the ordinary kind — a customer who later disagrees with what they agreed to — a record bound to an immutable version and kept beside the delivery that carried it is precisely what you needed, and JobProof gives it to you without an account or a per-signature fee. If a signed report has to stand up outside the two of you, use a service that stakes its own reputation on the timestamp instead.

Not every job needs a signature. Sign when the customer is standing there and you would otherwise be relying on memory; skip it when the handover is a quick drop-off with nothing to dispute.