> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudsquid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Tables: reconcile, storage, extraction

> Reconcile tables run your processes, storage tables hold your master data, extraction tables structure documents at volume.

Every project contains tables, and tables are typed. The type determines what a table is for, what operations it supports, and how the agent uses it.

Start with the one that does the work.

## Reconcile tables

A **reconcile table** is where a process runs. Each row is one **case**: an event came in, the agent worked it following your [SOP](/concepts/sops), and the row holds the result — output fields, the reasoning, the actions taken, and a review status.

An order arrives as a PDF. That's one row. The agent reads the document, queries your customer master, applies the match rules, fills `customer_number` and `match_status`, notes why, and hands the case to review.

**What you configure** (in the table's **Configure** view):

| Setting                  | What it does                                                                                                                  |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| **Operating Procedures** | The agent's standing instruction for this table. Keep it short and point at the SOP — the real procedure belongs in `SOP.md`. |
| **Output Fields**        | The structured result the agent produces per case. Each field has a name, a type, and a description the agent reads.          |
| **Data Access**          | Which storage and extraction tables this agent may query. It can only touch what you grant.                                   |
| **Connectors**           | Which connected systems this agent may use from its environment.                                                              |
| **AI Model**             | The model tier for this table: **Fast**, **Balanced**, or **Powerful**. See [the agent runtime](/concepts/agent-runtime).     |
| **File Outputs**         | Lets a case produce files, not just field values — a drafted document, an export, a generated report.                         |
| **Auto Review**          | Turns on [agentic approval](/concepts/review-approvals): a second agent validates each result before it needs a human.        |

**Input.** A case can carry files (documents to work from), structured data (a JSON payload), or both. Reconcile tables take files directly — you do not need an extraction table in front of them.

**Statuses.** A case moves `Running → Agent Done`, then through review to `Approved`, `Needs review`, or `Rejected`. See [Review & approvals](/concepts/review-approvals).

**Unit of work.** Usually one reconcile table per process. If your process has distinct steps that each deserve their own record, model the steps as tasks in one shared table rather than splitting into many tables.

**Key API operations:**

* Create a task (without running it) → `POST /projects/{name}/tables/{id}/tasks` → returns `task_id`
* Run reconciliation synchronously → `POST /projects/{name}/tables/{id}/reconcile`
* Use the [async run pattern](/concepts/async-run-pattern) with the `row_id` from a task

**Input format:** `AgentJobInput` — pass `files` (references to extraction table rows by UUID) and/or `data` (arbitrary JSON payload).

***

## Storage tables

A **storage table** holds reference data: your customer master, item master, price lists, PO headers, carrier codes, GL mappings. It's the "against what" of every matching process.

The agent queries storage tables directly with SQL from its environment — it is not handed a pre-filtered slice. That means it can look up, join, count, and check candidates the way an analyst would, but only in the tables you granted under **Data Access**.

**Make your columns legible.** The agent reads your schema to understand your data. `postal_code` and `vendor_item_number` are useful; `col_7` and `f3` are not. Add a description to any column whose name isn't self-explanatory.

**Keeping it fresh.** Load a CSV by hand, push rows via the API, or sync from a source system on a schedule with a [workflow](/concepts/integrations).

**Key API operations:**

* Upload or overwrite a CSV → `PUT /projects/{name}/tables/{id}` (mode: `overwrite` or `append`)
* Insert rows as JSON → `POST /projects/{name}/tables/{id}/data`
* Read rows → `GET /projects/{name}/tables/{id}/data`

***

## Extraction tables

An **extraction table** turns documents into structured rows at volume. One row per file, one column per extraction task, a schema you define. It's a helper, not a process: it structures, it doesn't decide.

**When it earns its place:** high document volume with a stable shape, where pre-structuring is cheaper and faster than having the agent read every file from scratch — or when structured rows are the deliverable themselves.

**What it gives you:**

* Nested output: a header record plus its line items in one row.
* A side-by-side source view — every value next to the page it came from.
* **Run AI** on selected rows only, so re-running after a schema change is cheap.
* Optional **bounding boxes** (where in the document each value came from) and **Review mode** (a human approval gate before rows are considered final).

**Settings:** `active_pipeline` (see [Extraction pipelines](/concepts/pipelines)), `bounding_boxes`, `review_mode`.

**Key API operations:**

* Upload a file → `POST /projects/{name}/tables/{id}/files` → returns `row_id`
* Start an AI run → `POST /projects/{name}/tables/{id}/run` → returns `run_id`
* Poll for results → `GET /projects/{name}/tables/{id}/run/{run_id}`
* Extract synchronously → `POST /projects/{name}/tables/{id}/extract`

See the [extraction quickstart](/quickstart-extraction).

***

## How they chain

**The common case — files straight into the process:**

```
documents ──▶ reconcile table ──▶ review ──▶ output
                    │
                    └── queries ──▶ storage tables (master data)
```

The reconcile table takes the files, the agent reads them, queries master data, and produces the case. Two table types, no pre-processing step.

**Adding extraction, when volume calls for it:**

```
documents ──▶ extraction table ──▶ reconcile table ──▶ review ──▶ output
                (structured rows)         │
                                          └── queries ──▶ storage tables
```

Extraction structures the documents first; the reconcile table receives rows instead of raw files. Same process, less work per case — worth it once you're running thousands of similar documents.

<Tip>
  Start without the extraction table. Add it when per-case latency or cost tells you to, not before.
</Tip>

***

<CardGroup cols={2}>
  <Card title="SOPs" icon="file-lines" href="/concepts/sops">
    The procedure the reconcile agent follows.
  </Card>

  <Card title="Review & approvals" icon="user-check" href="/concepts/review-approvals">
    Statuses, evidence, assignment, and approval gates.
  </Card>

  <Card title="Extraction pipelines" icon="microchip" href="/concepts/pipelines">
    Model configurations for extraction tables and the extraction API.
  </Card>

  <Card title="Async run pattern" icon="repeat" href="/concepts/async-run-pattern">
    The three-step upload → start → poll flow.
  </Card>
</CardGroup>
