At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| Deposited baseline identity | Load its recorded verification evidence | Verification run tied to one baseline | The required persisted verification inputs must exist |
| Frozen members and hashes | Recalculate canonical digests | Matching or changed evidence states | A matching digest does not prove source correctness |
| Section counts and order | Compare expected and supplied records | Completeness and ordering findings | Only recorded package scope is checked |
| Governed references | Resolve retained targets | Valid, dangling, moved, stale, or unavailable states | Candidate links do not become governed evidence |
How it works
- Open Enterprise evidence workspace.
- Select the required deposited baseline.
- Review Coverage blockers before verification.
- Select Run verification.
- Read the integrity and conformance results.
- Resolve each reported state before export or incident review.
Example
An archive handoff contains the expected policy revision, but one stored object has changed. Verification recalculates the object digest and reports a mismatch. The baseline remains unchanged. The evidence administrator investigates the affected object and does not present the package as verified until a valid deposited baseline is available.
What this does not mean
Verification is read-only. It checks the recorded package and references. It does not certify compliance, establish legal validity, approve a release, or prove that the original source content was correct. A newly created enterprise freeze also needs the persisted verification inputs required by the workspace action.
Related questions
Next step
Run verification before evidence export, audit handoff, or incident reconstruction.
View on Atlassian Marketplace