Overview
A bundle captures the rows, chunks, memory facts, redactions, and capability invocation metadata used for an output.
Evidence ids and resource records are produced by Synapsor when a capability runs with evidence enabled. Store the returned run_id, evidence_bundle_id, proposal_id when present, workflow, capability, business object ids, principal, tenant, request_id, and timestamp with your app decision.
The evidence id is one lookup key, not the only lookup path. A support lead can also start from a ticket, invoice, order, customer, workflow, capability, principal, tenant, request_id, query fingerprint, proposal, settlement, or time window.
At scale, humans should find evidence through indexed run/evidence/proposal/audit search by project, database, workflow, capability, principal, tenant, business object id, proposal or settlement id, query fingerprint, and time window. A billion reads should never mean scrolling Activity search or model logs.
For automatic approvals, settlements, or merges, reviewers should follow settlement -> proposal -> run -> evidence bundle -> query audit -> replay. That chain answers what the agent saw, what it proposed, why policy allowed it, and what changed.
Use READ RESOURCE, FROM AGENT ACTIVITY, synapsor_evidence_bundles, synapsor_evidence_resources, replay, or the workspace Activity/Evidence/Proposal views when you need to inspect the stored bundle later. The Workspace result screens show a reviewer lookup recipe after each successful capability test.
Evidence is required for audit-grade agent workflows.
Bundle ids should travel with responses, proposals, and incident reports.
Evidence bundle lifecycle
Evidence turns a capability response into an inspectable database record instead of a loose log trail.
Root rows, lookup rows, hybrid-search chunks, and governed memory are collected under hidden session scope.
The reviewed capability returns an answer, decision, or proposal id.
Synapsor stores source ids, scores, policy versions, redactions, and invocation metadata under a searchable record.
Users, reviewers, or auditors inspect the bundle without reconstructing prompt glue.
The captured context can be compared with current policy, memory, and data.
Developer notes
- Require evidence for customer-facing decisions.
- Display source versions when an answer cites policy.
- Store run ids, evidence bundle ids, proposal ids, business object ids, tenant/principal scope, request ids, and timestamps alongside app decisions.
- Expose evidence lookup by indexed run/activity filters, not only by paste-a-handle forms.
- For automatic settlements or merges, link settlement -> proposal -> run -> evidence bundle so reviewers can inspect the original read and the write decision.
- Use replay to compare original and current behavior.