Knowledge and Research

You work over folders from the drives your team already uses, like a contracts folder in Google Drive. You choose which folders to ask over inside Research and Structured Query, and each shows exactly where its documents live, down to the folder, so you always know what you are asking across. Your administrators connect the folders that are available and may limit some to certain departments, which is why your list may differ from a colleague’s. Your files never move and their contents are never stored.

On the Research page, write your question, pick the folders to read, and review the preview: how many documents are in scope and roughly how long the run will take. Then run it. If you administer the workspace, you can add folders straight from a connected drive here; everyone else picks from the folders already available. Research reads every document in scope live, where it lives, and never copies it; Sonata stores no full text of your documents and builds no search index over them. What it keeps for an answer is the findings and the exact line from each document it used, so you can check the result against the source.

A single run reads each document closely, so it works best on a focused scope. Two things can make a run decline before it starts, and they are different. The first is a per-run document limit: how many documents one run may read, set by your administrators for the workspace (1 to 1000, 200 by default). If your scope is over it, the run tells you the count and the limit and asks you to narrow your folders or question, or an admin can raise the limit in Policy and access. The second is structural: Sonata scans your folders live each time, so it is never working from a stale picture, and a very large or deeply nested folder structure cannot be fully scanned in one pass. When that happens the run asks you to narrow to fewer or smaller folders, or to split your search across a few runs. This second limit is not a setting an administrator can change.

You watch progress as documents are read, with findings filling in as it goes. The answer arrives with citations linking to the documents themselves and a per-document findings table: each document, whether it was relevant, what it says about your question, and a supporting excerpt. The answer also states its basis plainly, including anything that couldn’t be read. As everywhere in Sonata, it is a model’s read of the documents: verify against the cited sources before relying on it.

Past runs are kept and reopenable, and an interrupted run resumes where it left off. You can delete your own runs (findings are removed; usage records are retained), and a completed run exports to Word as a memo carrying the question, the scope, the cited answer, and the findings.

Research reads and reasons; Structured Query counts. When you need an exact, repeatable answer, like how many agreements expire in 2026 or how many auto-renew, use Structured Query. It works over fields you set up for a set of folders: an administrator defines those fields (agreement type, effective date, whether a contract auto-renews) and prepares the documents once, and the page shows you which fields you can ask about. You ask in plain language; Sonata translates your question into an exact query, shows you how it read it (“Counting documents where Auto-renews is yes”), and runs it the same way every time, so the same question over the same data always gives the same count.

The exact count leads. Beneath it, the honesty is reachable rather than hidden: how many matches rest on a quote that couldn’t be verified, how many documents were left out because the field wasn’t found, and whether any document was only partially read. Each matching document is listed with its supporting quote, so the count is something you can check, not just trust. If you ask about something not tracked, it tells you plainly and names what it does track. If the data needs updating, the answer says so rather than resting silently on stale extractions. Your recent questions are kept and can be re-run.

If you ask about something not tracked yet, it tells you and offers to start tracking it. You suggest the field; Sonata drafts its definition (a name, a type, and a description of what to find), and an administrator reviews and edits that draft before approving it. On approval the field is added to the fields for those folders, which marks the documents as needing an update; an administrator then runs Update (the same deliberate step as any other change, so extraction is never a surprise cost), and once it finishes the new field is a permanent, exactly-queryable attribute backed by citations like every other. It is added the careful way, defined and then extracted with evidence, never answered by a guess.