Skip to main content

Access and Invitation Codes

The current authorization model is not centered on always-online validation. It is centered on local, enforceable module boundaries.

How authorization becomes effective​

Module visibility depends on two things together:

  • invitation-code tier configuration in backend code
  • the current activation record and runtime snapshot stored in the local database

This means:

  • module availability does not depend on constant online connectivity
  • holding a permission code does not guarantee a module is open
  • menus, routes, and APIs follow the same authorization result

Current tiers​

The visible tier names remain:

  • Free
  • PLUS
  • PRO

The exact submodules inside each tier are driven by current code configuration instead of a rigid package table.

In-session refresh​

Admin and superuser sessions silently refresh permission results when the app starts, returns to the foreground, or changes invitation codes. That helps keep menus, tier badges, and backend access aligned without forcing a logout cycle.