About extractions
An extraction schema is a reusable list of the pieces of information you want pulled out of a contract. Each item names one thing to extract — a notice period, an annual rent, the parties — pairing a label that names the row in your results with a fuller statement of what the agent should extract, including the form you want the answer in. An item can also fix the answer's shape: a choice from a list you supply, a date, a number, or a currency amount. When you run the schema against a document, an AI agent works through every item, searches the document for it, and returns an answer for each one, linked to the clause it came from.
Write a schema when the same questions come up again and again: the key terms you check on every lease, the data points a client asks for across a portfolio, the fields you fill into a report for each new matter. Once written, a schema runs against any document as many times as you need. The parts of a schema, and every limit and rule, are listed in Extraction schemas and results; the steps are in Extract information from contracts.
Two ways to write a schema
You can build a schema by hand, item by item, or have an agent draft it from a requirements document or description of your own, from example documents of the kind you want to extract from, or from both. See Draft a schema with AI.
The two inputs play different parts. Documents show the agent the form: what that kind of document contains, in what order, and in what words. A requirements document or description carries your intent: what you need out of it. Given both, the agent shapes your list to the documents, typing each row and wording it as the documents do. When the documents are several instances of one standard form, the wording they share tells you nothing about any one of them, so when you draft from examples alone you can ask the agent to focus only on differences, proposing fields only for the terms that change between them. What each combination of inputs produces is set out in What a draft does with your inputs.
A draft is a schema in waiting. The agent returns the fields it suggests, with the evidence it found for each and the rows of your brief it left out and why. You review the proposal field by field, keep or drop each one, and edit anything you like, and your edits save as you go. Until you accept it, the draft cannot be run and only you can see it. The agent never publishes a schema on its own.
A run happens in the background
Running a schema does not answer you on the spot. The run goes off on its own — typically for a minute or two — and its results arrive in Activity, alongside your team's other agent work. The Extractions page is where schemas are written and run; results are always read in Activity. See Track agent runs.
What a result tells you
A completed run shows one row per item in your schema: a status, the extracted value, the sources it was drawn from, and the agent's notes. The full list of statuses is in Extraction schemas and results; three distinctions matter when reading them.
"Not found" is an answer. The agent asserts that the document does not contain the information. That is a definite finding, and often a useful one — the notes may say what the document has instead.
"Unaccounted" is not. It means the run finished without answering the item at all. Nothing was found and nothing was ruled out, so treat the item as unresolved rather than answered.
Sources and notes carry the weight. Each source names the clause and quotes the passage, so you can check any value against the contract in one step. An answer with no source deserves more care than one with several. The notes hold the agent's caveats — ambiguities, conflicting clauses, assumptions it had to make — and are often where the legally interesting detail lives.
The agent's own notes. Where the agent has something to say about the documents that no item asked for — a term deferred to an agreement you did not supply, an execution block left blank, two clauses that pull against each other — it leaves a short note beneath the table under Notes from the extracting agent, naming the clause. Most runs need none, so the section appears only when there is something to say. These notes are about the documents; points about the schema itself are separate — see Suggestions about your schema.
Reports
A report is something made from a run's results afterwards, on request: a summary in prose, or whatever else you have told an agent to make of the table. Nothing is produced unless you ask for it — the results are the deliverable.
Every schema comes with a built-in Standard summary, which works from the results and the agent's notes alone and never re-reads the contracts. The schema's owner can add reports of their own, including ones that do read the documents. Tick the reports you want under Also produce when you start a run, or produce any of them later from the run itself, as often as you like. Each report is kept with the run and can be saved to your library like any other output. The details are in Reports.
Suggestions about your schema
Sometimes the difficulty is in the question rather than the document. An item's wording may allow two readings that give different answers, a list of choices may have no entry for what the contract plainly says, or an item may ask for a judgement the document alone cannot support. When the agent meets a difficulty like that, it can leave a short suggestion for whoever maintains the schema: what got in the way, and the change it would make.
These suggestions are advisory. They never change a run's results, and the agent never edits your schema. They gather under the items they concern, across every run of the schema, so a point raised on three runs out of four stands out from one raised once. Acting on them is described in Extract information from contracts.
Your schemas and the team's
Every schema has an owner. Your own you can edit, run, and delete. A colleague's you can read and run, but not edit — duplicate it to make your own editable copy. The full permissions are in Extraction schemas and results.