Application Foundation · BaseApp
No customer project starts from zero.
A locked base profile where the tech stack, security model, and folder layout are already decided. Instead of re-deciding those three questions for every new customer project, you add only your own domain on top of the base.
- Status
- Prototype
- Last verified
- 2026-07-18
- Access
- TODO_CONTENT_CONFIRMATION
The problem it solves
Starting every new customer project by re-deciding the tech stack, the security model, and the folder layout wastes time and creates inconsistency across projects.
BaseApp makes those three decisions once. Each consuming project adds only its own data model and business rules on top — the base itself stays unchanged.
How it works
Add the base to your project as a read-only git submodule.
Declare your business objects in model.yaml.
Describe views and access rules in appmodel.yaml.
Schema, types, and UI are derived from that single definition.
Permission checks run in the engine on every request.
Verified capabilities
A read-only base
The base arrives as a git submodule. The consuming project adds only its own identity and domains — it never writes to the base directly.
A layered-diff application model
A business object's behavior is computed across layers; each layer carries only its own diff, and the merge follows a rule-based process.
Everything derives from one metadata file
model.yaml defines the business object; the database schema, types, and UI view are derived from that single definition.
Permissions enforced at the query level
Row, field, and role permissions are designed as a query-level control, not UI-side hiding.
Architecture and integration
BaseApp is added to projects as a read-only git submodule — the base evolves once, for all projects together, with approval, never per project. Consuming projects add only their own project configuration and domain definitions, and never touch the base.
It shares a common base contract with the backend, UI, and data-access layers; data access runs through BaseORM, and the UI runs through a single canonical UI contract.
Trust and control model
The base evolves once, for all projects together, with approval — a single project's special need never silently changes the base.
Permission and access controls are enforced in the backend at the query level; test coverage for critical scenarios such as tenant isolation is ongoing in the internal development environment, and an independent, publicly available verification report has not yet been published.
Known limits / areas for improvement
Access model not yet settled
How the product will be distributed and under what conditions it can be accessed hasn't been confirmed by the product owner yet.
Independent verification ongoing
A comprehensive, independently verified test report for critical scenarios such as authorization and tenant isolation hasn't been published yet.
Prototype maturity level
The product is at the prototype stage; production hardening and scale testing are ongoing.
Evidence
There is no publicly available, independently verifiable evidence set (live demo, published test report, reference project) for this product yet. The read-only base model is confirmed internally in the ecosystem doctrine; external evidence will be added here once published.