What a signed manifest contributes to a reviewable record
A plain-language guide to AuditIt’s signed-manifest result, how it differs from a hash digest or customer signature, and what still needs human review.
By AuditIt Editorial Team · Fact checked
What to know
- A signed-manifest match is one recorded-field result on AuditIt’s public verification page.
- The signed manifest, customer signature or refusal, and hash digest are separate records.
- A matching manifest cannot decide physical condition, cause, responsibility, or liability.
When AuditIt says a signed manifest matched, read the phrase literally: one named field agreed with the AuditIt verification record. That is useful, but it is narrower than “the customer signed it” and much narrower than “the record proves what happened.”
AuditIt’s public copy does not identify the signed manifest as a validated FIPS 186-5 implementation. The US Digital Signature Standard helps explain digital signatures in general; it does not certify AuditIt. Keeping those two facts separate is the first step toward reading the result accurately.
If the whole verification page is unfamiliar, begin with what AuditIt public report verification checks. This guide stays with the signed-manifest line.
Start with the sentence AuditIt actually shows
On the default public page, a Valid result says:
This report's signed manifest, report hash, PDF hash record, signature/refusal records, and persisted evidence hash metadata match the AuditIt verification record.
The signed manifest is one item in that list. The sentence reports a match between saved fields; it does not say that AuditIt re-read the stored PDF or original photographs. Those byte-level comparisons appear only when a separate deep result is shown.
This distinction matters in ordinary handovers. A reviewer can use the match to understand the integrity record without turning it into a claim about a dent, a scuff, or who should pay.
A customer signature is a different record
The same Valid sentence lists signature/refusal records separately from the signed manifest. AuditIt also distinguishes a refusal submitted by a customer from one recorded by staff. Those records describe whether a person signed or declined to sign the condition record; they are not the signed-manifest field.
So “the manifest matched” should not be paraphrased as “the customer agreed with every observation.” If a signature or refusal matters to the review, read that record on its own terms.
Where the hash fits
A hash digest and a digital signature do related but different work. FIPS 180-4 describes hash digests used to detect whether messages have changed. FIPS 186-5 says a hash function is often used first to produce a message digest that is then given to a digital-signature algorithm.
That relationship does not prove which algorithm AuditIt uses for its signed manifest. It simply explains why “hash,” “digital signature,” and “signed manifest” should not be treated as interchangeable labels. For the byte-comparison side of the record, read SHA-256 in audit records.
What FIPS 186-5 contributes to the explanation
NIST’s current landing presents FIPS 186-5 as the 3 February 2023 Final. A planning note dated 12 May 2025 says issues will be corrected in a future update or revision; it does not announce a successor Final.
The standard says digital signatures are used to detect unauthorized modifications to data and authenticate the signatory. It also uses the term non-repudiation. This article does not carry that term across to AuditIt: the product’s public copy does not promise that a person cannot dispute a condition fact, and a signed-manifest match does not determine liability.
FIPS 186-5 is a US Federal standard, with private and commercial adoption available as the standard states. It is not a global inspection rule. The standard also says conformance does not ensure that a particular implementation—or the larger system containing it—is secure.
A practical reading order
Suppose a boom lift returns with a new-looking scrape. Work through the public record in this order:
- Read the exact overall result and the time shown.
- Treat the signed-manifest match and any customer signature or refusal as separate records.
- Look for a deep PDF or original-media result before making a stored-byte claim.
- Use the photographs, notes, timestamps, and audit history to review the physical question.
A Valid signed-manifest line can support step two. It cannot complete step four for the reviewer.
AuditIt’s audit ledger keeps stages, entries, events, manifests, signatures, hashes, and verification state as the durable history. Exported files are recoverable copies, not a replacement for that history. The same integrity language can support records across sixteen named industries plus a general fallback; customizable templates are not universal inspection checklists.
Where AuditIt fits
AuditIt can keep submitted observations, photographs, signatures or refusals, and verification details together for human review. Its public page reports the signed-manifest match as one bounded integrity result. AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability.
To start a structured condition record, create an AuditIt account.
Direct answers
Frequently asked questions
What does “signed manifest matched” mean in AuditIt?
On the default public page, it means the report’s signed-manifest field matched the AuditIt verification record. It is one recorded-field check, not a statement that stored PDF or photo bytes were re-read.
Is the signed manifest the customer’s signature?
They are different records. AuditIt’s Valid copy names the signed manifest and signature/refusal records separately. A customer or staff refusal also has its own wording.
Is a signed manifest the same as a SHA-256 digest?
A digest and a digital signature perform related but separate jobs. FIPS 180-4 describes change-detection digests; FIPS 186-5 says a digest is often an input to a digital-signature algorithm. The public signed-manifest match should not be renamed as a stored-byte SHA-256 check.
Does a matching signed manifest prove the original photo is unchanged?
Only a passed deep original-media rehash supports that narrow statement for the named file at the time shown. The default page compares recorded fields rather than re-reading stored photo bytes.
Can an automated workflow rely on a signed-manifest match alone?
It can use the match as one input and keep the exact result, object, and time attached. A person still has to assess the photographs, notes, condition, cause, and any question of responsibility; the match is not a final operational or liability decision.
Does FIPS 186-5 mean the other side cannot dispute the record?
FIPS 186-5’s non-repudiation language is part of that US standard. AuditIt does not make it a product promise, and a condition record does not settle liability.
Sources
- FIPS 186-5, Digital Signature Standard (DSS), National Institute of Standards and Technology
- Digital Signature - Glossary | CSRC, National Institute of Standards and Technology
- FIPS 180-4, Secure Hash Standard (SHS), National Institute of Standards and Technology
- signed manifest
- digital signature
- condition records
- public verification
- tamper-evident
