Core concepts
Sea has a small set of objects. There are two things you do with them: extract structured data from documents, and ask questions about data you have already captured. This page explains each object and the distinctions that are easy to miss.
The objects
Form
A definition
The schema of the data you want to capture: the fields, their types, and the prompts used to extract them. A form is fixed. You change it only when you want to change what gets captured, in the app or over the API. One form (for example a Balance Sheet or a Valuation Report) is reused across many submissions.
Submission
An instance of a form
One form applied to a single case, holding the extracted data. Upload documents and Sea extracts the form's fields from them, each with a citation back to the source. This is one-shot extraction: documents in, structured data out. Submissions can be updated as new documents arrive, and prioritise the most recent input. Start here.
Deal
A grouping with shared context
Groups the submissions and documents for one customer, case or opportunity. It shares static context across every submission in the deal, and it is the unit Chat queries across. A deal does not automatically copy data extracted from one submission into another. Tag it with your own refId to address it by your identifier.
Chat
Query what you have captured
A general-purpose, agentic endpoint. It answers questions and reasons over data you have already captured, rather than extracting it. Give it one or more submissions, or a whole deal, as context and it can query, compare and interact across them. It is the API behind the Agents area of the app.
Pipeline
Automate the flow
Chains several steps (extraction, integration and analysis) into an automated, multi-document flow. A run advances on its own as documents and inputs arrive, pauses at any step that is blocked, and resumes when the blocker clears. Every value keeps a citation chain back to its source, and results can be delivered to an endpoint you own.
Workflow
A workspace
Groups related forms and submissions, so the work for a given process or team stays together.
Two distinctions worth getting right
Forms vs. submissions
A form is the definition; a submission is an instance of it, with data. You edit a form only when you want to change the schema of the extracted data or the prompts that extract it. Submissions, by contrast, are created and updated continually as documents arrive.
Extraction vs. chat
Submissions turn unstructured documents into structured data in one shot. Chat is a general-purpose agentic endpoint for querying and comparing data you have already captured, across a deal's submissions. If you are unsure which you need, start with submissions and add chat once your submissions are refined.
Common questions
Do I need to update the form each time a new document arrives?
No. The form definition changes only when you want to change what gets extracted (the fields or the prompts). The data lives on submissions, which update continually. You can generate or update form definitions over the API, so they can track your own application schema automatically.
Should I use /submissions or /chat?
Use /submissions to convert documents into structured data. Use /chat to ask questions about data already captured on a deal or its submissions. Start with /submissions; it is the one to reach for first. Note that the submissions extraction is designed to prioritise recency.
If I put two submissions in the same deal, do they share their data automatically?
Not automatically. A deal shares static context across its submissions, and lets Chat query across them, but each extraction stays focused on its own documents. There is no automatic sharing of extracted data from one submission into another.
Can I load my own structured data as context for Chat?
Yes. You can add individual submissions (structured data) or a whole deal, with all its submissions, as context for the chat endpoint, then ask it to query or compare across them.
Ready to build? See the Quickstart guide and the API reference.