Choose the type your code expects
Use numbers for amounts, booleans for visible checkbox states, and strings for identifiers. Deterministic normalization is easier when the type is explicit.
Guide / Schema design
A dependable extraction schema names exactly the fields your system consumes, in the types it expects. Start narrow, describe ambiguous fields, and require only what must always be present.
Start here
Routeser requests carry user-defined field names, types, descriptions, and required flags. Mirror the vocabulary of the system that will store the result so downstream code needs no translation layer.
Resist a wide schema. A focused set of fields is easier to validate, cheaper to review, and more predictable across documents than a catch-all object.
Use numbers for amounts, booleans for visible checkbox states, and strings for identifiers. Deterministic normalization is easier when the type is explicit.
Field descriptions tell the extractor which visible label or region a value comes from. They are the cheapest way to disambiguate lookalike fields.
Mark a field required only when its absence should be treated as a problem. Optional fields let the extractor preserve uncertainty instead of inventing a value.
Before you submit
Related
Questions, answered plainly
No. A narrow schema is easier to validate and review. Add fields when a downstream consumer needs them, not speculatively.
Require a field only when its absence should fail or flag the workflow. Optional fields let the extractor preserve genuine uncertainty.
No. Descriptions guide where a value is found; the field type defines what your system receives. Keep both explicit.
Next step
Open the console to create a schema and evaluate it against your own documents in an authenticated workspace.