FaultTrailSupport → trace
Early pilot
In development · Pilot teams wanted

The AI was wrong.Make it debuggable.

FaultTrail is building a way for AI SaaS teams to turn a customer report into the traces, context, and clear engineering issue needed to investigate it. People review every handoff.

Email the founder Browse free resources
Built forAI SaaS · RAG · agents · developer tools

Start with workflow details only. Do not email tickets, traces, credentials, personal information, or confidential customer content.

FT / ILLUSTRATIVE INVESTIGATION
Not a product screenshot
SUPPORT TICKET · FICTIONAL COMPANY14:32 UTC

“The assistant says INV-1042 is unpaid, but finance says it was paid last Thursday.”

!Duplicate payment reminder nearly sent
Suspected failure
Retrieval / stale data
Low confidence
✓Source recordInvoice status: paid
?Trace neededTool call + response
Engineering issue

Finance assistant incorrectly reports paid invoice as unpaid

ai-assistantdata-freshnessneeds-trace
Customer symptomEvidence trailFixable issue
Support reports the symptom→FaultTrail follows the Evidence→Engineering reviews the trail

01 / WORKFLOW

From “something feels wrong” to a credible investigation.

This is the workflow FaultTrail is building. It shows the intended process, not a product you can connect to or use today.

STEP 01

Start with what the customer saw.

Keep the original report, plus the details support already has: account, feature, time, interaction, and impact.

+Start with the symptom · no diagnosis needed
01FAULT
TRAIL
signalevidenceaction

02 / THE REPRO PACK

A structure for the questions engineering usually asks.

A Repro Pack keeps the customer report, supporting details, possible causes, open questions, and next engineering step in one reviewed handoff.

01
Complaint distilled
Customer impact, user intent, and the exact symptom without losing the original report.
02
Expected vs actual
A crisp behavioural delta tied to a source of truth - not a generic quality complaint.
03
Failure classified
Retrieval, prompt, model, tool, memory, permission, policy, latency, or expectation.
04
Evidence mapped
What is attached, what is missing, and the next questions for support or engineering.
05
Issue drafted
A specific title, body, labels, and owner hint ready for Linear or GitHub.
06
Regression prevented
A concrete eval or test candidate designed to catch the same failure next time.

03 / PLANNED CONNECTIONS

Planned to fit the tools your team already uses.

We are not connected to these tools yet. Our first integrations will be shaped by the systems pilot teams rely on most—not a long, generic connector list.

Planned report sources
ZendeskIntercomProvider escalationAPI / webhook
FaultTrailproduct in developmentPlanned connections · not live
Details to check
Conversation / runTracesLogsReleases
Planned destinations
GitHubLinearEval draft

04 / EARLY PILOT

A direct product conversation, not a mailing list.

FaultTrail is looking for a few AI SaaS teams to test whether this approach fits their support-to-engineering process. There is no self-serve product or live integration to sign up for yet.

WHO THIS IS FOR
Pilot teams
  • A 2–50 person AI SaaS team with a customer-facing AI feature or agent.
  • Customer-visible failures regularly pull engineers into reconstruction work.
  • Execution Evidence exists in provider traces, logs, runs, or source records.
WHAT WE WOULD TEST
Five historical incidents
  • Start with five anonymised historical incidents—not live customer ingestion.
  • Map one place reports arrive, one source of run data, and GitHub or Linear.
  • Compare the supporting details, open questions, and draft issues with the team’s current handoff.

START WITH THE WORKFLOW

Tell the founder where the handoff breaks.

Describe the product, where incidents arrive, where execution Evidence lives, and which issue tracker engineering uses. This starts a direct conversation; it does not subscribe you to a marketing list.

Email the founder

Prefer to compose it yourself? Write to faulttrail@gmail.com.

Do not send tickets, traces, credentials, personal information, secrets, or confidential customer content. A safe process can be agreed first.