AI features

The AI group covers grounded assistants, the models behind conversational search, recommendation models, behavioural personalization and GraphRAG inspection. AI operations are metered from the organization's credit wallet — see API keys, scopes and credits.

Assistants

/dashboard/assistants is the assistant list. Each row shows the name, id, collections, retrieval mode, model and maximum sources. Creating one asks for:

A Default collection for new assistants selector above the table pre-fills the create form's collection and shows the query_by it would suggest. The list itself has a Refresh, a row count, and a filter box once there are six or more assistants (/ focuses it).

The plan's assistants feature is required (Pro). Rows open the assistant in the Chat playground or filter Conversations to it, and can be deleted. Multi-collection JSON, provider-specific knobs and memory TTL are not exposed in this form — the console's raw-resource admin is where the full shape lives.

Conversation models

/dashboard/conversation-models manages the models used by conversational search — distinct from assistants. A conversation model pairs an LLM with a history collection that stores the conversation:

• Model id — optional; left blank, the engine assigns one.
• Model — a provider/model name.
• API key — optional; stored on the platform and never returned. Blank uses the platform's credentials.
• History collection — where the turns are written. Give conversations their own collection rather than pointing this at a catalogue.
• Max bytes and TTL — how much history is kept and for how long; both must be positive numbers when given.
• System prompt.

The model name and history collection are required. The table shows the id, the model, a link to the history collection, the context size, the remembered TTL and the system prompt (in a tooltip); the list has a Refresh, a filter box once there are six or more rows, and a link to Assistants.

Deleting a model means searches that named it stop working; turns already written stay. The assistants plan feature is required.

Conversations

/dashboard/conversations lists the most recent conversations an assistant handled, with the transcript and the sources each answer cited. It supports a client-side search over the preview, assistant and visitor identifiers; an assistant filter; a JSON or Markdown transcript export; single delete and bulk delete.

The visitor column distinguishes a signed-in user from a session or server call. The list is capped at the 100 most recent conversations — the screen says so, and older conversations need server-side pagination that the conversations API does not offer yet. Deleting a conversation removes its transcript and messages for good; the next visitor message starts a new one. Deletion is limited to owners and admins.

Recommendations

/dashboard/recommendations manages trained recommendation models per collection. The recommendations plan feature is required. Creating or editing a model exposes its type plus type-specific parameters:

Model types include looking_similar, related_items, bought_together, trending, popular, session, query_to_item, upsell, cross_sell, complementary, substitutes, alternatives, recently_viewed, recently_searched, sequential and graph. Vector-based types need a vector field; category-based types need a category field. Event-based models show a building status until their first build; vector models serve immediately. Deleting a model makes every page that asks for it fail until the id exists again.

The model list shows each model's id, type, status, vector field, window, filter and last build time, with a Refresh and a collection selector that round-trips through the URL; an empty list suggests starting with trending or looking_similar.

Preview queries the model and is disabled while a model is still building. Its inputs depend on the type: an anchor object_id (or several as a comma-separated object_ids), a user_id / anonymous_id / session_id for subject-based models, and a query for query_to_item; the result size is clamped to 1–100 and the result reports took_ms, the experiment and — for recently_searched — the recent queries.

A 7 / 30 / 90-day analytics table (with CSV download) reports requests, coverage, impressions, clicks, CTR, carts, purchases, revenue and a CTR by position column breaking the first ten positions down per slot ("no positions reported" when there are none); empty_requests appears in the CSV. The screen also emits the <nova-recommendations> snippet for a storefront.

Personalization

/dashboard/personalization shapes ranking per visitor from behavioural events. It has five tabs; edits require an owner or admin. A collection picker in the header (showing the document count and an "on" marker) and the tab both round-trip through ?collection= and ?tab=, so a view is a shareable link, and a header action links to Recommendations.

• Settings — enable personalization; a strength slider (0–100%); a decay half-life; the maximum number of boosts per search (0–20); the category and brand fields; event weights for view, click, add-to-cart, purchase, favourite, wishlist and dismiss (negatives demote); and which surfaces it applies to (search, autocomplete, recommendations). A status banner says whether it is on, what it is applied to, and warns when it is enabled but applied to nothing. A "Wiring it up" sample shows the POST /events call with the x_user_id, x_anonymous_id and x_surface headers and the x-nova-personalized response header.
• Profiles — look up a profile by subject type (user / anonymous) and id; see its segments, statistics and top affinities (negative ones in red); delete the profile (everything learnt about it is erased and results fall back to the collection's own ranking); and browse recently updated profiles.
• Rules — named rules with a scope (one collection or all), a condition ("is in segment" over ten segments, or "has affinity for" a category, brand, product or query above an optional minimum score), actions (boosts, an exclusion filter, pins) and a priority. The highest priority wins. A rule on a collection where personalization is off does nothing.
• Simulator — run a query as a subject with an optional strength override (0–1, defaulting to the configured value) and see the profile it found, its segments and the rules that matched, the boosts applied (filter_by:weight), the sort_by / filter_by used, and baseline versus personalized result lists with the positions that moved.
• Analytics — the personalization summary for the period.

Knowledge graph

/dashboard/graph inspects the GraphRAG layer built from a collection: entities, claims, community reports and global search.

These screens drive the graph search API; the same endpoints work from your own server.

Entities and claims are requested with caps — 200 entities and 500 claims — and the screens do not show a truncation notice, so a capped table looks complete.

Next

• Search and relevance
• Insights and quality
• Storefront UI