---
title: "The Data Center: A Pre-Built Foundation"
category: "data-center"
canonical: "https://www.ai-go.app/en-US/docs/guide/data-center"
locale: "en-US"
last_updated: "2026-08-10"
source: "AI GO 開發者文件（https://www.ai-go.app）"
---

# The Data Center: A Pre-Built Foundation

AI GO's real value isn't its interface — it's **what has already been built for you**. This chapter inventories the pre-built data model: which tables exist, how they relate, and which business engines are already wired to them.

This is what your Custom Apps and API integrations can use from day one.

---

## Why this matters

Building an enterprise data model from scratch, the expensive part isn't creating tables — it's **connecting them**. Orders link to customers, to products, to shipments, to invoices, to payments, to journal entries. Miss one link and the books stop reconciling.

AI GO ships that entire web of relationships and cascades pre-built. Your application's job is to decide **which parts to use**, not to rebuild them.

---

## Eight modules

### CRM

| Table | Purpose |
|---|---|
| `customers` | Customer master (level, salesperson, payment terms, credit limit) |
| `customer_levels` | Tiers with base discount rates |
| `customer_tags` / `customer_tag_rel` | Tags and their bindings |
| `customer_tag_prices` | Tag-specific negotiated prices |
| Leads, sales teams, activities | Pipeline management |
| Stages, lost reasons, recurring plans | Pipeline configuration |
| UTM campaigns / sources / mediums | Marketing attribution |

### Sales

Sales orders, quotation templates, product list, product categories. Order lines link to products; products link to categories; categories determine default income accounts and tax rates.

### Purchasing

Purchase orders, requisitions, supplier master, supplier pricing. Orders track **received quantity** and **invoiced quantity** separately, so vendor bills can be generated for the difference only.

### Inventory & Warehousing

| Group | Tables |
|---|---|
| Operations | Transfers/pickings, stock moves, scrap orders, delivery batches |
| Stock management | Physical counts, packaging conversions |
| Reports | On-hand quantities, lots/serials |
| Costing | Landed costs |
| Configuration | Warehouses, reordering rules, routes, packaging, storage categories, freight groups |

### Manufacturing (MRP)

Production orders, work orders, unbuild orders, bills of materials, routings, work centers.

### Accounting

| Group | Tables |
|---|---|
| Documents | Customer invoices, vendor bills, journal vouchers |
| Payments | Inbound, outbound, settlements |
| Adjustments | Credit notes, refunds |
| Bookkeeping | Journal entries, voucher templates, fixed assets, inventory valuation, general ledger, bank statements, reconciliation workspace, period locking |

### Projects

Projects, updates, stages, tags.

### Human Resources

Employees, departments, positions, leave types, payroll runs, plus HR configuration.

---

## The business engines already wired in

This is the second layer of value: **the tables aren't statically related — there is logic running between them**.

| Engine | Trigger | What happens automatically |
|---|---|---|
| Sales invoicing | Create invoice from a confirmed order | Pulls lines and to-invoice quantities, brings in income account and tax rate from the product category, drafts a customer invoice |
| Purchase billing | Create bill from a purchase order | Drafts a vendor bill for the received-but-not-yet-billed difference only, with the expense account on the debit side |
| Real-time stock valuation | Stock move completes | Produces a **posted** valuation journal entry from quantity × unit cost |
| Payroll | Confirm / cancel a payroll run | Creates payroll accrual entries; cancellation generates reversing entries |
| Payment reconciliation | Payment is posted | Matches open invoices first-in-first-out and derives payment status |

Full detail in Chapter 14. **The key point: these cascades apply to every entry point equally** — it does not matter whether the data arrived via a Custom App, the API, or the AI assistant.

---

## Four system columns on every table

| Column | Type | Notes |
|---|---|---|
| `id` | UUID | Primary key, generated |
| `created_at` | timestamptz | Set automatically |
| `updated_at` | timestamptz | Maintained automatically |
| `tenant_id` | UUID | Organization identity, **injected automatically**, provides row-level isolation |

Never supply these on write — the system handles them.

---

## `custom_data`: industry-specific data without schema changes

Every functional table carries a `custom_data` JSONB column for fields the platform doesn't model.

```json
{
  "name": "New customer",
  "email": "new@example.com",
  "custom_data": {
    "passport_no": "A123456789",
    "travel_pref": ["eco", "window_seat"]
  }
}
```

It accepts arbitrary JSON — objects, arrays, nesting — and follows the same isolation and authorization rules as any other column.

**Note**: `custom_data` is itself an authorized column. If an application's reference doesn't include it, reads won't return it and writes will drop it.

If you need something **queryable, indexable, and type-constrained**, `custom_data` is the wrong tool — use an extension field or a custom table (Chapter 5).

---

## Three ways to reach these tables

| Method | For | Authorization |
|---|---|---|
| Dashboard grid | Verification, audit, occasional correction | The user's roles |
| Custom App SDK (`ctx.db` / `src/db.ts`) | Application runtime | Reference declaration + scope approval |
| REST Proxy API | Third-party systems | Reference declaration (published snapshot) + API key |

All three share one query engine and one set of guardrails. Only the authentication and the reference version differ.

---

## References: column-level authorization

Neither Custom Apps nor third-party systems can reach ERP tables directly. They must first declare a **reference** specifying:

- **Which table**
- **Which columns**
- **Which operations** (`read` / `create` / `update` / `delete`)

Undeclared tables and undeclared columns are unreachable. Core system tables (authentication, tenant management, permission settings, audit records) can **never** be referenced.

Query the referenceable surface directly:

```bash
GET /api/v1/refs/available-tables
GET /api/v1/refs/tables/{table_name}/columns
```

The column response reports type, nullability, and foreign-key targets — making it a more reliable source of truth for data-flow planning than any static documentation list.

---

## Extending the model

When the pre-built tables aren't enough, there are three paths, lightest first:

1. **`custom_data`** — no schema change, suited to unstructured extras
2. **Extension fields** — real columns on existing ERP tables: queryable and typed
3. **Custom tables** — entirely new entities, organization-level, with relations

The trade-offs are covered in Chapter 5.