How verification works
A step is verified only when it ran on realistic data and its output was judged correct. Covers fixture runs, trigger captures, previews, and revocation.
Most AI builders stop at "the graph looks right." MadMax's bar is higher: a step is verified only when it has run on realistic data and its output content was judged correct. This page is what that means mechanically.
The proof ladder
Different steps need different proofs; the verification run picks the strongest one available:
- Fixture runs: read-safe steps (logic, transforms, AI steps) actually execute against realistic inputs; branch steps get both branches exercised. The output is judged semantically, so an AI step that returns an empty object fails, even though nothing crashed.
- Real captures: trigger steps verify against a real sample: the webhook URL gets a test delivery, the form gets one submission, the upload gets one file. The sample window opens right in the chat when it's your move.
- Previews: steps that would send externally (Slack posts, emails, API writes) are verified by previewing the exact request without sending it. Nothing fires for real until activation.
- Human stops: a missing connection, a real sample only you can provide, or a real missing thing (a workflow, a store, a base that doesn't exist yet) land on you as a visible ask.
When only a human can provide the proof, the row says exactly what it needs.
What the canvas tells you
- Faded node: planned, not yet proven (only plan-linked steps fade; your manual drops stay solid).
- Amber ring: the step being verified right now.
- Green check on the row: proof landed.
- Red halo: the last run of that step failed; fixing the config clears it on the next pass.
Proof revocation
Evidence is honest: editing a verified step revokes its proof. The row demotes, the next run re-verifies it, and downstream steps whose inputs changed re-verify too. That's not friction; it's the reason the green checks are trustworthy.
The loop, and where it stops
Max drives the verification: the server runs it once after the build, then Max calls it himself (read the report, repair what it names, run again) until every row passes or belongs to you. Two things keep that honest. The third identical failure on a step stops the automated repair and hands the row to you as a question. The failure signature survives config edits on purpose, and clears only when the step passes, when a verified row is demoted, or when a missing connection lands. And a turn that ends with rows still unverified and nothing changed puts a notice on each ("reply to continue, or press Verify"), because silence is never an end state. The spend checkpoint is the only other brake.
FAQ
Did my Slack message actually send during the build? No. External sends verify by preview. The first real send happens after you activate.
Why did a green step turn gray again? You (or an edit) touched it, so the proof was revoked and a re-verify queued.
Where to go next
- Build mode & the plan
- Testing before activation: the same machinery, driven by hand.