FlowScan v2.0 Overview

This is the reference document for how FlowScan v2.0 scores a workflow. Each of the seven categories has its own article going deeper on its specific findings; this page covers the mechanics that apply across all of them — what the analyzer can and can't see, how the 0–100 score is calculated, the caps that override the math, and the two supporting structures (Cost Exposure Score, Controls Matrix) that sit alongside the health scores.

What FlowScan analyzes

FlowScan is a static analyzer. It reads an exported workflow or scenario as JSON — nodes, connections, parameters, error settings — and evaluates structure. It does not execute the workflow, and it has no access to execution history, logs, live credentials, or actual run frequency.

That's a real constraint, and it shapes what a finding can and can't claim. FlowScan can report that a webhook has no authentication configured. It cannot report whether that webhook has been hit by anyone malicious. It can report that an AI agent has write-capable tools and no iteration limit. It cannot report that the agent has actually misbehaved. Every finding describes a structural pattern and its associated risk — not an event that happened.

The seven categories

A workflow is scored across seven categories. Each one starts at 100 and is reduced by its own findings. The seven category scores combine into a single weighted total:

Category	Weight	What it measures
Reliability	0.35	Whether the workflow keeps working under retries, partial failures, and malformed data
Cost Risk	0.20	Where AI/API spend can multiply unexpectedly
AI Governance	0.15	How much autonomy an AI agent has been given
Observability	0.15	Whether a failure would be noticed without manual investigation
Security	0.10	Exposure of credentials and unauthenticated public entry points
Naming	0.025	Whether the next person to open the workflow can understand it
Complexity	0.025	Whether the workflow has grown past what one person can safely reason about

Reliability alone carries more weight than Cost Risk, AI Governance, and Observability combined — a workflow that silently duplicates a write is treated as a bigger production risk than one with generic node names.

How your score is calculated

Each category starts at 100 (clean) and cannot drop below 0. Every finding in that category subtracts a fixed number of points based on its severity:

Severity	Points deducted
Critical	−30
High	−15
Medium	−8
Low	−3
Info	−1

For example, a category with one high-severity finding and two medium-severity findings loses 15 + 8 + 8 = 31 points, landing at 69. The seven resulting category scores are then combined using the weight table above to produce the total.

Hard score caps

Three specific combinations of findings override the weighted math entirely, because they represent risk severe enough that no amount of "everything else is clean" should offset them:

1. Retry without idempotency, next to a financial write. If a workflow retries a step on failure with no way to detect whether the first attempt already succeeded, and that step sits near a financial write (a charge, a refund, a payout), Reliability is capped at 50 regardless of the category's calculated score.
2. A write-capable agent with no iteration limit. If an AI agent has critical-severity write-tool access and has no cap on how many reasoning iterations it can run, AI Governance is capped at 35.
3. A partially-guarded write chain, next to a financial write. If a multi-step write chain has some steps protected against duplication and others not, and the chain touches a financial write, the overall total is capped at 50 — this one caps the total directly, not just a category.

If your total looks lower than your individual findings would suggest, one of these three scenarios is almost always why.

Cost Exposure Score

Health scores measure cleanliness: 100 is good, 0 is bad, and the math is a straight subtraction. The Cost Exposure Score is a different kind of number, and it moves in the opposite direction: higher means worse.

It's built from 12 independent risk factors — model tier, prompt size, loop multiplier, retry multiplier, agent iteration risk, agent tool-call risk, output-bound risk, data concentration risk, unnecessary-loop risk, high-frequency-trigger risk, chained-LLM risk, and poll-without-filter risk — each scored 0–3, for a combined maximum of 36. Bands: 0–2 low, 3–5 medium, 6–9 high, 10+ critical.

The reason this exists separately from the Cost Risk health score: a health score can only subtract so much for any single finding, which flattens out combinations. A workflow running a premium model inside a loop with no output cap has three compounding multipliers stacked on top of each other — a materially worse spend profile than any one of those alone, even if the category deduction looks similar. The Cost Exposure Score is built to surface that stacking. See the Cost Risk article for the full breakdown of each factor.

Controls Matrix

Before individual findings, the report leads with nine present/partial/missing/n·a checks — a fast read on overall safety posture:

• error_workflow — is an error workflow attached?
• retries — do external calls retry on failure?
• timeouts — do external calls have timeouts?
• idempotency_guard — is there a guard in front of writes to prevent duplicates?
• empty_state_branch — do conditional branches have a default/empty-state path?
• ai_token_cap — is there a token/output limit on AI calls?
• structured_ai_output — does AI output get parsed into a structured format before use?
• audit_log — is there a log of consequential writes?
• dedupe_before_write — is there de-duplication before a write?

Each control is marked present, partial, missing, or n/a (a workflow with no writes doesn't need a dedupe guard). These map directly onto findings in the Reliability, Cost Risk, Observability, and Security categories.

Production Impact Tier

Every finding also carries a Production Impact Tier — critical, high, medium, or low — separate from severity. Severity describes how bad a pattern is in the abstract; impact tier describes how bad it is given what it's connected to. A missing retry on a read-only lookup and a missing retry on a step that charges a card are the same underlying pattern, but the second gets a higher impact tier because the blast radius is larger. Financial, destructive, and public-facing writes escalate the tier; anything inside a loop escalates it further; read-only operations pull it back down. This tier — not raw severity — determines the ranking of "Break Points" and "Prioritized Fixes" in a report.

Our scoring philosophy

Every finding is built around one test: would an experienced n8n developer, looking at a production incident, point to this finding as the cause? If a pattern doesn't clear that bar, it either doesn't ship as a finding or ships at reduced confidence.

The same discipline governs the language findings use. Descriptions use "risk," "likely," and "detected pattern." They do not use absolute claims like an exact failure rate or a dollar cost per month — static analysis of a JSON export can describe the shape of a risk, not its precise price, and a claim more specific than the evidence supports is a worse failure mode than an appropriately hedged one.

Category reference

• Reliability — error handling, idempotency, branching integrity, chain failure risk, structural hygiene
• Cost Risk — loop multipliers, oversized prompts, missing token caps, chatty agents
• AI Governance — write-capable agents, prompt-injection-shaped paths, shadow AI
• Observability — audit logs and execution summaries for consequential writes
• Security — webhook authentication, hardcoded secrets
• Naming — generic and duplicate node names
• Complexity — node count and path depth thresholds