What ships
FlowRail is built as a set of interlocking capabilities. Each has its own page; together they cover the SDLC from intent to incident.
1. Design review read the spec, predict threats, open a review id 2. Guardrail engine policy framework: OWASP, framework, compliance, custom 3. Pre-write verifier block risky writes before they land 4. Dependency integrity gate installs on supply-chain signals 5. Scanner orchestrator ingest scanner findings, contextually filtered · v1 6. Triage & feedback auto-triage with guardrail-escape detection · v1
What ties them together
In v1, every component writes to the same threat graph, scoped by design_review_id. A finding from your scanner can be traced back to the design-time threat that should have caught it; a guardrail can be tightened automatically when its escape rate climbs. The graph is what makes them more than the sum of their parts. Today, every decision already lands in the append-only audit lineage, threaded by the same design_review_id.
Three audiences
Developers: ship faster without security friction. Pre-write feedback in seconds, not post-deployment surprises.
Security teams: in v1, query the threat graph for triage, dashboards, and audit. "Show me all live code derived from threats we flagged in Q1." "What's our guardrail escape rate by category?"
Security leaders: in v1, tune the autonomy slider. Guardrail enforcement (hard block, soft block, advisory). Auto-triage verdicts (autonomous, notify, human-approves). Guardrail updates (confidence-based auto, notify, always-approve).
What FlowRail is not
Not a SAST tool (we'll orchestrate Semgrep in v1; we don't replace it). Not a vulnerability scanner (we ingest findings; we don't generate them). Not a code review tool. Scanning is commoditizing; the value is in knowing what to scan, how to triage, and when to act. That's the decision layer we ship.