NEXUS ORBIT
How it works?
A complete walkthrough of every layer of NEXUS ORBIT — from the moment knowledge enters the platform to the moment a governed AI response reaches the right person through the right channel, and how NEXUS AGENTIC builds autonomous workflows on top.
Every AI response travels through seven governed layers
No response is generated without passing through knowledge separation, access control, identity qualification, routing, behaviour profiling, and delivery governance. Here is the complete chain.
Foundation
knowledge layers
Governance
policies
Verification
and how verified
Routing
→ agent profile
Profile
fallback & confidence
Delivery
right channel
Escalation
when required
Every layer of the NEXUS ORBIT routing chain you see above is also the infrastructure NEXUS AGENTIC agents rely on — agents inherit the same knowledge separation, governance policies, identity verification, and escalation framework, then extend them with autonomous reasoning and human approval gates.
The Knowledge Foundation
Every Nexus deployment begins with structured, classified, and tenant-isolated knowledge. Nothing is pulled from the open internet — only from your approved content.
Nexus stores knowledge in structured layers. Each tenant — a business unit, department, product, or customer organisation — has its own completely isolated knowledge space. Knowledge within that space is classified, chunked, and made AI-ready before any query can reach it.
Before knowledge is available to the AI, it moves through a structured pipeline — ensuring every piece of content is processed, validated, and tested before it can influence any response.
Publishing knowledge is not the end of the process. Nexus continuously monitors how knowledge performs in live use, closes gaps proactively, and generates correlated questions so that sources are robust against paraphrasing.
During processing, Nexus automatically generates a set of useful questions for each knowledge source — questions that this source is best equipped to answer. These are indexed alongside the content and used by the routing engine to understand a source's coverage area, improving retrieval precision over plain keyword matching.
Backward testing produces Knowledge Test Cases — multiple phrasings of the same question — testing whether the source retrieves reliably under paraphrasing and synonym variation. These correlated question sets stay attached to the source and are re-evaluated whenever content is updated, maintaining retrieval quality over time.
When a live query falls below the confidence threshold and triggers a fallback, the system automatically logs a Knowledge Gap record — capturing the visitor's question, session context, and which access categories were searched. Gaps accumulate a frequency count so high-volume gaps rise to the top of the review queue.
A Knowledge Gap can be converted directly into a new Knowledge Source draft in one action. Nexus pre-populates the draft with the gap's question cluster, category assignment, and suggested access classification. Once approved and published, the related gap records are automatically closed.
An isolated knowledge environment. Each tenant's data, configuration, and access rules are fully separated from every other tenant. No information crosses tenant boundaries.
A named collection of knowledge documents, FAQs, SOPs, policies, or reference material. A tenant can have multiple profiles — one per product, topic, or department.
Each document is automatically split into searchable, semantically meaningful chunks. These chunks are what the AI actually retrieves and reasons over when answering a question.
What types of content become knowledge?
- Product and service documentation
- Customer-facing FAQs and support articles
- Internal SOPs, policies, and HR handbooks
- ERP operational guides and business rules
- Partner onboarding and training material
- Compliance and regulatory reference content
Content is uploaded, classified, and approved by your team inside Nexus Studio before it is ever available to the AI. No uncontrolled content enters the system.
Every knowledge item carries a classification — sensitivity level, applicable identity types, and which access categories it belongs to. Classification happens once; the AI applies it automatically on every query.
Access Governance
Not every user should see every piece of knowledge. Nexus enforces a layered access model that determines exactly which knowledge is reachable — before the AI ever starts composing a response.
Access in Nexus is not a simple on/off gate. It is a structured hierarchy — knowledge is grouped into categories, categories are linked to access policies, and policies are assigned to AI agent profiles. Every query goes through this hierarchy before retrieval begins.
Access Category
A named collection of knowledge profiles that belong together logically. For example: "Customer Support Knowledge" or "Internal HR Policy". A category is the unit of access control.
Access Policy
A rule set that defines which identity types can access which categories, under what conditions. Policies can require verification, restrict to specific channels, or limit scope by sensitivity.
Profile Access Categories
Each AI Agent Profile is assigned a set of access categories. The AI can only retrieve knowledge from those categories — no matter what the user asks, retrieval is bounded by this assignment.
How User Access Is Determined
Access to knowledge is never determined by a single rule. It is the result of two independent sets of permissions being intersected at query time — one from the AI agent profile, one from the Identity Registry. The user only reaches knowledge that exists in both sets simultaneously.
In the example above: the agent profile grants Customer Support, Product FAQs, Billing. The Identity Registry permits Customer Support, Product FAQs for this identity type. The AI retrieves only from Customer Support and Product FAQs — Billing is excluded even though the agent profile includes it. The narrower set always wins.
Identity & Verification
The same question asked by two different people may deserve two different answers. Nexus qualifies who is asking before composing any response.
Every conversation carries an identity type. That identity type determines which access categories are permitted, which AI behaviour profile is selected, and how the system routes the interaction. Nexus supports seven distinct identity types — each with its own access profile and verification requirements.
A classification of the visitor based on their relationship with the organisation. It is set at the start of a conversation and determines what the user is allowed to access throughout the session.
Each identity type is linked to a specific verification mechanism — defining exactly how the platform confirms who the user is before upgrading their access level. The verification type is configured per identity type and enforced automatically during the chat session.
Verification type per identity
Access limited to public knowledge. No verification prompt is shown.
Must verify via a one-time password or a pre-registered email address to unlock customer-level knowledge.
Verified against the organisation's registered employee directory or SSO. Unlocks internal SOPs and operational knowledge.
Verified against a registered partner email list. Grants access to partner-specific content and controlled guidance.
Verified before accessing training modules and controlled onboarding content.
Verified against a supplier registry. Access is scoped to procurement and vendor-relevant content only.
Elevated verification for management-level access to sensitive operational and reporting knowledge.
Certain identity types — such as Verified Customer or Internal Employee — require the user to verify before unlocking additional knowledge access. Nexus supports OTP and registered email verification flows built directly into the chat experience.
A per-tenant lookup table that defines the maximum set of access categories each identity type is ever allowed to reach. Configured once by the tenant administrator, it acts as a permanent ceiling — independent of how AI agent profiles are set up. Even if an agent profile is later expanded to include more categories, the Identity Registry ensures verified customers, partners, or vendors can never accidentally gain access to categories they should not see.
Identity Type mapping — For each identity type (Public Visitor, Verified Customer, etc.), administrators define the specific access categories that type may ever reach across the entire tenant.
Hard ceiling, not a grant — The registry does not grant access on its own. It only caps. Actual access still requires the AI agent profile to also include the category. Both must agree.
Globally intentional — Identity Type and Identity Registry are intentionally shared across all tenants in a deployment. They define platform-wide identity semantics, not tenant-specific rules. Tenant isolation is enforced by knowledge and access category assignment, not by identity configuration.
Prevents profile sprawl risk — As a platform grows and more agent profiles are created or modified, the Identity Registry ensures that no profile misconfiguration can ever expose restricted content to the wrong identity type.
A named identity context within a tenant that bridges an Identity Type to a specific Knowledge Profile. Where Identity Type defines who someone is (Customer, Partner, Employee), the Identity Profile defines which knowledge scope they receive within this tenant. Multiple profiles can map to the same identity type — a "Standard Customer" and a "Premium Customer" can both be Verified Customers but receive different knowledge ceilings. The Category Identity Route selects the right profile per conversation.
Identity is qualified once per conversation session and stored securely. It cannot be changed mid-session by the user. If verification lapses, the session reverts to the unverified identity level automatically.
Intelligent Routing
Every conversation is routed to the right AI agent profile based on the channel it came from, the topic category it belongs to, and the identity of the person asking.
Routing in Nexus is deterministic, not probabilistic. A combination of three inputs — channel, chat category, and identity type — is mapped to a specific AI agent profile. That profile determines everything about how the AI will behave during the conversation.
Channel is identified
The incoming conversation arrives through a specific channel — a website chat widget, an embedded app, an internal desk integration, or an API endpoint. Each channel carries its own configuration and is associated with one or more chat categories.
Chat Category is selected
The chat category classifies the topic domain of the conversation — for example "Customer Support", "HR Queries", "Partner Onboarding", or "ERP Assistance". Categories are configured per channel and presented to the visitor at the start of the conversation when multiple categories are available.
Identity Type is qualified
The system determines the identity type of the visitor — Public Visitor, Verified Customer, Internal Employee, or another type — based on how they authenticated or how the session was started.
Category Identity Route is matched
The system looks up the Nexus Category Identity Route — a mapping table that joins Chat Category + Identity Type to a specific Nexus AI Agent Profile. This lookup is instantaneous and deterministic.
AI Agent Profile is loaded
The matched agent profile carries the behaviour configuration, the list of permitted access categories, the escalation policy, and the channel settings. From this point, every AI action is governed by this profile.
Behaviour resolution chain
If the conversation has a manually assigned profile, that takes priority. Otherwise the system resolves in order: (1) conversation-level override, (2) internal user assignment, (3) category identity route, (4) agent default behaviour. The first match wins.
Why deterministic routing matters
With probabilistic or LLM-driven routing, a misrouted conversation can expose knowledge the user should not see or apply the wrong behaviour profile. Nexus routing is a lookup, not a guess — the same Channel + Category + Identity always maps to the same agent profile, making governance auditable and predictable.
AI Behaviour Profile
The AI does not simply retrieve and repeat. Before composing any response, it applies a precise behaviour configuration that controls how it sounds, what it does when uncertain, and when it asks for human help.
A Nexus AI Behaviour Profile is a complete set of instructions that governs the AI's personality and response quality for a specific context. Different channels, categories, and identity types can each have a distinct behaviour — a public visitor chatbot sounds different from an internal employee assistant, for good reason.
Persona
The AI's name, role description, and identity. A customer-facing persona might be "Nexus Assistant", warm and helpful. An internal HR persona might be more concise and policy-precise.
Tone
How the AI communicates — formal, conversational, empathetic, technical. Tone is configured independently per behaviour profile, ensuring each deployment feels appropriate for its audience.
Confidence Threshold
A minimum retrieval confidence score below which the AI will not attempt an answer. If the retrieved knowledge does not meet this threshold, the fallback behaviour activates instead.
Fallback Rules
What the AI does when it cannot answer with confidence. Options include: returning a graceful decline message, offering to connect with a human agent, or presenting a contact route. Configured per profile.
Escalation Policy
Whether this profile supports human escalation, and under what conditions — low confidence, explicit user request, repeated fallback, sales lead, or restricted topic. The policy works in combination with the chat category's escalation setting.
System Instructions
Optional directives that shape the AI's reasoning — formatting preferences, topic boundaries, how to handle ambiguous queries, how strictly to follow the knowledge base versus general reasoning.
Governed AI Delivery
By the time the AI generates a response, everything about it is governed — which knowledge was retrieved, who the answer is for, which channel delivers it, and what gets logged.
Delivery in Nexus is not just sending a message. It is the final execution of a chain of constraints — tenant boundary, access category scope, identity qualification, agent profile behaviour, and channel rules all combine to produce one answer that is right for this person, at this moment, in this context.
The response only contains knowledge the user's identity type is permitted to receive. A public visitor will never see content restricted to verified customers, even if they ask for it directly.
The AI retrieves only from the access categories assigned to the active agent profile. No general internet knowledge, no cross-tenant data, no out-of-scope inference.
Every conversation, every message, every retrieval event is stored and attributable. Nexus keeps a complete audit trail — what was asked, what was retrieved, what was answered, and by which AI profile.
The response is delivered through the channel the conversation started on — Chat Bot widget, embedded Q&A, workflow app, or API. Each channel carries its own rendering, formatting, and UX behaviour.
Because the AI only reasons over approved, retrieved chunks — not the open internet — and because a confidence threshold gates delivery, the platform structurally prevents hallucination at the infrastructure level, not just at the prompt level.
Responses are generated in the background by an async worker and pushed to the client via a real-time socket event the moment they are ready — providing a responsive, typing-aware experience even for complex queries.
Human Escalation
When AI should not continue alone, Nexus passes the conversation to a qualified human agent — seamlessly, with full context, with zero loss of conversation history.
Human escalation in Nexus is a governed transition, not a fallback hack. It is opt-in per chat category, configurable per agent profile, and managed through the Nexus Live console by trained human agents who are assigned to specific categories.
When does escalation trigger?
Seven distinct trigger conditions — each independently configurable per AI Agent Profile. All require both gates to be open (see right).
Escalation is doubly opt-in
Two gates must both be open
Escalation only triggers when BOTH conditions are true:
- The AI Agent Profile has escalation enabled in its behaviour policy
- The Chat Category has the escalation flag turned on
This prevents accidental escalation in categories where no human agents are configured, and allows the same AI profile to behave differently across different categories.
Human agents are assigned to specific chat categories. When a conversation escalates, only agents assigned to that category receive the alert — ensuring the right person handles the right type of query.
The escalation flow
Escalation Triggered
AI flags the conversation. Visitor sees a holding message. AI stops responding.
Agents Alerted
Real-time notification sent to all available agents assigned to the conversation's category.
Agent Claims
First agent to claim gets the conversation. Others see it locked. Full history is visible.
Agent Responds
Agent types directly in the console. Messages appear as agent messages in the visitor's chat.
Resolved or Closed
Agent resolves (returns to AI) or closes the conversation. Visitor is notified of both outcomes.
Three Workspaces. Complete Control.
Everything described in this documentation is configured, managed, and monitored through three dedicated workspaces — one for each role in the platform lifecycle.
Nexus is operated entirely through no-code workspaces. Your knowledge managers, governance teams, and operations staff never need to write code to configure, govern, or monitor the platform.
Nexus Studio
The knowledge authoring and platform configuration workspace. Knowledge managers upload, classify, and approve content here. Behaviour profiles, access categories, identity routes, and agent profiles are all configured in Studio.
Nexus Admin
The governance and access control workspace. Administrators manage tenants, define access policies, configure identity types, set up the Identity Registry SafeGuard, and manage user assignments. Every compliance and audit requirement is addressed here.
Nexus Live
The real-time operations and escalation console. Operations teams monitor live conversations, track escalation queues, and human agents claim and respond to escalated conversations. Agent mode restricts each agent to only the categories they are assigned to, ensuring proper scope.
See every layer working together
Talk to us to see a live demo of the full Nexus platform — from knowledge upload to governed AI delivery.