MICROEXTRACT DOCUMENTATION

Live Test, Confidence and Human Review

The objective is not to make uncertainty disappear. The objective is to make uncertainty visible before it becomes trusted business data.

1. Use Live Test with representative documents

Where the current application release exposes Live Test, compare the source PDF beside the available structured JSON output after a test job reaches a terminal state. Check both obvious values and edge cases.

If Live Test is not visible in your environment, use the downloadable structured output and the original source file for the same comparison.

2. Interpret confidence as a review signal

MicroExtract combines extraction confidence with completeness and deterministic validation. A high score does not override a failed business rule, and a lower score does not automatically mean the extracted value is wrong.

Use confidence to prioritise attention, then verify the source when the result matters operationally.

3. Use field-level confidence where available

Field-level or row-level confidence helps reviewers focus on uncertain values instead of rechecking every field equally. In the current product, detailed confidence visibility depends on the active release and extracted field group.

Do not treat a threshold as universal. The right review threshold depends on the risk of the field and the downstream action.

4. Keep exception review human controlled

Jobs can enter review-required states when validation, completeness or source ambiguity needs attention. Review reasons should remain visible so an authorised person can decide whether to accept, correct, reject or escalate the result.

5. Compare against the source, not another AI guess

When resolving an uncertain value, use the original document and the configured business rule. A second generated answer is not a substitute for evidence from the source or an authorised reference system.

6. Retest after template or rule changes

After changing a mapping, template or validation rule, rerun a representative sample set. Include normal documents and known exceptions so the change does not improve one example while breaking another.

Need help with a real document workflow?

Use representative samples, define the required output and validation rules, then test before production use.

Confidence Signals and Human Review Decisions

Confidence can help prioritise review. It does not replace a source check, a business rule or an authorised decision.

Three questions, not one score

Ask whether the value matches the source, whether required information is complete and whether the result satisfies the configured rule. Those are different questions.

A high-confidence value can still violate an approved limit. A low-confidence value can still be correct after source verification.

Use the available comparison method

Where the current release exposes Live Test, compare the source with the available structured output. Otherwise use the downloaded result beside the original permitted source.

Detailed field-level or row-level confidence visibility depends on the active release and field group. Do not promise a universal threshold or interface.

Record a decision with reasons

A useful review records what was checked, which source or authorised reference resolved the uncertainty, and whether the result was accepted, corrected, rejected or escalated.

Acknowledging a warning is not the same as correcting it. Keep unresolved reasons visible and retest after template or rule changes.

  • Check missing fields before downstream use.
  • Verify ambiguous identifiers against an authorised reference.
  • Distinguish extraction error from a genuine business exception.
  • Retain the decision and source traceability.