At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| Frozen evidence value | Serialize the governed record in canonical form | Deterministic SHA-256 value | Validates the recorded value, not its real-world truth |
| Uploaded file | Compare the supplied digest with received bytes | Accepted file or integrity failure | Does not approve the file's content |
| Archive part | Recalculate the part digest | Matching or changed part state | Does not make storage legally immutable |
| Baseline manifest | Recalculate member and root evidence | Verification findings and computed root | Completeness still depends on recorded scope and coverage |
How it works
- Capture a governed revision or uploaded file.
- Calculate SHA-256 from the canonical bytes.
- Store the digest with the evidence identity.
- Select Run verification when evidence must be checked.
- Compare the computed digest with the recorded digest.
- Investigate every mismatch before using the package.
Example
A baseline contains a frozen policy revision and its recorded SHA-256 value. A later verification reads the deposited bytes and calculates the digest again. If one byte changed, the values differ and verification reports an integrity finding. If they match, the check confirms byte integrity only. It does not certify the policy.
What this does not mean
SHA-256 is an integrity mechanism. It does not establish authorship, approval, legal validity, source correctness, or regulatory compliance. Application hashes and content-addressed object keys are tamper evidence. They are not legal WORM storage.
Related questions
Next step
Use verification before relying on a deposited evidence package.
View on Atlassian Marketplace