Kiket docs
Start

Evidence Center

Browse normalized evidence, explore the provenance graph, and navigate to linked cases and findings.

The Evidence Center (/evidence) is the audit-ready catalog of evidence records — durable proof objects normalized from operational events and adapter ingestion. Each record carries type, source system, capture time, content hash, and links to the case and process it supports.

Evidence is server-owned platform data (not git-backed). Configuration for what evidence a process requires lives in .kiket/ workflow YAML; the center shows what was actually observed.

In the UI, inbound connectors are Evidence sources (Settings → Evidence sources, route /settings/integrations). That label is distinct from outbound notification webhooks on the same page.

Layout

RegionPurpose
Filter bannerShows active scope (case, process, or finding) with a quick Show all evidence action.
Provenance graphInteractive graph of cases, evidence, findings, and events for the current scope.
Evidence listRows with title, type, source, timestamp, content hash, linked case, and optional anchor status.

When no records exist, the empty state points to Connect evidence source (Settings) or Open Process Twin.

URL parameters

Query params scope the list and graph (deep-linkable):

ParamMeaning
caseIdShow evidence linked to one operational case.
processIdFilter to a monitored process (combine with caseId for AND scope).
findingIdShow evidence linked to a specific finding (via evidence links).
selectedHighlight and scroll to one evidence row by id.

Examples:

/evidence?caseId=<uuid>
/evidence?caseId=<uuid>&processId=<uuid>
/evidence?findingId=<uuid>
/evidence?selected=<evidenceId>

From Operational Cases, the Evidence for this case shortcut opens /evidence?caseId=…. From the Findings Inbox, attach-proof steps navigate to Evidence Center with finding or case scope.

The command palette action Open Evidence for selected case works when /cases?selected=<caseId> is in the URL.

Provenance graph

The graph visualizes how entities connect in the compliance twin:

  • Cases — operational work items flowing through the monitored process.
  • Evidence — normalized proof records.
  • Findings — scanner output tied to cases and checks.
  • Events — operational events that produced or contextualize evidence.

Click a node to open the corresponding case, finding, or evidence row. Edge labels show link types (for example supports).

API

The UI loads the graph from:

GET /platform/evidence/provenance-graph

Query parameters mirror the page filters:

ParamBehavior
caseIdFull case graph (case ↔ evidence ↔ findings ↔ events).
findingIdGraph centered on one finding and its linked evidence.
processIdProcess-scoped evidence and related findings.
workspaceIdOptional tenant scope when listing without a case.

Response shape matches the case graph schema (nodes, edges) used elsewhere (GET /platform/cases/:id/graph).

Unscoped org-wide requests return a capped sample when no caseId, findingId, or processId is set — prefer scoped deep links for investigation.

Evidence records are created during normalization (adapter or replay) and can be linked explicitly:

Link targetTypical use
CasecaseId on the evidence record scopes proof to one operational case.
FindingScanner runs create evidence_links with targetType: finding when a check references supporting proof.
Operational eventEvents that emitted or contextualize evidence appear as graph neighbors.

From a finding in the inbox, open Evidence Center to attach or review proof before resolving. From a case detail panel, the case evidence graph uses the same layout primitives with case-first scope.

RoutePurpose
GET /platform/evidenceList evidence records (workspace/process/case filters).
GET /platform/evidence/:id/contextIntegrity hashes, source event, graph neighbor counts, anchor proof ids.
GET /platform/cases/:id/graphCase-scoped graph (alternative entry when starting from a case).

Integrity and anchors

Each evidence row displays a content hash and, when present, an anchor pill for optional chain-backed integrity proofs. Anchoring is additive — local hashes and PostgreSQL storage remain authoritative for day-to-day operations. See Audit Room for the attestation stepper.

What's next?

On this page