Sonata

Documentation · For administrators

Setting up Knowledge

Knowledge works over folders in the drives your organization already uses. You connect a drive, point at the folders your team should be able to ask over, and those documents become available in Research and Structured Query. Files never move and their contents are never stored, only a metadata inventory.

Pointing at folders

Connect a cloud drive (Google Drive today) and point at the folders your team works with by browsing to them. A folder is referenced by its stable identifier, so renames and moves do not break it, and its path is shown as provenance wherever it appears. Sonata keeps a metadata-only inventory of what is there (titles, types, sizes, links), never document content, and reads documents live at question time, so it always works from the current files. Search-style sources, like a public case-law service, are not folder material; they belong to a different, future part of Research.

Who can use which folders

Folder access is governed: some folders are available to everyone in the organization, others limited to certain departments, enforced at the database, not just hidden in the interface. An administrator manages the curated folder collections, which drives they draw from, and who can see them, under Policy and access in the Knowledge and access area. Letting members add their own folders is a setting still on the way; today setting up folders is administrator-only.

Research and Structured Query

Two tools ask over the folders you choose, and they differ by design. Research reads and reasons: non-deterministic, weighing and interpreting like a careful analyst, the right tool when a question needs judgment rather than a count. Structured Query answers exactly: deterministic, so the same question returns the same precise, repeatable count every time. Both read documents live and cite a short supporting quote so an answer is verifiable.

Optional depth: exact answers

Structured Query has an optional setup applied to a set of folders, so it can answer exact questions over them. You define the fields worth tracking, each a name, a type (text, number, date, yes/no, or one of a fixed set), and a plain-language description of what to extract, like “the contract version number, often labeled Version near the title.” The description is what later finds the field, so it is worth writing well, and a field’s name can be edited freely without losing anything tied to it. Then Prepare reads each document and pulls those fields out, storing each value with a short verbatim quote that is checked against the source, so a value you can see is a value you can trace. A field not present in a document is recorded as not found rather than guessed. The first run is Prepare; afterwards Update re-reads only what changed (a document edited upstream, or a field you added), and leaves current data as it is. This depth is opt-in: Research needs none of it.

How the pieces fit

The setup is organized around one idea: pick folders, ask. You pick folders directly in Research and Structured Query, where you use them, and Structured Query’s define-fields and prepare are available right there as opt-in depth. An administrator curates the named folder collections and their access centrally, under Policy and access in the Knowledge and access area; the legacy Collections page now sends you to whichever of those is right for your role.

All documentation · Everything above describes the product as it ships today. If something here doesn’t match what you see, tell us.

← Back to documentation