Taxonomies & routing
Class trees, routing versus label taxonomies, how class codes are derived, the leaf-to-schema mapping, coverage gating, and the unmatched-class rule.
A taxonomy is the tree of document classes a pipeline sorts documents into. Its shape is a hierarchy of classes; its behaviour depends on whether the leaves route to schemas. The Classify stage resolves each document to a class in the published taxonomy its pipeline is bound to.
Routing taxonomies vs label taxonomies
A routing taxonomy binds each leaf class to a schema, so classifying a document also decides which schema extracts it — classification and extraction are one decision. A label taxonomy classifies without routing: the class is recorded as a label on the document but drives no schema selection. The same tree structure serves both; the difference is whether the leaves carry schema bindings.
Class codes and how they are derived
Every class has a code — a short, stable key that pipeline routing rules reference. Codes derive from the class's path in the tree: a top-level Invoice class takes INV, and its child Standard invoice takes INV.SI. A code can also be set by hand. Because rules reference the code rather than the display name, the code is the stable identifier and renaming a class is a breaking change — one that is surfaced in the version diff at publish time.
Each class carries its code, a description, and a classification instruction. The code is what pipelines route against; the classification instruction is the positive-and-negative guidance the classifier reads to decide the class.
Mapping every leaf to a schema — no inheritance
In a routing taxonomy each leaf binds its own schema, and there is no inheritance from a parent. A parent class organizes its children and does not itself carry a binding unless the taxonomy is configured so that all classes, not only leaves, are classification targets. Two sibling leaves under the same parent can route to entirely different schemas; nothing is inferred from the branch they share.
Coverage gating before publish
A routing taxonomy cannot be published while any leaf is unbound. The routing view tracks coverage as a count of bound leaves against the total and reports how many remain, and publish is blocked until every leaf routes to a schema. Where a class name matches a schema name, the binding is offered as a suggestion, but the gate is on coverage being complete, not on how each leaf got its schema.
Coverage is absolute: the progress bar reaches 100% only when every leaf is bound, and the taxonomy reports it is ready to publish. Until then the warning names the count of leaves still needing a schema.
Starting points
A taxonomy can be built from any of several starting points, each of which produces the same editable tree. They differ only in how the first draft is seeded, and one is not yet available.
| Starting point | Produces | Status |
|---|---|---|
| Upload a folder | Nested folders become classes; sample docs enrich them | Available |
| Generate from schemas | One class per published schema, pre-routed | Available |
| Paste an outline | Indented text becomes a tree with derived codes | Available |
| Infer from samples | Clusters mixed documents into a proposed tree | Coming soon |
The per-option settings for each — how class names and codes are derived, how sample documents are attached — belong to the authoring flow in Create a taxonomy.
The unmatched-class rule
A document that resolves to no class in the taxonomy is not failed. It falls to the unmatched-class rule and is extracted generically — Extract returns free-form JSON rather than schema-validated fields — so an unexpected document still produces a result and a signal rather than an error. How a document is resolved to a class in the first place is covered in Classify.