Skip to content
VeraFrame Docs

Approve / reject workflow

The approve/reject workflow is VeraFrame’s implementation of human oversight — the “human in the loop” that the EU AI Act, NIST AI RMF, and ISO 42001 all require for consequential AI output.

This page describes the admin-level review step that runs after a user has already corrected individual findings. For the per-finding user-level actions (approve a single claim, override a mismatch, edit a passage), see Correcting findings.

When the workflow applies

The approve/reject workflow is available only on tenants where review workflow is enabled.

On a workflow-enabled tenant, a validation can create a review case in two ways:

  • Policy-driven review — the validation mode is included in review_required_for_modes.
  • Validation-driven review — the trust report contains needs review findings and the tenant has route_validation_review_to_queue enabled.

This means:

  • workflow disabled — VeraFrame stays in “create and forget” mode. A trust report may still say needs review, but no review case is created.
  • workflow enabled + policy match — the validation enters pending_review.
  • workflow enabled + validation routing enabled + trust report needs review — the validation enters pending_review.
  • high_risk_ready — review cases can additionally block final output from export / downstream API use until reviewed.

The compliance profile still matters, but it no longer acts as the only switch for creating review cases. Profiles define the default policy posture; workflow settings decide whether review cases are actually created.

The four actions

A reviewer opens a pending validation from the Review tab in the Admin dashboard and chooses one of four actions.

Approve

The output is acceptable for final use. The reviewer’s identity, timestamp, and optional note are recorded. The validation state moves to approved and the output becomes available for export.

Reject

The output should not be used. A note is required when the tenant policy requires one. State moves to rejected.

Rejection is a signal, not a gate — the underlying generation is not deleted. The rejected output remains in the audit trail so it can be reviewed later (“why did we reject this?”).

Edit

The output is almost right, but needs adjustment. The reviewer edits the output text, supplies a note, and saves. State moves to edited. The original output is preserved alongside the edited version — audits can see both.

An edit does not run a fresh validation by itself. If the reviewer’s edit changes factual content, they should revalidate afterwards.

Handoff (external review)

The validation is handed off to an external review system (legal review platform, ticketing system, internal governance tool). See External review.

Roles that can review

Only users whose role is in the tenant’s required_reviewer_roles list can make review decisions. In the current product role model, the supported user roles are admin, user, and viewer; required_reviewer_roles should therefore be chosen from those roles.

What gets recorded

Every action the reviewer takes writes an event to the audit trail:

  • review_required — emitted when a review case is created and enters pending_review.
  • approved / rejected / edited — emitted with actor ID, actor role, timestamp, and note.
  • review_handed_off — emitted when a case is sent to an external review system.
  • external_review_approved / external_review_rejected — emitted when the external decision is recorded.

See Audit trail for the export format.

UI behavior

The Review tab in the Admin dashboard appears when the tenant’s review workflow is enabled, or when the external_review_workflow feature is on. It shows review cases filtered by review state with actions inline.

The Validations tab also surfaces review state so users can see whether an output is still pending, in review, approved, rejected, or externally decided.