Snag · FMEA for pull requests

How snag works

Snag applies FMEA — Failure Mode and Effects Analysis, the discipline behind failure analysis in aerospace and manufacturing — to a change. Instead of reading a diff line by line, it asks a structural question: what is supposed to happen here, and every way it could silently not?

Why a review misses these

Line-by-line review is good at what's on the screen: this null check, that off-by-one, this awkward name. But the failures that hurt most are about what isn't there — the unhandled disconnect, the retry that runs twice, the log that's lost on a hard kill. They don't live on any single line, so a reader scanning lines has no place to notice them.

Snag reframes the change as a Happy Path → Failure Map. The blue spine is what should happen, step by step. Everything branching off it is a way it can go wrong — enumerated deliberately, the way an FMEA walks each step and asks how it fails. The result is a map you can read, argue with, and commit.

Anatomy of a map

Each map is a failure-map/v1 JSON document. It renders as an interactive graph in the viewer, and it lives in git next to the code it describes.

A worked example

Here's a real map from the demo — Runner Protocol v1, generated from a protocol spec. The spine is the intended lifecycle; below it are the failure modes snag surfaced off that spine — the kind a spec review nods past.

Each one is a node you can open in the interactive viewer — with the path it branches from and why it matters. None of them is a single line you'd circle in review.

What makes it different