What belongs in an evidence pack
An evidence pack should answer a buyer's practical questions: what entered the governed path, which policy applied, what decision was made, who approved it if approval was required, and what stable proof remains afterward.
What the pack is for
An evidence pack is not a dump of everything that happened. It is a structured explanation of a governed event that makes sense to a buyer, auditor, operator, or partner.
Request evidence fields
- entity_type and request_id
- tenant and use case
- decision and approval status
- policy version
- reason codes
- timestamps and actor trail
Document evidence fields
- entity_type and document_id
- inspectability and extractor
- detected classes and confidence
- file hash, mime type, extension, and size
- approval status and approval_id
- policy version and retention markers
Why this beats raw logging
Raw logging expands the data surface and still fails to explain the decision path clearly. A structured evidence pack is smaller, more reviewable, and easier to align with actual governance questions.
Who uses it
Buyers use it for assurance, auditors use it for reviewability, operators use it for incident reconstruction, and partners use it to show that policy is being enforced in runtime instead of sitting in a slide deck.
Next step
If the evidence story is central to your sales or assurance conversation, keep the article, the public evidence sample, and the one-pager aligned.