A lot of infrastructure diagnostics work fails in the same place: the data exists, but it is scattered.
Logs sit in one tool. API responses in another. Dashboards show part of the picture. Someone stitches the context together under time pressure, then an AI layer is asked to produce a trustworthy answer on top.
SignalForge started from that gap. Collect and normalise evidence first. Add AI only where it helps triage, not as the whole product.
The Problem
A lot of "AI for operations" tooling leads with the assistant layer.
That skips the harder questions: where does the input come from, how is it compared across runs, and what makes the output defensible?
If collection is implicit, the tool can sound smart while staying hard to audit. In diagnostics, that becomes a trust problem fast.
The Context
I had already run into a closely related lesson while building PipelineHealer.
One of the strongest architectural choices there was keeping deterministic handling as the default for common CI failure modes and using model calls in narrower, policy-aware ways. That made the system easier to reason about and safer to operate.
SignalForge takes the same instinct into a different domain.
Instead of focusing on remediation, the current product line is centered on:
- evidence ingestion
- deterministic analysis
- compare workflows
- external collection
- operator decision support
That scope is intentional. Structured diagnosis comes before any claim of autonomy.
The Change
The public shape of SignalForge maps to that split:
- the control plane repo: Canepro/signalforge
- the live app: signalforge.canepro.me
- the runtime lane: Canepro/signalforge-agent
- the collection lane: Canepro/signalforge-collectors
That separation is useful because it makes the boundaries more legible:
- what collects evidence
- what runs analysis
- what supports operator workflows
- where AI belongs, if it belongs at all
The goal is inspectability, not a chatbot surface that hides the pipeline.
Here is the kind of diagnostics surface I want this product line to make normal: a clear overview, inspectable run detail, and compare workflows that help an operator reason about drift instead of guessing.
Live SignalForge overview showing recent runs, sources, and operator entry points.
Live run detail page showing findings, operator signals, and analysis metadata for a specific target.
The Hard Parts
The hard part is saying no to a model-first story.
That narrative demos well: it sounds autonomous, it fits a short clip, it markets easily.
It also blurs evidence, reasoning, and guesswork. For ops tooling, that blur erodes trust quickly.
Collecting evidence explicitly, making structured analysis useful on its own, and keeping compare workflows human-readable is slower to sell. It is also easier to verify.
What Changed
Public artifacts are still early, but they line up:
- Live app at signalforge.canepro.me
- Repos split by role: control plane, agent, collectors
- Compare view in the app shows drift between runs (screenshot below)
A compare view beats marketing copy here because it shows what "drift" means in the product, not in a slide.
Live compare page showing the product’s drift-analysis path from one run to the next.
What I Would Keep
Keep collection and structured analysis as the foundation. AI stays optional and narrow.
What I Would Change
Ship proof faster:
- More screenshots of live flows
- One architecture diagram on the repo
- Keep README boundaries aligned with what each repo actually does