A gated chain is a workflow with a decision built into it: the routine case runs straight through to a result, and the case that trips a rule stops and waits for a person. Nothing about that split is implicit. The rule that decides which path a case takes is written down, versioned, and the same rule runs every time, for every case, so the exception queue holds exactly the cases that need a human and nothing else.
This page walks through how that gating works, why "auto-decisioning" is not the same claim as "fully automated," and points at the shipped workflows, mortgage preflight, adverse action, decision logging, that already run this way.
Regulated decisioning has always had to answer one question for every case: does this go through as-is, or does a person have to look at it? The traditional answer was to route everything through a person and let experience trim the queue. Full automation flips that into routing everything through code and hoping the code is right. Neither answer is what an examiner actually wants to see.
A gated chain answers the question a different way: the routing rule itself is the artifact under governance. It is written down before any case runs through it, it is the same rule for every case, and every case, whichever branch it takes, leaves a receipt that says which rule fired and why. Straight-through processing under a gate is not "no human in the loop." It is "the human wrote the loop, and only sees the part of it that needs them."
A gated chain is an ordinary OpenChainGraph chain (a sequence of deterministic nodes) with one node in the middle whose output includes a routing decision, not just a result. Everything downstream of that node forks on the decision. The diagram below is the shape every gated STP chain in the suite shares.
The gate node is not special machinery. It is the same kind of deterministic node as everything else in an OpenChainGraph chain, which means its output carries an execution_hash like any other, and it can carry a groth16 compute-integrity proof under the same ยง18 profile described in the compute-integrity explainer. What makes it a gate is only that a downstream chain edge reads its next field and routes on it.
Because the routing decision is compiled from a signed Work Mandate (scope, thresholds, escalation triggers, set by a human before any case runs), auto-decisioning here means the machine executes a human's standing instruction quickly and consistently, not that the machine decided the policy. The passkey that closes an escalation is the same human accountability the Mandate Loop closes with everywhere else in the suite.
The gated-chain pattern is not a proposal: it is how the mortgage, fair-lending, and AI-governance waves already run in the live suite. Three concrete examples, each a real, shipped node.
| Workflow | Routine path | Gate that escalates |
|---|---|---|
| Mortgage TRID/QM preflight | compute_trid_tolerance_cure and check_qm_points_and_fees clear the loan for closing disclosure | A tolerance breach or a QM points-and-fees cap miss routes to underwriting review before cure timelines run out. |
| Fair lending / HOEPA-HPML | compute_hmda_rate_spread confirms the loan is outside high-cost thresholds | test_hoepa_high_cost and test_hpml_escrow flip the rate-spread or escrow flags, forcing a compliance hold instead of a straight close. |
| Adverse action | An approved application proceeds to funding | A decline routes into build_adverse_action_notice / validate_adverse_action_notice, so the ECOA notice is generated and checked before it ever reaches a customer. |
Every one of these leaves an artifact behind either way, and the AI-governance wave adds a fourth layer on top: build_ai_decision_log_record turns the gate's own routing decision into an EU AI Act Article 12-shaped log entry, so "which rule routed this case, and when" is itself an auditable record, not something reconstructed after the fact from application logs.