The self-improving ERP engine
Every ERP processes transactions. Only ERPClaw learns from them. Constitutional articles. 3 evolution phases. A dedicated OS test suite. The only ERP that detects gaps and generates modules while protecting financial integrity.
Adding an industry is a recipe, not retraining
Teaching ERPClaw a new kind of business means writing one more recipe, not retraining the AI. A trained chef already knows knife work, heat, and timing. Hand them a recipe for a dish they have never cooked and they make it tonight, because the recipe carries what is specific and the chef carries what is general. In ERPClaw the AI model is the chef, each module's plain manifest (its SKILL.md file) is the recipe, and the shared database is the kitchen.
That is the job ERPClaw OS does when it generates a module. In the case study we presented at IEEE IRI 2026, it generated modules for businesses such as a tattoo parlour, and every decision a person had to make was a business preference, like how long a deposit is held, never an accounting decision. Nobody had to decide how double entry works, because the chef already knows.
Conventional ERP answers a new industry by hiring a second chef and building a second kitchen: new screens, new logic, and a services project to connect it to the books. Panorama Consulting's 2024 ERP Report, a survey of organizations, found a median project timeline of 15.5 months and a median project cost of $450,000. Those are survey medians, not a controlled comparison with ERPClaw, but they show the scale of a conventional ERP project.
The longer version: adding an industry is a recipe, not a kitchen. The question came from the IEEE IRI 2026 audience (the four questions from that talk). Survey: Panorama Consulting ERP Report archives.
Constitutional Articles
Inviolable rules that every module must pass before it deploys. The AI cannot override them. They are the foundation of trust.
Every module's tables carry its own namespace prefix
Money is stored as TEXT decimals, never floating point
Primary keys are UUID4 values
Foreign keys point only to tables that exist
A module writes only to the tables it owns
No module writes to the general ledger directly; all posting goes through the GL engine
Every action answers in structured JSON
Every action has tests
Tests pass against a fresh database in a sandbox
Generated code passes a security scan
Skill definitions follow the required format
Action names follow one naming convention
Every stock movement is backed by a document
Nothing posts into a closed period
Every query is scoped to one company
Submitted documents are locked; the only way back is a reversal
Sensitive personal fields are encrypted at rest and masked for display
Lease and subscription revenue follows a deferral pattern
Changes to an existing module only add; they never rewrite what is there
Every generated feature cites its business rule source
Every new feature is testable in isolation
Three Evolution Phases
ERPClaw OS grew through three phases, each adding more autonomy while maintaining safety.
Phase 1: Child
- Module generation from deterministic patterns
- SKILL.md validation and linting
- Sandbox testing before deployment
- Schema DDL generation and migration
- Constitutional article compliance checks
Phase 2: Teenager
- Tier classification system (Tier 0-3 autonomy)
- Schema migration engine
- Deploy pipeline with safety gates
- Install-suite for grouped installs
- Adversarial audit and compliance weather
Phase 3: Adult
- Semantic correctness engine
- Self-improvement log with change tracking
- DGM variant engine (evolutionary optimization)
- Heartbeat analysis per module
- Gap detection across business workflows
Safety Model
Self-improvement sounds risky. Here is how ERPClaw OS ensures every change is safe.
Protected Files
Core financial files (gl_posting.py, stock_posting.py, etc.) can NEVER be modified by the AI. Hard-coded exclusion list.
Constitutional Tests
Automated tests verify every article is enforced. Run before every deployment.
Tier Classification
Tier 0 (read-only, fully autonomous) through Tier 3 (human-only). Core financial changes are always Tier 3.
Invariant Checks
GL double-entry balance, voucher balance, immutability verification per transaction batch.
Sandbox Validation
Every generated module runs in an isolated sandbox before deployment to production.
Semantic Verification
Changes are validated against business rules, not just syntax. Catches logic errors before they reach production.
See the code behind the OS
Every constitutional article, every safety check, every generation pattern, open source under open source license.
View on GitHubRelated: read the architecture in AI-native ERP, see the test surface at quality, the foundation features, or the engineering deep-dive in building ERPClaw with Claude Code.