Create a schema
Author a schema two ways — infer the fields from a sample document, or build them by hand — tune each field's type and rules, then publish a version a pipeline can pin to.
A schema is the contract for a document class: the named fields IDPForge extracts, their types, and the rules that decide what passes. You author it once in Library → Schema, publish a version, and bind that version into a pipeline's Extract stage.
Workspace admins and pipeline builders. Anyone who can open Library can create a schema; binding it into a pipeline is a builder action.
1. Open the schema wizard
In Library, the Schema tab lists every schema in the workspace with its status, active version, field count, and the pipelines it is used in. Choose New schema and the wizard asks how you want to start.
The starting point decides the first steps, not the result — all three land in the same field editor. From a sample document is the fastest path when you have a representative file; Start blank gives you an empty editor; Clone an existing schema copies one from your Library.
The two paths below are equally good. Infer-from-sample is quicker when you have a clean example on hand; building by hand gives you exact control from the first field.
2. Infer the fields from a sample document
Choose From a sample document and drop in one representative file — PDF, image, or Office document. A single clean example works better than several messy ones.
IDPForge reads the file and proposes a field for every value it can extract, working through four passes: reading the document layout, detecting fields and tables, inferring each value's type, and building the draft.
The review step puts the sample on the left and the proposed fields on the right. Each field carries the confidence of the inference and its inferred type. Clear the checkbox on anything you do not want, or use Drop low-confidence to remove the weakest proposals in one action.
Keep the fields that belong in the contract and drop the rest — a footer field or a page number the model happened to read is rarely worth extracting. Continue carries your selection into the naming step, where the summary notes it was inferred from your sample.
3. Or build the fields by hand
Choose Start blank and name the schema first: a clear name and description tell teammates and downstream services what the contract is for. The schema context prompt is guidance applied to every field at once — the document type, the language, the currency, and what to prefer when a value is ambiguous.
The field editor. Add field appends a field; Add group starts a nested group of related fields. Selecting a field opens the inspector on the right, where its type and rules live. A schema needs at least one field before it can be created.
4. Configure a field
Select any field — inferred or hand-added — to open its inspector. A field carries a name, a type, and an optional group, plus the guidance and rules that shape how it is read:
| Setting | What it does |
|---|---|
| Type | One of text, long text, number, currency, date, boolean, enum, checkbox, radio, table, or group. The type routes the field to the matching extraction sub-stage. |
| Description | A human-readable note for teammates and reviewers. |
| Extraction instruction | Where and how to read the value — a direct instruction to the model. |
| Formatting instruction | How to shape the extracted value, for example a date format or a currency's decimals. |
| Required | When on, a document missing this field is rejected rather than delivered. |
| Confidence threshold | Extractions below this score are flagged for review. The default is 80%. |
| Validation rules | Optional constraints on the accepted value; Add rule to start one. |
Use table for repeating rows — line items on an invoice — and group to nest fields that belong together. Both keep related values structured instead of flattened into one long list.
5. Publish a version
Creating the schema saves it as a draft. A draft is editable and is not yet usable by a pipeline; publishing snapshots the current fields into an immutable, numbered version.
Choose Publish, write a release note describing what this version contains, and confirm. The first publish mints v1.
Publishing snapshots the field set and mints a version. The release note is required — it is what you and your teammates read in the version history to know what changed between v1 and v2.
After publishing, the working-draft banner clears and the version badge shows the live version. Versions in the header lists every published version with its release note.
Edge cases
- A pipeline binds a published version, not the draft. Editing a published schema starts a new working draft; the pipeline keeps running the version it is pinned to until you publish the next one and rebind. This is how you change a schema without disturbing live jobs.
- Required rejects; low confidence reviews. A missing required field fails the document outright. A field that is read but scores below its confidence threshold is flagged for review — the job still completes.
- Cloning copies fields, not history. Clone an existing schema starts a fresh draft from a copy of another schema's fields; the clone has its own version line from v1.
- A schema with no bound class still works. With no schema bound to a class, Extract returns free-form JSON instead of validated fields — see Extract.