Assertions
Verify outcomes with inline assertions and Assertion nodes — warn, fail, or fatal.
Assertions are how a flow proves the app did the right thing. Cofactor checks them two ways: inline assertions that ride along with an action, and Assertion nodes that stand on their own in the path.
01Inline vs. node
Use an inline assertion when the check belongs to the action that triggered it — "after I click Save, a success toast appears." The check runs immediately after the action completes, in the same step, so the verification stays tied to its cause.
Use an Assertion node when the check is its own step — a standalone verification between other steps, or a check that doesn't follow directly from one action. Add it from the node menu like any other node.
Both evaluate a condition you write in plain language, such as "Ticket appears in the list."
02Severity
Severity decides what a failed check does to the run.
| Severity | Behavior | Available on |
|---|---|---|
| Warn | The check didn't pass, but the flow continues and records a warning | Inline + node |
| Fail | The check didn't pass and the run is marked failed | Inline + node |
| Fatal | The check didn't pass and the run stops immediately | Inline only |
- Use Fail for checks that must pass before the rest of the flow is meaningful.
- Use Warn for non-blocking checks that still matter — flag an unexpected UI state for review without failing the whole run.
- Use Fatal (inline) when continuing past the failure would be pointless or misleading.
03Dynamic content
Assertion conditions support variables and macros — type $ to insert them. For checks against content that changes every run (timestamps, live feeds), enable Always use agent evaluation so the assertion re-evaluates fresh each run instead of reusing a cached result.
04Reading results
Assertion outcomes appear directly on the relevant steps in run details, with a per-run summary of what passed, warned, or failed. A warn marks the step as a warning and the run continues; a fail (or fatal) marks the run failed.
05Best practices
- Prefer inline assertions when a check directly follows one action — it keeps cause and verification together.
- Reserve Assertion nodes for standalone or multi-step verification logic.
- Don't over-assert: a few meaningful checks beat many brittle ones. See Designing a good test.
- Reach for Warn before Fail when you're unsure whether a state is truly broken.