Stolen Orbit
ENIT
Let’s talk
FREE TEMPLATE · FILL IN, DOWNLOAD, REUSE

Document extraction schema

Define exactly what each field means before extracting it. An output can follow the correct structure while still containing wrong values or claims unsupported by the document.

By Stolen OrbitRevision

When to use it and what to produce

When extracting information from requests, confirmations, invoices or other documents for transfer into an operating system.

A schema for each document family with field meanings, validation rules, evidence and missing-data behaviour.

Fill in the fields below and download your document. The website does not send or save answers: closing the page may lose them. Examples are illustrative and should be replaced with your process data.

Download the complete blank template (.md)

1. Define document and destination

Separate document families that use the same labels with different meanings. Describe the output needed by the process instead of collecting every available detail.

See a worked example

Illustrative example: extract a supplier order confirmation to compare with the original purchase order. Do not treat a quotation as confirmation merely because it contains codes and prices.

List included documents, languages, scans, attachments and versions requiring exclusion or separate handling.

Explain which system receives the data and which decisions or actions depend on it.

Define stable reference, version and how lines, pages and duplicate documents are distinguished.

2. Specify the fields

Complete one entry per field. Distinguish information present in the document from values calculated using an explicit, verifiable rule.

See a worked example

Illustrative example: “delivery_date” means a date explicitly assigned to delivery, not document issue. If the document says “to be agreed”, leave it empty and record why.

Describe field, type and when it is required; clarify ambiguous labels such as date or total.

Specify date format, currency, separators, units and allowed transformations while preserving the original value.

Require a page or text reference; define the result when a field is absent or ambiguous.

3. Check before use

Combine deterministic checks with review of ambiguities. Do not silently correct amounts or identifiers just to pass validation.

See a worked example

Illustrative example: quantity multiplied by unit price differs from the line total. Preserve both values and request review instead of inventing a discount to explain the difference.

List formats, total consistency, master-data matches and rules with explicit tolerances.

Define critical fields, conflicts and unreadable documents that must stop a write.

Prepare ordinary, missing and conflicting examples with results verified by someone familiar with the documents.

Pitfalls to avoid

  • Using a field name without defining its operational meaning.
  • Filling missing information with plausible guesses.
  • Treating valid JSON as proof that the extracted data is correct.

Take the next step together.

Use this document to start a discussion about scope, evaluation and project ownership.

Review the text before sending. Only your email is needed alongside the message; other details are optional.