ZMongo Content Pack Get Boolean

Not every stored parameter is a number or a prompt. Sometimes it's a flag - "hires fix on", "watermark off", "upscale enabled". Get Boolean pulls those true/false values out of a content pack by alias, and it's the least forgiving of the Get family about what counts as a real boolean, so it's worth knowing how it thinks.

The lookup is standard: content_pack in, field_alias (alias, source path, label, or numeric index) to find the field, strict_type to gate the check. default_value is a string whose truthiness gets parsed - the strings 1, true, yes, and on count as true; everything else is false.

The quirk that matters

With strict_type on (the default), the node only returns a value if the stored field is a genuine boolean. If the field exists but was stored as a string or int, you get found: false and the default - it won't guess. Flip strict_type off and it gets permissive, coercing string values through that same 1/true/yes/on truthiness test. The asymmetry is deliberate and it's the same design as the numeric getters: strict mode is a contract ("the pack stores real booleans"), loose mode is a convenience ("just give me a truthy answer").

This matters in practice because of how JSON classifies things. JSON has a real boolean type, but the value also could arrive as 0/1 or "yes"/"no" depending on where your source data came from. If you Build a pack from a document that stores flags as strings, the node will classify them STRING, and a strict Get Boolean will reject them. Either normalize your source JSON to real true/false, or run this node with strict_type off.

Outputs

value (BOOLEAN) feeds conditional logic downstream - a switch, a compare, a router node. field_info_json is the field record for debugging. found (BOOLEAN) tells you whether the field existed and matched; when it's false you're on the default_value path. Pure in-memory read, no session, no network.