Primary NIST standard specifying SHA algorithms and explaining message digests as a way to detect changed messages.
Controller resource · Evidence integrity
What SHA-256 proves about close evidence content integrity.
A content hash can help a reviewer detect whether a saved evidence payload changed. It cannot prove the source was complete, the accounting was correct, or the reviewer reached the right conclusion. Use this protocol to keep those assertions separate.
Prepared by Sebastian Product & EngineeringUpdated July 20, 2026Educational worksheet · not audit advice
How to use it
Evaluate one real workflow, not a generic promise.
Evidence integrity starts before hashing. Define the source system, entity, period, query or report parameters, cutoff, row count, control totals, and canonical serialization. If two implementations serialize the same logical data differently, they may produce different digests; if the source population is wrong, a perfectly stable digest only fingerprints the wrong population.
The strongest operating pattern is an append-only source version. Save the content and its recipe, generate the digest from a documented canonical form, and cite that version from the review work. Later verification should recompute the digest on the server and compare it with the stored value. A mismatch is a stop signal that requires investigation, not an automatic conclusion about intent.
Original controller worksheet
Integrity protocol for a source snapshot
- 01
Identify the source
Ask: Which system, report, endpoint, or uploaded file produced the evidence?
Retain: Stable source identifier and extraction timestamp.
- 02
Record the recipe
Ask: Which entity, period, filters, parameters, and cutoff produced the population?
Retain: Machine-readable parameters saved with the version.
- 03
Capture completeness checks
Ask: What row count and control totals should a reviewer compare?
Retain: Named totals with units, currency, and calculation scope.
- 04
Canonicalize deterministically
Ask: Are key order, number formats, nulls, timestamps, and row order handled consistently?
Retain: A documented serialization rule covered by repeatability tests.
- 05
Generate and retain the digest
Ask: Which algorithm and exact bytes produced the fingerprint?
Retain: Algorithm identifier, digest, source version, and creation time.
- 06
Verify independently
Ask: Can the server recompute the digest from stored content rather than trusting the client?
Retain: Verification result and timestamp returned from a server-side calculation.
- 07
Separate review judgment
Ask: Does the workpaper explain procedures, findings, and conclusions apart from the source?
Retain: Reviewer identity, work performed, decision, and links to exact evidence versions.
Decision tool
Assertion boundary
Use precise language in control narratives. A hash is an integrity mechanism, not an assurance opinion.
| State / score | Minimum evidence | Decision rule |
|---|---|---|
| Digest matches | Stored canonical content matches the fingerprint generated for that version. | Does not prove source completeness or accounting correctness. |
| Digest differs | Stored canonical content no longer matches the recorded fingerprint. | Investigate versioning, serialization, corruption, or unauthorized change. |
| Source reconciles | Separate completeness and accuracy procedures support the population. | Document those procedures; do not infer them from the digest. |
Completed teaching example
Worked example: one changed control total
The two canonical payloads below differ by one amount. Their real SHA-256 digests were calculated from the exact compact JSON strings shown.
| Field | Completed example | Interpretation |
|---|---|---|
| Version A payload | {"controlTotal":125000,"period":"2026-06","rowCount":2} | SHA-256 aa8e93f3…aaf85d1 |
| Version B payload | {"controlTotal":125100,"period":"2026-06","rowCount":2} | SHA-256 cc2f2c67…a0cbe1e |
| What changed | controlTotal increased by 100 | A different digest detects different canonical bytes; it does not explain whether the change is correct. |
| Reviewer action | Stop, identify the intended source version, and reperform completeness/accuracy checks | Hash comparison is one signal inside a broader evidence procedure. |
Product boundary
How this maps to Sebastian today
Sebastian can store a close source as an immutable version with query parameters, rows, row count, named control totals, and a canonical SHA-256 content hash. Review work can cite a specific source version instead of whichever data is newest.
The server can recompute the digest from stored canonical content and report whether it still matches. Review workbooks and activity records preserve analysis and human decisions separately from the source snapshot.
Sebastian describes this as content verification, not tamper-proofing, audit assurance, or proof that the source was complete. Those broader conclusions require controls and procedures outside the hash itself.
Primary references
Standards context, with applicability boundaries.
Primary standard for audit documentation; company workpapers and external-audit requirements are not interchangeable.
Go deeper
See the work up close.
Keep your ERP. Close and plan in one pane.
AI for accounting and FP&A on the ledger you already run. No migration. No rip and replace.
Agents at work · Matching an invoice to its PO line…