Package evidence for a purpose — with the gaps declared
An evidence bundle is a purpose-bound package of permitted workforce-record evidence. Its manifest identifies the exact record versions, source references, policy snapshots, corrections, approvals, notices, downstream status, filters, redactions, unavailable items, generator, time context, recipient, and package version.
It supports review and export continuity. It does not by itself establish legal admissibility, compliance, completeness, payroll correctness, or factual correctness.
Synthetic bundle manifest
The manifest is the package contract. Nine items, and only four of them made it in — because a manifest that hides what it could not include is worse than no manifest at all.
- Purpose
- Internal review support
- Generator role
- Payroll reviewer
- Organization scope
- Field Services · North
- Date range
- 28 Jul – 03 Aug 2026
- Records in scope
- 1 record, versions pinned
- Evidence categories
- 6 requested
- Included
- 4 of 9 items
- Redaction summary
- 1 item, free-text category
- Recipient
- Named internal reviewer
| Evidence item · pinned version | State | Reason |
|---|---|---|
| Record version 3TR-77841 · v3 · pinned at as-of time | Included | Authorized and packaged at the pinned version. Version 1 and 2 are referenced but not packaged. |
| Policy snapshotFN-WT v3 · effective 01–09 Aug | Included | The version that actually applied. Current v4 is not substituted. |
| Approval decisionDEC-2288 · conditional approval | Included | Decision, authority scope, reason, condition and effective time. |
| Correction requestCOR-0912 · worker free-text context | Redacted | Free-text worker statement removed for this purpose. Redaction category is stated; the value is not revealed. |
| Reviewer notesInternal deliberation | Excluded by purpose | Not permitted for internal review support. The purpose rule is named without exposing protected logic. |
| Related worker recordsOther workers, same shift | Excluded by permission | Requester not authorized. No hidden identifier, count or title is disclosed — including the number of such records. |
| Policy history 28–31 JulFN-WT v2 window | Missing | Expected reference absent — not retained. The gap is stated; no content is inferred. |
| Downstream reconciliation statusTarget holds version 1 | Conflicting | The record is approved at v3 while the target holds v1. Both are shown; the conflict is not resolved inside the package. |
| Notice delivery receiptsNotification service | Failed during packaging | The item could not be added, so the bundle is partial rather than ready. The failure is recorded in the final manifest. |
Authorized and packaged at the pinned version. Version 1 and 2 are referenced but not packaged.
The version that actually applied. Current v4 is not substituted.
Decision, authority scope, reason, condition and effective time.
Free-text worker statement removed for this purpose. Redaction category is stated; the value is not revealed.
Not permitted for internal review support. The purpose rule is named without exposing protected logic.
Requester not authorized. No hidden identifier, count or title is disclosed — including the number of such records.
Expected reference absent — not retained. The gap is stated; no content is inferred.
The record is approved at v3 while the target holds v1. Both are shown; the conflict is not resolved inside the package.
The item could not be added, so the bundle is partial rather than ready. The failure is recorded in the final manifest.
Five of nine requested items are absent, redacted or in conflict, and each is named above. One item failed during packaging, which is why this bundle is Partial and not Ready. No integrity feature is supported for this package, so no checksum, signature or verification claim appears. Downstream state has not been verified. Evidence completeness for this purpose is partial.
Who may access: the named internal reviewer, plus the generator. Access basis: purpose-bound authorization, checked server-side on every request. Delivery state: not requested. Access state: available. No expiry duration, download limit, or secure-link behaviour is stated, because none is a confirmed capability for this package.
Thirteen item states
A bundle item is not simply in or out. The reason it is out determines what may safely be said about it.
| State | Definition | Display rule |
|---|---|---|
| Included | Authorized item packaged at its pinned version. | Show the version and the reason it was used. |
| Excluded by user | Authorized item deliberately not selected. | Show the selection decision where safe. |
| Excluded by purpose | Not needed or permitted for the selected purpose. | Explain the purpose rule without exposing protected logic. |
| Excluded by permission | Viewer or requester not authorized. | Do not leak a hidden identifier, count, or title. |
| Unavailable | A known item cannot currently be retrieved or packaged. | Show a safe reason, plus retry or support where applicable. |
| Missing | An expected evidence reference is absent. | State the gap. Do not infer content. |
| Stale | Evidence or source status requires review for current use. | Preserve the historical version and show the warning. |
| Superseded | A later version exists. | Show the exact version packaged and its relationship to current. |
| Restricted | Existence or detail limited by policy or role. | Use a controlled generic description. |
| Redacted | Some permitted content removed or masked. | State the redaction category without revealing the value. |
| Conflicting | Evidence objects disagree, or authority is unresolved. | Keep both and the limitation visible where permission allows. |
| Unknown | The system cannot establish the item state. | Never map to available or complete. |
| Failed during packaging | A selected item could not be added. | The final manifest marks the failure; the bundle becomes partial or failed per policy. |
Authorized item packaged at its pinned version.
Show the version and the reason it was used.
Authorized item deliberately not selected.
Show the selection decision where safe.
Not needed or permitted for the selected purpose.
Explain the purpose rule without exposing protected logic.
Viewer or requester not authorized.
Do not leak a hidden identifier, count, or title.
A known item cannot currently be retrieved or packaged.
Show a safe reason, plus retry or support where applicable.
An expected evidence reference is absent.
State the gap. Do not infer content.
Evidence or source status requires review for current use.
Preserve the historical version and show the warning.
A later version exists.
Show the exact version packaged and its relationship to current.
Existence or detail limited by policy or role.
Use a controlled generic description.
Some permitted content removed or masked.
State the redaction category without revealing the value.
Evidence objects disagree, or authority is unresolved.
Keep both and the limitation visible where permission allows.
The system cannot establish the item state.
Never map to available or complete.
A selected item could not be added.
The final manifest marks the failure; the bundle becomes partial or failed per policy.
Nine independent state dimensions
These are orthogonal, not stages. A bundle can be authorized, generated, and expired at the same time — and generation readiness can never be inferred from evidence completeness.
Builder state
Draft · validation error · ready to confirm · approval required.
Do not infer generation readiness from evidence completeness alone.
Generation state
Queued · processing · partial · failed · ready · unknown result.
Job state is separate from access and delivery.
Evidence completeness
Complete for the selected purpose · partial · missing · restricted · stale · conflicting · unknown.
No universal “complete evidence” claim.
Permission state
Authorized · limited · approval required · denied · changed since generation.
Server-authoritative, always rechecked.
Access state
Available · viewed · downloaded · expired · revoked · blocked.
Separate from delivery.
Delivery state
Not requested · pending · delivered · rejected · unknown.
Separate from recipient acceptance and reconciliation.
Reconciliation state
Not applicable · pending · matched · mismatch · unresolved · reopened.
Only where a downstream comparison is configured.
Lifecycle state
Current · superseded · retention-limited · disposition pending · disposed where supported.
Historical attribution stays distinct from current usability.
Integrity feature state
Not supported · available · generated · verification failed or unknown.
Never imply cryptographic assurance from package presence.
Collapsing these into a single progress bar is the most common way an export feature starts lying. “Ready” would then imply delivered, delivered would imply accepted, and a package with four of nine items would look finished. Keeping them independent is what lets the manifest above say partial and mean it.
Format and integrity capability gate
This page names no file format and no integrity feature. Every one of them is gated on a capability registry, and a marketing page is not a registry.
- File or package formatRegistry only
- Machine-readable schema and versionRegistry only
- Checksum or hashNot claimed
- Digital signature or certificateNot claimed
- Encryption, password, or secure linkNot claimed
- Watermark or classification labelNot claimed
- Compression or archive containerNot claimed
- Manifest as the package contractRequired
- Human-readable summaryRequired
No placeholder formats and no “coming soon.” Where a checksum is technically implemented, verified, and approved it may be rendered — and even then it never implies tamper-proofing or a legal chain of custody.
Redaction and sensitive data
What a redaction states
- That content was removed or masked
- The category of what was redacted
- The purpose basis for the redaction
And never the value itself, nor enough surrounding detail to reconstruct it.
Where a classification label or watermark capability exists, it supplements access control. It never substitutes for it — a labelled document in the wrong hands is still in the wrong hands.
Worker-safe review
Before a bundle is generated, the builder shows what a worker-visible package would contain, so a reviewer can see the package as its subject would. Free-text worker statements are redacted by default for purposes that do not require them.
Access, delivery & receipt
CurrentObjective: keep four things apart that products routinely merge.
- Access
- Whether an authorized person can open it — checked server-side on every request, not at generation time
- Delivery
- Whether it was sent to a destination, where delivery is configured
- Download
- Whether a copy was actually taken
- Receipt & reconciliation
- Whether a target acknowledged it, and whether expected matched observed
Limitations: permission can change after generation, and it is rechecked rather than trusted. A package generated under one authorization does not stay open because it once was.
Expiry, revocation & supersession
CurrentObjective: be precise about what revocation can and cannot reach.
- Revocation
- Platform access can be revoked where supported
- Supersession
- A newer bundle links to the prior one with a reason; the prior manifest stays historical
- Retention
- Retention, hold and disposition follow authoritative policy
The honest limit: ZoikoTime cannot recall or erase copies already obtained outside its control. Revoking platform access is a real control; claiming a downloaded file can be un-downloaded would be false. No expiry or retention duration is stated here, because none is a confirmed capability.
How worker records are protected in a package
Export is where a workforce product most easily becomes a dossier tool. Five controls exist to stop that.
Purpose limitation
A bundle is built for a stated purpose, and items not permitted for that purpose are excluded by rule rather than by discretion.
Role and field authorization
Authorization is per role and per field, checked server-side. A generator cannot package what they could not view.
Redaction & protected audit
Sensitive content is masked by category, and every generation, access, and download is itself auditable.
Anti-surveillance boundary
Nothing that does not exist can be exported. There is no screen, keystroke, URL, application, or clipboard data in any package.
An unrestricted log dump · a bulk employee dossier · a surveillance export · a productivity report · a worker ranking · a misconduct score · an inferred risk profile. None of these is a missing feature; each is a prohibited output.
No screenshots, keystroke content, URL history, application-name monitoring, or clipboard collection under any tier or configuration.
When packaging goes wrong
The governing rule: never silently substitute a changed version into a confirmed package, and never present a partial package as complete.
| Condition | Required behaviour |
|---|---|
| Records changed after preview | The manifest becomes stale and requires revalidation. Changed versions are never silently substituted into the confirmed package. |
| Generation partially succeeds | The bundle is Partial, the failed items are named in the final manifest, and it is not presented as Ready. |
| Generation fails | Failure state with a safe reason, a retry path, and no half-usable artifact presented as a package. |
| Duplicate confirmation | Idempotent — a repeated confirmation does not silently create a second package. |
| Permission changed since generation | Access is rechecked server-side and newly restricted content is withheld, without leaking through the error. |
| Item unavailable at packaging time | Named as unavailable with a safe reason and support route; no placeholder content is generated. |
| Integrity feature unsupported | Stated as not supported. No checksum, signature, or verification language appears. |
| Delivery rejected | Recorded as rejected, distinct from generation success and from access state. |
| Downstream mismatch | Expected and observed both shown; the conflict is not resolved inside the package. |
| Bundle expired or revoked | Access blocked and the manifest remains historically attributable — with no claim that external copies were recalled. |
| Retention-limited | Allowed residual metadata and the period limitation. Disposed content is not reconstructed. |
| No JavaScript | Server-rendered direct answer, manifest summary, limitations, and approved links remain usable. |
Records changed after preview
The manifest becomes stale and requires revalidation. Changed versions are never silently substituted into the confirmed package.
Generation partially succeeds
The bundle is Partial, the failed items are named in the final manifest, and it is not presented as Ready.
Generation fails
Failure state with a safe reason, a retry path, and no half-usable artifact presented as a package.
Duplicate confirmation
Idempotent — a repeated confirmation does not silently create a second package.
Permission changed since generation
Access is rechecked server-side and newly restricted content is withheld, without leaking through the error.
Item unavailable at packaging time
Named as unavailable with a safe reason and support route; no placeholder content is generated.
Integrity feature unsupported
Stated as not supported. No checksum, signature, or verification language appears.
Delivery rejected
Recorded as rejected, distinct from generation success and from access state.
Downstream mismatch
Expected and observed both shown; the conflict is not resolved inside the package.
Bundle expired or revoked
Access blocked and the manifest remains historically attributable — with no claim that external copies were recalled.
Retention-limited
Allowed residual metadata and the period limitation. Disposed content is not reconstructed.
No JavaScript
Server-rendered direct answer, manifest summary, limitations, and approved links remain usable.
What this module owns
Evidence Bundle owns
- Purpose, scope, and version pinning
- Evidence selection and the manifest
- Redaction and worker-safe review
- Recipient, destination, access, and approval
- Generation, delivery, expiry, and revocation
And does not duplicate
- Inspect Lineage — relationship topology and provenance
- See Policy Evidence — the policy version and rule trace
- Review History — the chronological event record
- Worker Experience — the worker journey as a whole
- Evidence Ledger — the broader record-centred evidence authority
View Bundle is the focused packaging and export task. Evidence Ledger is the record-centred history and lifecycle authority. Asking either to do the other's job produces a worse version of both.
What a package cannot establish
A complete-looking package does not prove that every underlying fact, rule, decision, external system, legal requirement, or consequence is correct, complete, current, lawful, admissible, or sufficient. It is not a legal discovery package, statutory audit file, regulator submission, payroll filing, evidence certification, non-repudiation mechanism, or chain-of-custody guarantee.
No customer evidence
No customer names, logos, export volumes, or outcome metrics appear here. None has been verified for this module.
Export evidence without exporting a dossier
See how purpose limitation, pinned versions, declared gaps, redaction categories, and separated access states make a package defensible — and make its limits legible.
Request Enterprise Demo
Evidence bundle questions
A purpose-bound package of permitted record evidence and context, with an inspectable manifest, pinned versions, inclusion and exclusion states, redactions, and lifecycle information. The manifest is the package contract — it is what makes the package reviewable rather than merely deliverable.