USoft Authorizer as a runtime application
When you deliver a USoft solution, authorization rules have a different status from other deliverables (application rules, UIs, batches...). Unlike other deliverables, authorization rules may be changed, dropped, or added to in the Production environment, after release time (that is, between two application releases). This also applies to rules governing authentication.
To make this possible, USoft Authorizer is always a runtime application in the same way that it is also a design-time application. Typically, deliverables are released to Production in flat-file format, except for the content of authorization tables. While USoft Definer's tables (prefixed T_..., eg. T_TABLE) exist only in Development, USoft Authorizer's tables (prefixed T_AUTH_..., eg., T_AUTH_USER) also exist as physical tables in Production:
USoft Authorizer is a design-time as well as a runtime application
In theory, this arrangement implies that all aspects of authorization rules can be changed by a runtime administrator independently of application releases. In practice, however, authorization rules tend to be so closely interrelated with other application functionality that developers usually deliver authorization rules at release time as an integral part of the application.
In the past, USoft Authorizer as a runtime application was a useful interface for administrators such as helpdesk officers to add or remove application users from the system between releases. Adding and dropping application users between releases is of course still of vital importance, but now that USoft Authorizer is available as a module of your application, and with the growing importance of funneling accounts in web applications, these actions are now typically performed by data manipulation on an application-specific table such as a Person or a Team Member table.
This new arrangement makes it much easier to implement authorization rules. However, the implication is that you choose a deployment strategy for transferring records in T_AUTH_... tables from Development to Production.
In Production, the USoft Authorizer application has lost much of its purpose, but it is still in most cases the primary interface for creating, changing or dropping runtime administrator access (eg., for helpdesk officers) between application releases. Usually, it is also a useful interface for inspecting and understanding runtime data access generally.