Human-in-the-loop
Accountability as a workflow step, not an inbox somewhere else.
Approval, correction, rejection, escalation and data collection happen inside the live execution, with the reviewer seeing the same data the workflow will act on.
The decision sits inside the run
Because approval is a node, the decision and the action it authorizes belong to the same execution record.
- and resume mid-execution
- Pauseand resume mid-execution
- workflows supported
- Long-runningworkflows supported
- reviewer access
- Role-basedreviewer access
- of decision and reason
- Full recordof decision and reason
The principle
Automation removes the typing. It should not remove the responsibility.
Most consequential processes have a point where somebody has to be accountable. The usual failure is putting that point outside the automation, in a mailbox or a ticket queue, where context is lost and progress becomes invisible.
The common pattern
Review outside the process
- Automation stops and emails a person
- The reviewer opens three systems to rebuild context
- The decision is recorded in a different tool
- Someone restarts the automation by hand
- The audit trail spans four places and one memory
The Nexus pattern
Review inside the process
- The run pauses at an approval node with state intact
- The reviewer sees assembled data, rule results and any model output
- The decision and reason are captured as structured fields
- The workflow resumes and performs the authorized action
- One execution record covers the whole transaction
Decision types
More than approve and reject.
Real review work involves fixing a value, asking for something missing or passing the case to a higher authority. Each of these is a distinct outcome with its own downstream branch.
Approve
Confirm the proposed result and let the workflow continue to the system action that follows.
Correct
Adjust extracted values or proposed parameters before continuing. The corrected version becomes the value the workflow uses.
Reject
Stop the proposed action and route the case down a rejection branch with the reason recorded.
Escalate
Send the case to a different role or authority level when it exceeds the reviewer's mandate.
Request more data
Collect additional information through a form, from a requester or from another system before the decision is made.
Return for rework
Send the case back to an earlier stage so the originating team can supply what is missing.
Execution model
Pause, wait, resume.
A workflow that has to wait for a person is a long-running workflow. That is a property of the engine, not something bolted on with a polling job.
The run waits, it does not end
When execution reaches a human node, the workflow suspends with its state intact. Nothing has to be reconstructed when the reviewer eventually responds.
Long-running by design
A decision that takes minutes and one that takes days are handled the same way. Processes that span shifts, weekends or an escalation chain remain a single execution.
Resume with full context
On response, the workflow continues from the same node with the earlier node outputs still available, so the write-back uses the data the decision was made against.
Timeouts and reminders
A pending decision can follow its own branch if it is not answered, which keeps stalled cases visible instead of silently ageing.
One record, start to finish
Because the pause is inside the run, the trigger, the retrieved data, the decision and the resulting action share a single execution record.
Reviewer experience
Give the reviewer everything the decision needs.
Decision quality depends on context. A review step that only shows a request identifier moves the work rather than doing it.
The case, assembled
The reviewer sees the values retrieved from each system, not a notification asking them to go and look somewhere else.
What the rules found
Deterministic check results are presented alongside the case, so it is clear which conditions passed and which triggered the review.
What the model proposed
Where a self-hosted model classified, extracted or summarized, the output is shown as a proposal that can be corrected.
Structured decision forms
Forms capture the decision and any additional fields the process requires, in a shape the workflow can act on directly.
Reason capture
The reviewer records why, which is what turns a click into evidence that stands up in a later review.
Decision history
Previous decisions on comparable cases are part of the record, which supports consistency across reviewers and over time.
Worked example
Rules first, model second, person last.
Deterministic checks eliminate the clear cases. The model interprets what rules cannot read. The reviewer decides, and only then does anything get written back.
- 01
Trigger
A credit limit increase request is submitted through a form and starts the workflow.
- 02
Integration
Connector and database steps retrieve the customer master record, current exposure and payment history.
- 03
Rules + Code
Deterministic checks run first: policy limits, outstanding disputes, arrears thresholds and required documentation. Clear failures are rejected without reaching a person.
- 04
Sovereign AI
A self-hosted model summarizes the account correspondence and flags themes the numbers do not show, such as repeated delivery disputes.
- 05
Human Approval
The credit officer sees the exposure figures, the rule results and the model summary together, then approves, adjusts the limit or rejects with a reason.
- 06
System Action
The approved limit is written back to the ERP and CRM, and the requester is notified.
- 07
Audit
The inputs, rule outcomes, model output, reviewer identity, decision, reason and write-back are retained together.
- 08
Escalation path
Requests above the officer's mandate route to a second approver rather than being approved at the wrong level.
Governance
Who may decide, and what the record shows.
A review step is only meaningful if the right person made it and the evidence survives.
Role-based access
Approval nodes are assigned to roles and groups, so authority follows organizational structure rather than an individual's calendar.
Workspace boundaries
Reviewers see the cases belonging to their workspace, which keeps sensitive processes separated across teams and business units.
Escalation levels
Thresholds route cases to the appropriate authority level, and the workflow enforces the routing rather than relying on a reviewer to pass it on.
Immutable run history
The decision, the person, the timestamp, the reason and the data in front of them at the time are retained with the execution.
Evidence for review and audit
When an outcome is questioned later, the answer comes from the run record, not from reconstructing events across several systems.
Institutional intelligence
Decisions become material for improving the process.
Every correction a reviewer makes is a signal that the rules, the prompt or the retrieval source did not match reality. Captured as structured data, those signals are usable.
- Stage 01
Capture
Decisions become structured data
Each approval, correction and rejection is recorded as structured fields rather than free text buried in a ticket.
- Stage 02
Review
Patterns become visible
Repeated corrections of the same field, or repeated escalations of the same case type, point at a rule that is wrong or missing.
- Stage 03
Refine
Workflows are updated deliberately
Teams adjust rules, thresholds, prompts, retrieval sources and routing in a draft revision, then test before publishing.
- Stage 04
Evaluate
Changes are measured against real cases
Recorded decisions provide the material to evaluate whether a change improved outcomes before it is trusted more widely.
- Stage 05
Extend
Proven cases carry less review
Where evidence supports it, a case type can move to lighter review. That is an explicit human decision, not something the system awards itself.
This is deliberate improvement carried out by your teams, not autonomous learning. Nexus records the decisions and makes them available. Changes to rules, prompts, retrieval, policies and any approved fine-tuning are made, tested and published by people who own the process.
Operation
Operating responsibilities.
Process owners define review points and use recorded decisions to test and approve workflow changes.
Owner-approved changes
Recorded decisions are evidence. They do not silently retrain a model or rewrite a rule. Every change is authored, tested and published by a person.
Review points follow policy
Process owners retain the review steps their policies require. Nexus presents the case context and records each decision within the run.
Existing case tools retain ownership
Where a dedicated case management or service desk system is the system of record, Nexus integrates with it rather than trying to displace it.
Architecture session
Bring us the approval nobody wants to own.
If a process stalls because a decision lives in an inbox, the fix is not a faster inbox. Show us the review step and we will design it into the execution, with context, routing and evidence attached.