Concepts

An ERP Kit project combines parts that the kit provides with parts that you own. This page explains each part and how they fit together.

Your app is deployed to a Tailor Platform workspace together with the modules it uses. The erp-kit CLI and the agent skills help you build it, but are not part of what runs.

Modules

A module is one business function, such as sales, inventory, or accounts-payable. Each module provides:

Part	What it is
Models	TailorDB tables, such as SalesOrder and SalesOrderLine.
Commands	Operations that change data, such as confirmSalesOrder. They enforce state transitions, permissions, and audit.
Queries	Operations that read data, such as getSalesOrder.
Features	Docs that describe the business behavior the commands and queries implement.

Modules depend on each other explicitly. For example, sales needs organization for companies, business-partner for customers, and item-management for items. You pass these dependencies when you define the module.

A command returns a result instead of throwing: ok: true with the value, or ok: false with an error code your resolver maps to a message. See Where logic goes.

The modules are code in the @tailor-erp/kit package. You use them by composing them, not by copying them, so a new ERP Kit release updates them in your app. See Capabilities for the full list.

Apps

An app is what you deploy: one Tailor Platform application with its own backend, frontend, and docs, under apps/<app>/.

• The backend is a Tailor SDK application. It composes the modules it needs in src/modules.ts, adds its own resolvers, executors, and tables, and defines sign-in in tailor.config.ts.
• The frontend is an AppShell React app. It calls the backend's GraphQL API and is published as a static website by the same deploy.
• The docs describe the app in business terms: who uses it (actors), what they do (business flows and stories), and how (screens and resolvers).

A project can hold several apps, and they can share modules.

Templates

A template is a working app that erp-kit app init copies into apps/<app>/. After the copy, the app is yours: ERP Kit releases update the modules it uses, but not the copied files. See Update packages for how to bring template changes in.

Docs and code stay in sync

ERP Kit treats docs as the specification. Each kind of doc has a schema, and the CLI checks both the docs and their match with the code:

Command	Checks
erp-kit app check	App docs follow their schemas.
erp-kit app sync-check	Every source file in the app has a doc, and every doc has a source file.
erp-kit module check	Module docs follow their schemas.
erp-kit module sync-check	Every source file in the module has a doc, and every doc has a source file.

erp-kit app generate code and erp-kit module generate code create the boilerplate for docs that do not have code yet.

Skills

Skills are instructions for coding agents such as Claude Code. erp-kit init installs them into .agents/skills/ and erp-kit update refreshes them. They teach the agent the kit's conventions, so that it writes resolvers, tests, and docs the way this guide describes. See Agent skills.

What the kit owns and what you own

ERP Kit owns, and updates on each release	You own
Module models, commands, and queries	Your apps: resolvers, app-owned tables, custom fields, screens, docs
The erp-kit CLI and its schemas	Your own modules under modules/
Skills, the App CI workflow, and its actions	tailor.config.ts, seed data, and environments
The template sources	Your data, including migrations when a release changes module tables

Keep your changes on your side of this line. Extend module tables with custom fields instead of editing them, and change module data only through module commands. Then each ERP Kit upgrade stays a package upgrade instead of a merge.