Docs/How-to/Create a taxonomy
How-to6 min read

Create a taxonomy

Build a classification taxonomy — outline the class tree, let the class codes derive, bind every leaf to a schema, and publish a version your pipelines can route against.

A taxonomy is the set of document classes a pipeline sorts documents into, and — for a routing taxonomy — the schema each class extracts against. You author it in Library → Taxonomy: draft the class tree, bind each leaf to a schema, and publish a version.

Who this is for

Workspace admins and pipeline builders. Build the schemas the classes route to first, or create them inline while you bind — see Create a schema.

1. Open the taxonomy wizard

In Library, the Taxonomy tab lists your taxonomies with their status, active version, and the pipelines using them. Choose New taxonomy and pick a starting point.

Four ways to start, all landing in the same tree editor. Upload a folder turns nested folders into classes; Generate from schemas makes one class per schema, pre-routed; Paste an outline turns indented text into a tree with a live preview. Infer from samples is coming soon.

The steps below use Paste an outline, the most direct way to see the tree and its codes take shape. Whichever start you pick, the editing, binding, and publishing steps are the same.

2. Draft the class tree from an outline

Give the taxonomy a name and paste an indented outline into the editor — each line is a class, and indentation nests it under its parent. The live preview renders the tree as you type and derives a short code for every class from its path.

An outline on the left, the class tree on the right. Codes derive from the path — Invoice becomes INV, its child Standard invoice becomes INV.SI. The footer counts the branches and leaves and reminds you that no schemas are bound yet; that comes next.

Create & map schemas saves the draft and opens the tree editor on its routing view.

3. Bind every leaf to a schema

A routing taxonomy sends each document to a schema, so every leaf class must be bound before you can publish. The routing view tracks your coverage and will not let a partly-bound taxonomy go live.

The routing view lists each leaf and the schema it routes to. The progress bar counts bound leaves; the warning names how many are still unbound. When IDPForge can match a class to a schema by name, it offers the binding — Accept all takes every suggestion at once, or bind each leaf yourself from the picker.

Bind the remaining leaves from the schema picker on each row — it searches your Library and can create a new schema inline. Coverage reaches 100% when every leaf is bound, and the view reports it is ready to publish.

4. Refine classes in the tree editor

Switch to the Tree view to edit a class directly. Selecting a class opens its inspector.

Each class carries a code — the stable routing key pipelines reference — a description, and a classification instruction that tells the classifier how to decide the class, with positive and negative cues. A parent that only organizes its children is marked as such; documents resolve to its leaves, which carry the schema bindings.

Add few-shot example documents to a class to anchor tricky decisions, and write the classification instruction as a direct instruction to the model — "classify here when…", "do not classify here even if…".

5. Publish a version

Publishing snapshots the tree and its bindings into a numbered version.

Publishing mints v1. A pipeline pinned to a specific version stays on it; a pipeline tracking the latest version re-resolves to the version you just published.

After publishing, the version badge shows the live version and the working-draft banner clears. Versions in the header lists the published history.

Edge cases

  • Leaf classes route; parents organize. By default only leaf classes carry a schema binding and receive documents. To let documents land on a parent class directly, switch Classification targets to All classes in the taxonomy's Settings.
  • A class code is a stable key. Pipeline routing rules reference the code, so renaming a class is a breaking change and is flagged in the version diff at publish time. Codes derive from the path but can be set by hand.
  • Coverage gating is absolute. You cannot publish while any leaf is unbound — bind it, or remove the class.
  • Background enrichment can fail. Starting points that enrich classes from sample documents do that work in the background; a class whose enrichment fails is marked so you can retry it, and the taxonomy still publishes without it.
  • Unmatched documents fall through. A document that matches no class is handled by the unmatched-class rule rather than failing the job — see Taxonomies & routing.
Was this page helpful?
Last updated 23 Aug 2026