Start with a business purpose

A document class describes what the record is; extraction fields describe the information needed from it. Define stable field keys and useful business names before choosing recognition phrases. Information classification such as Restricted remains a separate governance property.

Published tenant configuration takes precedence where supported. Existing processing runs retain their recorded schema/version context; editing a draft does not rewrite historical results.

Build the class

  1. Open Configuration → Extraction schemas and create or select a draft classification. Define the business name and machine key.
  2. Add distinctive recognition phrases, exclusions and likely filename terms. Avoid generic words that match unrelated documents. Configure supported parent rules, hierarchy or secondary labels when needed.
  3. Define fields with stable keys, types, labels/synonyms or supported patterns, required flags, thresholds and validation rules. Choose predefined fields, key/value discovery or both where offered.
  4. Configure redaction proposals and human-review rules. Sensitive documents and low-confidence results may require review even when automation is enabled.
  5. Test positive and negative examples, including similar classes, absent required values and poor scans. Inspect mismatches rather than lowering thresholds merely to make the sample pass.
  6. Save, validate and publish the permitted version. Use a new version for later changes and repeat acceptance testing.
Local product example · sample dataClick to enlarge ↗
Follow the configuration guide

Choose a step on the left for guidance, then use its action to open the relevant configuration controls. Test recognition and review policy before publishing a new version.

Local product example · sample dataClick to enlarge ↗
Use recognition signals that distinguish this class

The sample invoice class increases its match score for invoice and payment due, and reduces it for credit note. Review file-name signals, minimum confidence and priority together. These sample values illustrate the controls; tune them using representative positive and negative examples.

Use discovery carefully

Key/value discovery can retain additional explicit source pairs for variable documents. A discovered pair is not automatically a stable business identifier or a field approved for indexing. Use mappings/synonyms where downstream outputs need consistent names.

Forms, region templates and tables depend on the supported source evidence and extraction path. A drawn region must bind to the correct page/template. It does not authorise inference of values absent from the original.

Control automation

A published schema is not itself an activated action policy. Indexing and other consequential effects require their own permitted, current policies and receipts. Benchmark results and confidence scores support a launch decision but do not constitute independent accuracy certification.

Local product example · sample dataClick to enlarge ↗
Inspect the sample result before publishing

This local example returns an invoice classification and two extracted values. A passing sample is not proof of OCR layout accuracy, calibrated confidence or production-wide quality. Inspect the values, test other representative documents and complete the required publication checks.

Publish against expected results

  1. Choose stable downstream field keys and appropriate data types.
  2. Test matching and non-matching examples, missing values and difficult scans.
  3. Inspect failures rather than lowering thresholds to make samples pass.
  4. Save, validate and publish the permitted draft; use a fresh run to verify version selection.