design_review_completed spec → threats / approved deps / channel allowlist verification_completed file → per-guardrail verdicts (≤280 chars each) dep_install_checked resolved package set → registry verdict + signals secret_detected local hard-deny match → secret kind, never the value destructive_api_blocked destructive HTTP / GraphQL call → blocked pre-bash operational_event install, config, and fail-mode notices # all events carry: tester_id, design_review_id, occurred_at # payloads scrubbed: hashes only (file_content_sha256, spec_content_sha256)
Append-only by design
Once an event is written, it cannot be edited or deleted. Not by you, not by FlowRail support, not by us. The constraint is enforced at the database with a trigger, not in the application layer; the app can't bypass it. When a regulator asks how a write got past your team, the lineage is what answers.
Audit configuration
Three retention depths per workspace, set on the security leader page. Minimal: stores verdicts and event metadata only; suitable for startups with sensitive code. Standard: adds finding evidence and guardrail diffs; the default for most teams. Full: retains LLM transcripts on every verify call; required for regulated industries (finance, healthcare) where reconstruction of the decision must be byte-faithful.
Reading lineage
Three ways. The dashboard at /reviews/<dr_id> shows the full thread visually. flowrail-lineage from inside Claude Code returns an ASCII tree without leaving the terminal. Or export the raw events as NDJSON from Settings, Export, useful for piping into Splunk, Datadog, or any SIEM you already run.
$ flowrail-export --since 30d --kind verification_completed > events.ndjson $ wc -l events.ndjson 41,288 events.ndjson
Workspace isolation
Every event carries the workspace it belongs to. Reads are filtered at the database, not the application. A misrouted query can't return another team's events. Cross-workspace access is unrepresentable.