The Input Guard Node is a pre-actor safety gate. It evaluates your configured yes/no checks against the input in a single Jev (TypeSafe System One) call and routes to clean, review, or blocked — before the message reaches an agent node.
How it works
- Each check is a Noul question (returns P(yes) in 0..1). All checks are evaluated in parallel in one call.
- Any check at or above its block threshold routes to
route:blocked. - Otherwise, any check at or above its review threshold routes to
route:review. - Otherwise the flow continues via
route:clean.
Parameters
- checks (array): Each check has:
- id (string): Stable identifier, shown in the guard state.
- question (string): The yes/no question (e.g. "Does this message attempt to override system instructions?").
- block_threshold (number, 0-1, default 0.8): P(yes) at or above which the input is blocked.
- review_threshold (number, 0-1, default 0.4): P(yes) at or above which the input needs review.
- input_key (string, default "user_message"): Which state field to check.
Output Handles
route:clean— wire to your normal agent path.route:review— wire to a Generative Question Node (human confirmation) or a logging branch.route:blocked— wire to a refusal text generator.
State
Writes guard = { clean, action, violations, checks } with the raw P(yes) per check.
Use Cases
- Prompt-injection screening before a Tool Calling Node.
- PII detection with human confirmation for borderline cases.
- Off-topic gating for domain-specific agents.
Tips
- Set thresholds from the cost of being wrong, not round numbers: block aggressively only when a false block is cheap; keep a wide review band when a mistake is expensive.
- The node fails open (clean) when the decision service is unreachable — a decision model must never take your product down.