The ARIA Console

Organization identity

After sign-in, the console resolves the organization attached to the authenticated user. The navigation rail should show the real organization/business name from the organizations record rather than exposing a raw internal org_... identifier.

The organization is also the primary data-scoping key for customer records. Customer-facing repository and API operations must use the signed-in user's organization identifier rather than a client-supplied organization value.

Overview

Overview is the home screen for the account. Its Your ARIA workforce area shows all products defined in the current product catalog together with their organization-specific access state. Core activity sections can also show recent conversations, agent status and available account metrics.

ARIA product navigation

The customer navigation is grouped so product work is separate from shared records and account administration.

• ARIA Voice — customer conversations.
• ARIA Agent — general work assistant.
• ARIA IDE — software development inside Agent.
• ARIA Sales — prospecting and sales operations.
• ARIA R.I. — Resource Intelligence.
• ARIA S.A. — authorized security support.
• ARIA Probate — probate-support workflows.

Locked products show their status in navigation. See Product access & plans.

ARIA Voice

The Voice area represents the organization's web/telephone voice-assistant capability. Depending on the deployment, it can surface configured agents, voice status and recent conversations. Conversation records are organization-scoped and can also appear in the shared Conversations section.

See ARIA Voice documentation for channel setup, business knowledge, realtime behavior and current limitations.

ARIA Agent

The Agent area is the general workspace entry point for research, documents, writing, planning and other business work. It also explains and links to ARIA IDE because IDE is a specialized development workspace inside the same ARIA Agent identity.

ARIA IDE

The IDE area describes the development relationship and can surface development project/workspace status. ARIA IDE's defining product direction is real-time conversation plus software execution: the developer can speak back and forth while ARIA works with the connected project and permitted tools.

Do not interpret seeing the IDE page as permission to run arbitrary commands. Repository/project connection, edit permissions, command execution and deployment controls remain governed by the specific IDE workspace. See ARIA IDE documentation.

ARIA Sales

ARIA Sales is the first specialist product with an entitlement-aware customer operational path in the current foundation.

• If the organization does not have an accessible aria_sales entitlement, the customer sees a locked product explanation rather than the Sales operations workspace.
• If the entitlement is Active or Trial, authorized customer roles can open /console/sales.php.
• Customer Sales records are queried and changed using the signed-in customer's organization_id.
• Random Target AI's internal Sales workspace remains /console/internal/sales.php and is not a customer route.

See ARIA Sales documentation for prospect, approval and run behavior.

ARIA R.I., ARIA S.A. and ARIA Probate

These specialist products now have customer-console presence, entitlement states and locked-product preview pages. Their full operational customer backends are not represented as complete in this foundation.

A customer who sees one of these products as Locked is seeing the expected product-discovery state. An Active entitlement should only be granted once the operational product required for that customer is actually configured.

Shared workspace sections

Conversations

Provides an organization-scoped view of conversation history supported by the connected products.

Leads

Lead records captured by supported channels such as ARIA Voice or the public website contact flow. Role restrictions apply; do not assume every Member can modify leads.

Knowledge

Organization knowledge sources used to ground supported ARIA responses and workflows. Administrative actions such as upload, add website/text or re-index should remain permission-controlled.

Usage & billing

The Usage page contains account activity plus a Product access area that can show the current state of each ARIA product. Metered provider usage bars are still explicitly pending until the usage-provider integration is connected. The UI must not fabricate consumption or billing numbers.

See Usage & billing.

Settings & team

Settings is the account administration area for user/account information, security/session controls and future team management. The first customer owner can self-register an organization, but a full self-service invitation flow for additional team members is not yet implemented.

Customer versus Random Target AI internal navigation

Only authorized users in the Random Target AI internal organization with the required internal role can see the Customer / Internal switch. A normal customer must never see that control.

The customer-side role name Admin is not enough to obtain internal access. Internal checks additionally require organization_id = org_random_target_ai.

Roles and organization isolation

Customer accounts use Admin, Manager and Member roles. Individual product/API operations may apply a narrower role guard. For example, current ARIA Sales customer operations align with Admin/Manager API guards.

Role checks do not replace organization scoping. Both are required: the caller must hold an allowed role and every customer record query/update must stay inside that user's organization.

Mobile navigation

At phone widths, the navigation rail becomes an off-canvas drawer controlled by the menu button and scrim. Product access labels remain available in the same navigation. Data tables that genuinely need additional width can scroll horizontally; the overall page should not create uncontrolled horizontal overflow.