Delivery Confirmation: What It Is and How It Works

What is delivery confirmation in our service?

When you complete a task at an address and take a photo, the service creates a signed confirmation package. This isn't just a snapshot or a "Done" checkbox. It's a set of files that records the fact of your work and protects it from being altered.

The package consists of three parts:

• The photograph — the image taken at the delivery point
• The metadata file (manifest.b64) — contains the photo's hash, GPS coordinates, timestamp, and order details (order number, address, task info)
• The electronic signature — a detached signature that validates the metadata file. The public key needed for verification is included in the signature itself.

What exactly does it guarantee?

The signed package guarantees three things:

1. Immutability. After signing, no one can change the coordinates, timestamp, order details, or swap the photograph. Any change will break the signature or the hash comparison, and this will be visible upon verification.

2. Binding to place and time. The package proves that the photo was taken at a specific point, at a specific moment, while performing a specific task. It's not "somewhere around that area" — it's exact coordinates.

3. Independent verifiability. The package can be exported and verified by third-party means. Without our app, without an account, without contacting support. Everything needed for verification is already inside the package.

What does it NOT guarantee?

The package does not confirm the contents of the parcel or the quality of the work performed. We record the fact: the employee was at this place, at this time, with this object. What's inside the box and whether it matches the order is outside the scope of delivery confirmation.

If the photograph shows an opened package or damage — that is also recorded and can serve as grounds for a claim. But the package itself is not an inspection of the contents.

How does the signature work?

The signature is created on the service's server at the moment the data is received from the app. It uses asymmetric cryptography (RSA).

The essence is simple: the service has two keys. The private key is stored only on the server and is used to sign the data. The public key is used to verify the signature. Forging a signature knowing only the public key is mathematically impossible.

The signature is detached — it exists as a separate file alongside the metadata. This means you can verify the metadata without modifying it, and the signature file can be stored or transferred independently. The public key is embedded directly in the signature file, so you don't need to obtain it from anywhere else.

The metadata file (manifest.b64) includes the SHA-256 hash of the photograph — a unique string computed from the photo file's contents. If even a single pixel in the photo is changed, the hash becomes different, and verification will catch it.

Why is the photo hash needed?

The SHA-256 hash is a "digital fingerprint" of the photo file. It is unambiguously tied to the photograph's contents. It lets you confirm that the photo was not swapped after signing.

Without the hash, someone could theoretically replace the photo file while leaving the metadata unchanged. With the hash, this is impossible: replacing the photo changes the hash, and the changed hash will not match the one stored in the manifest.

How does verification work?

Verification follows a clear sequence. No special expertise is required — just the three files from the package.

Step 1: Verify the signature. Take the detached signature file and the metadata file (manifest.b64). The signature file already contains the public key. Verify that the signature is valid for this exact metadata file. If the signature checks out — the metadata has not been altered since signing.

Step 2: Decode the manifest. The metadata file is stored as manifest.b64, which is a base64-encoded file. Decode it to get the readable metadata content. Inside, you'll find structured fields: the photo's SHA-256 hash, GPS coordinates, timestamp, and order details.

Step 3: Check the data fields. Review the decoded metadata. Confirm that the coordinates match the expected delivery address. Confirm that the timestamp aligns with the delivery window. Confirm that the order number and details correspond to the correct task.

Step 4: Verify the photo. Take the SHA-256 hash stored in the manifest. Compute the hash of the actual photo file you have. Compare the two. If they match — this is the exact photo that was present at the moment of signing. If they don't match — the photo was replaced or altered.

Result: if all four steps pass, you have confirmed that the delivery took place at the stated location, at the stated time, for the stated order, with the stated photo — and none of it has been tampered with.

Can I verify or share the package myself?

Yes. The entire package (photo + manifest.b64 + signature file) can be exported. Everything needed for verification is self-contained: the signature already includes the public key. You just need the three files and any standard tool capable of verifying electronic signatures and computing file hashes.

No account in our service is required. No access to the app is required. Verification is performed mathematically: either the signature matches and the hash is correct, or it doesn't.

You can hand the package to a lawyer, an insurance company, a manager, or a security service. They will verify it independently, without contacting us.

What to do in a dispute?

If a client or customer disputes the fact of delivery:

1. Export the signed package for the relevant order.
2. Hand the three files (photo, manifest, signature) to the party reviewing the dispute.
3. That party verifies authenticity following the steps above.

You don't need to justify yourself, ask someone to "look it up in the system," or look for witnesses. The signed package is a self-sufficient piece of evidence. It shows where you were, when, and what you recorded.

Does it last long?

The package is a set of files. It doesn't depend on the app running, the company existing, or the service version being current. A year from now, five years from now, it verifies the same way as on the day it was created — provided that the RSA and SHA-256 algorithms remain cryptographically strong (as of today, they do).

In short

Delivery confirmation in our service is not a checkbox. It's a photo, a metadata file, and a detached signature with the public key inside. Bound to a place, a time, and an order. It cannot be altered. It can be verified without us. It protects you in a dispute. You take the photo — cryptography does the rest.