SAX Assert Pipe

Pipe-based workflows in SAX_Bridge are great right up until they're not. Everything travels down one PIPE_LINE wire, which means the exact value that's silently wrong - the CFG that got overwritten, the LoRA that never applied - is hidden inside a dict you can't see. SAX Assert Pipe is the tool that reaches into that bundle, pulls out one field, and verifies it before it poisons the rest of the graph.

It's the same idea as SAX Assert, aimed at a pipe. You hand it the pipe, tell it where to dig (path), and it checks whatever it finds against the mode/expected pair. Fail, and the run stops with a clear message instead of a mysterious blank output three nodes later.

How it works

The key input is path, written dot-separated: loader_settings.steps, seed, images, applied_loras. The node walks each segment trying, in order, a dict key lookup, an attribute access, then an integer index - so it copes with plain dicts, objects, and lists. If a segment can't be resolved, it raises an error that lists the available keys or attributes at that level, which is a handy little introspection tool in its own right.

Once the field is extracted, the checks are identical to SAX Assert: not_none, is_none, equals, contains, matches (regex), greater_than/less_than, in_range, length_equals, has_key, and so on, with the same auto-parsing of expected (numbers, booleans, null, comma lists). label is just the tag shown in the PASS/FAIL status.

Where it earns its keep

• path="loader_settings.steps", mode="greater_than", expected=10 - catches the case where a custom path rebuilt the pipe and loader_settings fell back to its defaults (20 steps / CFG 8 is the fallback when the pipe is missing these keys).
• path="seed", mode="not_none" - makes sure your seed made the trip through whatever switcher or collector you routed through.
• path="images", mode="not_none" before the output node, so you never save a blank image because a decode_vae=False sampler output silently skipped the decode.

The most useful habit: park one after any node that modifies the pipe (SAX Pipe, a switcher, the LoRA loader) and assert the one field that node is supposed to change. That's the real job here. The whole design of a context bus trades forty visible wires for one opaque bundle - the KB's plumbing doc calls the failure mode "stale context," where the wire is connected but the contents are wrong. Assert Pipe is the antidote: cheap, explicit checks that tell you the contents are right before you find out the hard way.

The catch

There's no output - it's a terminal node, so it sits on a side branch, not in the data path. And it's only as useful as the path you give it. Typing loader_settings.steps wrong gives you a confusing error, though at least that error shows the actual keys, so it's a self-correcting typo. If you're brand new to SAX_Bridge, run SAX Debug Inspector first to see what a real pipe contains, then build your assert paths from what it printed. That combo - inspect once, assert forever - is the workflow you'll settle into.