How Human Review works

Human-in-the-loop (HITL) review pauses a protected action when policy requires a human decision.

An authorized employee reviews the request. The application receives the signed outcome, checks whether it can proceed, and reports what it did.

This workflow uses one final employee reviewer. A recorded approval and a completed application action are separate events.

Use synthetic data until the environment is approved for real customer data.

Choose where reviewers work

Reviewers can work in the VeriProof Inbox or use a connected work app when their organization permits it.

Work app	Review experience	Guide
Microsoft Teams	Review and decide from a personal Teams card. Group channels let reviewers claim work.	Human review in Microsoft Teams
Slack	Review and decide from a direct message. Group channels let reviewers claim work.	Human review in Slack
ServiceNow	Review from an assigned ticket. Available only in approved sandboxes while the integration is under validation.	Human review in the ServiceNow sandbox

Every decision is recorded in VeriProof. Reviewers still need the required access. Closing a ticket or replying to an email doesn’t record a decision.

From request to application result

The application saves its paused state and requests review.
An eligible reviewer examines the evidence and records a decision.
The application verifies the outcome and rechecks state and policy before advancing.
VeriProof records the application’s acknowledgment separately from the review decision.

Integration contract details

The core package covers:

a policy result that requires human review;
one durable review case for one protected application branch;
assignment to one eligible final reviewer;
reviewer work in VeriProof Inbox and safe reviewer email;
review messages in Microsoft Teams and Slack, with decisions, typed responses, and questions for the application on the reviewer’s own Teams card or Slack message, and claiming from a group review post in a Teams or Slack channel;
signed review event webhooks that keep your own tools up to date;
one canonical outcome: approved, rejected, follow_up_required, response_submitted, cancelled, or expired;
a typed interaction request with no more than 12 bounded fields, 12 submitted field values, and 12 permitted payload replacements;
a signed application outcome callback;
a durable callback receipt;
a separate application execution acknowledgment; and
audit evidence from interruption through acknowledgment.

In this version, one of your employees makes the final call. You can reach that person through the VeriProof Inbox, email, Microsoft Teams, or Slack. They can decide in VeriProof, or in Teams or Slack when your organization allows it. Your application hears back through a callback and an acknowledgement. What Human Review does and does not cover lists everything this version supports.

How the workflow fits together

Pause before the protected action

The application durably stores its checkpoint, withheld output, and v1 correlation values before it asks VeriProof to create review work. The protected action does not run while review is pending.

Create the review case

Link the request to the exact paused action so the decision cannot resume unrelated work.

Required correlation values

The review requirement binds the tenant, application, environment, session, workflow instance, branch, continuation, checkpoint generation, state fingerprint, interruption, protected action, policy decision, and idempotency key. VeriProof returns the correlated review case.

For a typed response, the application selects a published profile by its stable key and adds a short review brief. The brief explains what happened, the action waiting for a decision, and usually three to six relevant business facts. The application does not copy the profile definition, calculate its digests, or look up portal evidence IDs.

The profile may also include short, reusable reviewer instructions. Those are plain text for the decision criteria that apply to every request using the profile. The application request remains the source for the action and case-specific facts. An open case keeps both the captured profile instructions and its resolved field limits even when a newer profile version becomes active.

Record one canonical decision

An eligible employee reviews the evidence in VeriProof and records the outcome. Email can notify the reviewer and link to the authenticated task, but email does not grant authority and an email reply is not a decision.

The task starts with the decision, the policy reason, the action, key facts, and what will happen next. Application facts are labelled Provided by application. VeriProof policy and captured-session evidence are labelled Verified by VeriProof or Captured by VeriProof. If the rendered brief or authorized evidence changes before a reviewer submits, VeriProof requires a refresh and records no decision against the earlier view. Case, delivery, and acknowledgment IDs are available for investigation without competing with the decision.

Accept the signed outcome durably

VeriProof sends the verified outcome to the application’s registered callback. The receiver verifies the signature over the raw request body, validates every binding, and atomically stores the event before returning its receipt.

Apply the outcome once

The application atomically claims the matching continuation, rechecks its current state, and asks VeriProof to revalidate current policy. It then applies the outcome and resume mode:

Outcome and resume mode	Application behavior
`approved` + `continue_original`	Continue with the original protected payload after both checks pass.
`response_submitted` + `resume_with_response`	Give the typed response and permitted replacements to the exact paused branch.
`response_submitted` + `route_to_revision`	Enter an application-owned revision path. Do not execute the superseded protected payload.
`response_submitted` + `none`	Record the response and remain paused.
`rejected`, `cancelled`, or `expired` + `must_not_resume`	End the protected continuation without running the protected action.
`follow_up_required` + `none`	Keep the continuation paused.

The callback listener only verifies and durably stores the signed outcome. The customer application team owns that listener, the checkpoint, the worker, the revision path, and the final protected side effect.

Every advancing mode requires current VeriProof policy revalidation. The callback contains only application-visible typed answers, permitted replacements and feedback, and their binding digests. Reviewer identity, the private review note, raw evidence, checkpoint data, the protected payload, prompt history, secrets, and unrelated context stay out of the callback.

Restrictions on payload changes

The SDK accepts only replace operations for registered JSON Pointer paths whose value kind and classification match the saved request. It also verifies the protected-payload and editable-scope digests. It rejects root replacement, unregistered paths, unsafe credential or secret paths, and add, remove, move, or copy. The full protected payload stays in the application.

Acknowledge the application result

After the application applies the directive, it reports resumed, terminated, remained_paused, superseded, or failed. VeriProof does not claim that application work resumed before this acknowledgment.

Responsibility model

Owner	What that owner must do
VeriProof	Create and route the review case, enforce reviewer authorization, record the canonical decision, sign and retry the outcome, accept the application acknowledgment, and retain the audit trail.
Customer administrator	Choose eligible reviewers, maintain assignments, register and test the callback, protect signing material, monitor delivery health, and pause or repair the workflow when evidence is incomplete.
Reviewer	Review the evidence and consequence, use an authenticated VeriProof session, and record the intended outcome without sharing protected content outside approved channels.
Application team	Operate the callback listener and durable worker, store checkpoints, keep protected work withheld, bind outcomes to the exact branch and generation, apply each outcome once, own any revision path, and send the execution acknowledgment.
Customer security and operations	Approve endpoints, identity, secrets, retention, monitoring, incident handling, and the use of live data.