At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| Captured terms, page revisions, usages, findings, links, and membership | Canonicalize and hash each persisted chunk | A deterministic chunk root | The root represents canonical record material. It is not the source content by itself. |
| Baseline ID and completed chunk roots | Sort the chunk roots and hash the aggregate | The enterprise baseline root hash | Equivalent chunk-root order produces the same result. A changed chunk changes the aggregate. |
| Manifest objects, usages, trace endpoints, and declared counts | Sort each collection by stable identity and recompute canonical material | A verification root | Duplicate identities or malformed collections are rejected before comparison. |
| Expected root and recomputed root | Run the manifest root check | match or conflict evidence inside the verification result | A root mismatch makes the verification nonconformant. Invalid counts can remain separately unresolved. |
| Supplied objects and indexes | Compare presence, checksum, application hash, source revision, usage, and endpoints | Distinct missing, corruption, drift, stale-source, and index states | A matching root does not hide missing supplied evidence or a count mismatch. |
| Ordered archive section proofs | Hash the section proofs under the baseline identity | A separate archive source snapshot hash | The archive source hash and baseline root hash are different controls and are not interchangeable. |
How it works
- Open Baseline and find Enterprise evidence workspace.
- Select the deposited evidence set under review.
- Inspect Frozen meanings and revisions. Review each visible SHA-256 and Availability value.
- Select Run verification when persisted verification inputs are available.
- Review Conformance and any Coverage blockers. A root conflict must not appear as a successful result.
- Use Export archive only when the baseline also contains its separate archive source snapshot proof.
Example
A deposited baseline contains two artifact revisions and three usage observations. One stored usage observation later differs from the manifest expectation. Verification recalculates the canonical manifest root and checks the supplied usage independently. It reports the conflict instead of treating the package as conformant. Reordering the same correctly identified manifest records does not create a false conflict because the verifier sorts them first.
What this does not mean
The root hash is not a certificate, signature, timestamp authority, or legal WORM guarantee. It does not prove authorship or regulatory sufficiency. It does not reveal which business fact is correct. It only supports integrity checks over the defined canonical material. The archive source snapshot hash serves a different purpose and must remain separate.
Related questions
Next step
Evaluate a small deposited baseline. Record its expected root, run verification, and review root, count, object, usage, and endpoint checks together. View Compliance Glossary on Atlassian Marketplace.
View on Atlassian Marketplace