Intelligence Commerce Suite (ICS) Functional Document

This document describes the functional capabilities of the Intelligence Commerce Suite (ICS) — how each persona navigates the platform and performs day-to-day tasks across agents, knowledge, prediction, language, connectors, and administration. It is intended for Product Owners, Business Analysts, Solution Architects, and Client Stakeholders evaluating or implementing ICS.

1. Overview

What is the Intelligence Commerce Suite?

The Intelligence Commerce Suite (ICS) is an AI-powered commerce platform that helps retail and e-commerce businesses run intelligent, automated operations — without building AI infrastructure from scratch.

Businesses today use multiple commerce platforms (Shopify, Salesforce, Equinox) and generate vast amounts of data — product information, customer orders, return policies, sales forecasts. But turning that data into real-time, intelligent actions is slow, manual, and fragmented.

ICS solves this by providing:

• A single place to build and run AI agents that act on your commerce systems automatically
• A Knowledge base where you upload your policies, documents, and architecture — and agents can use that knowledge when responding to customers or making decisions
• Predictive analytics that forecast demand, detect churn, and recommend actions using your own data
• Connectors to link your Shopify, Salesforce, or Equinox accounts — so agents can read and update real data on your behalf
• Strict data isolation so each business’s data, AI spend, and access controls are completely separate

Who is ICS for?

ICS is delivered through a single web application. It is organised into purpose-built zones for each capability, all under the same login.

2. Glossary

3. User Roles & Access Levels

ICS has four user tiers. Each tier includes all the capabilities of the tier below it.

Instance Admin  ▶  manages all organisations on the platform
    │
    └── Org Admin  ▶  manages one organisation and all its tenants
            │
            └── Tenant Admin  ▶  manages one or more tenants within the org
                      │
                      └── Business User  ▶  works within one tenant, in specific business areas

4. Persona-wise Navigation & Feature Access

This section describes what each user persona sees and can do after logging in — organised by the left-side navigation menu visible to their role.

4.1 Instance Admin

The Instance Admin is the platform operator (Infosys) with full visibility across all organisations and tenants on the platform.

Left Nav: Dashboard · Organizations · Catalog · Connectors · Members & Access · Audit · Cost Dashboard

4.1.1 Dashboard

• Once login, the instance admin will land on the dashboard where they will be able to view data in the form of KPIs, existing organization, etc.

KPI Cards (top row)

OOB Assets by IP Track

Four track cards are displayed, each showing the asset count, description, and a Manage → link. Clicking Manage → on any track card redirects the user to the Catalog menu, filtered to that track’s tab.

Existing Organizations

• Lists all provisioned organisations in card view with filter tabs (All · Active · Pending · Deactivated · Offboarding),

• Search bar, and a + Create Organization button.

• Each org card shows: name, slug, Org Admin email, Tenants (as tags), Members count, Connections, and Created date.

4.1.2 Organizations

• Organisations displayed in card view showing: name, status badge (Active / Deactivated + MFA Enabled / Disabled), Home region, Plan / tier, and Created date.

• Filter tabs: All · Active · Pending · Deactivated · Offboarding. Search by name or org ID.

How to: Organisation & Tenant Management

Purpose

The foundation of the platform. It controls how companies, business units, and users are set up, structured, and isolated from each other. Everything else on ICS depends on having an organisation and tenant correctly provisioned.

Instance Admin — creates orgs · Org Admin — creates tenants & users · Tenant Admin — manages tenant users

Creating an Organisation

Purpose

Set up a new company account on ICS, completely isolated from all other companies.

⚠ Prerequisites

• You must be an Instance Admin
• First org admin’s email address and display name must be available
• The organisation name (identifier) must be decided

Steps

1. The platform creates a dedicated identity pool for the organisation
2. Reserved admin roles (org-admin, tenant-admin) are automatically created
3. The first org admin is invited and granted full org-admin access
4. The org admin receives an email and sets their password on first login

Creating a Tenant

Purpose

Create a business unit or store within an organisation — e.g., a specific brand, region, or channel. Each tenant has its own agents, connectors, knowledge bases, and users.

⚠ Prerequisites

• You must be an Org Admin
• The organisation must already be provisioned
• First tenant admin’s email address (optional — can add one later)

Steps

1. Go to Organisation → Tenants → Create Tenant
2. A dedicated data partition is created for the tenant (all data is isolated)
3. If a first admin email is supplied, that person is invited and granted tenant-admin access
4. An AI cost allocation (virtual key) is automatically created so the tenant’s AI spend is tracked separately

Inviting a User

Purpose

Add a team member to an organisation or tenant with an appropriate role.

⚠ Prerequisites

• You must be an Org Admin (any user) or Tenant Admin (tenant-scoped users only)
• The role you want to assign must already exist (see the Members & Access section)
• The user’s email address must be known and unique within the organisation

Steps

1. Go to Organisation → Users → Invite User
2. Enter the user’s email address and display name
3. Select the role(s) and scope (org-wide or specific tenant)
4. The user receives an invitation email and sets their own password on first login

Offboarding a User or Tenant

Purpose

Remove access for a departing team member or decommission a tenant that is no longer needed.

⚠ Prerequisites

• You must be an Org Admin
• For tenant offboarding: all active agent runs should be stopped first
• Data export must be completed before hard deletion (GDPR compliance)

Tenant offboarding follows a staged process: access revoked → data exported → data retained for the configured period → data permanently deleted.

4.1.3 Catalog

• The Catalog page is organized into four tabs.

• Each asset card has a View link that opens a detail page showing: metadata summary cards (Category · Type · Domain · Status), an Asset Details table (Asset ID, Name, Category, Type, Domain, Scope, Status, Description), and a Features list.

Agentic Studio tab

Lists all OOB agents in card view. Each card shows: name, type (agent), version (e.g., v1), category (e.g., b2b, marketing, customer-service, merchandising), and status badges (PUBLISHED · published to orgs). Click View for full agent details and feature capabilities.

Knowledge tab

Lists the three platform-wide knowledge capabilities:

Prediction tab

• Lists OOB prediction models and ML pipelines available across business domains.

• Use cases include customer churn prediction, demand forecasting, return rate prediction, product lifecycle classification, and customer segmentation.

• Each model card shows name, version, category, and publication status.

• Click View to see model details and supported features.

Language tab

• Lists all LLM and SLM models available on the platform.

• Each card shows: name, type (llm or slm), version, category, and status badges (PUBLISHED · published to orgs).

• Click View to see full model details.

4.1.4 Connectors

• The instance admin will be able to view all connectors on this page.

• They will also be able to add new connectors by providing the necessary information.

4.1.5 Members & Access

• From this page, instance admin will be able to provide access to the members.

How to: Access Control (RBAC)

Purpose

Ensures that each person on ICS can only see and do what is appropriate for their role. Prevents unauthorised access, enforces business boundaries, and makes it easy to grant or revoke access as teams change.

Org Admin — creates roles, manages org-wide access · Tenant Admin — manages tenant access · Instance Admin — manages platform roles

Creating a Role

Purpose

Define a new set of permissions for a category of user — e.g., a “Merchandiser” who can only work with products and pricing.

⚠ Prerequisites

• You must be an Org Admin
• Decide which business domains this role grants access to (e.g., product, order, pricing, inventory, customer)

Steps

1. Go to Organisation → Roles → Create Role
2. Enter a name and description
3. Select the business domains this role grants access to
4. Save — the role is now available to assign to users in any tenant within the org

Admin roles (org-admin, tenant-admin) are automatically created when an org or tenant is provisioned — you do not create these manually. You only create roles for business users.

Assigning a Role to a User

Purpose

Grant a user access to specific business areas within a tenant.

⚠ Prerequisites

• The role must already exist (the Members & Access section.1)
• The user must already be invited (the Organizations section.3)
• You must be an Org Admin (any role) or Tenant Admin (tenant-scoped roles only)

A user can hold multiple roles across multiple tenants — e.g., Tenant Admin in one tenant and Merchandiser in another, under the same login.

Understanding Domain-Based Access

4.1.6 Audit

• The audit page gives the instance admin an overview on what actions/ activity has been done and by whom.

• They will be able to select the date range and get the audit logs.

How to: Audit

Purpose

Provides a tamper-proof record of every significant action taken on the platform — answering “Who did what, and when?” for compliance, security reviews, and operational troubleshooting. The audit log cannot be altered retroactively — any tampering would be immediately detectable.

Instance Admin — all organisations · Org Admin — entire organisation · Tenant Admin — own tenant only

Viewing the Audit Trail

⚠ Prerequisites

• You must be a Tenant Admin, Org Admin, or Instance Admin

Not visible: The content of documents or agent conversations (only the fact that an action happened is recorded). Credentials and secrets never appear anywhere in the platform.

4.1.7 Cost Dashboard

• Displays the cost impact based on real-time data.

• Instance admin will be able to apply filters for: Organisation · Tenant · Track · User (all dropdowns).

• Date range selector top-right. Export and Refresh buttons.

Overview tab

Token Usage tab

Agents & Workflows tab

How to: Cost Dashboard

Purpose

Gives organisation and instance admins visibility into how much AI spend is being consumed — broken down by tenant, capability, model, and project. Lets org admins set monthly budget limits and alerts so costs stay within expected ranges.

Instance Admin — platform-wide token cost view · Org Admin — org-level view; sets budgets · Tenant Admin — cost trends for their tenant

Viewing AI Token Costs

Purpose

Understand how much your organisation is spending on AI model calls for agents, knowledge queries, and other language model usage.

⚠ Prerequisites

• You must be an Org Admin or Instance Admin
• The platform tracks costs automatically — no setup required

Setting a Budget

Purpose

Set a monthly spending limit for your organisation’s prediction compute. The platform will alert you when you approach the limit.

⚠ Prerequisites

• You must be an Org Admin

Steps

1. Go to Prediction → Cost Analysis → Budget → Set Budget
2. Enter the monthly budget amount
3. Set an alert threshold (e.g., alert at 80% of budget)
4. Save — you will be notified when spend approaches the threshold

Managing Idle Endpoints

Purpose

Reclaim compute resources that are running but not being used, to reduce unnecessary costs.

⚠ Prerequisites

• You must be an Org Admin
• At least one prediction model must be deployed

The platform automatically detects idle endpoints, warns you, converts them to serverless (zero cost when idle), and eventually deletes those beyond the configured threshold. You can also trigger a manual sweep or exempt specific endpoints.

4.2 Org Admin

Navigation Context

The Org Admin manages a single organisation — provisioning tenants, curating platform assets for their teams, and configuring connectors.

Left Nav: Dashboard · Tenants · Catalog · Connectors · Members & Access · Requests · Audit

4.2.1 Dashboard

• Once login, the org admin will land on the dashboard where they will be able to view data in the form of KPIs, existing organization, etc.

• An Invite member button is available directly on the dashboard. Clicking it opens a slide-over with: Org Admin Email*, Org Admin Name*, and optional Role Grants (Scope, Scope ID, Role ID).

KPI Cards

OOB Assets by IP Track

Four track cards showing asset count and a Manage → link. Clicking Manage → redirects to the Catalog menu, filtered to that track’s tab.

Existing Tenants

• Org admin will be able to view the tenant list in the form of card view.

• Org admin will be able to filter the tenant list by provided filter options such as; All · Active · Provisioning · Deactivated · Offboarding.

• They will be able to search by name, region or tenant.

• To create a new tenant, org admin will be required to click on ‘Create Tenant’ button at top right and enter the required details.

• Each card shows: name, slug, region, Admin email, Members count, Connectors (pill tags), status badge, and a three-dot menu (⋮) with a Deactivate option.

4.2.2 Tenants

• On click of the Tenant option, the org admin will be able to view list of all the tenants in the form of card view.

• On each card, org admin will be able to view details like; admin name, number of members, and connectors name.

• On click of ‘Open’ link on the card, org admin will be redirected to the tenant section.

• They will be able to search the tenant by entering tenant name in the search box.

• On click of the Create Tenant button, a window will get open where org admin can provide necessary details and add the tenant.

4.2.3 Catalog

• On the catalog page, org admin will be able to view resources under each tracks i.e. Agent studio, Knowledge, Prediction, and Language tracks.

Agentic Studio tab

• On this tab, org admin will be able to view list of OOB agents in the form of card view.

• On card, they will be able to view details such as: name, type (agent), version, category, PUBLISHED status badge, View link.

Knowledge tab — CAPABILITIES

Knowledge tab — DOMAIN SPECIALISATIONS

Prediction tab

• Lists OOB prediction models and ML pipelines available across business domains.

• Use cases include customer churn prediction, demand forecasting, return rate prediction, product lifecycle classification, and customer segmentation.

• Each model card shows name, version, category, and publication status.

• Click View to see model details and supported features

Language tab

• Lists all LLM and SLM models available on the platform.

• Each card shows: name, type (llm or slm), version, category, and status badges (PUBLISHED · published to orgs).

• Click View to see full model details.

4.2.4 Connectors

Read-only reference view — no actions are available on this page. Each connector card shows:

4.2.5 Members & Access

• Org admin will be able to view list of members and their status in a tabular format. It will have details like:

  • Member name

  • Email

  • Status

  • Role

  • Created date

• On click of Invite Member button, org admin will be able to provide access to the members by providing required details.

• In the Roles tab, org admin will be able to view roles created by them in tabular format.

• They will be able to search for any role by entering role name in the search box.

4.2.6 Requests

• On this page, org admin will be able to view the requests raised by tenant admins.

• Org admin will be able to approve/ reject the request as well.

4.2.7 Audit

• The audit page gives the org admin an overview on what actions/ activity has been done and by whom.

• They will be able to select the date range and get the audit logs.

• The org admin can view the track wise audit logs by selecting the respective track from the dropdown.

4.3 Tenant Admin

Navigation Context

The Tenant Admin manages one or more tenants — connecting commerce systems, building and publishing agents, managing knowledge bases, and overseeing team access within their tenant.

Left Nav: Overview · Connectors · Agentic Studio · Knowledge · Prediction · Language

4.3.1 Overview

• Upon login, the tenant admin will land on the Overview page where they will be able to view data’s in different KPIs, track information and tenant information.

• A Tenant switcher dropdown is always visible at the top left. Clicking it opens a searchable list of all tenants the admin manages. Switching tenants reloads all four IP tracks scoped to the selected workspace.

KPI Cards

Intelligence Platform Tracks (2×2 grid)

• Each track card shows a status summary and a quick-navigate link.

• Clicking the link navigates to that track’s Dashboard screen.

Tenant Members section

• Tenant admin will be able to view list of tenant admin and tenant users invited by them and their status. On the tenant admin tab, it will be a tabular format with details like:

  • Member name

  • Email

  • Role

  • Status

  • Last active date

  • Resent button

• On tenant users tab, the details will be:

  • Member name

  • Email

  • Role

  • Status

  • Last active date

  • Resent button

  • Manage role

• To add a new member, the Invite Member button opens slide-over with details such as: Member Email*, Member Name*, Role* dropdown (default: Tenant Admin).

4.3.2 Connectors

• The instance admin will be able to view all connectors on this page.

• They will also be able to add new connectors by providing the necessary information.

• Tenant admin will be able to view KPI cards for: Total Connectors · Active · Inactive · Total Capabilities.

• They will be able to view Tabs for connectors which are ACTIVE (count) and INACTIVE (count).

• Tenant admin will be able to search connectors by entering connector name in the provided text field.

• Further, they will be able to view connectors in card view.

• Each card will be having details like: name, scope (tenant), Active status badge, capabilities count, tools count, protocol badge (MCP).

• From the three-dot menu (⋮) they will be able to perform actions such as: Edit · Test Connection · Disconnect · Delete.

• Clicking a connector card opens its detail page.

How to: Connectors

Purpose

The integration layer between ICS and your commerce platforms. Lets agents read and update data in Shopify, Salesforce, or Equinox — without the agent ever seeing API details or credentials. When an agent issues a standard command (order.read, pricing.update), the connector translates it into the correct API call and injects credentials automatically.

Instance Admin — registers connector types · Tenant Admin — creates connections

Supported Platforms (V1)

🛒 Shopify

Read and update products, pricing, inventory, and collections. Customers and orders support coming.

☁ Salesforce

Read, create, update, and delete products, customers, orders, and pricing. Requires two connections for full CRUD.

⚡ Equinox

Connect to Equinox cloud admin and subscribe to marketplace events for event-driven automation.

🔧 Custom

Register your own MCP server or REST/GraphQL API as a connector through a self-service flow.

Adding a Connector (Creating a Connection)

Purpose

Link your Shopify, Salesforce, or Equinox account to your ICS tenant so agents can act on your behalf.

⚠ Prerequisites

• You must be a Tenant Admin
• The connector type must be registered on the platform by the Instance Admin
• You must have the platform credentials:
  • Shopify: Custom App Admin API access token with appropriate scopes
  • Salesforce: Connected App Consumer Key & Secret, plus your org’s domain URL
  • Equinox: OAuth client ID and client secret for the Equinox cloud admin
• Credentials must have the necessary permissions on the external platform

Steps

1. Go to Connectors → Add Connection
2. Select the platform (e.g., Shopify)
3. Enter your credentials — they are stored securely in the platform’s Vault and are never visible again
4. Click Test Connection to verify the credentials work
5. Go to Connectors → Routing and map which business domains route through this connection
6. Agents in your tenant can now use this connection

Subscribing to Commerce Events (Equinox only)

Purpose

Automatically trigger an agent whenever a specific event happens in Equinox — e.g., a customer submits a return request or a product is updated.

⚠ Prerequisites

• An Equinox connection must already be created and active (the Connectors section.1)
• You must know the specific event name (e.g., orderservice/return/requested)
• An agent must be published and ready to handle the event (the Agent Studio section.5)
• You must be a Tenant Admin

Dry-Running a Connector Action

Purpose

Test what an agent would do with a connector action without actually making any changes in your commerce platform.

In dry-run mode, actions that would change data (like pricing.update) are stubbed — the agent goes through all the steps but no actual change is made. Read-only actions (like product.read) execute for real so you see actual data.

4.3.3 Agentic Studio

Sub-menu: Dashboard · Agent Store · Chat · Playground · Docs

Dashboard

• On click of the Agent Studio, tenant admin will land on the dashboard where they will be able to view card view structure of workflows/ agents they have subscribed to and the actions to be taken on it.

• In the NEEDS YOUR ATTENTION section, tenant admin will be able to view all Action cards in a grid, each requiring a decision or action.

• Each card shows: status badge, source trigger (scheduled / event listener / agent name), title, description, and inline action buttons specific to that item.

INVENTORY SIGNALS section: Quick-view status widgets for key business signal monitors running in the background (e.g., Best-Seller Stockout Check, SKUs Flagged as Dead Inventory).

Agent Store

• The Agent Store page will be comprising of 3 different tabs.

• The default landing page will be Agents tab.

Agents Tab

• Agents: In this section, list of all OOB agents will be displayed in the form of card view.

• On click of any agent will redirect tenant admin to details of that agent.

• For any agent, they will be able to perform actions like Subscribe and Clone.

• The magic icon on the top right corner of the card will open a chat where tenant admin will be able to initiate chat with that agent.

• They will be able to sort the list by Most active and Newest.

• They will also be able to change the page layout from card view to list view.

• The text search will enable them to search for any agent by entering its name.

Workflows Tab

• In this section, list of all OOB workflows will be displayed in the form of card view.

• For any workflow, they will be able to perform actions like Subscribe and Clone.

• The magic icon on the top right corner of the card will open a chat where tenant admin will be able to initiate chat with that workflow only in case of chat-based workflows.

• They will be able to sort the list by Most active and Newest.

• They will also be able to sort the workflows by selecting trigger types such as; All triggers, Scheduled, and Event.

• They will also be able to change the page layout from card view to list view.

• The text search will enable them to search for any workflow by entering its name.

• On click of any workflow will redirect tenant admin to details of that workflow.

• On the workflow details page, they will be able to view 2 tabs; Overview and History.

• The Overview sections will display the complete working of the workflow.

• Whereas, History tab will show the trigger history.

My Creations

• This page is further divided into 3 sub-tabs; All, Agent, Workflows.

• ‘All’ tab will display list of all agents and workflows created by tenant admin in the form of card view.

• Agents tab will display the agents created by themselves.

• Workflows tab will display the workflows created by themselves.

• They will also be able to change the page layout from card view to list view.

• On click of any agent/workflow will redirect tenant admin to details of it.

• On the details page, they will be able to view 2 tabs; Overview and History.

• The Overview sections will display the complete working of the workflow.

• Whereas, History tab will show the trigger history.

Chat

• On the chat page, tenant admin will be able to initiate a chat to create an agent or workflow.

Playground

• On the playground screen, the tenant admin will be able to test the agent by selecting the agent’s name from the dropdown.

Docs

• The docs section will have ready only information regarding the agent studio, the frontend and backend logics, and other operations details.

How to: Commerce Agent Studio

Purpose

Where business teams build, test, and run AI agents that automate commerce operations — customer service, return processing, pricing updates, inventory responses — all within guardrails you define. Agents are chat-driven: you interact with them through conversation, and they use their configured tools and knowledge to respond and act.

Tenant Admin — creates & publishes agents · Business User — chats, approves HITL · Org Admin / Instance Admin — can also create; publishes OOB

Creating an Agent

Purpose

Build a new AI agent tailored to a specific commerce task, with its own instructions, tools, knowledge sources, and access to your connected platforms.

⚠ Prerequisites

• You must be a Tenant Admin or have agent creation permission
• The organisation and tenant must be provisioned (the Organizations section)
• An AI model must be available (default: Claude Sonnet 5 — configured by the platform team)
• If the agent reads/writes commerce data: a Connector must be set up (the Connectors section)
• If the agent answers questions from documents: a Knowledge base must have approved content (the Knowledge section)
• If the agent produces predictions: the relevant Prediction model must be deployed (the Prediction section)

Steps

1. Go to Agent Studio → Mine → Create Agent
2. Enter a name and description for the agent
3. Choose the AI model (the default is recommended for most cases)
4. Write the agent’s system prompt — its standing instructions, personality, rules, and scope
5. Select the business areas the agent can access (e.g., customer, order, product)
6. Optionally enable the Knowledge Base for document-grounded responses
7. Configure the approval gate if human sign-off is required before sensitive actions
8. Save — the agent is now a draft. Test it in the Playground before publishing.

Testing an Agent (Playground)

Purpose

Run the agent interactively with real data before making it live, to validate its behaviour and connector access.

⚠ Prerequisites

• Agent draft must be saved with a valid definition
• If the agent uses connectors: the connector must be active and credentials valid
• You must be the agent’s author or a Tenant/Org Admin

Publishing an Agent

Purpose

Freeze the agent’s current configuration as an immutable, live version that others can use.

⚠ Prerequisites

• Agent must be in draft state with a valid saved definition
• You must have agent publish permission
• A changelog (description of what changed) must be written — the platform requires it

A numbered, frozen version is created (e.g., v1). This version can never be overwritten. Any future change requires opening a new draft and publishing v2. Only published versions can be used in scheduled or event triggers.

Scheduling an Agent

Purpose

Run an agent automatically on a recurring schedule — e.g., every morning at 8 AM to check overnight orders.

⚠ Prerequisites

• The agent must be published (at least v1 exists)
• You must have agent execution permission
• A valid cron schedule and timezone must be provided (minimum interval: 60 seconds)
• If the agent uses connectors: credentials must be active

Steps

1. Go to the agent detail page → Triggers → Add Trigger → Schedule
2. Enter a name, the cron schedule, and timezone
3. Optionally enter a starting message (the first thing the agent will “read” when it runs)
4. Save — the agent will start automatically on the next cron occurrence

Connecting an Agent to a Commerce Event

Purpose

Run an agent automatically when something happens in your connected commerce platform — e.g., a customer submits a return request.

⚠ Prerequisites

• The agent must be published
• A Connector must be set up and the marketplace app registered (the Connectors section.2)
• The event name must be known (e.g., orderservice/return/requested)
• You must have agent execution permission

Approving a Human-in-the-Loop (HITL) Decision

Purpose

Review and approve (or reject) an action the agent has proposed but cannot execute without human sign-off.

⚠ Prerequisites

• A run must be in the “Awaiting approval” state
• You must be a subscribed user, the agent’s owner, or a Tenant/Org Admin

Steps

1. You receive a notification that an agent run is awaiting your decision
2. Go to Agent Studio → Runs and open the waiting run
3. Review the agent’s proposal (e.g., “I would like to issue a $349 refund — reason: damaged item”)
4. Click Approve or Reject
5. The agent resumes (approved) or closes cleanly (rejected)

Cloning an OOB Agent

Purpose

Take a pre-built agent from the platform catalog and create your own customised copy for your tenant.

⚠ Prerequisites

• The OOB agent must be published and available to your org
• You must have agent creation permission

4.3.4 Knowledge

Sub-menu: Dashboard · Domain Expert · Client Brain · Enterprise Architect · Docs

Dashboard

• On click of the knowledge, the tenant admin will land on the Dashboard page where they will be able to view different trends, graphical and analytical information for its sub-tracks.

Domain Expert

OVERVIEW tab: Shows “Infosys Experts” — count of active experts and total available. Each expert row: Name + Active badge · description · feature tags (pill tags) · Test button (redirects to the CHAT tab to interact with that expert) · Deactivate button.

CHAT tab: “Start a conversation — Ask Domain Expert a question about your knowledge base.” Message input with sample placeholder. + (new session) and history icons top-right.

Client Brain

• OVERVIEW tab: Summary line (knowledge categories · documents · items extracted · confirmed).

• Alert banner when items are pending review → Review Now → button.

• 4 KPI cards: DOCUMENTS · EXTRACTED · CONFIRMED · AVG COVERAGE.

• Knowledge categories table (CATEGORY · DOCS · PROGRESS · COVERAGE · ACTION):

• CHAT tab: “Start a conversation — Ask Client Brain a question about your knowledge base.” Context-aware quick action buttons (suggested questions from ingested documents). + and history icons top-right.

• MANAGE DOCUMENTS tab: “UPLOAD FILES” section. Search field to search for any document. Upload from Confluence and Upload from Device buttons. Documents list table: DOCUMENT (name + uploader + version badge) · UPLOADED · STATEMENTS · STATUS (Pending Review / Partially Reviewed) · ACTIONS (Review link + delete icon).

• REVIEW INBOX tab: Lists all AI-extracted statements awaiting human review. Filter pills: All · Pending · Approved · Rejected. Document filter dropdown + search field. Approve all pending button for bulk approval. Checkbox per row for individual bulk selection. Table columns: STATEMENT (extracted text + source document filename) · STATUS (Pending badge) · ACTION — Edit (modify statement text before approving) · Reject (discard) · Confirm (approve and publish to knowledge graph).

Enterprise Architect

OVERVIEW tab: 5 KPI cards: Categories (modules with docs) · Platforms (platforms with docs) · APIs (endpoints documented) · Entities (across all uploads) · Covered (modules with entities). Below the KPIs, an interactive architecture diagram renders the full digital commerce platform ecosystem:

CHAT tab: “Start a conversation — Ask questions about the Equinox Commerce Platform architecture.” Input placeholder: “Ask about services, APIs, dependencies…”. Six architecture-focused quick action buttons: “What microservices handle payment processing?”, “Explain the Commerce Core architecture and its key capabilities.”, “How are orders managed across the system?”, “What integration patterns are used between services?”, “Which services depend on the API Gateway?”, “How does the loyalty and subscriptions engine work?”. Disclaimer: “AI can make mistakes — please verify important information.”

MANAGE DOCUMENTS tab: Structured differently from Client Brain. Top section titled Architecture Knowledge Coverage — “Click a card to filter – use the + Add docs strip to upload into that module.” Platform/module cards displayed in a grid, each showing: colour-coded name, docs count, status (“No docs yet” / doc count), and a + Add docs link. A + Add card allows creating new platform/module categories. Below the grid: Search by filename field. Upload from Confluence and Upload from Device buttons.

Documents table columns differ from Client Brain — includes two additional columns: MODULE (colour-coded module tag) and PLATFORM (platform name). Full columns: DOCUMENT (name + uploader + version badge) · MODULE · PLATFORM · UPLOADED · STATEMENTS · STATUS · ACTIONS. STATUS values: Pending Review / Partially Approved. ACTIONS: Review link + delete icon.

REVIEW INBOX tab: Filter pills: All (total) · Pending (count) · Approved (count) · Rejected (count) + refresh icon. “Select entities for bulk action, or approve all pending.” checkbox row. Approve all pending button top-right. Table: STATEMENT (extracted text + source document shown as a “Statement | filename” tag below the text) · STATUS (Pending badge) · ACTION — Edit · Reject · Confirm.

Docs

In-platform developer and operational reference documentation for the Knowledge track.

How to: Knowledge

Purpose

Lets you ingest your organisation’s documents, policies, and architecture content into a searchable knowledge base. Once approved, agents can retrieve content when answering questions or making decisions, and users can query it directly through chat.

Tenant Admin — uploads & approves · Business User — queries via chat · Instance Admin — manages capabilities

Creating a Knowledge Base (Institutional Brain)

Purpose

Build a searchable knowledge base from your organisation’s internal documents — policies, procedures, meeting decisions, operational guides.

⚠ Prerequisites

• You must be a Tenant Admin or have knowledge write permission
• The org and tenant must be provisioned
• Documents must be in a supported format: PDF, Word (.docx), or PowerPoint (.pptx)
• Documents should be relevant, accurate, and approved for internal AI use before uploading

Steps

1. Go to Knowledge → Institutional Brain → Upload
2. Upload your document(s)
3. The platform extracts entities and key statements using AI automatically
4. The extracted content appears in the Review Inbox
5. A knowledge admin reviews, corrects if needed, and approves the batch
6. Approved content is published to the knowledge graph and is now queryable
7. Agents and users can now ask questions answered from this content

Why review? AI extraction is not perfect. The review step lets a human verify extracted information is accurate before it becomes part of the knowledge base.

Adding Architecture or API Documentation (Enterprise Architect)

Purpose

Build a searchable knowledge base from architecture diagrams, system documentation, API specifications, and OpenAPI specs.

⚠ Prerequisites

• Same as Institutional Brain (the Knowledge section.1)
• Supported formats: PDF, Word, YAML, JSON, OpenAPI specs (.json/.yaml), architecture images (PNG, JPG)

Key difference: Structured files (YAML, JSON, OpenAPI specs, images) are automatically approved — they skip the human review inbox and go directly to the knowledge base. Only prose documents require human review.

Training a Domain Expert Model

Purpose

Create a commerce-specialised AI model (Small Language Model) fine-tuned on your own domain documents, for faster and more targeted responses on specific topics like pricing, marketplace operations, or retail strategy.

⚠ Prerequisites

• You must be a Tenant Admin or have knowledge write permission
• Source documents must be uploaded (PDF, Word)
• Sufficient source material is needed — the more relevant content, the better the model
• Compute resources must be available — contact the Instance Admin if unsure

Steps

1. Go to Knowledge → Domain Expert → Specialisations → Create Specialisation
2. Name the specialisation and describe its scope (e.g., “Commerce Operations — pricing and promotions”)
3. Upload the source documents
4. Click Generate Training Data — the platform creates question-and-answer pairs automatically
5. Click Train — a model training job is launched (30–60 minutes typical)
6. Once training is complete, click Bundle then Deploy
7. The Domain Expert model is now live for agent conversations and direct chat

Querying the Knowledge Base

Purpose

Ask natural language questions and get answers grounded in your approved documents.

⚠ Prerequisites

• At least one capability must have approved content
• You must have knowledge read permission

4.3.5 Prediction

Sub-menu: Dashboard · Model Catalog · Data Explorer · Monitor · Docs

Dashboard

DEPLOYMENT OVERVIEW — 6 KPI cards across the top:

QUICK ACTIONS — three shortcut cards: Browse Model Catalog → (“See every pre-built model and what it predicts”) · Connect Data → (“Add a warehouse so more models can activate”) · Monitor Models → (“Watch live model health, drift and predictions”).

Coverage by business area — “Models you have running in each domain.” Horizontal progress bar per domain showing active / total models and % coverage across 10 domains: Customer intelligence · Marketing & engagement · Product intelligence · Pricing & revenue · Demand & inventory · Risk & trust · Operations & fulfillment · B2B commerce · Search & discovery · Customer service.

What’s happening — “Latest model projects.” Chronological list of recent project activity, each showing: project name · last updated · current pipeline stage badge (e.g., Deploying · Mapping data · Needs attention · Awaiting review).

Model Catalog

+ Create Model button. Tabs: ACTIVE (count) | INACTIVE (count). Domain filter chip strip. Models displayed in a 3-column card grid grouped by domain. Each card: model name · status badge (Active / Deployed / Deploying / Mapping / Failed / In Review) · project version · description · domain tag · model type tag.

Data Explorer

+ Add Connection button. Your Data Sources section lists connected sources as cards, each showing: name · type badge (e.g., S3) · Connected badge · description · Tables / Columns / PII count · Last discovered date · Refresh icon · Delete icon.

Clicking a data source opens its detail page:

Monitor

Page title: “Operations Monitor” — “ML model health, system status & alerts auto-refresh every 60s.” Refresh button · notification bell icons top-right.

Docs

Technical documentation for the Prediction zone (internally named Equinox Quant).

How to: Prediction

Purpose

Provides AI-powered forecasting and recommendation models for commerce use cases — predicting customer churn, demand for a product, the likelihood a customer will buy again, and more. Use pre-built models immediately or train custom models on your own data.

Org Admin / Tenant Admin — projects, models, costs · Business User — views dashboards, triggers predictions · Instance Admin — manages OOB model catalog

Using an Out-of-the-Box Prediction Model

Purpose

Deploy a pre-built commerce AI model against your own data without building from scratch.

⚠ Prerequisites

• You must be an Org Admin or Tenant Admin
• The OOB model catalog must be available (provisioned by Instance Admin)
• A data source must be connected with relevant historical data (the Prediction section.3)
• Sufficient compute quota must be available

Available OOB Models:

Customer Lifetime Value Customer Churn Predictor Next-Purchase Predictor SKU Demand Forecaster New Product Success Product Lifecycle Classifier Return Rate Predictor Reactivation Likelihood Replenishment Trigger Search Ranking Model Customer Segmentation

Building a Custom Prediction Model

Purpose

Build a prediction model from scratch for a use case not covered by OOB models.

⚠ Prerequisites

• You must be an Org Admin or Tenant Admin
• A labelled dataset must be available and connected as a data source
• You must know the problem type: classification, regression, or time series
• Sufficient historical data is needed (consult Instance Admin for guidance)

Project Lifecycle:

Draft→ Data Mapping→ Build Plan→ Profiling→ Feature Engineering→ Review→ Training→ Consolidation→ Evaluation→ Deployed

Connecting a Data Source

Purpose

Link your commerce data to the Prediction platform so models can be trained on your real data.

⚠ Prerequisites

• You must be an Org Admin or Tenant Admin
• Connection details for the data source (host, credentials, database/table name)
• The data source must be accessible from the platform’s cloud environment
• The data must contain historical records relevant to the prediction use case

4.3.6 Language

Sub-menu: Model Catalog · Docs

Model Catalog

• On this page, tenant admin will be able to view OOTB models based on the categories.

• On click of any model will redirect tenant admins to the details page of that model.

• To create a new model, tenant admin will be required to click on Create Model button.

• They will also be able to search any model by name or ID field at the top.

• Each card shows: model name · type badge (LLM or SLM) · one-line description · time since last update. Clicking a card opens the model detail page.

Model detail page

Header: model name · Active badge · category · tag chips · model ID · last updated. Try it out button top-right. Short description below the title.

Create Model

Two modes selectable via toggle: LLM | Fine-tune. Basics, Examples, and Catalog metadata fields are shared between both modes.

Curate feedback

Info banner: “Every chat ticked as Valid below is added as a training sample to the next LLM → SLM finetune run for this model.” Chat history table — columns: DATE · INPUT · RESPONSE · FEEDBACK · VALID (checkbox) · LATENCY. Tick Valid per row to include that conversation as a training sample in the next fine-tune job.

Docs

Technical documentation for the Language zone.

How to: Language

Purpose

Manages the AI language models available on the platform — both large general-purpose models (like Claude Sonnet 5) and smaller domain-specific models (Domain Expert SLMs) trained on your commerce content. Provides a catalog, a playground for testing, and cost tracking for language model usage.

Instance Admin — manages model catalog · Org Admin / Tenant Admin — browses models, tracks costs · Knowledge Admin — deploys Domain Expert SLMs

Browsing the Language Model Catalog

Purpose

See which AI language models are available on the platform for use in agents and knowledge queries.

⚠ Prerequisites

• You must be logged in as any admin tier
• Models are provisioned by the Instance Admin

Testing a Model (Language Playground)

Purpose

Interact with a language model directly to test its responses before using it in an agent.

⚠ Prerequisites

• The model must be available in the catalog
• You must be an Org Admin or Tenant Admin

4.4 Business User (Tenant User)

Navigation Context

The Business User is a day-to-day commerce operator (merchandiser, customer service representative, analyst). Their access is restricted to the business domains granted by their assigned role — they can query knowledge bases, run agents, and act on HITL approvals, but cannot create, configure, or publish platform resources.

Left Nav: Agent Studio · Knowledge · Prediction · Language

Business Users do not see the Overview or Connectors menu items. All views are filtered to show only content within their permitted business domains.

4.4.1 Agent Studio

Sub-menu: Dashboard · Agent Store · Chat · Playground · Docs

Dashboard

• On click of the Agent Studio, tenant users will land on the dashboard where they will be able to view card view structure of workflows/ agents they have subscribed to and the actions to be taken on it.

• In the NEEDS YOUR ATTENTION section, tenant users will be able to view all Action cards in a grid, each requiring a decision or action.

Agent Store

• The Agent Store page will be comprising of 3 different tabs.

• The default landing page will be Agents tab.

Agents Tab

• Agents: In this section, list of all OOB agents will be displayed in the form of card view.

• On click of any agent will redirect tenant users to details of that agent.

• For any agent, they will be able to perform actions like Subscribe and Clone.

• The magic icon on the top right corner of the card will open a chat where tenant admin will be able to initiate chat with that agent.

• They will be able to sort the list by Most active and Newest.

• They will also be able to change the page layout from card view to list view.

• The text search will enable them to search for any agent by entering its name.

Workflows Tab

• In this section, list of all OOB workflows will be displayed in the form of card view.

• For any workflow, they will be able to perform actions like Subscribe and Clone.

• The magic icon on the top right corner of the card will open a chat where tenant users will be able to initiate chat with that workflow only in case of chat-based workflows.

• They will be able to sort the list by Most active and Newest.

• They will also be able to sort the workflows by selecting trigger types such as; All triggers, Scheduled, and Event.

• They will also be able to change the page layout from card view to list view.

• The text search will enable them to search for any workflow by entering its name.

• On click of any workflow will redirect tenant users to details of that workflow.

• On the workflow details page, they will be able to view 2 tabs; Overview and History.

• The Overview sections will display the complete working of the workflow.

• Whereas, History tab will show the trigger history.

My Creations

• This page is further divided into 3 sub-tabs; All, Agent, Workflows.

• ‘All’ tab will display list of all agents and workflows created by tenant users in the form of card view.

• Agents tab will display the agents created by themselves.

• Workflows tab will display the workflows created by themselves.

• They will also be able to change the page layout from card view to list view.

• On click of any agent/workflow will redirect tenant users to details of it.

• On the details page, they will be able to view 2 tabs; Overview and History.

• The Overview sections will display the complete working of the workflow.

• Whereas, History tab will show the trigger history.

Chat

• On the chat page, tenant users will be able to initiate a chat to create an agent or workflow.

Playground

• On the playground screen, the tenant users will be able to test the agent by selecting the agent’s name from the dropdown.

Docs

• The docs section will have ready only information regarding the agent studio, the frontend and backend logics, and other operations details.

4.4.2 Knowledge

Sub-menu: Dashboard · Domain Expert · Client Brain · Enterprise Architect · Docs

Dashboard

• On click of the knowledge, the tenant users will land on the Dashboard page where they will be able to view different trends, graphical and analytical information for its sub-tracks.

Domain Expert

OVERVIEW tab: Shows “Infosys Experts” — count of active experts and total available. Each expert row: Name + Active badge · description · feature tags (pill tags) · Test button (redirects to the CHAT tab to interact with that expert) · Deactivate button.

CHAT tab: “Start a conversation — Ask Domain Expert a question about your knowledge base.” Message input with sample placeholder. + (new session) and history icons top-right.

Client Brain

• OVERVIEW tab: Summary line (knowledge categories · documents · items extracted · confirmed).

• Alert banner when items are pending review → Review Now → button.

• 4 KPI cards: DOCUMENTS · EXTRACTED · CONFIRMED · AVG COVERAGE.

• Knowledge categories table (CATEGORY · DOCS · PROGRESS · COVERAGE · ACTION):

• CHAT tab: “Start a conversation — Ask Client Brain a question about your knowledge base.” Context-aware quick action buttons (suggested questions from ingested documents). + and history icons top-right.

• MANAGE DOCUMENTS tab: “UPLOAD FILES” section. Search field to search for any document. Upload from Confluence and Upload from Device buttons. Documents list table: DOCUMENT (name + uploader + version badge) · UPLOADED · STATEMENTS · STATUS (Pending Review / Partially Reviewed) · ACTIONS (Review link + delete icon).

• REVIEW INBOX tab: Lists all AI-extracted statements awaiting human review. Filter pills: All · Pending · Approved · Rejected. Document filter dropdown + search field. Approve all pending button for bulk approval. Checkbox per row for individual bulk selection. Table columns: STATEMENT (extracted text + source document filename) · STATUS (Pending badge) · ACTION — Edit (modify statement text before approving) · Reject (discard) · Confirm (approve and publish to knowledge graph).

Enterprise Architect

OVERVIEW tab: 5 KPI cards: Categories (modules with docs) · Platforms (platforms with docs) · APIs (endpoints documented) · Entities (across all uploads) · Covered (modules with entities). Below the KPIs, an interactive architecture diagram renders the full digital commerce platform ecosystem:

CHAT tab: “Start a conversation — Ask questions about the Equinox Commerce Platform architecture.” Input placeholder: “Ask about services, APIs, dependencies…”. Six architecture-focused quick action buttons: “What microservices handle payment processing?”, “Explain the Commerce Core architecture and its key capabilities.”, “How are orders managed across the system?”, “What integration patterns are used between services?”, “Which services depend on the API Gateway?”, “How does the loyalty and subscriptions engine work?”. Disclaimer: “AI can make mistakes — please verify important information.”

MANAGE DOCUMENTS tab: Structured differently from Client Brain. Top section titled Architecture Knowledge Coverage — “Click a card to filter – use the + Add docs strip to upload into that module.” Platform/module cards displayed in a grid, each showing: colour-coded name, docs count, status (“No docs yet” / doc count), and a + Add docs link. A + Add card allows creating new platform/module categories. Below the grid: Search by filename field. Upload from Confluence and Upload from Device buttons.

Documents table columns differ from Client Brain — includes two additional columns: MODULE (colour-coded module tag) and PLATFORM (platform name). Full columns: DOCUMENT (name + uploader + version badge) · MODULE · PLATFORM · UPLOADED · STATEMENTS · STATUS · ACTIONS. STATUS values: Pending Review / Partially Approved. ACTIONS: Review link + delete icon.

REVIEW INBOX tab: Filter pills: All (total) · Pending (count) · Approved (count) · Rejected (count) + refresh icon. “Select entities for bulk action, or approve all pending.” checkbox row. Approve all pending button top-right. Table: STATEMENT (extracted text + source document shown as a “Statement | filename” tag below the text) · STATUS (Pending badge) · ACTION — Edit · Reject · Confirm.

Docs

In-platform developer and operational reference documentation for the Knowledge track.

4.4.3 Prediction

Sub-menu: Dashboard · Model Catalog · Data Explorer · Monitor · Docs

Dashboard

DEPLOYMENT OVERVIEW — 6 KPI cards across the top:

QUICK ACTIONS — three shortcut cards: Browse Model Catalog → (“See every pre-built model and what it predicts”) · Connect Data → (“Add a warehouse so more models can activate”) · Monitor Models → (“Watch live model health, drift and predictions”).

Coverage by business area — “Models you have running in each domain.” Horizontal progress bar per domain showing active / total models and % coverage across 10 domains: Customer intelligence · Marketing & engagement · Product intelligence · Pricing & revenue · Demand & inventory · Risk & trust · Operations & fulfillment · B2B commerce · Search & discovery · Customer service.

What’s happening — “Latest model projects.” Chronological list of recent project activity, each showing: project name · last updated · current pipeline stage badge (e.g., Deploying · Mapping data · Needs attention · Awaiting review).

Model Catalog

+ Create Model button. Tabs: ACTIVE (count) | INACTIVE (count). Domain filter chip strip. Models displayed in a 3-column card grid grouped by domain. Each card: model name · status badge (Active / Deployed / Deploying / Mapping / Failed / In Review) · project version · description · domain tag · model type tag.

Data Explorer

+ Add Connection button. Your Data Sources section lists connected sources as cards, each showing: name · type badge (e.g., S3) · Connected badge · description · Tables / Columns / PII count · Last discovered date · Refresh icon · Delete icon.

Clicking a data source opens its detail page:

Monitor

Page title: “Operations Monitor” — “ML model health, system status & alerts auto-refresh every 60s.” Refresh button · notification bell icons top-right.

Docs

Technical documentation for the Prediction zone (internally named Equinox Quant).

4.4.4 Language

Sub-menu: Model Catalog · Docs

Model Catalog

• On this page, tenant admin will be able to view OOTB models based on the categories.

• On click of any model will redirect tenant admins to the details page of that model.

• To create a new model, tenant admin will be required to click on Create Model button.

• They will also be able to search any model by name or ID field at the top.

• Each card shows: model name · type badge (LLM or SLM) · one-line description · time since last update. Clicking a card opens the model detail page.

Docs

Technical documentation for the Language zone.

5. End-to-End Scenarios

Scenario 1: Onboarding a New Retail Brand (Tenant)

Goal: Set up a new tenant for a retail brand, connect it to Shopify, and deploy a customer service agent.

Scenario 2: Deploying a Demand Forecast Model

Goal: Deploy a SKU-level demand forecasting model on existing sales data.

Scenario 3: Granting a Merchandiser Product-Only Access

Goal: Invite a new merchandiser who should only be able to work with products — not orders, pricing, or customer data.

6. Assumptions & Open Questions