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.
{
"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:
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:
custom_data— no schema change, suited to unstructured extras- Extension fields — real columns on existing ERP tables: queryable and typed
- Custom tables — entirely new entities, organization-level, with relations
The trade-offs are covered in Chapter 5.