Skip to main content
The Model Performance dashboard turns human corrections into a prioritised list of things to fix. It shows which document types, fields, and Model Memory reference documents are generating the most rework, so you can target field descriptions, settings, and Model Memory instead of guessing. The dashboard is most valuable if human review is part of your business-as-usual workflow. Correction volume is only a reliable accuracy signal where reviewers are consistently checking and confirming documents.
A correction is a field-level event where the current annotation differs from the original model prediction. Field confirmations with no change to the value, selection, or count are excluded.

​
Overview tab

Model Performance Overview Filter the whole view by date range, workspace, document type, type of human change, and issue type. Three summary metrics sit at the top:
  • Human corrections – total correction events across the fields in scope.
  • Docs corrected – the share of documents in scope that needed at least one correction.
  • Field issues – the number of distinct fields with corrections.

​
Cumulative coverage

Shows how concentrated the correction burden is across fields. In most configurations a small group of fields accounts for the majority of corrections, which tells you how much of the problem you can solve with a handful of changes.

​
Main issue type breakdown

Correction volume split by the kind of change the reviewer made: The mix matters when deciding what to change. Missing and extra fields usually point to an unclear field description or a schema that does not match the document. Wrong selection or location usually points to a Model Memory reference that is not a close match to the documents being processed.

​
Field detail

Performance Field Detail Open any field to see:
  • Field description – the instruction used for future predictions. Edit and save it directly from this panel. Changes affect all future extractions for that field.
  • Issue type distribution – the same four issue types, scoped to this field.
  • Evidence – individual correction events showing the original model prediction next to the reviewer’s annotation, with surrounding row context for table fields. Filter by failure mode, search across evidence, open the source document in the review interface, or export the full set to CSV. Reading the before and after values across several examples usually makes the fix obvious. A field that is repeatedly captured from the wrong region needs a description that states where the value sits. A field that is repeatedly reformatted needs the expected format written into the description, or a text transformation.
Work top-down. Fix the highest-volume field first, let new documents flow through, then come back and check whether the correction count has fallen. Small numbers of corrections spread across many fields are rarely worth chasing.

​
Model memory tab

Performance Model Memory Reference documents are ranked by the number of corrections made on the documents that used them, alongside how many documents used each reference and the average corrections per document. Documents parsed without any reference are reported separately. A reference document at the top of this list is a signal, not a verdict. There are three common explanations:
  1. The reference has inaccurate annotations. Errors in a Model Memory document propagate to every document that references it. Open the reference, correct the annotations, re-confirm it, and reparse the affected documents.
  2. The reference is a poor choice for Model Memory. It may be an unusual or low-quality example that is being matched too broadly.
  3. A closer match is missing. The fingerprinting algorithm selected the best available reference, but no reference closely resembles the incoming format. Confirm a representative document of that format and add it to Model Memory. Average corrections per document is the more useful column when comparing references, since total corrections is partly a function of how often a reference is used.
See Model Memory for more on how references are selected and managed.

​
A suggested working rhythm

  1. Set the date range to your last review period and leave the other filters open.
  2. Use the cumulative coverage chart to decide how many fields are worth addressing.
  3. Work through the top fields, reading the evidence before changing anything.
  4. Update field descriptions, settings, or validation rules based on what the evidence shows.
  5. Check the Model memory tab for reference documents with a high average corrections per document, and correct, remove, or supplement them.
  6. Reparse affected documents so the changes apply to work already in the queue.
  7. Return the following period and compare correction volume on the fields you changed.