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 (or the + Taxonomy header button):

Click Taxonomy (footer) to open Create Taxonomy. Give it a Name and Description.
Set Type to one of Document / Page / Section / Table Classification, pick the Entity (collection), and Submit.
Select the new taxonomy, open the Fields sub-tab, click the add button (labelled Label, or whatever your workspace calls a field).
Enter the category as the Label Name (e.g. Invoice) and a Description (both required).
Show Advanced Settings reveals the same six accordions as any field (Table Styling, Contextual Insights, Record Config, Toggles/Features, Lookup Config, View Config). 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

Left “Lifecycle” panel — lists the collection’s lifecycles by Name + Description; a star marks the Primary. Row menu: Edit / Delete (Delete is hidden for the Primary). Footer + Lifecycle to add one.
Right pane — the stage graph (drag to reorder, click a stage to open its editor), a Show Legends strip (Start / Conditional / End markers), a Validate button that checks the graph, and — for Processing collections — the Auto-decide policy card.

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.	Exactly one Start, one End.
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.

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 field value. 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 document_type = Invoice, go to Invoice Review.” Each 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.

Validation rules

Before you can switch lifecycles or save, the lifecycle must be a valid graph:

Exactly one Start and one End stage.
At least one Start → End path.
No unterminating cycles.
A stage can’t be deleted while documents currently sit in it.

If it’s invalid you get the toast “Please validate the workflow before proceeding.”

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.