Evidence that explains what happened — and why
ZoikoSuite is designed to preserve governance decisions, workflow history, document lineage, operational events and integrity context as work happens — then connect the relevant proof into evidence manifests for audit, compliance, legal, security and executive review.
Each layer answers a different question
An auditor asking "did the control operate" needs a different layer from a lawyer asking "who signed this version" or a security reviewer asking "what else happened in that session".
Governance decision
Actor, entity, jurisdiction, policy or rule basis, authority evaluated, outcome and rationale — captured at the moment of decision, not reconstructed.
Answers: who decided, under what authority, on what basis
Workflow history
Every state transition with its approver, delegation, rejection, escalation and recorded rationale, in sequence.
Answers: how it moved, who touched it, what was refused
Document lineage
Version chain, source, integrity hash, signature state, access history, retention reference and residency position.
Answers: which version, signed by whom, seen by whom
Operational event
Typed events with source service, actor or system principal, object reference, correlation ID and causation link.
Answers: what else happened, in what order, caused by what
Evidence manifest
A scenario-specific package assembling the required evidence across layers — and stating what is missing.
Answers: is the proof complete for this question
Integrity controls
Append-only storage, hash verification, tamper-evident chaining and cryptographic validation where implemented.
Answers: has this record changed since it was written
The registry, with its integrity state per object
Every evidence object carries its layer, source, integrity state and last verification. Synthetic data throughout.
Seven states, and what each one must not be taken to mean
Integrity vocabulary is where evidence claims most often overreach. Each state below carries an explicit limit.
A manifest states its gaps rather than hiding them
Completeness is computed against what the scenario requires. A package that is missing three items says so on its summary card.
Six states that must stay visible
Missing, stale, external, partial and unsupported are all real answers. Hiding any of them makes the whole surface untrustworthy.
Missing
A required item does not exist. Shown as missing with the requirement named — never replaced by a generic trust claim.
Stale
Integrity or freshness not confirmed within the review period. Flagged in place rather than silently accepted.
External / referenced
Evidence lives in another system under separate custody. Referenced, never counted as held.
Partial
Some required items present, others absent. Completeness states the ratio rather than rounding to complete.
Unsupported
The evidence type cannot currently be produced for the requested scope. Said directly, with an architecture route where one exists.
Excluded by policy
Restricted-class content withheld under access or classification rules, with the exclusion stated in the manifest.
Export is a governed action with its own evidence
Assembling a diligence package is itself an event: who exported what, for what purpose, to where, under which approval.
- •Scenario template defines the required items
- •Completeness computed and stated before export
- •Export requires approval where restricted content is in scope
- •Export event records actor, purpose, destination and approval
- •Restricted exclusions stated in the package, not applied silently
- •Evidence follows its own retention reference
- •An active legal hold blocks evidence deletion
- •Evidence residency follows the governed-records position
- •External references follow their source system's rules
Ingested evidence
Captured from a source system with source metadata and provenance recorded at ingestion.
Referenced evidence
Pointer to a record held elsewhere. Custody, retention and deletion remain with the source system.
Provenance metadata
Source service, ingestion time, transformation applied and correlation reference.
API and webhook access
Programmatic retrieval of evidence objects, subject to the same access and classification rules.
Five rungs, kept separate
Architecture proof, product proof, validation status, customer proof and independent proof answer different questions and carry different weight.
Architecture proof
The published six-layer model, integrity vocabulary and manifest logic — inspectable on this page without a conversation.
Product proof
Annotated registry and manifest interfaces with synthetic data, including qualified and missing states.
Validation status
Per-layer claim states: current architecture, phased delivery, by workflow, implementation status required.
Customer proof
Approved customer evidence with scope, period and limitations.
Independent verification
Third-party attestation that the evidence model operates as described, for a stated scope and period.
Bring the scenario, not the checklist
The useful question is not "do you have audit logs" but "for this decision, can you produce these nine items". A review works through a real scenario.
- Scenario walkthrough — your audit question mapped across the six layers
- Manifest definition — what a package for that scenario would require
- Completeness assessment — which items exist today and which do not
- Integrity position — per layer, with implementation status
- External dependency list — evidence held in systems we do not control
- Gap statement — unsupported evidence types, said directly
Request an evidence architecture review
Enough to scope a response, nothing more.
Bring the audit question you could not answer last time
The decision nobody could reconstruct. The approval chain that had to be rebuilt from email. The document version whose signer was disputed. We will map one across the six layers and tell you which items exist today, which are external, and which do not exist at all.
No evidence completeness, integrity guarantee, legal admissibility, regulatory acceptance or independent attestation is committed outside an approved commercial document.
Talk to a solutions architect
Every section of this page was readable without it.
Integrity, completeness, admissibility and export
Direct first sentences, then qualified detail. Every answer is present in the page source.
No. Tamper-evident is not tamper-proof, and the second term is never used.
Tamper-evident means a mechanism is designed to reveal specified changes. Tamper-proof is an absolute claim no storage system can honour. Each of the seven integrity states carries an explicit limit on what it must not be taken to mean.