Sheaf
Workflows
A saved recipe of steps and models. Attached at the gate, it lets a run go from packet to filed documents with nobody present.
A workflow is a named, versioned recipe: which steps a run performs and which model each step uses. Workflows are built under Workflows in the app. One of them is the organization's default.
Steps
| Step | What it does |
|---|---|
| Preview | A cheap first pass that proposes where the documents in the packet begin and end. Optional. |
| Parse | Reads the pages in full. Required. |
| Classify | Composes the read pages into documents, names them, and matches them to the expected document list. |
| Judge | An independent second opinion on each document, with a confidence. |
| Extract | Pulls field values using the document schema for each document type. |
Steps run in order. There is no branching, on purpose.
Versions
Like lists, a workflow version is a draft until activated and frozen once active. Only an active version can run. Publishing a new version changes what the workflow does without changing its id, so whoever calls it keeps calling the same thing.
What attaching a workflow means
Taking the gate with a workflow attached is a single consent for the whole chain. When the run lands, the workflow files and approves everything it recommended, and the ledger records those decisions as made by Workflow, under the identity of whoever took the gate.
What it will not do: override red flags at the gate, reject a document, or delete anything. Those stay with a person. Anything the workflow was unsure of is left unfiled in Triage.
Over the API
GET /workflows lists your workflows and their versions. Each one is addressable by id the moment it has an active version: see run a workflow.