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

# AI file ingestion

> Turn gig paperwork — contracts, call sheets, riders, emails — into structured event records you review before anything is written.

AI file ingestion lets you drop the documents a gig actually arrives as — a signed contract, a call sheet, a rider, a forwarded email thread — and have [CheckAI](/features/ai/overview) read them and propose the structured records: a timeline, a crew list with fees, ledger items, and any leads. You review every proposal and pick what gets written. **Nothing lands on the event until you commit.**

It produces the same [Universal Event Format (UEF)](/features/imports/universal-event-format) as the spreadsheet importer and partner feeds, so a file dropped on a gig and a row imported from a spreadsheet end up in the same normalized tables.

<Info>
  AI file ingestion is rolling out per organization. If you don't see it on your gigs yet, [contact support](mailto:support@soundcheck.live) to enable it.
</Info>

## The flow

<Steps>
  <Step title="Start a batch on a gig">
    Ingestion is scoped to a single event. You open (or create) an **ingestion batch** on the gig — a container for the files you're about to drop.
  </Step>

  <Step title="Add files">
    Attach PDFs, images, or paste text (a forwarded email, a block from a doc). Each file is analyzed independently.
  </Step>

  <Step title="Per-file analysis">
    CheckAI reads each file and extracts a set of **proposals** — schedule items, crew members, ledger items, leads, and event details. A file moves from analyzing → ready for review.
  </Step>

  <Step title="Review proposals">
    For each file you see exactly what was found, with a **dry-run preview**: which rows are new versus which already exist (a crew member already on your roster, a venue already in your CRM). You can edit a proposal to fix an extraction before committing.
  </Step>

  <Step title="Merge across files (optional)">
    When a batch has several files, CheckAI can **merge** them into one combined draft — deduplicating overlaps and flagging conflicts (two files with different load-in times, the same person listed twice). The merge carries a **merge version** so a review always reflects the latest combine.
  </Step>

  <Step title="Commit what you chose">
    Commit the proposals you selected — by file, or the merged batch as a whole. This is the only step that writes to the gig, and it runs through the [confirmation gate](#confirmation-before-anything-is-written): you approve a plain-language summary first.
  </Step>
</Steps>

## What gets extracted

A single file can propose any of:

| Proposal           | Becomes           | Notes                                                                                       |
| ------------------ | ----------------- | ------------------------------------------------------------------------------------------- |
| **Schedule items** | Gig timeline rows | Load-in, soundcheck, set times, strike.                                                     |
| **Crew members**   | Invitations       | Name + a contact channel (email or phone) and, when present, position, fee, and call order. |
| **Ledger items**   | Money on the gig  | Deposits, balances, expenses.                                                               |
| **Leads**          | Pipeline records  | Inquiries surfaced inside the document.                                                     |
| **Event details**  | Fields on the gig | Title, date, venue, customer, notes — applied only for the field keys you choose.           |

Crew rows without a contact channel can't become an invitation and are skipped at write time — the same rule the [importer](/features/imports/universal-event-format#uefmember) follows.

## New vs. duplicate

Before you commit, the review marks each proposed record as **new** or a **match** against data you already have. Matches reuse the existing crew member, venue, or customer instead of creating a duplicate — so re-ingesting an updated contract is safe and won't fork your roster or CRM. Identity follows the same external-ID and natural-key rules described in [Identity & idempotence](/features/imports/universal-event-format#identity-idempotence).

## Confirmation before anything is written

Commits are **destructive** actions, so they run through Soundcheck's confirmation gate. When you commit, CheckAI returns a short summary — "Add 3 crew members, 5 schedule items, and \$2,400 in ledger items to this gig" — and writes nothing until you confirm. The approval is bound to exactly what you reviewed: if the merge changes underneath you (a new file is added and re-merged), the prior approval is invalidated and you re-review before committing. See the [MCP security model](/integrations/mcp-server#security-model) for the underlying mechanism.

## From an AI client

The same pipeline is available as MCP tools, so you can drive it from Claude Code or Cursor — or let the [CheckAI assistant](/features/ai/overview) orchestrate it. The `ingest_gig_files` prompt walks the whole batch → review → confirm → commit loop. See the [ingestion tools](/integrations/mcp-server#available-tools) on the MCP server page.

## Related

<CardGroup cols={3}>
  <Card title="CheckAI overview" icon="robot" href="/features/ai/overview">
    The assistant behind ingestion.
  </Card>

  <Card title="Spreadsheet imports" icon="table" href="/features/imports/overview">
    The other way data gets into Soundcheck.
  </Card>

  <Card title="Universal Event Format" icon="code" href="/features/imports/universal-event-format">
    The shape every ingestion produces.
  </Card>
</CardGroup>