Core Human Review by role

Administrator

Administrator

Before publishing the workflow:

1. Confirm the application owner and the people eligible to review.
2. Choose the required capability: canReviewSessions or canApproveSessionReviews.
3. Confirm which eligible person or group receives work when the primary assignment is unavailable.
4. Register the application’s public HTTPS callback for the correct tenant, application, and environment.
5. Confirm the application can reach your VeriProof endpoint to load the published signing keys, or that its team has pinned the key set.
6. Send a synthetic test and confirm raw-body signature verification, durable receipt, directive application, and execution acknowledgment.
7. Review callback health, unresolved incidents, missing acknowledgments, and unresolved key-set errors before enabling the workflow.

Pause delivery when the endpoint, assignment, or evidence boundary is uncertain. Pausing delivery must not delete the review history.

Reviewer

Reviewer

When a case arrives:

1. Open the authenticated VeriProof task from Inbox, the exact email link, or the Review in VeriProof button in Teams or Slack.
2. Confirm the application, review reason, protected action, evidence, current assignment, due time, and consequence.
3. Record one outcome:
   • Approve when the evidence supports releasing the protected branch.
   • Reject when the work must end without release.
   • Follow-up required when the application must stay paused while another question or evidence request is resolved.
4. Add a short reason that another authorized person can understand.
5. Confirm the recorded decision version before leaving the task.

An email reply can’t record a decision. If your organization allows it, you can decide from your own Microsoft Teams card or Slack message. VeriProof records it like any other decision and notes where it was made.

Developer

Developer

The core SDK builds the review request, checkpoint, and continuation binding for you. Don’t create continuation IDs, generations, or state fingerprints by hand.

Before your first review, confirm the active review profile key, that human review is turned on for the organization, that the application key has Human review access, and that a public HTTPS callback is registered. See Add human review.

1. Pass review options to govern, such as review=GovernReviewOptions(profile="claims-review") in Python. When a rule requests review, the result is review_required, and result.review holds the checkpoint. The protected action has not run.
2. Create the review runtime with vp.reviews(store=..., revalidate=...). Use the VeriProof hosted store or your own durable store.
3. Save the checkpoint with runtime.save(result.review).
4. In the callback endpoint, pass the raw body and headers to runtime.receive(...) and return its status and body. The runtime verifies the signature before it reads the outcome and stores it durably. Don’t run protected work in the listener.
5. In a worker, call runtime.resume(checkpoint, action). The runtime claims the outcome once, rechecks your application state and current policy, applies the resume mode, and sends the execution acknowledgment. route_to_revision never runs the superseded payload.
6. If execution may have completed without a recorded result, check the durable effect, then call runtime.reconcile(...) before any retry.

The application team owns the callback endpoint, review store, worker, revision path, and protected side effect. VeriProof owns case routing, reviewer authorization, the canonical decision, and signed delivery.

See the Outcome Callback Reference for the published paths, headers, states, and response behavior.