Taxonomy, lifecycle, tags & events

In one line. The four configuration tabs inside a Collection that turn raw documents into classified, reviewed, decided, and reported-on records: Taxonomy, Lifecycle, Tags, and Events. You’ll be able to. Read and edit a collection’s classification fields, design the review stages a document moves through (including auto-decide rules), tag records, and fire an external webhook when a document changes stage. Where this lives. Studio ▸ Data ▸ Collections ▸ <collection> — then the Taxonomy, Lifecycle, Tags, and Events tabs in the right pane.

Why it matters

Collections & schema gave you a Collection and a taxonomy — the shape of a record. This page gives the record a life. Once a document lands, four things decide what happens to it: how it’s classified (Taxonomy), the stages it moves through and who reviews it (Lifecycle), the tags people stick on it (Tags), and the external systems told about it (Events). Three of these tabs are short; Lifecycle is the big one, because that is where “AI extracted some fields” becomes “the business made an auditable decision.”

All four are tabs inside a collection. You will not find them in the Studio menu — open Studio ▸ Data ▸ Collections, select a collection, and they are in the right pane.

Watch out — the one confusion to avoid. A Lifecycle is the set of stages a document moves through (Intake → Review → Approved…). An XFlow is a pipeline of steps that does processing work. They are different things, and the word “workflow” gets used for both — this page is about Lifecycle, not XFlow. XFlows are covered in XFlows & pipelines.

Taxonomy tab — classification vs extraction

You met this tab in Collections & schema as the place you define taxonomies (named groups of fields) and the fields in them. Here we focus on one specific use of it: classification.

There are two jobs a taxonomy can do, and the difference is the Type you pick when you create it:

Job	What it produces	Type to choose
Extraction	Pulls a value out of the document — `invoice_total`, `due_date`.	A field/record/table type.
Classification	Assigns the document (or a page/section) to a category — “this is an Invoice”, “this page is a Cover Letter”.	Document / Page / Section / Table Classification.

A classification field is just a field living under a Classification-type taxonomy: its name is a category the document can be sorted into (e.g. Contract, Invoice, Statement). Classification results are what drive routing later (a Conditional lifecycle stage can branch on them — see Lifecycle below).

Creating a classification field

Studio ▸ Data ▸ Collections ▸ <collection> ▸ Taxonomy:

Click Taxonomy (footer) to open Create Taxonomy. Give it a Taxonomy Name and Description.
Set Type to Document Classification (or Page, Section or Table Classification; the dialog starts on Section Classification), pick the Collection if the dialog asks for one, and Submit.
Select the new taxonomy, open its Labels tab, and click Label (or whatever your workspace calls a label).
Enter the category as the Label Name (e.g. Invoice) and a Description (both required).
Show Advanced Settings reveals the same accordions as any field: six for a plain label (Contextual Insights, Record Config, Toggles/Features, Standard values, Lookup Config, View Config), and a seventh, Table Styling, for a child or table label. For a plain classification field you rarely need them — leave defaults.
Add (keep going) or Add and exit.

Bulk import

On the field dialog switch to the import tab to load many categories at once: drag-drop or Choose File a .txt / .xlsx / .tsv / .csv; parent-to-child hierarchy is expressed by indentation (text) or columns (spreadsheet); Upload & Create.

Tip. Keep classification taxonomies small and flat — one taxonomy per decision (“Document type”, “Risk band”) with a handful of fields each. It reads better in the Conditional stage editor.

The full field-by-field reference for every advanced option lives in the Schema field reference; this page doesn’t repeat it.

Lifecycle tab — the stages a document moves through

This is the heart of the page.

A Lifecycle is an ordered set of stages, with gated edges between them. Every document in a Processing collection carries a current stage. Moving a document from one stage to the next is the unit of progress — and every move is written to the audit trail. A “decision” isn’t something you record separately; it is read straight back from that trail of stage moves. That is the whole point of the Lifecycle: it turns AI output into an auditable business decision.

The default: the 8-stage Four-Eyes flow

Every new Processing collection is seeded with the Four-Eyes lifecycle. Its motto: AI recommends, two humans confirm, the platform remembers. (How the humans in it actually receive and work their queue is Human-in-the-loop.)

#	Stage	Type	Who handles it	Sends to Inbox?
1	Intake	Start	everyone	no — assigned automatically on ingest
2	AI Processing	In-progress	everyone	no — the intake agent is running
3	AI Recommendation	In-progress	everyone	no — branches by confidence / policy
4	L1 Review	In-progress	L1-Reviewer (also visible to L2-Approver)	yes — first human eye
5	L2 Approval	In-progress	L2-Approver	yes — second human eye (the gate)
6	Needs Info	In-progress	everyone	yes — Inbox stage; awaits more info, then re-runs AI Processing
7	Approved	End	everyone	no — terminal (approved)
8	Declined	End	everyone	no — terminal (declined)

Intake (Start)
  │ auto on ingest
  ▼
AI Processing ◄──────────── re-runs when info arrives ──┐
  │ agent done                                          │
  ▼                                                     │
AI Recommendation                                Needs Info (Inbox)
  │                                                     ▲
  ├─ policy ON & confidence passes: auto-decide         │
  │  skips both reviewers ──► Approved / Declined       │ needs-info
  │                                                     │
  └─ low confidence / always ──► L1 Review (Inbox, L1-Reviewer)
                                   │ approve       ├ reject ──► Declined
                                   ▼               └ needs-info ─┘
                                 L2 Approval (Inbox, L2-Approver)
                                   ├ approve ──► Approved (End, terminal)
                                   └ reject  ──► Declined (End, terminal)

About the two reviewers. The Four-Eyes seed creates exactly two personas — L1-Reviewer (works L1 Review) and L2-Approver (works both review stages) — alongside the lifecycle. Personas are a project’s own workflow roles, managed at Studio ▸ Governance ▸ Users & Access on the Personas view. The protected Project Admin role runs the project itself and is separate from any persona. The seeded stages are open to everyone to start with; you narrow them yourself with Can be viewed by (below). Access is covered in Access & roles.

Layout of the Lifecycle tab

One lifecycle per collection. A collection’s Lifecycle tab shows its lifecycle directly — there is no list of lifecycles beside it. A collection that has none shows Add Lifecycle. (The Template Tour still shows a list of lifecycles, with a star on the Primary and + Lifecycle.)
The bar above the lifecycle — the Board, Graph and Table views, the Coverage chip (how many stages belong to a phase), Legends (add a legend), Policy (jumps to the Auto-decide policy card below the graph), + Stage, + Phase, and Save changes — which saves the phases and is enabled only when a phase changed.
Clicking a stage opens a read-only view of it. To change it, click its pencil (Edit Stage); the stage editor saves with Save Workflow Stage.

What every control does

Lifecycle level — the Add Lifecycle / Edit dialog:

Control	What it does	Notes
Name / Description	Identify the lifecycle.	Required.
Collection	Which collection it belongs to.	Prefilled to the current collection.
Set as Primary	Makes this the default lifecycle for the collection.	Exactly one Primary.
Allow Back Propogation	Lets documents move backwards to an earlier stage.	E.g. L2 sends back to L1.
Include StateFlow Change Message	Prompts for a note when a document changes stage.	Captured in the audit trail.
Disable Show Stage History	Hides the per-document stage history.	Default off (history shown).

Stage level — the Create / Edit State dialog:

Control	What it does	Notes
State Name / Description / Final Name	Name the stage.	Final Name is the label shown when terminal.
Workflow State	Start / In-progress / End.	Use one Start. Several End stages are fine — the seeded lifecycle ends in Approved or Declined.
Send to Inbox (human review)	Routes documents reaching this stage to the human work queue (Inbox).	This is what makes a stage a review stage. Routing detail: Human-in-the-loop.
Can be moved to	Target stages — the outgoing edges.	Multi-select.
Can be viewed by	The personas allowed to see and act on documents at this stage.	Leave it empty and everyone in the project can.
Legend	A coloured tag on the graph; inline Create New Legend (Name + colour).	Cosmetic + grouping.
Document View Type	How the document is displayed at this stage.	—
Automation Type	The action this stage runs on entry (11 types).	Summarised next.
Save Workflow Stage	Saves the stage.	Stages save here, not with Save changes.

The personas you pick in Can be viewed by are defined at Studio ▸ Governance ▸ Users & Access on the Personas view — and a persona itself names the stages it works in, so the two screens describe the same wiring from opposite ends.

What a stage can do: the 11 automation types

A stage isn’t only a waiting room — on entry it can trigger one Automation. The picker offers 11 types. Briefly:

Agent Flow — run an agent/agent-team on the doc. AI Pipeline — run an AI pipeline. Rescore — refresh confidence scores. Ingestion — pull data from sources. Export — push the doc out via an export template. Events — fire the collection’s webhooks. RPA Bots — hand to an RPA bot. Conditional — branch to different next-stages by the labels on the document. Auto Allocate Users — auto-assign reviewers. Auto Derivation — compute/auto-fill fields. Regroup Summary — refresh roll-up summaries.

The Conditional type is the workhorse for routing: “if the document carries the label Invoice, go to Invoice Review.” Each block of Label Conditions has a Success and a Failure stage; Sorting documents into types walks through routing by type, setting by setting. Each automation type is configured with its own fields and toggles.

The Auto-decide policy card (Processing collections)

Below the graph sits the Auto-decide policy card — one switch that lets the platform approve (or decline) clean documents without sending them through L1 + L2. It starts off — the card reads “Auto-decide is OFF (Four-Eyes always on)” — and even switched on it only fires when the conditions below are all met.

Control	Starts at	What it means
The on/off switch	off	Off means every document visits L1 and L2.
Min confidence	92%	A slider: the confidence the agent must reach before the platform may decide on its own.
Require zero open flags	on	If any flag is still open on the document, no auto-decision.
Max amount ($)	blank (no cap)	A dollar ceiling above which a person always decides.
Amount field name	—	Appears once you set a max amount: the field the amount is read from.
Applies to	Both approve and decline	Also offers Approve only (recommended start) and Decline only.

The card writes your settings back as a plain-English line, e.g. “Auto-approve when AI confidence ≥ 92% AND zero open flags AND amount ≤ $500.” Save policy commits it. The safest first step most teams take is to switch it on with Applies to = Approve only — let clean cases through, always keep human eyes on declines.

The trail stays honest. When a document is auto-decided, the audit record shows the platform as the actor — not a person — along with the confidence that allowed it. The trail always says who really decided.

What the product checks — and what it does not

The shape of the graph is not checked when you save. There is no Validate button, and nothing refuses a lifecycle without a path from Start to End — keep one yourself. Several End stages are normal.
A stage with documents in it can’t be deleted on this screen — “Stage cannot be deleted. Document(s) are set in this stage.” That check is on screen only. A stage deleted through the assistant or the API is deleted anyway: the documents on it are kept, but still point at the removed stage until you move them.
In the Template Tour, where lifecycles are listed, the list will not switch to another lifecycle after you add, change or delete a stage — it says “Please validate the workflow before proceeding.” Nothing on the screen clears that; reloading the page does.
Phases are checked by the server: when something is wrong with them, a strip above the lifecycle says what.

Watch out — Reset to default is destructive. At the foot of the Auto-decide policy card, Reset to default rebuilds the Four-Eyes flow — 8 stages, two reviewer personas, auto-decide off — and deletes the lifecycle you built. It asks you to type the collection’s id to confirm first. Don’t use it to “clean up” a lifecycle that already has live documents.

How stages move a document (and produce the decision)

Putting it together for one document:

It lands in Intake (Start) automatically on ingest.
The intake agent runs (AI Processing), extracts fields against the taxonomy with a confidence per field, then sits at AI Recommendation.
If auto-decide is on and the doc passes, it jumps straight to Approved/Declined. Otherwise it routes to L1 Review and is sent to the Inbox (Human-in-the-loop covers what the reviewer sees there).
Someone with the L1-Reviewer persona acts; approve sends it to L2 Approval, reject ends it, or it goes to Needs Info — also an Inbox stage, which re-runs AI Processing once more info arrives.
L2 Approval (the second eye) finalises it to Approved or Declined.
Every one of these moves appended a row to the audit trail. The “decision” is that trail — who moved it, when, with what note, at what confidence.

To read the trail: Studio ▸ Governance ▸ Oversight ▸ Audit & Usage for the whole project, or open one document and click the clock icon (Audit trail) for its complete life story.

Tags tab — free-form labels people stick on records

Studio ▸ Data ▸ Collections ▸ <collection> ▸ Tags.

Tags are a small, project-wide set of free-form labels your reviewers apply to documents. Use them to mark things like Duplicate, Missing PO, Wrong Vendor — anything you want to filter or report on later that isn’t an extracted field.

A simple table: each tag’s Name plus Edit and Delete (Delete confirms “Delete ?”).
+ Tag opens the Add/Edit dialog: one Tag name field (required; rejects duplicates with “Tag name already exist”) and Save.
Empty state: “No tags found in the project” with a Tag button.

That’s the whole tab — tags are deliberately simple. Reviewers apply them on the document detail surface (Document detail).

Events tab — fire a webhook when something changes

Studio ▸ Data ▸ Collections ▸ <collection> ▸ Events.

An Event is a subscription that fires an external action (an HTTP webhook, an email, a Slack message, …) when something happens to a document — a lifecycle stage change, a field change, an ingestion failure, and so on. This is how you tell your systems that the platform did something: “POST to our ERP the moment an invoice reaches Approved.”

Left “Events” panel — lists events by Name + trigger; row menu View Event / Edit / Delete; footer + Event.
Right details panel — shows the event’s trigger types, action type, and action details (Webhook URL / email To+Subject / Slack URL).

Creating an Event

Open + Event (the Create Event dialog):

Control	What it does	Notes
Name	Identify the event.	Required.
Events (triggers)	The trigger types — multi-select (stage change, field change, ingestion failure, callback, …).	One event can watch several triggers.
Entity	The collection.	Prefilled.
Workflow + Stage	When a stage-change trigger is chosen, scope it to a specific lifecycle and stage(s).	This is the lifecycle-to-events link.
Jobs (Ingestion-Failure only)	Which ingestion jobs to watch; empty = all.	—
Callback types (Callback trigger only)	Which callbacks fire it.	—
Actions (`+ Add Action`)	One or more actions, each with a Notification Type: Webhook (URL), Email (To + Subject), Slack (URL), etc.	An event can fire several actions.
Show Advanced Settings	Check SLA Breach + SLA Time (sec), Check File Upload, Alert Frequency (min), field filters, user filter.	Use SLA fields to alert when a doc sits too long.

Walkthrough — webhook on “Approved”

Events tab, then + Event. Name: Notify ERP on Approved.
Events trigger — choose the stage-change trigger.
Workflow — Four-Eyes; Stage — Approved.
+ Add Action — Notification Type Webhook — paste your endpoint https://erp.example.com/bm-hook.
(Optional) Show Advanced Settings — set Check SLA Breach + SLA Time if you also want a late-document alert.
Save. From now on, every document that reaches Approved POSTs to your endpoint.

Tip. Two ways to fire a webhook on a stage change: an Event here (set it once, no graph editing — the one to reach for) or an Events automation on the stage itself (Lifecycle tab). Prefer the Event unless you specifically need it bound to stage entry inside the graph.

Try it yourself

Pick one of these on a Processing collection (e.g. the Invoices collection from Collections & schema):

A — an “auto-approve under $500” rule. Open the Lifecycle tab, then the Auto-decide policy card. Switch it on, set Applies to = Approve only, Max amount ($) = 500, and put your total field (e.g. invoice_total) in Amount field name. Save policy. Confirm the line under the controls reads roughly “Auto-approve when AI confidence ≥ 92% AND zero open flags AND amount ≤ $500.” Now clean invoices under $500 skip both reviewers; everything else still goes through L1 + L2.

B — a webhook on approval. Follow the Events walkthrough above to POST to a test endpoint (use a free request-bin URL) when a document reaches Approved. Drive one document to Approved and check the bin received the call.

Either way, open the document’s Audit trail afterwards (the clock icon in the document header) and notice every move that was recorded — that’s your decision record.

Recap

The Taxonomy tab also defines classification fields (Document/Page/Section Classification taxonomies) — categories used later for routing.
A Lifecycle is the ordered stages a document moves through; new Processing collections are seeded with the 8-stage Four-Eyes flow (Intake → AI Processing → AI Recommendation → L1 Review → L2 Approval → Needs Info → Approved/Declined).
A stage has a type (Start/In-progress/End), edges (Can be moved to), persona gating (Can be viewed by), a Send to Inbox switch that makes it a review stage, and one of 11 Automation Types it runs on entry.
The Auto-decide policy card approves or declines clean docs on its own (off by default; confidence + open flags + an amount cap gate it).
Every stage move is written to the audit trail — the platform’s “decision” is that trail. Read it at Studio ▸ Governance ▸ Oversight ▸ Audit & Usage, or per document from the clock icon.
Tags are a simple free-form label set; Events fire webhooks/email/Slack on stage or field changes.
Lifecycle ≠ XFlow. Stages a document moves through, not a processing pipeline — that is what this page covered.

Where to go next

Dashboards & inbox — where the humans you route to in L1/L2 actually do the reviewing.
Human-in-the-loop — how Inbox routing and review assignment work end to end.
Access & roles — the personas that stage-gating depends on (the seeded L1-Reviewer and L2-Approver), and the protected Project Admin role that runs the project.
XFlows & pipelines — the other “workflow”: processing pipelines, not document stages.