Run your first packet
Start a case, drop the packet in, take the gate, and read what was filed.
Start a case
Open Applications and choose New application. Give the applicant's name and pick the expected document list the case must satisfy. The case copies that list at this moment and keeps its copy, so later edits to the list never change a case underneath you.
Drop the packet in
Open the case and drop one or more PDFs on it. Each file is stored as it arrived and never altered. Renaming or archiving a file changes its record, not its bytes.
As files land, pre-flight checks them: page count, scan resolution, blank and duplicate pages, and any file the case already has. Anything that will read badly is flagged before any money is spent on reading.
Take the gate
Nothing is analyzed until someone takes the gate. That is the one decision that spends money, and it is recorded with your name.
- With no red flags you confirm the file set. With red flags you either fix the files or explicitly process anyway. The two are different decisions and the ledger keeps them apart.
- Choose a workflow and the run goes unattended: it previews, parses, identifies, files what it is confident about, and extracts. See workflows.
- Without a workflow you go step by step: a cheap preview proposes the documents in the packet, you pick which to read in full, and you file the results yourself.
Read the result
| Lens | What it shows |
|---|---|
| Review | The latest run: each document it found, its pages, and the suggested filing. |
| Triage | What still needs a person, most urgent first. |
| Documents | Every document the case holds, filed or unmatched, across all runs. |
| Register | The expected document list with what is filed against each line, and what is missing. |
A filed document is a PDF cut from the packet, stored with a text version that records where every page came from.
The same thing without the app
Everything on this page is one API call plus a poll. See the API quickstart.
Sheaf