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

# Data Integration

> Two Supabase projects — Brain's and CutMake's — and the boundary between them

# Data Integration

Brain has its own Supabase database. CutMake has its own Supabase database. They're
separate projects with separate schemas, and that boundary is deliberate.

## Why two databases

CutMake is VinMake's structured source of truth for production records. Its schema
is tuned for the ERP workflows already running in production: clients, styles, BOMs,
true costs, quotations, materials, suppliers, orders, deliveries.

Brain needs to store a different kind of state: AI drafts (still being reviewed),
tasks (workflow state), approval queues, correction logs (AI draft vs. human final),
tracing events, and agent memory. Those are intrinsically AI-app concerns and don't
belong in CutMake's production schema.

Keeping them separate means:

* CutMake's schema doesn't get cluttered with AI artifacts.
* Brain can iterate fast on its own schema without coordinating CutMake migrations.
* A bug in Brain can't corrupt CutMake's production data directly.
* CutMake remains the single source of truth that auditors, finance, and ops can
  trust.

## What lives in CutMake's Supabase

| Domain                 | Owner   |
| ---------------------- | ------- |
| Clients                | CutMake |
| Styles                 | CutMake |
| BOMs (finalized)       | CutMake |
| True costs (finalized) | CutMake |
| Quotations (finalized) | CutMake |
| Materials              | CutMake |
| Suppliers              | CutMake |
| Production orders      | CutMake |
| Sales orders           | CutMake |
| Invoices, bills        | CutMake |

## What lives in Brain's Supabase

| Domain                                       | Owner |
| -------------------------------------------- | ----- |
| AI draft records (pre-promotion)             | Brain |
| Workflow state (tasks, approval queue)       | Brain |
| Inbox items                                  | Brain |
| Correction log (AI draft vs. human final)    | Brain |
| Email ingestion records                      | Brain |
| Attachment metadata                          | Brain |
| Agent memory                                 | Brain |
| Run metadata (LangSmith / Langfuse pointers) | Brain |
| Permissions / roles for Brain                | Brain |

## The integration pattern

### Read

Brain reads from CutMake's Supabase for context. For example, the duplicate-check
step in [Email → Style](/brain/staging/workflows/email-to-style) reads existing
client styles from CutMake. The pricing intelligence layer reads historical
quotations and negotiation outcomes from CutMake.

Reads are scoped, read-only, and use a Brain-owned service role with narrow row-level
security where applicable.

### Write (after approval)

When a Brain draft is approved (e.g., a new style record), Brain promotes it into
CutMake. The promotion path is:

* Use CutMake's existing write API if exposed, **or**
* Direct insert into the CutMake Supabase under controlled service-role permissions
  with the same row constraints CutMake's app would apply

The write path is the same path CutMake's own app uses internally. Brain doesn't
invent new constraints or skip validation.

<Note>
  **TBD:** The exact promotion mechanism (CutMake API vs. direct cross-project write)
  is a near-term decision. Both options are workable; the choice depends on what
  CutMake exposes and how much validation logic lives in the application layer vs.
  the database. This page will be updated when the decision lands.
</Note>

### Draft state never leaves Brain

AI drafts, partial extractions, low-confidence fields, abandoned workflows, and
correction logs all stay in Brain's database. CutMake only sees promoted, approved
records.

This is what makes the system safe to iterate on: we can throw away a year of
correction logs without affecting CutMake. We can rewrite Brain's draft schema
without coordinating a CutMake migration.

## Source linking

Every Brain record references its sources by ID:

* Email message ID
* Attachment file hash + storage URL
* CutMake record ID (for reads or for promoted writes)
* Run ID in the observability tool

These IDs are what make every output [auditable](/brain/staging/principles).

## Related

* [Principles #3](/brain/staging/principles) — CutMake is the structured source of
  truth
* [Runtime](/brain/staging/architecture/runtime) — deer-flow runs on top of these
  data stores
* [Observability](/brain/staging/architecture/observability) — what feeds the
  correction log