What AuditIt public report verification actually checks
Understand what AuditIt public verification checks, what each result label means, and when a separate stored-byte rehash may be claimed.
By AuditIt Editorial Team · Updated · Fact checked
What to know
- A Verified badge means the recorded report details passed the named integrity checks.
- The standard public page uses saved report data; reading the stored PDF or media again is a separate check.
- Each deep rehash applies to one object at the time shown.
- Share the exact row, object, and timestamp so the next reviewer has the same context.
A Verified badge answers a focused question: did the recorded report details pass the integrity checks named on AuditIt's public page? That gives a recipient a useful place to start, especially when a report has moved beyond the person who created it.
The standard public page checks saved report data; it does not reopen the stored PDF or original photos. Think of the result as a map of what held up, not the review itself. This guide shows what each row contributes, when a separate byte rehash matters, and where to look next.
For the difference between preventing a change and making a change detectable, read tamper-evident vs tamper-proof.
Read the badge, then the row beneath it
The public page uses three overall states.
- Verified. The signed manifest, report hash, PDF hash record, signature or refusal records, and persisted evidence hash metadata match the AuditIt verification record. The rows below show what was compared.
- Verified with a warning. At least one row needs attention, but none returned an invalid result. Open the warning and see which check produced it.
- Could not be verified. At least one check returned an invalid result. Review that row and the record's context before relying on the copy.
Start with the row that warned or failed. Note the object it refers to, then compare the report, related evidence, and event history.
Eight checks, eight narrower questions
Seven detail rows sit beneath the badge, with the server-signed manifest reported separately. Each answers its own question.
| Public row | The question it answers | Why a reader may look further |
|---|---|---|
| Report content hash | Does the recomputed hash of the recorded report content agree with the report and manifest records? | Compare the photos and notes when the question is whether an observation is true or complete. |
| PDF hash record | Does the recorded PDF SHA-256 agree with the value in the signed manifest? | Look for a separate stored-PDF rehash if you need a fresh check of the retained file. |
| Stage manifests | Do the recomputed stage manifests agree with the report manifest reference? | Read the stage entries when the question is what someone observed during that visit. |
| Evidence hash metadata | Does the persisted media hash metadata agree with the signed manifest? | A separate original-media rehash is needed to read the stored files again. |
| Signature / refusal records | Is the recorded signature or refusal still tied to the stage manifest it refers to? | Keep the customer record separate from the server signature. |
| Audit event chain | Do the recorded event hashes, sequence, links, and report anchor recompute? | Use the history to trace events; work out why something happened from the evidence and context. |
| Verification token | Is the token active, revoked, or marked compromised? | If the link was revoked, ask for a current one; the underlying report may still exist. |
| Server-signed manifest | Does the manifest hash recompute, and does the server signature verify against the recorded signing key? | Treat it as a server integrity check, not a customer identity check. |
Swipe horizontally to view every column.
Picture a van coming back with a dent. A Verified page can show that the recorded report content and signed manifest agree. It cannot tell you when the dent appeared. For that, a reviewer still needs the before-and-after photos, timestamps, notes, and event history. Verification checks the record; people interpret the evidence.
Did AuditIt reread the stored files?
Not in the standard view. AuditIt compares recorded report data, hashes, manifests, signature or refusal records, the event chain, token status, and the server signature. The stored PDF and original media stay unopened during that check.
The PDF and original-media rows tell you whether a stored-byte rehash was run. When a separate deep result appears, it reports whether AuditIt reread that object's bytes and matched them with the recorded SHA-256 hash at the time shown. A PDF result does not cover the original photos, and a media result does not cover the PDF.
Keep the object and timestamp with the result. Only describe an original file as unchanged when the specific original-media rehash passed for that file.
Why hashes and signatures help
The US Secure Hash Standard explains that hash algorithms generate message digests that can be used to detect whether messages changed after the digests were generated. That is hashing's job here: it gives a reviewer a recorded value to compare.
The US Digital Signature Standard describes digital signatures as a way to detect unauthorized data modification and authenticate a signatory. AuditIt shows the server-signed manifest and the customer signature or refusal in separate rows because they answer different questions.
Where AuditIt fits in the review
A finalized AuditIt report can have a public verification page that a recipient opens without an AuditIt account. The badge gives the headline; the rows make the underlying checks and warnings visible.
AuditIt keeps the report and its verification details together so another person can review the record later. The record is tamper-evident, not tamper-proof. The badge isn't a legal certificate and can't assign liability.
To organize a repeatable condition record, create an AuditIt account.
Direct answers
Frequently asked questions
What does AuditIt public report verification check?
It checks the recorded report content hash, PDF hash record, stage manifests, evidence hash metadata, signature or refusal records, audit event chain, verification token, and server-signed manifest. Each row covers one part of the record.
Did the default public check reread the original photo bytes?
No. It compares recorded verification data. Reading stored original-media bytes again is a separate result, shown with its own outcome and timestamp.
What should I do with a Verified with a warning result?
Open the affected row first and see which check warned. When you pass the result on, include the badge, row, object, and time so the next reviewer has the same context.
Does “Could not be verified” prove deliberate tampering?
No. It means at least one check returned an invalid result. Use the affected row and the record's context to investigate; the result alone cannot identify intent, cause, or responsibility.
Are the server-signed manifest and a customer signature the same thing?
They play different roles. The server-signed-manifest row checks the report manifest's cryptographic server signature. The signature or refusal row checks the customer record tied to a stage manifest.
Do the NIST standards certify AuditIt?
No. The cited standards explain hash and digital-signature concepts. AuditIt cites those definitions; NIST does not name or certify the product.
Can an automated workflow rely on a Verified result alone?
It can route or summarize the badge and detailed rows as scoped integrity signals. If a warning appears, route the record to a person before the workflow moves on. Any decision beyond those checks belongs with the responsible reviewer.
Sources
- FIPS 180-4: Secure Hash Standard (SHS), National Institute of Standards and Technology
- FIPS 186-5: Digital Signature Standard (DSS), National Institute of Standards and Technology
- public verification
- report verification
- condition records
- hash checks
- audit trail
