Extraction schemas and results
The parts of an extraction schema, the statuses a run can return, the limits on drafting a schema with AI and what a draft does with each of its inputs, and who can do what. For what a schema is and how to read a run, see About extractions; for the steps, see Extract information from contracts.
Where extractions live
Extractions are a sub-tab of the Workflows page. The sub-tab appears only where extractions are enabled for your team; if you would like them enabled, please get in touch.
The parts of a schema
| Part | What it holds | Required |
|---|---|---|
| Title | The schema's name, as it appears in lists and in Activity. Given when the schema is created; changed from the schema's ⋮ menu (Edit title and description). | Yes |
| Description | A note on what the schema is for, shown beneath the title in the list. Given and changed in the same places as the title. | No |
| Items to extract | The list of things to find. A schema needs at least one item, complete, before it can be run. | Yes |
Each item has three parts:
| Part | What it holds |
|---|---|
| Label | A short name for the item, e.g. "Termination notice period". This is what names the row in your results and in an export, so keep it brief. Required. |
| What to extract | What the agent should look for, in full, including the shape you want the answer in and any rule every run must follow, e.g. "the notice required to terminate for convenience, not for breach, as a duration like 60 days; the tenant's period, not the landlord's". This is the only instruction the agent gets for the item, so write it to stand on its own rather than relying on the label. Required. |
| Extraction format | Fixes the answer's shape outright. Free text unless you choose otherwise; a line beneath the selector says what each format is for. See below. |
Changes save automatically as you type, including on an item you have only half filled in; "Saving…" shows while a save is in progress. An empty Label or What to extract is outlined in amber, and the run control stays disabled until every item has both.
Notes from the extracting agent
A run may return a short note of its own beneath the results, headed Notes from the extracting agent: an observation about the documents that no item asked for, or a judgement the agent had to make — a term deferred to an agreement that was not supplied, an execution block left blank, a schedule that overrides the body. Each observation names the clause it rests on.
The note is about the documents, so it is separate from the suggestions the agent may leave about the schema's own wording (see Schema feedback). It is never a reason a run fails, most runs have none, and the section appears only when there is something to say. The note is included in an export and in anything you save to your library.
Reports
A report is made from a run's results after the run has finished, by an agent, when someone asks for it. It does not change which items the schema extracts or how their answers are stored, and nothing is produced unless it is asked for.
Every schema has a built-in Standard summary. It works from the results table and the agent's notes only — it does not re-read the contracts — and produces a concise summary of what was extracted, flagging any item that could not be found.
Open the schema's ⋮ menu in the list and choose Customise reports to view the built-in report or to add, edit, and delete reports of your own. A Word report can also be set up while drafting a schema with AI; it arrives with the draft and becomes the schema's when you accept. A report of your own has a name and either written instructions or a Word document from your library. Written instructions might say "Use three short headings for a commercial property lawyer". A Word report fills a copy of the selected document from the saved results and produces a .docx file; additional instructions are optional. The selected document supplies structure and wording, rather than evidence about the contract. Its example values are not findings, and unavailable information is identified in the report. The source document remains unchanged. Unlike the built-in, your instructions may tell the agent to read the source documents where it needs to.
There are two ways to ask for one:
- When you start a run. Tick any reports under Also produce. Nothing is ticked to begin with. Each ticked report is produced as soon as the run completes.
- From a completed run. Select Produce in the Reports section of the run's window and pick a report.
Each report is kept with the run, in its own Reports section rather than among the run's attachments, and has its own Save to documents so you can keep it in your library, filed by default in the collections the run's documents belong to. Producing the same report again adds another rather than replacing the first; the Reports section shows one row per report with its newest version, and N earlier on that row opens the older ones. Every report records the instructions it was produced from, so one you produced today still says what shaped it even if you later change or remove that report.
Extraction formats
| Type | Use it for | Shown in results as |
|---|---|---|
| Free text | A free-form answer in the agent's words: a name, a phrase, or a short passage. | As written. |
| Date | A single calendar date: a signing, commencement, or expiry date. Not for durations like "30 days". | Day, month, and year, e.g. 14 Mar 2026. |
| Number | A bare number with no unit: a count, a percentage, a duration in days or years. Not for money. | The number. |
| Currency | A money amount with its currency: rent, a fee, a deposit, a cap on liability. | The currency code then the amount, e.g. GBP 125,000. |
| Custom set | One of the values you list, e.g. Office, Retail, Industrial, when the answer is always one of a few options. Enter each value and press Enter; paste a comma-separated list to add several. | The chosen value. |
Export → CSV writes the values as they are shown in the table; Export → JSON writes the underlying stored values: dates in year-month-day form, bare numbers, and an amount with its currency code.
Result statuses
Every completed run shows one row per item in the schema, with one of these statuses.
| Status | Meaning |
|---|---|
| Found | The value was located in the document. |
| Not found | The document does not contain the information. A definite answer, not a failure. |
| Not applicable | The item does not apply to this document. |
| Failed | The agent could not complete the item. |
| Unaccounted | The run finished without answering the item at all. Treat it as unresolved: re-run the schema, or check the item's wording. |
Each row also carries the Value, the Sources (each names one clause; select one to read the quoted passage and open the document), and the agent's Notes. Sources come in two kinds: the clauses that state the value, shown first, and supporting passages the value depends on — a defined term, a schedule, a clause the first one refers to — folded behind a count. Select a row to see everything in full beside the table, including what the item asks for; Side by side places the document beside the results, and a report opened with Preview in that arrangement takes the document's place on the left while the document stays on the right. Column widths can be dragged and are kept for your next visit. A filter row beneath the headings narrows the table by text in any column or by status; filters change only what is shown, never what an export or a report contains. A row marked Feedback drew a suggestion from the agent about the item's wording; select the marker to jump to it. See Schema feedback.
If a run completes but its reply cannot be read as a table, the run is kept, marked as such, and the agent's raw reply is shown in full in place of the grid.
Models
Both running a schema and drafting one with AI use the thorough model setting.
Limits on drafting with AI
A draft starts from a requirements document, a description, or example documents, and you can add example documents to either of the first two. The limits:
| Limit | Value |
|---|---|
| Inputs | A requirements document, a description, or at least one example document. |
| Length of a requirements document or description | At most 100 pages. |
| Example documents | At most 4. |
| Combined length of the examples | At most 120 pages, a page being roughly 3,000 characters of text. |
A page here is a unit of text, not of paper: a densely typed contract page runs to about one, and a sparse one to less. A requirements document with no readable text yet, or one over its limit, is refused when you select it, as is a selection of examples that exceeds the page limit, so you can choose again before requesting the draft; the limits are checked again before any work starts.
What a draft does with your inputs
The window first asks Do you already know what you want to extract? Your answer sets the inputs. If you do, you either select a requirements document from your library or describe the information you need — the two do the same work — and can then add example documents. If you don't, the agent works from example documents alone, and with two or more selected the window also asks Should the agent focus only on differences? The table says what the proposal contains for each combination. The agent works by reading: these are the rules it is asked to follow, not checks the system performs.
| Inputs | The proposal contains | Left out |
|---|---|---|
| Example documents only | The terms a reader of that kind of document needs — the parties, the dates, the term, the money, and how it ends — then the terms particular to the document type, each grounded in a clause of an example document, in the order the document presents them. Typically 12 to 25 fields. | Boilerplate: notices, counterparts, governing law, jurisdiction, dispute resolution, and the like. Nothing is listed under Excluded. |
| Example documents only, focusing on differences | One field for each term whose value differs between the documents, in the order the form presents them, each flagged as varying and carrying the value found in every document. | Every term that is the same in all the documents, boilerplate or not. These are not listed under Excluded. |
| A requirements document or a description, with example documents | The rows of your requirements a document can answer, each typed, worded in the example documents' vocabulary, and grounded in an example, plus additions the agent proposes for what your requirements missed. | Rows a document cannot answer, each listed under Excluded with a reason. |
| A description alone | The rows of your description a document can answer, each typed and worded in your description's vocabulary. No evidence is attached, as there are no documents to quote. | Rows a document cannot answer, each listed under Excluded with a reason. |
| A requirements document alone | The rows of your requirements a document can answer, each typed and worded in your requirements document's vocabulary; its layout — blank answer cells, office-use boxes, sign-off lines — is not a row. No evidence is attached, as there are no documents to quote. | Rows a document cannot answer, each listed under Excluded with a reason. |
A requirements document and a description do the same work, with or without example documents:
- A row is kept if a document can answer it and otherwise listed under Excluded with a reason you can act on.
- An answer policy in your requirements, e.g. "stated dates only, never derived", is written into the field's What to extract so every later run follows it.
- A row that asks for a judgement against a standard, e.g. "a non-standard indemnity", is kept only if your requirements state the standard; otherwise it is excluded with a note on what you would need to add.
- Boilerplate your requirements ask for is kept, though the agent would otherwise leave it out.
- Where your requirements call for a choice list but leave it blank, the agent proposes the values and says so in its reasoning.
- Field names and notes follow your requirements' vocabulary; without requirements they follow the documents'.
The draft carries the name you gave when you requested it, in the list while it awaits review and as the schema's title when you accept it; the agent's own suggested title is not used. A description you gave is kept too; leave it empty and the agent's description stands.
Schema feedback
A run may leave suggestions about the schema's own items, addressed to whoever maintains it. An affected item shows an amber ! marker and the number of open suggestions; suggestions about the schema as a whole use a separate marker beside the items heading; and the schema's row in the list carries the same marker; hover it for the total, split between items and the schema as a whole, and select it to open the schema at the first affected item. Select a marker to open the suggestion history, newest first. Each entry says, in plain words, what got in the way ("Instruction needs clarifying", "A value is missing from the list", "Needs a standard to judge against", "Answer doesn't fit the chosen format"), the change the agent would make, and which run it came from. The modal also shows the current item so you can compare it with the suggestion.
Earlier version means the item has changed since that suggestion was raised. It remains in the history, but can no longer be applied automatically. Version unknown marks older feedback for which no item snapshot is available. A newer suggestion does not replace an older one merely because it arrived later: when both concern the same item wording, both remain open for a decision.
Feedback is advisory: it never changes a run's results, and the agent never edits a schema. The owner may ask AI to draft an amendment, which can replace one item or split it into as many as 10 focused items. The proposed amendment remains a review step until the owner accepts it.
Every decision remains in the history as Applied, Dismissed, or Superseded. A dismissed suggestion can be reopened; an applied or superseded one cannot, because those record a change to the schema. The history is reachable at any time from Suggestion history in the schema's Other actions menu, whether or not anything is open. Later runs may raise new suggestions.
The Word document must have an available .docx version when selected and when the report is requested. Each request uses the version selected at that point; adding another version afterwards does not change a report already being produced.
Who can do what
| Action | Schema owner | Colleague |
|---|---|---|
| Read the schema | Yes | Yes |
| Run it | Yes | Yes |
| Edit its title and items | Yes | No — fields are locked |
| Manage its reports | Yes | No — reports can be viewed |
| Duplicate it | Yes | Yes — the copy is theirs to edit |
| Delete it | Yes | No |
| See its runs and results in Activity | Yes | Yes |
| Read schema feedback | Yes | Yes |
| Apply, dismiss, or reopen feedback | Yes | No |
A draft awaiting review is visible only to the person who requested it — team administrators included — and cannot be run until it is accepted. Your own schemas are listed to begin with; Show team schemas brings your colleagues' into the list under Team schemas. Deleting a schema keeps its past runs and their results in Activity.