This workflow walks through using an MCP-connected AI agent to manage the document review queue — listing documents waiting for a human decision, inspecting their extracted data, and applying verdicts in bulk. Trigger phrases that start this workflow:Documentation Index
Fetch the complete documentation index at: https://docs.affinda.com/llms.txt
Use this file to discover all available pages before exploring further.
- “Review my documents”
- “What’s in my review queue?”
- “Confirm the invoices I just uploaded”
- “I want to validate my extractions”
Before starting, your AI client must be connected to the Affinda MCP server. See MCP Connector and Plugin for setup instructions.
Document states
Documents move through the following states:| State | Meaning |
|---|---|
pending / processing | Document is still being extracted. Nothing to review yet. |
review | Extraction complete; waiting for a human decision. This is the queue this workflow operates on. |
validated | Confirmed by a human or by auto-confirmation rules. |
archived | Removed from the active queue; no longer needs action. |
Steps
Show the review queue
The agent calls
list_documents with state=review and returns up to 20 documents waiting for a decision. If the queue is empty, there is nothing to review.You can narrow the queue by workspace or document type: “Show me the invoice review queue.”Inspect individual documents
For any document you want to examine in detail, ask: “Show me the extraction for document [ID or name].”The agent calls
get_document (for status and metadata) and get_document_extraction (for field values and confidence scores), then surfaces the results with low-confidence fields highlighted so you know where to look first.Apply your verdict
Tell the agent your decision in plain language. It will identify the relevant tool and batch the operation:
| What you say | Tool called |
|---|---|
| ”These look right — confirm them” | confirm_documents(document_ids=[...]) |
| ”These are wrong — reject them” | reject_documents(document_ids=[...]) |
| ”I don’t need these any more” | archive_documents(document_ids=[...]) |
| ”This is the wrong document type” | reassign_document_type(document_id=..., document_type_id=...) |
Model memory and confirmation
confirm_documents does more than mark a document as validated — it feeds the extraction into the workspace’s model memory, directly improving future accuracy. The effect depends on the workspace’s model_memory_strategy:
| Strategy | Behaviour |
|---|---|
auto (default) | The system selects which confirmed documents become training examples automatically. |
manual | Only documents you explicitly mark as training examples are used. |
always | Every confirmed document is added as a training example. |
Rejection vs archiving
These two operations are distinct:- Reject (
reject_documents) — marks an extraction as incorrect. Rejection participates in model memory: the system learns to avoid repeating the same mistake on similar documents. - Archive (
archive_documents) — removes a document from the active queue because it is no longer needed. Archiving does not signal to the model that the extraction was wrong.
Document reassignment
If a document was routed to the wrong document type (for example, a receipt was classified as an invoice), usereassign_document_type. The agent will:
- Verify that the target document type is assigned to the workspace.
- Call
assign_document_type_to_workspacefirst if it is not. - Call
reassign_document_type, which triggers a reparse under the new schema.
processing state during the reparse. Tell the agent you are expecting this and it will confirm once the new extraction is ready.
Related
- Debug low-confidence results — if users are repeatedly correcting the same field, this is the next step.
- Configuration guide: User Validation — details of the Affinda validation interface for human reviewers.
- Configuration guide: Machine Validation — setting up auto-confirmation rules so clean documents bypass the review queue.