Skip to main content

​
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

​
What lives in Brain’s Supabase

​
The integration pattern

​
Read

Brain reads from CutMake’s Supabase for context. For example, the duplicate-check step in Email → 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.
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.

​
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.