Skip to content

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.