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 collection except a Knowledge collection is seeded with the Four-Eyes lifecycle — on screen it’s named after your collection, “Four-eyes review — <collection name>” (so on a Vendor Invoices collection it reads “Four-eyes review — Vendor Invoices”). The seed describes it as AI recommends, two human reviewers (L1 + L2) confirm. (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 — a stage on the graph; nothing moves a document here by itself
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; waits there until a person acts
7	Approved	End	everyone	no — terminal (approved)
8	Declined	End	everyone	no — terminal (declined)

Intake (Start) — the intake agent runs while the document sits here
  │  Auto-decide then writes the document straight to its stage:
  ├─ needs-info / unknown word (on or off) ──► Needs Info (Inbox)
  ├─ policy ON & the doc passes (skips both reviewers) ──► Approved / Declined
  └─ otherwise ──► L1 Review (Inbox, L1-Reviewer)

The seeded edges (the moves the graph allows; a persona with a Stages list can make one only into a stage on that list):
  Intake ──► AI Processing ──► AI Recommendation
  AI Recommendation ──► L1 Review / Approved / Declined / Needs Info
  L1 Review   ├ approve    ──► L2 Approval (Inbox, L2-Approver)
              ├ reject     ──► Declined (End, terminal)
              └ needs-info ──► Needs Info
  L2 Approval ├ approve    ──► Approved (End, terminal)
              ├ reject     ──► Declined (End, terminal)
              └ send back  ──► L1 Review
  Needs Info  ── a person moves it back ──► AI Processing

No document passes through AI Processing or AI Recommendation by itself: they are stages on the graph, and Auto-decide writes a document straight from where it sits, so the timeline reads, for example, Intake → Approved. Nothing moves a document out of Needs Info by itself either. Once the information is in, select the document on the document list and choose Rescore from the list’s options: the collection’s intake agent reads it again, and Auto-decide routes it from where it is. A project admin can do this, or anyone whose persona has the Run the AI again on documents switch; the seeded reviewer personas don’t have it. The document header shows a Rescore icon only when Rescore Document is added to Document Icons at Studio ▸ Experience ▸ Appearance ▸ Documents Page; a new project’s header doesn’t have it. Moving a document back to AI Processing by hand runs nothing on its own.

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.

Watch out — five stage names are load-bearing. Don’t rename L1 Review, L2 Approval, Needs Info, Approved or Declined. Automatic decisions don’t find a stage by where it sits on the graph; they find it by its name, spelled exactly as the seed spelled it, capital letters included — retyping “L1 review” is enough to break it. Every document auto-decide routes is sent that way, whether Auto-decide is on or off: a needs-info verdict, or a word the gate doesn’t know, asks for the stage named Needs Info; with Auto-decide on, an approve or decline that passes the policy asks for Approved or Declined; and every other document asks for L1 Review. When the name a decision asks for isn’t there the document usually doesn’t move at all, and nothing on screen tells you why — rename L1 Review and every document that should have landed in that queue simply stops where it was processed. The one exception is a document on its way to review in a lifecycle you built yourself: if the document’s next step leads straight on to exactly one stage whose Workflow Type is Automated with Automate By Previous Stages switched off, the document is sent there instead and that stage runs — right for your own design, wrong for a Four-Eyes collection waiting on its review queue. If two such stages are on that next step, it doesn’t move. A missing Approved, Declined or Needs Info is never sent on anywhere. The readouts key off the same five names: rename one and its documents show a generic In progress or Completed instead of Approved, Declined, Awaiting L1 review, Awaiting L2 review or Needs info, and the collection’s needs human count stops finding them. Only the finished count is name-blind — it counts any stage whose Workflow State is End, so Approved and Declined still count as finished under a new name. Want your own word on screen? Fill the stage editor’s Alias Name and leave State Name alone. A document’s stage stepper and the move choices on its action pane show the alias; the Lifecycle tab’s Board, Graph and Table views and the stage pickers (the document stage filter, the stage editor’s own stage lists) keep showing State Name, and routing still runs on it.

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.
Alias Name	An optional display name. Blank falls back to State Name.	The safe way to put your own word on a seeded stage — routing and the readouts still use State Name.
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.	—
Workflow Type	Manual (a person moves documents on) or Automated (the platform may move a document on to it by itself).	Not the same as Automation Type below, which is what the stage runs on arrival.
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 auto-decide decides no document: every document the intake agent writes back goes to L1 Review, except one whose `recommendation` is `needs-info` (or a word the gate doesn’t know), which goes to Needs Info. From L1 Review, only a document the reviewer approves goes on to L2 Approval.
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.

What the trail shows. When Auto-decide moves a document, the move is written to the document’s timeline, stamped with the auto-decide service address. The trail counts this address as a person (it reads every address with an @ in it as a person, except the workflow engine’s own), so the move shows a Human actor, not a machine. The confidence that allowed it is not stored on the row, and the move does not appear in the project audit feed. Human-in-the-loop says what that means before you promise an auditor anything.

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. If the agent’s recommendation is needs-info, or a word the gate doesn’t know, it goes to Needs Info instead, whether auto-decide is on or off. 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 sends it straight to Declined (the end, with no L2 step), or it goes to Needs Info — also an Inbox stage, where it waits until someone runs Rescore on it (see above for who can). The seeded L1-Reviewer and L2-Approver are made once per project, for its first Four-Eyes collection, and hold that collection’s stages; a later collection’s seed reuses them and adds no stages, so these steps are for a project with one Four-Eyes collection. On a project with two, the persona editor lists each stage name twice and can’t tell the copies apart, so these steps don’t apply there. A persona with a Stages list can move work only into a stage on it (an empty list leaves it unrestricted), and the seeded L1-Reviewer’s holds only L1 Review. So first set that persona’s Stages to L1 Review, L2 Approval, Declined and Needs Info, and leave May move into empty; the cost is that the persona then also sees the documents in those stages. A list in May move into replaces Stages for moves and must also hold the stage a document leaves, and the action pane offers only the Stages list. A project admin is not restricted, though one who also holds a persona with a Stages list is shown only that list’s stage buttons.
L2 Approval (the second eye) finalises it to Approved or Declined, or sends it back to L1 Review. The seeded L2-Approver’s Stages list holds L1 Review and L2 Approval, so first set it to L1 Review, L2 Approval, Approved and Declined, again with May move into left empty; the persona then also sees the documents in Approved and 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, one per kind of thing that can happen (a stage change, a field change, an ingestion failure, a callback, …). The stage-change trigger is named “`<X>` State”, with the project’s own word for “Document” substituted for `<X>`. There’s no field on this dialog that sets that word: it is the name of the view or menu you opened when that names a collection, else the project’s own word for its documents, and “Documents” when the project hasn’t set one. A project whose word is “Invoice” sees “Invoice State”; an untouched project reads “Document State”.	One event can watch several triggers.
Entity	The collection.	Prefilled.
Workflow	When a stage-change trigger is chosen, pick the lifecycle whose stages the Stage list offers (e.g. `Four-eyes review — Vendor Invoices`, the seeded Four-Eyes flow’s real name on a Vendor Invoices collection).	A field of its own, separate from Stage below. It only narrows the Stage list: the Event matches the stages you pick.
Stage	Within that workflow, the specific stage(s) this event watches, picked by name (e.g. `Approved`).	Multi-select. The Event fires on a move into one of these stages.
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 review — Vendor Invoices; 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 a person moves into Approved POSTs to your endpoint, as long as Check SLA Breach is left off: with it on, a move a person makes never counts as late, so this Event never POSTs. A document that Auto-decide moves there by itself does not raise this Event today.

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. Neither fires when Auto-decide sends a document straight to L1 Review, Approved, Declined or Needs Info by itself: that move raises no Event and runs none of the stage’s automations today. The one exception is the step in the Watch out above: in a lifecycle you built yourself, a document on its way to review that is sent on to an Automated stage instead. That is an ordinary move, so it fires the stage’s Events and runs the stage.

Try it yourself

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

A — an “auto-approve up to $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 of $500 or less can skip both reviewers. The gate reads two keys in the agent’s reply: a recommendation and a confidence. With Applies to = Approve only, an approve (capital letters don’t matter) with a confidence of at least 0.92 (the 92% on the card, written as a number from 0 to 1), on a clean invoice of $500 or less, is approved by itself. An approve that misses any of these goes to L1 Review. A decline goes to L1 Review. A needs-info, or any word the gate doesn’t know (such as approved), goes to Needs Info whatever the confidence. A reply with no recommendation goes to L1 Review. That confidence is one number the agent gives for its whole answer — it is not the confidence per field from step 2 of How stages move a document. Everything else waits for a reviewer in L1 Review, and only what L1 approves goes on to L2 Approval.

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. Move one document from L2 Approval to Approved yourself (on a project with one Four-Eyes collection, as a project admin, or with a persona whose Stages list includes L2 Approval, so it sees the document there, and Approved) and check the bin received the call — if you also did A, an invoice A approves by itself sends nothing.

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.