The engine decides. A human handles the calls it flags.
Most decisions should run automatically; a few should not. Swiftward sends the calls the engine flags to a person, and that person's decision becomes part of the same auditable record as everything else.
How it works
A rule can open a review case with a priority, an owner, an escalation chain, and an SLA timeout. A reviewer approves, rejects, or escalates. The resolved decision then re-enters the engine as its own event, so the human's call is evaluated, recorded, and replayable exactly like an automated one. The human's call lands in the same trace as every automated one.
Configured, not coded
The review workflow is yours to shape without writing code: the queues, the screens a reviewer sees, who is allowed to act, the statuses a case moves through, the escalation paths and the SLAs, all declared as configuration on Swiftward's platform. It behaves like a task tracker built for your exact review, because that is what the declarative platform lets you stand up in an afternoon instead of a sprint. And if your team already lives in an external tracker, route cases there instead: a webhook or API call hands the case to your own system and takes the resolved decision back into the engine. Standard integration, not a custom build.
Why it matters
This is what lets you tighten a policy without breaking production. Borderline cases that you are not ready to auto-block go to a queue instead of failing silently or sailing through. And when a regulator asks who approved something, the answer is in the same place as everything else.