Evidence packets
What Luota must show before a monitor, incident, export, or notification deserves operator trust.
What an Evidence Packet is
An Evidence Packet is the retained record around one workflow promise. It is not a decorative report. It is the product object that explains why Luota opened an incident, resolved it, notified someone, or showed the workflow as healthy.
Required parts
| Part | What it proves | Product surface |
|---|---|---|
| Promise | What should happen and when | Onboarding, monitor detail |
| Healthy signal | The real workflow can report success | Monitor timeline |
| Bad-day signal | Luota can show the broken path | Incident detail |
| Owner route | Someone knows what to do next | Alert channel, runbook, owner |
| Audit trail | Sensitive changes are attributable | Settings, audit log |
| Export path | Evidence can leave Luota safely | Export and support flows |
What breaks trust
- A green state without the last accepted event.
- An incident without request id, run id, owner, or recovery context.
- A billing/export/admin action without an audit entry.
- A notification that links to a generic dashboard instead of the relevant packet.
- A public API response that leaks raw payload or output where the caller only needs status.
Where packets show up
The same object should feel consistent in:
- onboarding
- monitor detail
- incident detail
- dashboard queue
- notification emails and webhooks
- export files
- support/debug paths
If those surfaces use different language, the product feels generic and the user has to translate.
Support rule
When support asks for proof, the user should be able to provide a request id, run id, incident id, or exported packet without copying raw secrets or sensitive payloads.