SignalFlow

SignalFlow began with a practical failure of visibility: a 72-node n8n workflow took 115 seconds, and the execution log could show node durations without explaining what actually blocked completion.

The system reconstructs an execution graph from observed timing, finds the critical path, scores bottlenecks with measured evidence, groups recurring failures by meaning, and turns those findings into recommendations tied to the exact executions that triggered them.

Explore the public repository.

The operating problem

The slowest node is not always the bottleneck. A long task that runs in parallel may have no effect on total completion time. A shorter task on the critical path can hold everything behind it.

A useful profiler has to answer a harder question: what actually delayed completion, how often does it happen, and which evidence justifies fixing it first?

My role and scope

I defined the product, built the Next.js interface and FastAPI analysis service, designed the PostgreSQL and pgvector model, implemented the evidence and recommendation paths, and ran the audit and controlled optimize loop.

The work covered product framing, workflow data normalization, graph analysis, recommendation design, semantic error clustering, local deployment, and the proof needed to distinguish a working system from a convincing dashboard.

The system decision

SignalFlow uses the least ambiguous tool for each question.

• Critical-path analysis uses topological sorting and dynamic programming.
• Bottleneck ranking uses a four-factor score based on duration, criticality, frequency, and variance.
• Recommendations come from 37 deterministic rules and link to the execution evidence that fired them.
• Machine learning is reserved for semantic error clustering, where differently worded messages may mean the same thing.

An LLM is not asked to guess the critical path. Analysis is repeatable before explanation begins.

How the system works

SignalFlow imports an n8n workflow and its execution data, normalizes version-dependent payloads into a stable event model, reconstructs the execution dependency graph, and stores the evidence needed by the analysis layer.

The interface then exposes the critical path, bottleneck ranking, execution waterfall, recurring error groups, and recommendations. A recommendation is not just copy. It includes confidence, risk, estimated impact where available, and a link back to the runs that support it.

Operating boundary

SignalFlow is local software. Supabase runs through Docker, the embedding model runs locally, and there is no hosted deployment. The backend has no authentication layer and must not be exposed to the public internet without one.

The system recommends changes but does not auto-apply patches to a workflow. That keeps the evidence and the decision separate.

Evidence and verification

The end-to-end optimize loop used a controlled 28-node content pipeline with fan-out, a legacy API chain, polling, and a six-iteration Claude loop. SignalFlow profiled the baseline, its recommendations were applied, and the same workflow was run and imported again.

Each demo workflow ran three times and produced the same rule findings each time. The backend has 19 test suites across the core analysis paths, local database behavior, real schema shape, error clustering, and safety checks.

The audit also found and fixed a live scoring bug that displayed some priority scores as 250 out of 100. Tests that appeared to pass without meaningful assertions were corrected rather than counted as proof.

Limitations and what remains unverified

• Critical-path edges are inferred from finish order. Genuinely parallel branches can occasionally be chained together.
• The controlled optimize loop is a demo result, not a customer performance claim.
• The system is import-based and local. Real-time monitoring is not complete.
• There is no authentication, hosted service, team access model, or enterprise control layer.
• Multi-platform adapters beyond n8n remain future work.

What the system demonstrates

AI workflow development does not mean placing a model at the center of every decision. It means using deterministic analysis when the problem has a correct answer, machine learning where meaning is the problem, and visible evidence wherever trust is required.

Repository and technical artifacts

• Explore the public repository
• Read the controlled optimize-loop record
• Inspect the historical V1 specification
• Review the security boundary
• Inspect the 37 recommendation rules

The repository is MIT licensed and includes the application, database migrations, demo builders, controlled-run documentation, and test suites.