Review marks

Record a human assessment of a completed audit’s verdicts without changing the underlying verification.

POST /v1/audits/{id}/verifications stores whether a reviewer judged an item’s returned verdict correct. Use it after examining the source evidence and your review criteria. The audit must belong to your account and be completed.

What the mark means

correct: true means the reviewer accepts the returned verdict; correct: false means the reviewer judges that verdict incorrect. This is not an instruction to approve an expense, change a claim or release a payment. Those business actions stay in your application.

A mark records feedback on the existing result. It does not replace the original verdict, rerun checks, retrain a model, alter thresholds or add qualification evidence to the service automatically.

The endpoint also accepts a mark for an uncertain result. Define whether your reviewer is judging that uncertainty appropriate; the boolean does not supply a replacement true/false business conclusion. Store that conclusion and supporting rationale in your own review system.

Construct a review submission

Field	Requirement	Meaning
`verifications`	Array of 1–1,000 marks	One request can record several reviewed items from the same audit.
`item.type` and `item.id`	Must name an item in this audit	Use the identity from the returned Verification object.
`correct`	JSON boolean	The reviewer’s assessment of the returned verdict.
`note`	Optional string of at most 1,000 characters	A concise explanation or review reference. A longer note is rejected with `422 schema_violation` naming `verifications.<n>.note`, and no mark in that request is recorded.

Save this illustrative body as review-marks.json. Replace the item identity with an item that actually exists in your completed audit.

{
  "verifications": [
    {
      "item": {"type": "invoice", "id": "INV-2026-0841"},
      "correct": true,
      "note": "Confirmed missing PO reference above the 1000.00 control threshold."
    }
  ]
}

curl "https://openauditor.ai/api/v1/audits/$AUDIT_ID/verifications" \
  -H "Authorization: Bearer $OPENAUDITOR_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @review-marks.json

The example accepts the recorded false verdict after a reviewer confirms that the supplied invoice lacks its required PO reference. It records agreement with that control finding; it does not approve payment or determine audit materiality.

Read and update review counts

A successful submission returns 200, the audit ID and a verifications object containing aggregate correct and incorrect counts. The audit status response exposes those counts as well.

Submitting another mark for the same audit item replaces the stored mark for that item. The current endpoint stores one latest assessment per item; it does not expose individual marks or notes through a read endpoint, or record a separate reviewer identity. Keep your submitted marks, reviewer identity and detailed history in your own workflow.

Handle an unavailable or invalid audit

Response	Action
`409 not_completed`	Wait for the audit to complete before marking results.
`422 schema_violation`	Check that marks are a nonempty array, each item belongs to the audit and correct is a boolean.
`404 not_found`	Check the audit ID, owning account and whether the audit expired or was deleted.

Marks follow the audit’s lifecycle. Deleting or expiring the audit removes its stored review marks along with the inputs and results.

Continue reading

Batch audits — retrieve the results and monitor audit status.
Verification results — review the evidence before assigning a mark.
Evaluation evidence — understand why stored feedback and model qualification are different.