How ARIA decides what your organization can use

Visibility is not operational access

A product can appear in Overview and in the customer navigation while its status is Locked. That design lets customers understand what else ARIA can do without hiding the ecosystem behind pricing-page discovery.

Operational access must be enforced by the page/API layer, not by making a button look disabled.

Supported access states

• Active — product operational access is allowed.
• Trial — product operational access is temporarily allowed.
• Locked — product remains visible but operational access is denied.
• Setup required — product is associated with the account but still needs configuration before use.
• Suspended — operational access is disabled.

The current entitlement service treats only Active and Trial as accessible.

Organization entitlement settings

The current foundation uses the existing organization_settings table rather than introducing a second subscription database during this phase.

Keys follow this pattern:

product_entitlement.aria_voice
product_entitlement.aria_agent
product_entitlement.aria_ide
product_entitlement.aria_sales
product_entitlement.aria_ri
product_entitlement.aria_sa
product_entitlement.aria_probate

Values are one of the supported states above.

Current compatibility fallback

Until a billing provider writes explicit settings for every organization, the current fallback keeps the existing core customer experience reachable:

• ARIA Voice — Active
• ARIA Agent — Active
• ARIA IDE — Active
• ARIA Sales — Locked
• ARIA R.I. — Locked
• ARIA S.A. — Locked
• ARIA Probate — Locked

The Random Target AI internal organization resolves products as active for internal operational use.

Server-side enforcement

Product locks must survive direct URL/API access. The current product-access foundation includes a service for resolving entitlement state and guards for page/API enforcement.

A customer should not be able to unlock an API by removing a CSS class, changing HTML in Developer Tools or typing the endpoint directly.

ARIA Sales example

ARIA Sales demonstrates the intended pattern:

1. A locked customer can see Sales in the product catalog and open a product explanation.
2. An Active/Trial customer with an allowed role can open /console/sales.php.
3. The Sales APIs require either Random Target AI internal access or an accessible aria_sales entitlement.
4. Prospect and run data stays scoped by the signed-in user's organization.
5. The internal RTAI Sales route remains separate.

Billing integration

There is no automatic payment-provider-to-entitlement synchronization yet. A future billing integration should update organization entitlements on subscription start, trial, upgrade, suspension, cancellation or specialist-product purchase.

Until then, do not describe a Locked/Active state as proof that a payment processor has successfully charged the customer.

Troubleshooting product access

You can see the product but cannot open its tools: check whether the product is Locked, Setup required or Suspended. That is usually expected.

You paid or were told a product is included but it still says Locked: contact Random Target AI so the organization entitlement/configuration can be verified.

A product says Active but the operational backend is not configured: the entitlement should be corrected to Setup required or Locked until the deployment is complete. Do not use Active as a substitute for unfinished setup.