Redacted share PDF: which hash belongs to this copy?

Before comparing a PDF's hash, identify the copy in front of you. An AuditIt redacted share PDF is a public-share derivative with its own SHA-256 value. That value belongs to the shared file; the canonical report record and its verification page have a different scope.

This guide is for equipment-rental staff and recipients reading handover records. It explains a document check, without turning the result into an inspection or operating decision. The example is fictional.

Start with the PDF title

The redacted PDF is titled AuditIt Redacted Share Report. Its disclaimer says: “This is a redacted public-share derivative. Use the AuditIt verification page for the canonical report record.” Read that distinction before treating the download as a copy of the private report.

AuditIt generates this PDF from the redacted report content. The file may therefore contain a different selection of information from the canonical record. A recipient reviewing a handover should first establish which copy was supplied and which information it contains. That is a suggested reading check, rather than evidence that a particular rental event occurred.

Match the SHA-256 label to the downloaded copy

In the share page's report details, the derivative's digest is labelled Public-share PDF SHA-256 when it is available. Use that label to identify the value for the public PDF. Keep it separate from the canonical PDF hash and the report information checked through verification.

The NIST hash-function glossary describes a hash function as mapping an input bit string to a fixed-length output. The important practical question here is which input produced the recorded value.

For a downloaded public-share PDF, the relevant comparison is between that file's calculated SHA-256 and the recorded Public-share PDF SHA-256 for that copy. Comparing the public derivative's value with a canonical PDF hash mixes two objects. A difference between those values alone cannot establish that the canonical report failed verification.

If a comparison against the value for the same copy fails, keep the filename, copy type and compared label together for review. The difference needs investigation; the digest cannot tell you who changed a file or why. The SHA-256 guide explains the wider hashing concept.

Decide what this recipient needs to see

The W3C's Privacy Principles connect data minimization with restricting transfer to what is needed for a purpose or the user's wishes. That is a web-design principle. Applying it to a handover document is an editorial suggestion: identify the recipient's review task before choosing what to share. This is not a privacy-law compliance assessment.

In AuditIt, Show exact capture location is off by default. Selecting photographs or PDF download does not also select location. Enable that separate control only when the recipient needs exact coordinates and capture accuracy. A need to read the condition record does not automatically establish that need.

When a public derivative is missing or failed, it is unavailable. AuditIt's public delivery path does not substitute the private report or an original image as a fallback. Ask the sender to review the intended share and what it makes available; avoid treating a missing download as a conclusion about the underlying record.

Follow the canonical record to its own result

The verification page is the place to read the canonical report's named integrity checks. The default public check compares persisted verification information. It does not re-read the stored PDF or original-media bytes. A separate deep-verification result must state that those bytes were re-read and matched at the time shown before you describe that check as complete. Read the object and timestamp alongside the result.

Consider a fictional equipment handover, DEMO-SHARE-7. A recipient downloads a file titled AuditIt Redacted Share Report. They record that copy name and the Public-share PDF SHA-256 label when reviewing the download. If they also need the canonical report check, they read its verification page separately and retain the check's stated scope. No real customer, report, hash or access link is represented by this example.

These are the three suggested review actions shown in the illustration: name the copy, match the hash label, and review the result. Each action keeps the object being checked visible. The public verification guide explains the individual report results in more detail.

For the condition record itself, AuditIt's equipment checkout-and-return starter uses before_after for two stages. The equipment damage-report starter uses record_only for a single issue. The equipment checkout and return guide explains that workflow choice. Neither record shape changes which PDF hash belongs to a shared derivative.

AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability. If these record and sharing tasks fit your work, get started with AuditIt. A person still reviews what the submitted condition evidence means.

• equipment rental
• redacted share PDF
• SHA-256
• report verification