What AuraBoot is
AuraBoot is an AI-native enterprise application runtime — model-driven, command-governed, plugin-delivered.
It is not a CRUD builder. It is not a packaged ERP. It is the runtime layer underneath both: the place where business operations are defined, executed, authorized, audited, and exposed to AI agents under a single contract.
The three positions in this market
Different products optimize for different points. We describe the landscape without naming brands, because a customer choosing between us and a competitor needs to understand the shape of the choice, not a feature checklist.
| Position | Optimized for | Strength | Limit |
|---|---|---|---|
| Data-app builders | Quickly turning a database into a usable back-office | Visual modeling, fast time-to-screen, many data sources | Depth in cross-module business logic, governance, regulated workflows |
| Packaged business suites | Buying a working ERP/CRM out of the box | Mature standard modules, well-known implementation playbook | Deep non-standard processes, custom industry verticals, AI-driven operations |
| AuraBoot | Long-lived enterprise applications with complex operations | Governed business commands, layered permissions, plugin-delivered industry packages, AI-safe execution | Higher learning curve than a pure form builder; not a drop-in replacement for a standard accounting suite |
A customer who needs "a department-level form tool by Friday" should pick a data-app builder. A customer who needs "a working accounting suite next quarter" should pick a packaged suite. AuraBoot is for the third case: the business is complex, the lifecycle is years not weeks, and the operations must be safe to expose to automation and AI.
Core abstractions
AuraBoot is built on six first-class concepts. Every plugin, page, and AI tool is expressed in terms of these.
| Concept | What it does |
|---|---|
| Model | Defines business entities, fields, relationships, and the underlying storage. Drives schema, list/detail/form pages, and APIs. |
| Page | DSL-described UI composed of blocks. No business CRUD is written as ad-hoc TSX; the renderer is contract-driven. |
| Command | The only sanctioned write path. Every command flows through a multi-stage pipeline: authorization, entitlement, schema validation, preconditions, state guard, execution, audit, events, side effects. |
| Permission | Layered access control combining role-based, relation-based, and attribute-based checks across menu, record, organization, attribute, and field dimensions. |
| Process | Long-running orchestration (BPMN 2.0) where each task can resolve to a Command, keeping flow steps inside the same governance contract. |
| Plugin | The unit of delivery. A plugin declares the models, fields, commands, permissions, menus, pages, processes, and named queries it contributes. Industry solutions are themselves plugin packages. |
These six concepts are not abstract goals; they are enforced by the platform. The architecture document and the core-concepts section describe each one in detail.
How this changes day-to-day work
Three concrete consequences flow from these abstractions:
1. Business operations are not buttons; they are commands. When a user clicks "Submit", the front end dispatches a command code. The command's permission, preconditions, state transition, side effects, and audit record are defined in metadata, not buried in handler code. The same command is callable from the UI, from automation rules, from external integrations, and — when its risk and idempotency are declared — from AI agents.
2. Permissions are evaluated in layers, not stacked as rules. Functional access (RBAC), record sharing (ReBAC), organizational data scope, attribute policies, and field-level visibility are evaluated in a defined order with a clear principal (the tenant member, not the bare user). This is what lets enterprises grant a sales manager "see all opportunities owned by my org, edit only those above $50k that I created, hide the discount field from non-finance roles" — without writing custom code per permission scenario.
3. Delivery is plugin-shaped, not customization-shaped. Industry verticals (manufacturing, contract management, asset management) ship as plugin packages with their own models, commands, permissions, and pages. Upgrading the platform does not break your customizations because your customizations are not patches — they are plugins with declared dependencies.
What AuraBoot is not for
We are explicit about non-fit so teams can pick the right tool:
- Pure department-level form tools or single-purpose internal trackers. A data-app builder will reach a usable screen faster, and the depth AuraBoot offers (commands, layered permissions, BPM) is overhead you will not amortize.
- Drop-in replacement for a standardized accounting or payroll suite in the first quarter. Country-specific compliance, localization, and audit-trail expectations of a tier-one ERP are not solved by a runtime. AuraBoot connects to those systems and runs the surrounding business operations; it does not replace them on day one.
- Internal tools where no one will read the audit log. If audit, permissions, and traceability are not requirements, the time spent learning AuraBoot's contracts is not recovered.
When AuraBoot wins
- The business has complex cross-module flows (quote → order → procurement → ASN → batch traceability) that no off-the-shelf module captures exactly.
- The customer requires record-, organization-, and field-level governance, not just role-based access.
- The roadmap includes AI agents that need to execute business operations, not just answer questions about data.
- Industry-specific functionality must be delivered as a sustained product, not as a long-lived consulting engagement.
Next steps
- System overview — how the runtime is structured
- Command pipeline — the execution contract
- Permissions — the five-layer model
- Plugin manifest — how delivery is shaped
- Agent readiness — why commands are AI-safe