ADR-0001: Use a Universal Entity Platform
Status
Accepted
Context
The product needs to model customers, sites, buildings, rooms, assets, credentials, tags, groups, connection methods, and future object types.
Creating a dedicated schema, API, frontend CRUD flow, permissions model, and audit model for every new object type would slow development and create long-term maintenance overhead.
The system needs to be flexible without becoming an unbounded low-code platform.
Decision
Use a Universal Entity Platform based on stable primitives:
- entities,
- entity type definitions,
- hierarchy,
- properties,
- tags,
- groups,
- relationships,
- templates,
- root entity scope,
- lifecycle and audit.
Domain-specific modules may still exist for behavior-heavy concepts such as Vault, remote connectivity, audit, external integrations, and operational sessions.
Consequences
Positive
- New object types require less schema churn.
- Common CRUD behaviors are reusable.
- Properties, tags, hierarchy, groups, and audit are consistent.
- Frontend forms and views can be metadata-assisted.
- Future domain expansion is easier.
Negative
- Metadata governance becomes important.
- Developers must understand platform primitives.
- Over-abstraction is a risk.
Trade-off
The platform adds up-front architectural structure in exchange for long-term extensibility and consistency.