> ## Documentation Index
> Fetch the complete documentation index at: https://docs.privue.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Accuracy and limits

> Documents are read by a language model, and what that means for the values you receive.

Every document that reaches us is read by a language model rather than by a person, whichever way it
arrived. Some judgements a workflow makes are put to a model too, such as whether two written
addresses name the same place or whether a document is the kind that was asked for.

Models are not exact. What that can produce:

* **Nothing usable.** The document could not be read, and the step fails with a clear reason.
  A blurred photograph, a cropped page, a document that is not the kind the step asked for. This one
  announces itself, and a better copy settles it.
* **A value that is plausible and wrong.** A digit swapped in a number, a name taken off the line
  below the one that matters, a year read from the wrong row. Nothing about the value says it was
  misread, which makes this the case worth designing around.
* **The wrong one of several.** Where a document names more than one party, account or date, the model
  picks, and it can pick the wrong one.
* **A judgement that goes the wrong way**, where a step asks a model to decide rather than to read.
* **Readings that are not perfectly repeatable.** The same document read on two separate occasions can
  come back slightly different, so a difference between two readings is not evidence that the document
  changed.

## What stands against it

Most of what a verification publishes is not the reading. Where a body issues the document, the
reading is used to look the subject up, and that body's record is what gets published: the GST
registry's registration, the income-tax registry's word on a PAN, the bank's word on an account. A
misread identifier is one the source does not hold, so it fails rather than passing with a wrong
value.

Where nothing can confirm a reading, the reading is the result. Some documents have no register behind
them and some judgements have no second opinion, and what those steps publish rests on the reading
alone.

## What to do with that

* **Read an `-unreadable` failure as a document problem, not a finding about the subject.** Give it a
  path back to a better copy rather than a rejection.
* **Route a step that passed carrying a `gap`, or a near-miss score, to a person.** That is what those
  signals are for.
* **Ask us which values in your workflow rest on a reading alone**, and what your workflow holds each
  document up against. Both are configuration, and both can be tightened.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.