# README Welcome to your team’s developer platform ### Documentation and guidance for the European sovereign AI platform #### About GLBNXT GLBNXT is a European sovereign AI platform that enables organisations to securely adopt, build, and deploy artificial intelligence solutions within a fully controlled and compliant environment. The platform combines secure European infrastructure, enterprise governance, and an integrated ecosystem of AI tools and automation solutions, allowing organisations to implement AI while maintaining full control over data, privacy, and regulatory compliance. *** #### How This Knowledge Centre Is Structured The GLBNXT Knowledge Centre is organised into four main areas, each serving a distinct purpose depending on what you need. #### The configure GLBNXT This section is your reference for understanding, configuring, and managing your GLBNXT environment. It covers the operational layer of the platform: the applications you work within, the AI infrastructure that powers them, and the administrative controls that keep everything running to your organisation's requirements. **Applications** covers the Dashboard and Sandbox. The Dashboard gives you visibility into platform activity, usage, and status at a glance. The Sandbox is your space to test models, experiment with configurations, and evaluate outputs before committing them to production workflows. **AI Platform** covers the Model Hub, where you select, manage, and configure the language models available within your GLBNXT environment. This is where AI infrastructure decisions are made, from choosing the right model for a given use case to understanding the options available within your subscription. **Platform Configuration** covers the administrative controls your team needs to manage GLBNXT at an organisational level. This includes subscription management, application settings, user access and permissions, and compliance configuration to align the platform with your organisation's policies and regulatory requirements. #### Product Documentation This covers the two core products in depth. GLBNXT Workspace is the end-user AI environment, and its documentation guides users through the interface, AI capabilities, and day-to-day workflows. GLBNXT Platform is the full-stack infrastructure layer, documented for the IT teams, developers, and administrators who deploy and manage it. Each product has its own dedicated documentation track. #### Support and FAQ This brings together answers to common questions, troubleshooting guidance, and practical help for issues you may encounter. If you are looking for a quick answer or have run into a specific problem, this is the place to start. *** > GLBNXT helps organisations safely benefit from AI while maintaining European data sovereignty and enterprise security. *** #### Learn more
Cover image

:share-nodes:

Configure GLBNXTManage and configure your GLBNXT environment/spaces/pTjCOVawQy4IanIw4NcK/pages/LThc2RqOxBKU56Qt3TMy/files/pReeuHQF5YEkh08QcyXC

:desktop:

PlatformA fully managed AI platform built for development teams/spaces/wBtXZh9iWH29IcLY8HJR/pages/LThc2RqOxBKU56Qt3TMy/files/TcTzHwzIYB7WUYtINeex
# GLBNXT Knowledge Centre n8n is a visual workflow automation platform that enables developers and technical teams to build complex, event-driven AI pipelines. By combining standard API nodes with native LangChain nodes, n8n bridges the gap between raw LLM capabilities and your internal stack—allowing you to trigger agents via webhooks, interact with databases, and automate multi-step technical workflows without writing boilerplate glue code. In this section, you'll learn how to integrate n8n into your infrastructure to automate AI-driven operational tasks. This guide covers connecting API developer keys, configuring sovereign model nodes, and executing structured tool calling. # README The GLBNXT Customer Portal is your central hub for managing applications, AI models, and platform settings. From here you can access your deployed applications, explore ready-made configurations, and manage your organization's platform settings. ### Portal Overview The portal is organized into three main sections, accessible from the sidebar: #### Applications * **Dashboard**: Your home screen. View and launch your deployed applications. * **Sandbox**: Browse ready-made configurations and demos. Download configurations to use in your own setups, or try out included demos directly. #### AI Platform * **Model Hub**: Browse available AI models. View detailed model information to help you choose the right model for your use case. #### Platform Configuration These sections are only visible to users with the administrator role. * **Subscription**: View and manage your organization's subscription plan and usage. * **Application Management**: Configure and manage the applications available to your organization. * **User Management**: Add, edit, and manage user accounts and assign roles. See User Roles for details on available roles and permissions. * **Compliance**: Access compliance settings and audit controls. ### Navigation The sidebar provides access to all sections. At the bottom of the sidebar you will find: * **Help & Support**: Opens the documentation portal with help resources and guides. * **User profile**: View your account details and sign out. Your organization name is displayed at the top of the sidebar. ### ### Jump right in
Cover image
:align-justify:Model hubChoose your LLM/files/uSbK5QdacfhMzc3e2sMd/pages/CXMaWP0ciomB0uw6DjyW
:box:SandboxLearn, accelerate, and choose proven plans/files/mFB2fzPJHa8Xo4ngi9Gq/pages/Dg6aj0auNq1UMBvwZ5gT
:shield-check:ComplianceConfigure your required company complaincy/files/wrEPbfVGAePdj22ErpgOhttps://github.com/GLBNXT/glbnxt-docs/blob/main/glbnxt/platform-configuration/compliance.md
# Configure GLBNXT n8n is a visual workflow automation platform that enables developers and technical teams to build complex, event-driven AI pipelines. By combining standard API nodes with native LangChain nodes, n8n bridges the gap between raw LLM capabilities and your internal stack—allowing you to trigger agents via webhooks, interact with databases, and automate multi-step technical workflows without writing boilerplate glue code. In this section, you'll learn how to integrate n8n into your infrastructure to automate AI-driven operational tasks. This guide covers connecting API developer keys, configuring sovereign model nodes, and executing structured tool calling. # Dashboard The Dashboard is your starting point on the GLBNXT Platform. It provides quick access to all applications available to your organization. ### Overview When you log in to the GLBNXT Platform, the Dashboard is the first screen you see. It displays a personalized welcome message with your name, followed by a grid of application tiles representing the applications configured for your organization.
### Application Tiles Each tile on the Dashboard represents an application you can access. Tiles display: * **Name**: The application name * **Description**: A brief explanation of what the application does * **Logo**: The application icon or logo * **Badge**: Optional status indicator (e.g., "New" or "Beta") * **Action button**: Opens the application **Tile Order** Applications are arranged in a specific order set by GLBNXT. Active applications appear first, while unavailable applications appear at the bottom in a greyed-out state. **Unavailable Applications** Some tiles may appear greyed out and cannot be clicked. This means the application is currently unavailable for your organization. Contact support if you believe an application should be accessible.
### View Modes The Dashboard offers two view modes for displaying your applications: | View | Description | | ------------ | --------------------------------------------------------------------- | | Card view | Larger tiles showing name, description, and logo. Default on desktop. | | Compact view | Smaller icon-based tiles. Default on mobile devices. | On desktop, you can switch between views using the toggle button in the top-right corner of the Dashboard. Your preference is remembered for future visits. On mobile devices, the Dashboard always uses compact view for optimal screen usage.
### Single Sign-On (SSO) Some applications on the GLBNXT Platform support Single Sign-On. When you click a tile for an SSO-enabled application, you are automatically logged in without needing to enter your credentials again. Applications that do not support SSO may require you to log in separately. ### Empty Dashboard If your Dashboard shows no application tiles, this means no applications have been configured for your organization yet. Contact support to have applications assigned to your organization. #### Diagram ```mermaid flowchart LR User([You]) --> Dashboard Dashboard --> Tile1[Application Tile] Dashboard --> Tile2[Application Tile] Dashboard --> Tile3[Application Tile] Tile1 -->|SSO| App1[Application] Tile2 -->|SSO| App2[Application] Tile3 -->|Login required| App3[Application] ``` # Use cases The Use cases provides a collection of ready-made templates that showcase configurations you can download and use in your own setups. Some templates include interactive demos you can try out directly. ### Overview The Sandbox page displays a browsable collection of templates. Each template demonstrates a specific configuration or workflow that can be replicated in your own environment. Templates also indicate which applications are required, so you can quickly assess whether a template is relevant to your setup.
### Finding Templates The Sandbox includes search and filter options to help you find templates that are relevant to you: * **Search**: Filter templates by typing a name or keyword. Results update as you type. * **Filter by category**: Use the dropdown to narrow the list. You can view all templates, show only those available to your organization ("Available to Me"), or filter by a specific application (e.g., OpenWebUI, n8n). These controls are especially useful as the template library grows, helping you quickly identify templates that match the applications your organization has access to. ### Templates Each template is presented as a card that gives you a quick overview of what it offers. You can see the template's name, a short description of what it demonstrates, and which applications are needed to use it. Required applications are displayed as icons, making it easy to check compatibility at a glance. From each template card, you have two options: * **Try Demo**: Launches an interactive demo so you can experience the template in action. * **Instructions**: Opens setup instructions for replicating the template in your own environment. # Model hub The Model Hub is your central place to discover and explore all AI models available on the GLBNXT Platform. Whether you are looking for a model for text generation, code assistance, or multimodal tasks, the Model Hub helps you compare models and find the right fit for your use case. ### Overview The Model Hub presents all available models in a searchable, filterable table. Each model entry gives you key information at a glance: the model's name, its creator, a technical model ID for use in API calls, a description of what the model can do, and its supported use cases.
### Finding the Right Model To help you navigate the model library, the Model Hub offers several filters: * **Model Creator**: Filter by the organization behind the model (e.g., Anthropic, Mistral). * **Region**: Filter by where the model is hosted. This is important for compliance and data residency requirements (see "Regional Availability" below). * **Use Case**: Filter by what the model is designed for, helping you quickly find models that match your needs. You can also search by model name or model ID using the search field.
### Regional Availability Each model shows one or more flag icons indicating where it is hosted. Models may be configured in redundant setups across multiple regions, which is why you may see more than one flag. The flags have the following meaning: * **Dutch flag**: The model runs on physical hardware located in The Netherlands. * **European flag (EU)**: The model runs on physical hardware in Europe, operated by a European company. * **US flag**: The model runs on physical hardware in the United States, or the hosting company is a US entity. Understanding regional availability helps you make informed decisions about data residency and regulatory compliance. ### GLBNXT-Hosted Models Models with the `glbnxt/` prefix in their model ID run exclusively on dedicated GLBNXT infrastructure. This means the model is hosted and managed entirely by GLBNXT, giving you full control over where your data is processed. ### Model ID Each model has a unique technical identifier (e.g., `anthropic/claude-opus-4.6`) that you use to reference it in API calls. You can copy a model ID to your clipboard by clicking the copy icon next to it. A confirmation notification appears when the ID is copied. ### Model Card Clicking on a model row opens its model card, a detailed view with additional information: * **Overview**: The model's full name, model ID (both copyable), creator, and regional availability. * **Supported Modalities**: Shows which input types (e.g., Text, Image, Audio, Video, Code, Document) and output types the model supports, with clear indicators for supported and unsupported modalities. * **Capabilities**: Describes what the model can do, when available. * **Technical Specifications**: Key technical details such as context window size and maximum completion tokens. The model card helps you evaluate whether a model meets your technical requirements before integrating it.
### Benchmarks When choosing a model, benchmarks can help you understand how it performs on standardized tasks. Benchmarks measure a model's abilities across areas like reasoning, coding, mathematics, and instruction following. The Model Hub may display benchmark scores when available. For a broader view of how models compare, the following independent sources provide up-to-date benchmark data: * [**Artificial Analysis**](https://artificialanalysis.ai): Compares hundreds of models on quality, speed, and pricing. Covers both open-source and proprietary models. A good starting point for a general performance overview. * [**Hugging Face Model Cards**](https://huggingface.co/models): Each model's page on Hugging Face includes detailed benchmark scores reported by the model creator. Useful for in-depth technical evaluation of a specific model. * [**Chatbot Arena**](https://arena.ai): Ranks models based on anonymous head-to-head evaluations by real users. The Elo-based leaderboard reflects how models perform in practice, beyond standardized tests. These sources are publicly accessible and regularly updated. ### # Developer Keys Developer Keys is where you manage API keys that let your applications connect to AI models on the GLBNXT platform. From here you can create new keys, control which models each key can access, and revoke keys you no longer need. ### Overview The GLBNXT platform exposes an OpenAI-compatible API endpoint, which means any tool or application that already works with the OpenAI API can connect to your organization's AI models with minimal changes. Developer Keys is the starting point: you create a key here, then use it in your application to authenticate API requests. This feature needs to be provisioned for your organization. If you see a "Feature Not Available" message, contact your administrator or GLBNXT support to get it enabled. Only administrators have access to Developer Keys. Other users in your organization will not see this page. ### Connection Info At the top of the page you will find the Base URL for the API endpoint: ``` https://ai.glbnxt.com/v1 ``` Use this URL together with your API key to connect your applications. A copy button makes it easy to grab the URL. ### Key List Once you have created keys, the page shows them in a table. Each key displays its name, how many models it can access, when it was created, when it expires, and when it was last used. This helps you keep track of which keys are active and whether they are still in use. The table footer shows a summary of how many keys are active and how many have been revoked. You can toggle "Show revoked keys" to include revoked keys in the list. Revoked keys are marked with a badge and cannot be used or modified. If no keys exist yet, the page shows an empty state with a button to create your first key. ### Model IDs When connecting your application, you need to specify which model to use. Each model has an ID that you pass in your API requests. The available models and their IDs depend on what your organization has provisioned. You can find the exact model IDs available to your key in the **Assign Models** dialog. Model IDs come in different formats depending on how they were set up: * `claude-opus-4-6` * `glbnxt/gpt-oss-120b` (custom organization prefix) The model ID you see in the Assign Models dialog is what you use in your API calls and tool configurations. ### Key List Once you have created keys, the page shows them in a table. Each key displays its name, how many models it can access, when it was created, when it expires, and when it was last used. This helps you keep track of which keys are active and whether they are still in use. The table footer shows a summary of how many keys are active and how many have been revoked. You can toggle "Show revoked keys" to include revoked keys in the list. Revoked keys are marked with a badge and cannot be used or modified. If no keys exist yet, the page shows an empty state with a button to create your first key. ### Creating a Key Click **Create Key** to open the creation dialog. You give the key a name that identifies its purpose (for example, "Production Backend" or "Analytics Pipeline") and choose how long it should remain valid: 30 days, 90 days, 1 year, or indefinitely. The default is 1 year.
After creation, the portal displays the API key one time. Copy it immediately and store it securely. The key cannot be retrieved later. If you lose it, you will need to create a new one. ### Managing Models Each key can be scoped to specific AI models. Open the actions menu on a key and select **Assign Models** to choose which models the key can access. You can search and filter the available models, select individual ones, or use "Allow all models" to grant access to everything your organization has available.
If you are not sure which models to assign, allowing all models is a safe starting point. You can always narrow the scope later.
### Renaming a Key Open the actions menu on the key and select **Rename** to change its display name. Keeping names descriptive helps your team understand what each key is used for.
### Deleting a Key Open the actions menu and select **Delete** to permanently revoke a key. Any application using the key will immediately lose access, so make sure the key is no longer in use before deleting it. Deleted keys remain visible in the revoked keys list for reference.
# Subscription The Subscription page gives you a complete overview of what your organization has access to on the GLBNXT Platform. Use this page to understand your current plan, see which applications are available, and review the AI models included in your subscription. ### Overview The Subscription page is read-only and organized into three sections: your plan details, included applications, and included models. If you need to make changes to your subscription, please contact your GLBNXT representative.
### Plan Details At the top of the page, you can see your current subscription plan: * **Plan name**: The name of your active plan (e.g., "Platform"). * **Description**: A short summary of what the plan includes. * **Status**: Whether the plan is currently active. * **Billing cycle**: How often the plan is billed (e.g., "Monthly"). ### Included Applications This section lists all applications available under your subscription. Each application is shown with its logo and name. These are the same applications that appear on your [Dashboard](/configure-glbnxt/applications/dashboard). If you require additional applications, please contact GLBNXT. ### Included Models This section lists all AI models your organization can access, with the total count shown in the header. Each model entry displays the provider's icon, the model name and the provider organization. To learn more about any model, visit the [Model Hub](/configure-glbnxt/ai-platform/model-hub) where you can view detailed model cards with technical specifications, supported modalities, and regional availability. # Application management ## Application Management The Application Management page shows the applications connected to your organization and allows you to manage their configuration where applicable.
### Overview This page lists all applications linked to your account. For some applications, such as OpenWebUI and LibreChat, you can configure which AI models are exposed to the application. Other applications may not have user-configurable settings yet. {% columns %} {% column %}
{% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} ### Application Status Each application entry shows its logo, name, description, and current status: * **Available**: The application has configuration options you can manage. * **Not available**: The application is connected to your organization but does not currently have configuration settings for you to manage. {% hint style="info" %} This section is in early stages of development. More management capabilities will be added shortly. {% endhint %} # User management The User Management page gives administrators a central place to manage everyone who has access to the organization's portal. From here you can add new users, adjust roles, and handle account security.
### User List The main page displays all users in your organization in a table showing each user's name, email, role, account status, and an actions menu. A search bar lets you find users by username, email, first name, or last name. The **Add User** button creates a new user account for your organization. Each user's role can be changed directly from the table using a dropdown. Three roles are available: * **Administrator**: Full access to all portal sections, including Platform Configuration. Administrators cannot change their own role. This is a safety mechanism to prevent accidentally losing access to Platform Configuration. To change an administrator's role, another administrator must make the change, or you can contact GLBNXT support. * **Moderator**: Reserved for future use. This role will be used for content administration tasks such as managing system prompts. The platform is already prepared for this. * **User**: Access to Applications and AI Platform sections only. The actions menu provides shortcuts to view the user's profile, check their activity, deactivate their account, or temporarily lock it. ### User Detail Page Clicking a user row opens their detail page, which is organized into two tabs: **Profile** and **Activity**.
#### Profile Tab The Profile tab contains four sections: **Profile Information** shows the user's personal details, contact information, and account details. An Edit button allows modifications to the profile fields. **Access & Permissions** lets you change the user's role and view their current account status. Below that, Account Management provides two actions: * **Lock Account**: Temporarily suspends access as a security measure (e.g., suspicious activity or password issues). User data is preserved and the account can be unlocked at any time. * **Deactivate Account**: Permanently suspends access while preserving data. Use this when a user leaves or no longer needs access. The account can be reactivated later or permanently deleted. **Security** provides two password management options: * **Set Temporary Password**: Generate a password that you share with the user. They will be required to change it on first login. * **Send Password Reset Email**: Send the user a secure link to set their own new password. **Danger Zone** contains the permanent deletion option. A user account must be deactivated before it can be deleted: the delete button remains disabled with a notice explaining this requirement. Deleting a user permanently removes all their data and cannot be undone. #### Activity Tab The Activity tab provides an important audit trail for each user account. It records all significant account events in a table with columns for time, action, actor, and outcome. Use this tab to trace what has happened to a user account, such as when the account was created, when their email was verified, password changes, role updates, and login activity. You can configure how many events to display and refresh the list to see the latest activity.
### Identity Providers The platform supports connecting multiple identity providers for user authentication. If your organization uses an external identity provider (such as Azure AD, or Google Workspace), contact GLBNXT to discuss integrating it with your portal setup. # Compliance The Compliance section provides the tools your organisation needs to manage regulatory and internal policy compliance within the GLBNXT platform. From here, administrators can review a complete audit trail of platform activity and manage the full lifecycle of compliance policies. * [**Audit Logs**](/configure-glbnxt/platform-configuration/compliance/audit-logs) — a chronological record of all tracked changes on your platform, with filtering, detailed event views, and pagination. * [**Policies**](/configure-glbnxt/platform-configuration/compliance/policies) — create, publish, and track acceptance of compliance policies across your organisation, with document uploads, control questions, and reporting. # Audit Logs The Audit Logs page gives administrators a complete audit trail of all changes made on the platform. Every time someone adds, updates, or removes a configuration, the action is recorded here. This makes it straightforward to trace who changed what and when, whether you are investigating an issue, reviewing access changes, or preparing for a compliance audit. Navigational actions such as viewing pages are not tracked: only actions that modify data appear in the logs. ### Filtering Three filter buttons help you find specific events: * **Date Range**: Defaults to the last 7 days. The exact date range is displayed above the table. * **Action Type**: Filter by the type of change (e.g., User Locked, User Deactivated, User Reactivated). * **Actor**: Filter by the person who made the change. A label below the filters indicates how many filters are currently applied. ### Log Table Each log entry contains the following information:
ValueDescription
TimeWhen the action occurred
ActorWho performed the action (shown as their email address)
ActionWhat was done (e.g., "User Reactivated", "User Locked")
TargetWhich user or resource was affected
OutcomeWhether the action succeeded
### Event Detail Clicking a log entry expands it to reveal the full context of the change, organized into four sections: **Actor Details** identifies who performed the action, including their user ID, email, IP address, and browser user agent. This level of detail helps verify the authenticity of actions and identify the exact session involved. **Target Details** identifies the affected resource, including its type, ID, and name. **Changes** shows exactly what was modified, displaying the previous and new values side by side (e.g., status changed from "deactivated" to "active"). This makes it easy to understand the impact of each action at a glance. **Request Metadata** shows the technical context, including the source (e.g., "portal") and the API path that was called. ### Pagination Below the table, pagination controls show the total number of entries. You can configure how many entries to display per page and navigate between pages. # Policies The Policies section gives your organisation the tools to manage policy compliance across your entire team. Administrators create compliance policies, attach supporting documents, define control questions, and track employee acceptance, all from within the GLBNXT platform. Employees review and accept policies as part of their normal platform access. Every action is recorded in a full audit trail, giving your compliance and governance teams the visibility they need. The Policies page is available under **Platform Configuration → Compliance → Policies** in the sidebar for administrators. Employees can review accepted policies under **My Account**. ### Managing Policies #### The Policies Overview The Policies page is your central view of all compliance policies in your organisation. The list displays the following columns for each policy: **Title**, **Status** (Draft, Published, or Archived), **Version** (the current version number), **Published** (the date the active version was published), and **Acceptance** (the percentage of employees who have accepted the current version). From here you can create new policies, open existing ones for editing or review, and export compliance reports. Navigate to the Policies page from the sidebar: **Platform Configuration → Compliance → Policies**. #### Creating a Policy To create a new policy: 1. On the Policies page, select **Create Policy** 2. Enter a title and description for the policy 3. The policy is created in **Draft** status A draft policy is visible only to administrators. Employees will not see the policy until it is published. #### Uploading a Document Each policy version requires a PDF document that employees will review before accepting. To upload a document: 1. Open the policy and navigate to the document section 2. Drag and drop a PDF file, or click to browse your files 3. Only PDF files are accepted, with a maximum size of 10 MB The document is stored securely within your organisation's environment and is accessible only to authenticated users within your organisation. #### Adding Control Questions Control questions verify that employees have read and understood the policy. You can add up to three control questions per policy version. Two question types are available. **Multiple Choice** questions present a set of answer options. One option must be marked as the correct answer. Employees must select the correct answer before they can accept the policy. This is useful for verifying comprehension of specific policy requirements. **Free Text** questions allow employees to provide a written response. Any non-empty answer is accepted. This is useful for collecting acknowledgements or asking employees to describe how a policy applies to their role. To add a control question: 1. Open the policy and navigate to the questions section 2. Select **Add Question** and choose the question type 3. For Multiple Choice: enter the question, add answer options, and mark the correct answer 4. For Free Text: enter the question 5. Save the policy #### Publishing a Policy Publishing a policy makes it immediately active for all employees in your organisation. Every employee will be required to review the document, answer the control questions, and accept the policy before they can continue using the platform. To publish a policy: 1. Open the draft policy 2. Select **Publish** 3. Confirm the action in the confirmation dialog Once published, the policy cannot be returned to draft status. If changes are needed, create a new version instead. #### Understanding Policy States Each policy version moves through a defined lifecycle: * **Draft** — the policy is being prepared and is visible only to administrators * **Published** — the policy is active and requires acceptance from all employees * **Superseded** — a newer version of the policy has been published, replacing this version * **Archived** — the policy has been retired and is no longer presented to employees #### Creating a New Version When a policy needs to be updated, create a new version rather than editing the published version. This ensures that employees who accepted the previous version are required to review and accept the updated content. 1. Open the published policy 2. Select **Create New Version** 3. Update the document, questions, and description as needed 4. Publish the new version when ready When a new version is published, the previous version moves to **Superseded** status. All employees must accept the new version, regardless of whether they accepted the previous one. ### Tracking Acceptance #### Acceptance Rates The Policies overview page displays the acceptance rate for each published policy, showing how many employees have accepted the current version relative to the total number of employees in your organisation. #### Per-Employee Acceptance For a detailed view, open a policy and navigate to the **Acceptance** tab. This shows each employee's acceptance status for the current version, including: * Whether they have accepted * The date and time of acceptance * Their responses to control questions This information supports internal audits and regulatory evidence requirements. Acceptance records are retained even after a policy is archived, ensuring a complete historical record. ### Exporting Reports The Compliance Center includes a reporting function that allows you to export acceptance data for offline analysis, auditing, or sharing with compliance stakeholders. To export a report: 1. Select **Export** from the Policies overview page or from within a specific policy 2. Choose a format: **CSV**, **XLSX**, or **PDF** 3. Apply filters as needed: * Filter by specific policy * Filter by version * Filter by date range 4. Select **Export** to download the report Exported reports include employee names, acceptance status, acceptance dates, and responses to control questions for the selected scope. ### Archiving Policies When a policy is no longer relevant, it can be archived. Archiving retires the policy so that it is no longer presented to employees, but all acceptance records and audit history are preserved. To archive a policy: 1. Open the policy 2. Select **Archive** 3. Confirm the action Archived policies remain visible to administrators in the policy list for reference and audit purposes. Policies cannot be deleted, only archived. This ensures that your compliance history remains complete and auditable. ### Audit Logs All compliance-related actions are recorded in the platform audit trail. Navigate to **Platform Configuration → Compliance → Audit Logs** to view compliance-specific audit entries. Recorded action types include: * `policy.created` — a new policy was created * `policy.published` — a policy version was published * `policy.archived` — a policy was archived * `acceptance.submitted` — an employee accepted a policy version Each entry includes a timestamp, the user who performed the action, and the details of what changed. Audit log entries are immutable and cannot be modified or deleted. For more information on the platform's audit capabilities, see [Audit Logs](/configure-glbnxt/platform-configuration/compliance/audit-logs). ### Accepting Policies as an Employee When your organisation publishes a compliance policy, you will be asked to review and accept it the next time you access the platform. This is a required step and cannot be skipped or dismissed. #### What to Expect When you log in and there are policies awaiting your acceptance, a full-screen dialog will appear. You will need to complete the following steps for each pending policy: 1. **Read the policy document:** the full PDF document is displayed within the dialog 2. **Answer the control questions:** your organisation may include questions to confirm you have understood the policy * For multiple choice questions, you must select the correct answer. If you select an incorrect answer, you can try again without penalty * For free text questions, provide a written response. Any non-empty answer is accepted 3. **Accept the policy:** once you have reviewed the document and answered all questions, confirm your acceptance If multiple policies are pending, you will work through them one at a time. You must accept all pending policies before you can access the platform. #### Viewing Your Accepted Policies You can review policies you have previously accepted at any time. Navigate to **My Account → Policies** to see a list of all policies you have accepted, along with the documents and your responses to the control questions. #### Common Questions **Why can I not close this dialog?** Your organisation requires all employees to review and accept this policy before using the platform. This is a compliance requirement set by your administrator. The dialog will close once you have completed the acceptance process. **What happens if I answer a question incorrectly?** For multiple choice questions, you will be asked to try again. There is no penalty for an incorrect answer, and you can attempt the question as many times as needed. **Where can I find my accepted policies later?** Navigate to **My Account → Policies** to view all policies you have accepted, including the documents and your responses. ### Getting Started This section covers the initial steps for administrators setting up the Compliance Center for their organisation. #### Permissions Access to the Compliance Center is controlled through your organisation's permission settings in the GLBNXT platform. Two permission levels are relevant: * **Manage compliance** — allows administrators to create, edit, publish, and archive policies, view acceptance data, and export reports. Assign this to users who will manage your organisation's compliance policies. * **View compliance** — allows employees to view and accept published policies. This should be assigned to all users who need to interact with compliance policies. To configure permissions, navigate to your organisation's user management settings and assign the appropriate compliance permissions to each user or role. #### Document Storage Policy documents are stored securely within your GLBNXT platform environment. Documents are scoped to your organisation, ensuring that policy files are accessible only to authenticated users within your organisation. No additional storage configuration is required. ### Known Limitations The following limitations apply to the current release of the Compliance Center: * **Document viewer** — the built-in document viewer does not currently support zoom or in-document search. * **No policy deletion** — policies can be archived but not permanently deleted. This is by design to preserve audit integrity. * **No version changelog** — when creating a new version of a policy, there is no dedicated field to describe what changed from the previous version. # README GLBNXT Workspace is the AI work environment for knowledge workers. It gives your teams a secure, sovereign alternative to public AI tools like ChatGPT, hosted entirely on European infrastructure, under your organisation's control. Workspace provides a unified interface to access and interact with leading AI models, build intelligent assistants, and work with your own documents and data. It is designed to be immediately usable by business users without technical setup, while meeting the governance and compliance requirements that enterprise organisations demand. {% columns %} {% column %}
{% endcolumn %} {% column %} Workspace provides a unified interface to access and interact with leading AI models, build intelligent assistants, and work with your own documents and data. It is designed to be immediately usable by business users without technical setup, while meeting the governance and compliance requirements that enterprise organisations demand. {% endcolumn %} {% endcolumns %} *** This section of the GLBNXT Knowledge Centre covers everything you need to get the most out of Workspace, from your first conversation to deploying AI assistants across your team. It is organised around the core capabilities of the product: the chat and model interface, knowledge and document handling, agent and assistant building, and the enterprise controls available to administrators. If you are looking for infrastructure, deployment, or advanced AI development capabilities, those are covered in the GLBNXT Platform section. ### Jump right in

:message-captions:

THE CHAT INTERFACEThis is where your interaction with AI happens/pages/tpLPCMdnfODdsOV1rQSm

:book-copy:

QUERYING YOUR DOCUMENTSQuery your uploaded documents through natural language/pages/JQEYxuqF0FLVscCB5Bl8

:message-bot:

BUILD YOUR AGENTHave a purpose-built AI assistant ready to use/pages/j0jnk8TUhrUo4v9IqY1x
# GLBNXT Workspace n8n is a visual workflow automation platform that enables developers and technical teams to build complex, event-driven AI pipelines. By combining standard API nodes with native LangChain nodes, n8n bridges the gap between raw LLM capabilities and your internal stack—allowing you to trigger agents via webhooks, interact with databases, and automate multi-step technical workflows without writing boilerplate glue code. In this section, you'll learn how to integrate n8n into your infrastructure to automate AI-driven operational tasks. This guide covers connecting API developer keys, configuring sovereign model nodes, and executing structured tool calling. # What is GLBNXT Workspace GLBNXT Workspace is the AI work environment for knowledge workers. It gives your teams a secure, sovereign alternative to public AI tools like ChatGPT, Gemini, and Perplexity, hosted entirely on European infrastructure and fully under your organisation's control. Where public AI tools require you to send your data to third-party clouds outside your control, Workspace keeps everything within a managed, EU-hosted environment. Your conversations, documents, and outputs never leave the platform. This makes Workspace suitable for organisations operating under strict data governance requirements, including those subject to GDPR, NIS2, and sector-specific compliance frameworks. *** ### A Unified AI Environment for Your Organisation Workspace brings together everything a knowledge worker needs to benefit from AI in their daily work, without requiring technical expertise or IT involvement for day-to-day use. At its core, Workspace provides a single interface to interact with a broad range of AI models, including open-source models running on GLBNXT infrastructure and leading cloud-hosted models from providers across the market. Users can switch between models depending on the task at hand, compare outputs, and work with the models best suited to their domain or use case. Beyond the chat interface, Workspace allows users to work with their own documents and data, build reusable AI assistants tailored to specific roles or workflows, and collaborate with colleagues through shared agents and prompts. Administrators have full visibility and control over who has access, what they can do, and how the platform is being used. *** ### Who Uses GLBNXT Workspace Workspace is designed to serve a broad range of users within an enterprise organisation. It does not require a technical background to use effectively. **Business and knowledge workers** use Workspace for day-to-day tasks such as drafting, summarising, researching, translating, and analysing documents. It replaces the informal use of public AI tools with a governed, secure alternative that does not expose company information. **Legal, HR, and compliance teams** use Workspace to process sensitive documents, review contracts, draft policy content, and get AI assistance on regulatory questions, while keeping all data within a controlled environment with a full audit trail. **Business leaders and managers** use Workspace to accelerate decision-making, generate reports, and query internal knowledge, with confidence that outputs are traceable and that data governance is maintained throughout. **IT administrators and workspace managers** use the enterprise controls layer to manage user access, configure authentication, monitor usage, and enforce organisational policies across the entire Workspace environment. *** ### How Workspace Differs from Public AI Tools Public AI tools are designed for individual, general-purpose use. They are powerful, but they come with trade-offs that are difficult to accept in an enterprise context. When you use a public AI tool, your prompts and documents are processed on infrastructure you do not control, governed by terms of service that may allow your data to be used for model training or product improvement. You have no visibility into how your data is handled, no audit trail of what was shared, and no ability to enforce organisational policies around usage. GLBNXT Workspace is built on a different premise. All data is processed and stored on GLBNXT-owned infrastructure within the EU. Your organisation's data is never used to train models. Every interaction is logged and auditable. Access is governed by role-based controls that your administrators manage. And the entire environment is operated under GDPR-compliant terms, with ISO 27001 and SOC 2 Type II standards applied across the platform. The result is AI that delivers the same productivity benefits your teams expect, without the data sovereignty, compliance, and governance risks that come with public tools. *** ### The GLBNXT Workspace Advantage **Sovereign by design.** All data stays within EU-hosted infrastructure operated by GLBNXT. No data is shared with third parties or used for model training. **Enterprise-ready from day one.** Workspace supports SSO and enterprise authentication, role-based access control, audit logging, and usage monitoring without additional configuration or integration work. **Access to leading AI models.** Users have a single interface to interact with a wide range of models, from open-source models running locally on GLBNXT infrastructure to frontier models from major providers, all routed securely through the platform. **Built for business users.** Workspace requires no technical setup to use. Business users can start working with AI immediately, while administrators retain full control over the environment. **Modular and scalable.** Workspace is part of the broader GLBNXT platform. Organisations that need more advanced capabilities, such as custom knowledge pipelines, vector search, or AI agent development infrastructure, can extend into GLBNXT Platform without changing their environment. *** ### What This Section Covers The Workspace section of the GLBNXT Knowledge Centre is organised around the core capabilities of the product: * **AI Chat and Models** covers the chat interface, model selection, conversation management, and prompt tools available to every user. * **Knowledge and Data** covers how to upload and query documents within Workspace, and what the embedded retrieval capabilities include. * **Agents and Assistants** covers how to build, configure, and share AI assistants tailored to specific tasks or teams. * **Enterprise Controls** covers user management, authentication, access policies, audit logging, and compliance configuration for administrators. If you are looking for infrastructure, deployment, or advanced AI development capabilities, these are covered in the GLBNXT Platform section of this Knowledge Centre. # Who is it for GLBNXT Workspace is built for organisations that want to put AI to work across their teams, without compromising on data sovereignty, security, or compliance. It is designed to be used by business professionals in their daily work, not just by developers or technical specialists. The platform serves a broad range of roles within an enterprise organisation. Below is an overview of the primary audiences Workspace is designed for, and how each of them benefits. *** ### Knowledge Workers and Business Professionals The largest group of Workspace users are the people who work with information every day. Analysts, consultants, project managers, marketers, operations professionals, and anyone whose work involves reading, writing, researching, or synthesising information will find immediate value in Workspace. Common use cases include drafting documents and communications, summarising lengthy reports, translating content across languages, extracting key points from meeting notes, and getting fast answers to complex questions grounded in internal documents. Workspace allows these users to work with AI in the same way they might use a public tool, but within an environment that keeps their organisation's data private and secure. *** ### Legal, Compliance, and HR Teams Teams that handle sensitive or regulated information have historically been the most cautious about adopting AI tools, and for good reason. Public AI tools offer no guarantees about how submitted data is processed, stored, or used. Workspace changes this calculus. Legal teams can use it to review contracts, identify risk clauses, and draft correspondence without sending confidential information to external services. Compliance teams can query regulatory documents, check policy alignment, and generate audit-ready summaries. HR teams can process sensitive personnel documents, draft job descriptions and policies, and handle employee queries, all within a governed environment with a full audit trail. For these teams, Workspace is not just a productivity tool. It is a compliant alternative to the informal use of public AI that is already happening within most organisations. *** ### Business Leaders and Decision-Makers Senior leaders and managers use Workspace to accelerate decision-making and improve the quality of their outputs. Whether preparing for board meetings, reviewing performance data, or drafting strategic documents, Workspace provides AI assistance that is fast, contextually aware, and grounded in the organisation's own information. Business leaders also benefit from Workspace at an organisational level. Rather than allowing uncontrolled, ungoverned use of public AI tools across the organisation, Workspace provides a single governed environment where AI adoption can be monitored, managed, and scaled responsibly. *** ### Teams in Regulated Industries Workspace is particularly well-suited to organisations operating in industries where data handling is subject to regulatory oversight. This includes healthcare, financial services, legal, public sector, and education. In these environments, the question is rarely whether AI can add value. It almost always can. The question is whether it can be adopted in a way that satisfies compliance obligations, protects sensitive data, and maintains the trust of clients, patients, or citizens. Workspace is designed to answer that question with a clear yes, providing AI capabilities that are sovereign, auditable, and operated entirely within EU jurisdiction. *** ### IT Administrators and Platform Managers While Workspace is built for business users, it also serves the IT administrators and platform managers responsible for deploying and governing it within the organisation. Administrators have access to a full enterprise controls layer that allows them to manage user accounts and roles, configure SSO and enterprise authentication, set access policies at a team or individual level, monitor platform usage, and review audit logs. This gives IT teams the visibility and control they need to support Workspace across the organisation with confidence, without creating an ongoing operational burden. *** ### What Workspace is Not Designed For Workspace is optimised for knowledge work and business use cases. It is not a development environment for building custom AI infrastructure, training models, or deploying large-scale data pipelines. Organisations that need those capabilities, such as data science teams building custom agents or CTOs scaling AI development across hundreds of users, will find the right tools in GLBNXT Platform. Workspace and Platform are complementary. Many organisations start with Workspace to get immediate value across their business teams, and extend into Platform as their AI ambitions grow. # How to access Workspace Accessing GLBNXT Workspace is straightforward. Once your organisation has been onboarded, users log in to the GLBNXT dashboard and are presented with the AI interfaces available to them. Each interface is represented by its own icon. Clicking it opens the chat environment directly, ready to use. No installation, configuration, or technical setup is required on the user's side. *** ### Your Entry Point From the GLBNXT dashboard, you will see one or more AI interfaces made available by your administrator. Clicking the icon of your assigned interface launches the chat window immediately in your browser. What you see on the dashboard depends on what your administrator has configured for your account or team. Some users may have access to a single interface, others may have access to multiple. *** ### Access is Defined by Your Administrator GLBNXT Workspace uses role-based access control (RBAC) to manage what each user can see and do within the platform. Your administrator defines which interfaces you have access to, which AI models are available to you, and what features and settings are enabled for your role. This means that the Workspace experience may look different from one user or team to another, depending on how your organisation has configured the platform. All of this is managed centrally by your administrator, with no action required from end users. *** ### Dashboard Features For a full overview of the GLBNXT dashboard, including how to navigate your interfaces, manage your profile, and understand the features available to you, refer to the dedicated GLBNXT Dashboard documentation. # The chat interface The chat interface is where your interaction with AI happens. It is the primary working environment within GLBNXT Workspace, designed to feel immediately familiar to anyone who has used a modern messaging or AI tool, while offering a depth of functionality that supports serious professional use. No training or onboarding is required to get started. Open the interface and begin typing. *** ### Layout and Navigation The chat interface is organised around a clean, browser-based layout. The main area is the conversation window, where your messages and the AI's responses appear in a continuous thread. A persistent input bar at the bottom of the screen is where you type your prompts, attach files, or trigger additional features. On the left side of the screen, a collapsible sidebar gives you access to your conversation history, allowing you to navigate between previous chats, pick up where you left off, or search for a specific conversation by keyword. New conversations are started with a single click. *** ### Starting a Conversation To start a conversation, type your message in the input bar and press enter or click the send button. The AI will respond in the conversation window, typically within a few seconds depending on the model and the complexity of the request. You can ask questions, request summaries, draft content, analyse documents, translate text, or work through complex problems step by step. There are no rigid templates or formats to follow. The interface is designed for natural language, so you can interact with it the same way you would communicate with a knowledgeable colleague. *** ### Rich Output and Formatting Responses are rendered with full formatting support. This means the AI can return structured content such as tables, numbered lists, headers, and code blocks directly in the conversation window, presented clearly and ready to copy or act on. For technical users, code output is syntax-highlighted and can be copied with a single click. For business users, long-form responses such as reports, summaries, or drafted documents are rendered in a readable format that can be copied into any downstream tool. Some interfaces also support an artifact view, which opens generated content such as documents, structured outputs, or interactive elements in a separate panel alongside the conversation, keeping the chat thread clean while giving you full access to the output. *** ### Multi-Turn Conversations The chat interface supports multi-turn conversations, meaning the AI retains context across the entire thread. You can ask a follow-up question, request a revision, or refine an output without restating the context from earlier in the conversation. This makes the interface well-suited for iterative work, such as drafting a document through several rounds of feedback, working through an analysis step by step, or exploring a topic in depth over the course of a single session. *** ### Editing and Managing Messages You can edit your own messages after sending them, which will regenerate the AI's response based on the updated input. This is useful when you want to refine your prompt without starting a new conversation. Responses can be regenerated if the output does not meet your expectations, and individual responses can be copied, rated, or used as the basis for further prompts. Conversations can be renamed, organised, and deleted from the sidebar at any time. *** ### Voice Input Depending on your interface configuration, voice input may be available as an alternative to typing. This allows you to speak your prompt directly into the interface, which is then transcribed and submitted as a text message. The AI responds in the standard text format in the conversation window. *** ### Working Across Devices The chat interface is fully browser-based and requires no installation. It is accessible from any modern browser on desktop or laptop. Mobile access is supported, with the interface adapting to smaller screen sizes for on-the-go use. *** ### A Note on Conversations and Privacy All conversations within GLBNXT Workspace are processed and stored on GLBNXT-owned EU infrastructure. Your prompts and the AI's responses are not shared with third parties and are not used to train AI models. Depending on your organisation's configuration, conversation history may be subject to audit log policies set by your administrator. # Model selection & switching One of the defining capabilities of GLBNXT Workspace is access to a wide range of AI models through a single interface. Rather than being locked into one model or one provider, users can choose the model that best fits their task, and switch between models at any point without leaving the chat environment. This flexibility is a core part of what makes Workspace a professional-grade AI environment, rather than a single-purpose tool. *** ### Available Models GLBNXT Workspace provides access to a broad portfolio of AI models, spanning both open-source models running on GLBNXT sovereign infrastructure and leading frontier models from major providers across the market. This includes models from providers such as OpenAI, Anthropic, Mistral, Google, Meta, DeepSeek, and others, alongside locally hosted open-source models optimised for specific tasks or data sensitivity requirements. The exact models available to you depend on the configuration set by your administrator. Your organisation may have enabled a curated selection of models suited to your industry, use cases, or compliance requirements. Models that have not been enabled for your role or team will not appear in your selection. *** ### Selecting a Model Model selection is available directly within the chat interface. A model selector is displayed at the top of the conversation window, showing the currently active model. Clicking it opens a list of all models available to your account, from which you can select the one you want to use. Each model in the list is typically labelled with its name and provider, giving you enough context to make an informed choice. Some interfaces display additional information such as context window size or a brief description of the model's strengths. Once selected, the model becomes active for your current conversation and any subsequent messages in that thread. *** ### Choosing the Right Model for Your Task Different models have different strengths, and part of getting the most out of Workspace is developing a sense of which model works best for which type of task. As a general guide: **For writing, drafting, and communication tasks**, frontier language models from providers such as Anthropic or OpenAI tend to produce polished, nuanced prose and handle complex instructions well. **For reasoning, analysis, and structured problem-solving**, models with strong reasoning capabilities, including dedicated reasoning-optimised variants, are better suited to working through multi-step logic or quantitative analysis. **For tasks involving sensitive or confidential data**, locally hosted open-source models running on GLBNXT sovereign infrastructure are often the most appropriate choice, as they do not route data through any external provider at all. **For coding and technical tasks**, models specifically trained on code tend to produce more accurate, well-structured output than general-purpose models. Your administrator may have configured model descriptions or labels within Workspace to help guide your team toward the appropriate models for your organisation's use cases. *** ### Switching Models Mid-Conversation You can switch models at any point during a conversation. When you change the active model, subsequent messages in the thread are processed by the newly selected model. Previous messages and responses remain visible in the conversation history, giving you full context regardless of which model generated them. This makes it possible to use different models for different stages of a task within the same conversation thread, for example drafting an initial outline with one model and then switching to a stronger reasoning model to stress-test the logic. *** ### Running Multiple Models in Parallel Some Workspace interfaces support running multiple models simultaneously on the same prompt. When enabled, this allows you to submit a single message and receive responses from two or more models side by side, making it straightforward to compare outputs and select the best result. This is particularly useful when evaluating which model handles a specific type of task most effectively for your workflow, or when you want a second perspective on a response before acting on it. *** ### Model Access and Governance Model availability within Workspace is fully governed by your administrator through the role-based access control layer. Administrators can enable or restrict specific models at the organisation, team, or individual user level. This ensures that model usage within your organisation remains aligned with your data governance policies, cost controls, and compliance requirements. If a model you need is not available in your interface, contact your Workspace administrator to request access. # Conversation management Every interaction you have within GLBNXT Workspace takes place within a conversation. Understanding how conversations work, how they are stored, and how to manage them effectively will help you get more out of the platform over time. *** ### How Conversations are Stored Each time you start a new chat, a conversation is created and stored within your Workspace account. Conversations persist between sessions, meaning you can close your browser and return to any previous thread exactly where you left off. Your full conversation history remains accessible from the sidebar for as long as your administrator's retention policies allow. All conversations are stored on GLBNXT-owned EU infrastructure. They are private to your account and are not visible to other users unless explicitly shared. *** ### Organising Your Conversations As your conversation history grows, keeping it organised becomes important. The sidebar displays your conversations in reverse chronological order by default, with the most recent at the top. To make conversations easier to find, you can rename them at any time. By default, the interface generates an automatic title based on the content of your first message. Renaming a conversation with a clear, descriptive title makes it much faster to locate later. Depending on your interface configuration, you may also be able to organise conversations into folders, allowing you to group related threads by project, client, topic, or any structure that suits your workflow. *** ### Searching Conversations The sidebar includes a search function that allows you to find previous conversations by keyword. This is useful when you remember the subject of a conversation but cannot locate it by scrolling through your history. Search scans conversation titles and, depending on configuration, may also search the content of messages within threads. *** ### Continuing a Previous Conversation To return to a previous conversation, simply click on it in the sidebar. The full thread loads in the main window, including all previous messages and responses in their original order. You can continue the conversation from where you left off by typing in the input bar, and the AI will retain the context of everything discussed earlier in the thread. This makes it straightforward to return to ongoing work, pick up a task after a break, or build on a previous analysis without having to restate background information. *** ### Starting a New Conversation A new conversation can be started at any time by clicking the new chat button at the top of the sidebar. Starting a new conversation gives you a clean context window, which is useful when you are moving to a completely different topic and do not want the AI to carry over context from a previous thread. As a general rule, it is good practice to start a new conversation for each distinct task or topic, and to continue within an existing thread when your work is iterative or builds on earlier exchanges. *** ### Editing and Regenerating Responses Within any conversation, you can edit your own messages after they have been sent. Editing a message will regenerate the AI's response based on the updated input, allowing you to refine your prompt without starting over. All subsequent messages in the thread will be updated accordingly. If a response does not meet your expectations, you can request a regeneration without editing your prompt. This asks the model to produce an alternative response to the same input, which is useful when the first output is close but not quite right. *** ### Deleting Conversations Conversations can be deleted from the sidebar when they are no longer needed. Deletion is permanent and cannot be undone. If your organisation has audit logging enabled, deleted conversations may still be retained in the audit record depending on your administrator's configuration. *** ### Shared Conversations Depending on your interface configuration and the permissions set by your administrator, it may be possible to share a conversation with a colleague. Shared conversations allow another user to view the thread, which is useful for handovers, reviews, or collaborative work where context needs to be passed between team members. Sharing settings and permissions are controlled by your administrator through the role-based access control layer. *** ### A Note on Context Windows Each AI model has a context window, which is the maximum amount of text it can process in a single interaction. In very long conversations, older messages may eventually fall outside the model's active context, meaning the AI may not be able to reference content from the earliest parts of a long thread. If you are working on a complex or extended task, it is worth being aware of this limit. Starting a new conversation with a brief summary of the relevant background is a practical way to reset the context without losing continuity in your work. # Prompt templates & presets Getting consistent, high-quality responses from an AI model depends largely on how you frame your requests. Prompt templates and presets are the tools within GLBNXT Workspace that help you and your team work more efficiently by saving, reusing, and standardising the prompts that work best for your specific tasks and workflows. *** ### What is a Prompt Template A prompt template is a saved piece of text that can be inserted into the chat input with a single action, rather than typed from scratch each time. Templates are useful for any prompt you find yourself writing repeatedly, whether that is a standard instruction format, a structured request for a specific type of output, or a detailed set of guidelines you want the AI to follow for a particular task. For example, a legal team might save a template for contract review that includes specific instructions on what to look for and how to format the output. A communications team might save a template for drafting press releases that includes tone guidelines and structural requirements. Once saved, these templates can be called up in seconds, ensuring consistency across every use. *** ### What is a Model Preset A model preset goes a step further than a prompt template. A preset combines a saved prompt or set of instructions with a specific model selection and model parameter configuration, such as response length, creativity level, or output format. When you load a preset, it sets up the entire chat environment to a predefined state, ready for a specific type of task. Presets are particularly useful when different tasks in your workflow require different model configurations. Rather than manually selecting the right model and adjusting parameters each time, you can switch between presets with a single action and be immediately set up for the task at hand. *** ### Creating and Saving Templates Templates are created directly within the chat interface. When you have crafted a prompt that produces reliable, high-quality results, you can save it as a template by giving it a name and optionally adding a description that helps you or your colleagues understand what it is for. Saved templates are stored in your account and accessible from within the chat input bar. Most interfaces allow you to trigger your template library by typing a specific character, such as a forward slash, which opens a searchable list of your saved templates. Selecting one inserts it directly into the input field, where you can edit it before sending if the task requires any adjustment. *** ### System Prompts A system prompt is a special type of instruction that is sent to the AI before the conversation begins, setting the context, tone, role, or rules that should govern its behaviour throughout the entire thread. System prompts are invisible to the end user in the sense that they do not appear as a visible message in the conversation, but they actively shape every response the AI produces. Common uses for system prompts include instructing the AI to respond as a domain expert in a specific field, to always format its output in a particular way, to only answer questions relevant to a specific topic, or to maintain a specific communication style throughout the conversation. System prompts can be configured at the model or assistant level by administrators, or set manually by users at the start of a conversation, depending on the permissions defined by your administrator. *** ### Sharing Templates Across Your Team Templates and presets can be shared with colleagues, allowing your organisation to build a shared library of prompts that reflect best practices for your specific workflows, industry, and use cases. This is particularly valuable for teams that rely on consistent AI-assisted outputs, such as legal, compliance, or communications teams where quality and format consistency matter. Shared templates ensure that everyone on the team is working from the same starting point, reducing the time spent crafting prompts individually and improving the overall quality and consistency of AI-assisted work across the organisation. Sharing permissions are controlled by your administrator through the role-based access control layer. *** ### Tips for Effective Prompt Templates Well-designed prompt templates consistently produce better results. A few principles that make templates more effective: **Be specific about the output format.** If you want the AI to respond with a structured list, a table, a summary of a specific length, or a document in a particular style, say so explicitly in the template. Vague instructions produce variable results. **Define the role or context.** Starting a template with a brief context statement, such as "You are a compliance specialist reviewing documents for GDPR alignment", gives the model a clear frame of reference that improves the relevance and quality of its responses. **Include examples where helpful.** For complex or nuanced tasks, including a short example of the kind of output you expect helps the model calibrate its response accurately. **Keep templates focused.** A template designed to do one thing well will outperform a template that tries to cover multiple different tasks. If you have several distinct workflows, create a separate template for each. **Iterate and refine.** The best templates are built through experience. Start with a working version, use it across real tasks, note where the output falls short, and refine the template accordingly over time. # Rich output & artifacts GLBNXT Workspace does more than return plain text responses. The chat interface renders AI output in a range of structured formats, and supports the generation of artifacts, self-contained pieces of content that can be viewed, interacted with, and used independently from the conversation thread. Together, these capabilities make Workspace a practical working environment for producing real outputs, not just a tool for asking questions. *** ### Formatted Text Output By default, AI responses within Workspace are rendered with full text formatting support. This means the model can return content using headers, bold and italic text, numbered and bulleted lists, tables, and block quotes, all rendered visually in the conversation window rather than as raw markup. This matters for professional use. A response that returns a structured report, a comparison table, or a step-by-step process is immediately readable and usable, without any manual reformatting required. When you copy a formatted response into another tool such as a document editor, the formatting is preserved. *** ### Code Output For technical tasks, code responses are rendered with syntax highlighting, making them easy to read regardless of the programming language. A copy button is available on every code block, allowing you to transfer code to your editor or terminal with a single click. The interface also supports multi-language code output within a single response, which is useful for tasks that involve configuration files, scripts, and documentation together. *** ### Tables and Structured Data When asked to compare, summarise, or organise information, AI models in Workspace can return data in table format, rendered clearly within the conversation window. This is useful for tasks such as comparing product options, summarising contract terms side by side, or presenting structured analysis in a format that is easy to scan and share. Tables can be copied directly from the conversation window and pasted into spreadsheet applications or document editors while retaining their structure. *** ### Mathematical and Scientific Notation For users working in technical, scientific, or financial domains, Workspace supports LaTeX rendering for mathematical expressions and formulas. Complex equations and notation are displayed in properly typeset format rather than as raw code strings, making responses in these domains significantly more readable. *** ### Artifacts Artifacts are a distinct output mode available within Workspace. When the AI generates a substantial, self-contained piece of content, such as a drafted document, a structured report, a data visualisation, or an interactive element, it can present this as an artifact in a dedicated panel alongside the conversation thread. This keeps the conversation itself clean and focused while giving you full access to the generated content in a separate view. Artifacts can be reviewed, copied, downloaded, or iterated on without interrupting the flow of the conversation. *** ### What Can Be Generated as an Artifact The types of content that can be generated and displayed as artifacts include: **Documents and long-form text.** Drafted reports, summaries, proposals, policy documents, and other structured written outputs are well-suited to artifact display, particularly when they are long enough that viewing them within the conversation thread would be disruptive. **Code and scripts.** Longer code outputs, complete scripts, or multi-file structures can be presented as artifacts with syntax highlighting, making them easier to review and copy in their entirety. **Structured outputs.** JSON, XML, CSV, or other structured data formats generated for downstream use are displayed as artifacts so they can be reviewed and extracted cleanly. **Diagrams and visualisations.** Some interfaces support the generation and display of diagrams, flowcharts, and data visualisations as artifacts, rendered directly within the workspace without requiring an external tool. **Interactive content.** Depending on your interface configuration, certain types of generated content may be interactive within the artifact panel, allowing you to engage with outputs such as structured forms, calculators, or dynamic displays directly. *** ### Iterating on Artifacts Artifacts are not static outputs. Once an artifact has been generated, you can continue the conversation to request changes, additions, or revisions. The artifact updates in place in the side panel, reflecting the latest version of the content without generating a new thread entry each time. This makes iterative work on a document or output significantly more fluid than editing within the conversation thread itself. Version history for artifacts is supported in some interface configurations, allowing you to step back to a previous version of the content if a revision does not meet your expectations. *** ### Sharing and Exporting Artifacts Artifacts can be copied to the clipboard for pasting into any downstream tool, such as a document editor, a content management system, or a project management platform. Depending on your interface configuration, direct export or download options may also be available. For sharing within your team, some interfaces allow artifacts to be included when sharing a conversation with a colleague, so the recipient can view both the discussion that produced the output and the artifact itself. # Uploading documents GLBNXT Workspace allows you to bring your own documents into the chat environment and work with them directly alongside AI. Rather than copying and pasting content into your prompts, you can upload files and ask the AI to read, analyse, summarise, or extract information from them as part of a natural conversation. All documents uploaded within Workspace are processed entirely on GLBNXT-owned EU infrastructure. Your files are never sent to third-party services and are not used for model training. *** ### How to Upload a Document Uploading a document is done directly from the chat interface. A file attachment button is available in the input bar at the bottom of the conversation window. Clicking it opens a file picker, from which you can select one or more files from your device. Once uploaded, the document appears as an attachment within the conversation thread, confirming it has been received and is ready to work with. You can then type your prompt as normal, and the AI will reference the uploaded content as part of generating its response. Depending on your interface configuration, it may also be possible to drag and drop files directly into the chat window as an alternative to using the file picker. *** ### Supported File Types Workspace supports a range of common document formats for upload. These include: * PDF documents * Microsoft Word documents (.docx) * Plain text files (.txt) * Markdown files (.md) * Microsoft PowerPoint presentations (.pptx) * Microsoft Excel spreadsheets (.xlsx) * CSV files * Audio files, for transcription and analysis, depending on interface configuration Support for specific file types may vary depending on the interface and model you are using. If a file type is not supported, the interface will notify you at the point of upload. *** ### What Happens When You Upload a Document When a document is uploaded, the interface processes it automatically. The content is extracted, broken into segments, and made available to the AI as context for your conversation. This process happens in the background and typically takes only a few seconds for standard document sizes. Once processing is complete, the AI can read, reference, and reason over the content of the uploaded file in response to your prompts. You do not need to paste the text manually or direct the AI to the document explicitly in most cases, though being specific in your prompt about what you want the AI to do with the document will always produce better results. *** ### Working with Uploaded Documents Once a document is uploaded, you can interact with it in a wide variety of ways through natural language. Common tasks include: **Summarising.** Ask the AI to produce a concise summary of the document, a specific section, or a particular topic covered within it. **Extracting information.** Ask the AI to find and return specific data points, clauses, dates, names, figures, or any other discrete piece of information contained in the document. **Comparing documents.** Upload two or more documents and ask the AI to compare them, identify differences, or highlight where they align or conflict. **Reviewing and analysing.** Ask the AI to review a contract for risk clauses, assess a report for logical consistency, or evaluate a policy document against a set of criteria you define in your prompt. **Drafting based on source material.** Use an uploaded document as the basis for generating new content, such as a summary report, a response letter, a set of action points, or a revised version of the original. **Translating.** Upload a document in one language and ask the AI to translate its content, either in full or for specific sections. *** ### Uploading Multiple Documents You can upload more than one document within a single conversation, allowing you to work across multiple source files simultaneously. This is particularly useful for tasks such as cross-referencing contracts, comparing proposals, or consolidating information from several reports into a single output. When working with multiple documents, it is good practice to be explicit in your prompts about which document you are referring to, particularly if the files cover similar topics. Naming the documents in your prompt reduces ambiguity and improves the accuracy of the AI's responses. *** ### File Size and Processing Limits Uploaded files are subject to size limits that are set at the platform level. Very large files or documents with complex formatting may take longer to process, and in some cases, only a portion of a very large document may fall within the model's active context window at any one time. For best results, work with documents that are focused and relevant to the task at hand rather than uploading large, multi-topic files and expecting the AI to navigate them comprehensively. If you need to work with large document sets at scale, refer to the GLBNXT Platform section for information on advanced knowledge pipeline capabilities. *** ### Document Privacy and Retention Documents uploaded within a conversation are processed and stored on GLBNXT-owned EU infrastructure and are private to your account. They are not accessible to other users and are not shared with any external services. Retention of uploaded documents is subject to the policies configured by your administrator. Depending on your organisation's settings, documents may be retained for the duration of a session, tied to the lifecycle of the conversation they were uploaded in, or subject to a broader data retention policy. Contact your administrator if you have questions about how uploaded documents are handled within your organisation's Workspace configuration. # Querying your documents Uploading a document is only the first step. The real value comes from what you can do with it. GLBNXT Workspace allows you to query your uploaded documents through natural language, asking questions, requesting specific information, and directing the AI to reason over the content in ways that would take significantly longer to do manually. This section covers how to query your documents effectively and how to get consistently accurate, useful results. *** ### How Querying Works When you upload a document and ask a question, the Workspace interface retrieves the most relevant sections of the document and passes them to the AI model as context, alongside your prompt. The model then generates a response grounded in that content. This process, known as retrieval-augmented generation, means the AI is not relying on its general training data to answer your question. It is reading your document and responding based on what is actually in it. This makes responses significantly more accurate and relevant for document-specific tasks than asking the same question without any uploaded content. *** ### Writing Effective Document Queries The quality of your results depends heavily on how you frame your prompt. Unlike a keyword search, querying documents in Workspace works best when you communicate clearly and specifically, as you would when asking a knowledgeable colleague to review a document on your behalf. A few principles that consistently produce better results: **Be specific about what you want.** Vague prompts produce vague results. Instead of asking "what does this document say", ask "what are the termination conditions described in section four of this contract" or "summarise the key financial obligations of each party." **Name the document when working with multiple files.** If you have uploaded more than one document, specify which one you are referring to in your prompt to avoid ambiguity. **Specify the output format you need.** If you want a bullet point list, a table, a paragraph summary, or a specific structure, say so. The AI will follow your formatting instructions and return content in the form that is most useful to you. **Break complex tasks into steps.** Rather than asking the AI to do everything in one prompt, work through a document progressively. Ask for a summary first, then drill into specific sections, then ask for a comparison or assessment based on what you have found. **Use follow-up questions.** Querying documents is a conversation, not a single transaction. If the first response does not cover what you need, ask a follow-up. The AI retains the context of the uploaded document and your previous exchanges throughout the thread. *** ### Common Querying Tasks The following are examples of how document querying is used in practice across different professional contexts. **Extracting specific information.** Find a particular clause in a contract, identify the methodology section of a research report, or locate the deadline dates within a tender document. Rather than reading through the entire file, ask the AI to find and return exactly what you need. **Summarising at different levels.** Request a one-paragraph executive summary of a lengthy report, or ask for a section-by-section summary that preserves more detail. You can control the level of compression and the focus of the summary through your prompt. **Identifying risks and issues.** Ask the AI to review a contract for liability clauses, flag any non-standard terms, or identify areas where the document deviates from a set of criteria you define. This is particularly useful for legal, compliance, and procurement workflows. **Comparing documents.** Upload two versions of a document and ask the AI to identify what has changed, or upload two separate agreements and ask it to highlight where the terms differ. The AI can surface differences that would be time-consuming to identify through manual review. **Answering questions grounded in source material.** Instead of relying on the AI's general knowledge to answer a domain-specific question, upload the relevant reference document and ask your question in that context. The AI will draw its answer from the uploaded content, reducing the risk of inaccurate or hallucinated information. **Drafting based on document content.** Use a document as the source material for generating new content. Ask the AI to write a briefing note based on a report, draft a response letter informed by an incoming document, or produce a set of action points from a meeting transcript. *** ### Understanding the Limits of Document Querying The embedded document querying capability within Workspace is designed for focused, session-based work with individual documents or small document sets. It is important to understand where its boundaries lie. **Context window limits apply.** Each AI model has a maximum context window, which determines how much text it can process at one time. For very long documents, only the most relevant sections are retrieved and passed to the model at any given point. This means the AI may not have visibility of the entire document simultaneously, and for very large files, some content may fall outside its active context. **Retrieval accuracy varies.** The process of identifying which sections of a document are most relevant to your query works well for most professional documents, but it is not infallible. Highly technical documents, files with complex layouts, or content where meaning depends heavily on visual structure, such as tables embedded in PDFs, may produce less accurate retrieval. **Session-based storage.** Documents uploaded in Workspace are tied to the conversation they were uploaded in. There is no persistent, organisation-wide knowledge base that indexes documents across users or sessions. Each conversation starts with a fresh context. For organisations that need to query large volumes of documents, maintain persistent knowledge bases, or require higher retrieval precision for complex content, the GLBNXT Platform provides a dedicated knowledge and data infrastructure layer built for these requirements. *** ### Verifying AI Responses Against Source Documents When querying documents for professional or high-stakes purposes, it is good practice to verify the AI's responses against the source material, particularly for tasks such as contract review, compliance checks, or regulatory analysis. The AI will generally indicate which part of the document it is drawing from in its response, and you can ask it to quote the relevant passage directly if you need to confirm the source of a specific claim. Treating AI-generated document analysis as a first-pass review rather than a final output, and applying human judgement to the results, will consistently produce the most reliable outcomes. # Supported file types & limits GLBNXT Workspace supports a range of common file formats for document upload and querying. This section provides an overview of what is supported, what limits apply, and what to consider when working with different types of content. *** ### Supported File Types #### Documents | Format | Extension | | ---------------------- | --------- | | PDF | .pdf | | Microsoft Word | .docx | | Plain text | .txt | | Markdown | .md | | Microsoft PowerPoint | .pptx | | Microsoft Excel | .xlsx | | Comma-separated values | .csv | #### Images Image uploads are supported for models with vision capabilities. When an image is uploaded to a vision-enabled model, the AI can describe, analyse, and reason over the visual content, including text within images. | Format | Extension | | ------ | ------------ | | JPEG | .jpg / .jpeg | | PNG | .png | | GIF | .gif | | WebP | .webp | #### Audio Audio file uploads are supported in some interface configurations, enabling transcription and content analysis of spoken recordings. | Format | Extension | | --------- | --------- | | MP3 | .mp3 | | MP4 audio | .m4a | | WAV | .wav | | WebM | .webm | Support for audio uploads depends on the interface and model configuration enabled for your account. If audio upload is not available in your interface, contact your administrator. *** ### File Size Limits Individual file uploads are subject to a maximum file size limit. This limit is set at the platform level and may be further defined by your administrator based on your organisation's configuration. As a general guideline: * Standard document uploads are supported up to a maximum of **10MB per file** in most configurations * Image uploads are typically supported up to **10MB per file** * Audio files may be subject to different limits depending on the transcription model in use If a file exceeds the applicable limit, the interface will notify you at the point of upload and the file will not be processed. In this case, consider reducing the file size, splitting the content across multiple smaller files, or extracting the relevant sections into a new document before uploading. *** ### How File Type Affects Processing Quality Not all files are processed with equal accuracy. The format and structure of a document have a direct bearing on how well the AI can read and reason over its content. **Plain text and Markdown files** produce the most reliable results. The content is clean, structured, and directly readable without any conversion required. **Word documents** are generally processed well, with text content and basic formatting preserved during extraction. **PDFs** vary significantly depending on how they were created. PDFs generated from digital sources, such as exported Word documents or typeset reports, are typically processed accurately. Scanned PDFs, where the content exists as an image rather than selectable text, are processed less reliably and may produce incomplete or inaccurate results. If you are working with scanned documents, consider running them through an OCR tool before uploading to improve the quality of the extracted text. **Spreadsheets and CSV files** are supported for tabular data, but complex formatting, merged cells, or heavily structured layouts may affect how accurately the content is interpreted. For best results, ensure the data is organised in a clean, flat structure with clear column headers. **PowerPoint presentations** are supported for text content extraction, but visual elements such as diagrams, charts, and embedded images within slides are not processed as part of the text extraction. If the key information in a presentation is contained in charts or visuals rather than text, consider exporting the relevant content to a document format before uploading. **Images** are processed by vision-capable models and can include text recognition, scene description, and visual analysis. The accuracy of text recognition within images depends on the clarity and resolution of the original file. *** ### Working Within Context Window Limits Regardless of file size, the amount of content that can be actively referenced by the AI in any single interaction is constrained by the context window of the model you are using. Different models have different context window sizes, and very long documents may only have their most relevant sections retrieved and passed to the model at any one time. This means that for very large documents, the AI may not have simultaneous visibility of the entire file. If you are working with lengthy documents and need the AI to reason over content from multiple distant sections, breaking your queries into focused, section-specific prompts will generally produce more accurate results than broad queries across the whole document. *** ### Recommendations for Best Results **Use digital source documents where possible.** Natively digital files produce significantly more accurate results than scanned or photographed documents. **Keep files focused.** A document containing only the content relevant to your task will produce better results than uploading a large, multi-topic file and asking the AI to navigate it. **Split large files where practical.** If you are working with a document that exceeds the file size limit or is very long, splitting it into logical sections and uploading the most relevant portion for each query is more effective than attempting to work with the full file. **Check file formatting before uploading.** Heavily formatted documents with complex layouts, multiple columns, embedded tables within tables, or non-standard structures may not extract cleanly. Where possible, simplify the formatting of a document before uploading if you expect extraction quality to be an issue. *** ### Limitations and When to Consider GLBNXT Platform The file upload and processing capabilities within Workspace are designed for individual and team-level document work within a session-based environment. They are well-suited to the majority of professional document tasks. For organisations that require support for a broader range of file types, higher volume document ingestion, persistent knowledge bases that index content across users and sessions, or custom processing pipelines for complex or proprietary document formats, these capabilities are available through GLBNXT Platform. # Upgrading to GLBNXT Platform GLBNXT Workspace is designed to cover the knowledge and data needs of most business teams. For organisations that need to go further, GLBNXT Platform provides the infrastructure to do so. *** ### When to Consider GLBNXT Platform The embedded document and knowledge capabilities within Workspace work well for session-based, individual, and team-level tasks. There are situations, however, where a more advanced setup is the right choice. Consider GLBNXT Platform if your organisation needs to: * Maintain a **persistent, organisation-wide knowledge base** that multiple users can query from a shared corpus of documents * Ingest and index **large volumes of documents** on a continuous basis, rather than uploading files per conversation * Achieve **higher retrieval precision** for complex, domain-specific, or heavily structured content * Build **custom knowledge pipelines** tailored to your data sources, formats, or business processes * Integrate AI knowledge capabilities directly into **existing enterprise systems and applications** *** ### What GLBNXT Platform Adds GLBNXT Platform provides a dedicated knowledge and data infrastructure layer that goes well beyond what is embedded in the Workspace frontends. This includes configurable vector search engines, knowledge graph capabilities, and scalable data pipelines that can be tuned, extended, and integrated with your existing technology environment. It is built for data science teams, developers, and organisations scaling AI across their entire operation, not just for individual users working with documents in a chat interface. *** ### Getting Started To explore GLBNXT Platform and discuss whether it is the right fit for your organisation, visit the GLBNXT Platform section of this Knowledge Centre or contact your GLBNXT representative directly. # What are AI Agents An AI agent is a configured version of an AI model that has been given a specific purpose, a defined way of behaving, and optionally a set of tools or knowledge it can draw upon to do its job. Where a standard chat conversation is open-ended and general-purpose, an agent is focused. It knows what it is for, how it should respond, and what it has access to. Within GLBNXT Workspace, agents allow your organisation to turn AI into purpose-built assistants that are tailored to specific roles, workflows, or domains, and that any authorised user can access and work with consistently, without needing to configure anything themselves each time. *** ### The Difference Between a Chat and an Agent When you open a standard conversation in Workspace and start typing, you are interacting with an AI model in its default state. It is capable and flexible, but it has no specific context about your organisation, your role, or the task at hand. You provide that context through your prompts. An agent changes this dynamic. It has already been configured with a defined purpose and set of instructions before the conversation begins. A user who opens an agent does not need to explain the context, establish the rules, or set the tone. The agent already knows its job. The user simply starts working. This makes agents particularly valuable in an enterprise setting, where consistency, quality, and efficiency across a team matter as much as the capability of the underlying AI. *** ### What Makes an Agent An agent in GLBNXT Workspace is defined by a combination of the following elements: **A system prompt.** The core instruction set that tells the agent who it is, what it is for, how it should behave, and what constraints it should operate within. This is what gives an agent its character, focus, and boundaries. **A model selection.** The specific AI model the agent uses to generate responses. Different agents within the same Workspace environment can be configured to use different models, matched to the requirements of the task. **Knowledge and documents.** Agents can be connected to specific documents or knowledge collections, allowing them to answer questions grounded in your organisation's own content rather than general AI training data. **Tools and capabilities.** Agents can be equipped with specific capabilities that extend what they can do, such as the ability to search the web, execute code, generate structured outputs, or interact with connected systems. *** ### What Agents are Used For Agents are most valuable when a particular task or workflow is repeated regularly across a team, or when a specific type of AI interaction needs to be consistent, governed, and easy to access for non-technical users. Common examples include: **Role-specific assistants.** A legal assistant configured to review documents for risk and compliance. An HR assistant configured to help employees navigate policy questions. A finance assistant configured to support reporting and analysis tasks. **Domain knowledge assistants.** An agent connected to your organisation's internal documentation, trained to answer questions based on your own policies, procedures, and knowledge base rather than generic information. **Process-specific tools.** An agent designed to support a particular workflow, such as drafting tender documents, reviewing supplier contracts, generating meeting summaries, or producing structured reports in a defined format. **Customer or partner-facing assistants.** Agents that can be deployed to serve external users, with carefully defined scope and behaviour that ensures responses stay within the boundaries your organisation has set. *** ### Agents vs. General Chat Neither approach is better than the other. They serve different purposes and complement each other within Workspace. General chat is best for exploratory, ad hoc, or varied tasks where flexibility matters more than consistency. Agents are best for repeatable, structured, or high-stakes tasks where consistency, quality control, and ease of use across a team are the priority. Many organisations use both. General chat for individual, open-ended work. Agents for the workflows and roles where a purpose-built assistant delivers more reliable results. *** ### Who Can Create and Access Agents Within GLBNXT Workspace, who can create, edit, and access agents is governed by the role-based access control layer. Administrators define which users or teams have the ability to build and publish agents, and which agents are available to which users. End users access agents that have been made available to them by their administrator or by a colleague with the appropriate permissions. From the user's perspective, working with an agent feels the same as working in a standard chat interface. The difference is entirely in the configuration that shapes the interaction from the start. For guidance on building your first agent, see the Building Your First Assistant section. # Building your first agent Creating an AI assistant in GLBNXT Workspace does not require any technical background. The agent builder is a guided interface that walks you through the configuration step by step. Within a few minutes, you can have a purpose-built assistant ready to use and share with your team. This section walks you through the process from start to finish. *** ### Before You Start Before opening the agent builder, it helps to have a clear idea of what your assistant is for. The most effective agents are built around a specific, well-defined purpose. A few questions worth thinking through before you begin: * What task or workflow is this assistant designed to support? * Who will use it, and what do they need it to do? * What tone, style, or behaviour should it have? * Does it need access to specific documents or knowledge? * Are there things it should explicitly not do or say? You do not need detailed answers to all of these before starting. But having a clear sense of the assistant's purpose will make every configuration decision easier, and will produce a more effective result. *** ### Opening the Agent Builder The agent builder is accessible from within the chat interface. Look for the agents section in the sidebar or the model selector, depending on your interface configuration. Selecting the option to create a new agent opens the builder panel, where you will configure your assistant. If the option to create agents is not visible in your interface, it may not be enabled for your account. Contact your administrator to request access. *** ### Step 1: Give Your Assistant a Name and Description Start by giving your assistant a clear, descriptive name that communicates its purpose to anyone who encounters it. Avoid generic names. An assistant called "Contract Review Assistant" is immediately understood by a colleague who has never seen it before. One called "My Assistant" is not. Add a short description that explains what the assistant is for and who should use it. This description is visible to users when browsing or selecting agents, and helps them quickly identify whether a particular assistant is relevant to their task. *** ### Step 2: Write the System Prompt The system prompt is the most important part of your agent configuration. It is the instruction set that tells the assistant who it is, what it is for, how it should behave, and what boundaries it should operate within. Everything the assistant does flows from this prompt. A well-written system prompt typically includes: **A role definition.** Tell the assistant what it is. For example: "You are a legal document review assistant specialising in contract analysis for a European enterprise." **A description of the task.** Explain what the assistant is designed to do. Be specific. "Your role is to review uploaded contracts and identify liability clauses, termination conditions, and any non-standard terms that may require legal attention." **Tone and style guidance.** Define how the assistant should communicate. "Respond in a professional, concise tone. Use structured output with clear headings and bullet points where appropriate." **Scope and constraints.** Be explicit about what the assistant should and should not do. "Only respond to questions related to legal document review. If asked about topics outside this scope, politely redirect the user to the appropriate resource." **Output format instructions.** If the assistant should always return responses in a specific structure, define that here. This ensures consistency across every interaction, regardless of who is using it. Take your time with the system prompt. It is worth testing and refining it across several real interactions before sharing the assistant more broadly with your team. *** ### Step 3: Select a Model Choose the AI model your assistant will use to generate responses. Different models have different strengths, and the right choice depends on the nature of the task. For most business writing, summarisation, and communication tasks, a capable general-purpose frontier model will perform well. For tasks that require precise reasoning, structured analysis, or complex multi-step logic, a reasoning-optimised model may be more appropriate. For tasks involving sensitive or confidential data that should not leave GLBNXT infrastructure, a locally hosted open-source model is the right choice. Refer to the Model Selection & Switching section for guidance on choosing the right model for your use case. *** ### Step 4: Attach Knowledge and Documents If your assistant needs to answer questions based on specific content, such as your organisation's internal policies, a reference document, or a knowledge collection, you can attach that content during the configuration step. Documents and knowledge collections attached to an agent are available to every user who works with it, without them needing to upload the files themselves each time. This makes knowledge-grounded assistants significantly more consistent and easier to use across a team. For guidance on how document retrieval works within agents, refer to the Knowledge & Data section. *** ### Step 5: Configure Tools and Capabilities Depending on your interface configuration and the permissions enabled for your account, you may be able to equip your assistant with additional capabilities beyond standard text generation. These may include: * Web search, allowing the assistant to retrieve current information from the internet as part of its responses * Code execution, allowing the assistant to run and return the results of code as part of its workflow * Structured output generation, enabling the assistant to produce formatted data such as JSON or CSV alongside its text responses Enable only the capabilities that are genuinely needed for the assistant's purpose. Keeping the configuration focused produces a more reliable and predictable assistant. *** ### Step 6: Test Before Publishing Before making your assistant available to others, test it thoroughly across a range of real interactions. Use the prompts and scenarios your intended users are likely to bring to it, and evaluate the responses critically. Ask yourself: * Does the assistant stay within its defined scope? * Are the responses consistently formatted and structured as intended? * Does it handle edge cases or unexpected questions appropriately? * Is the tone and style right for the intended audience? Refine the system prompt based on what you observe. Even small adjustments to the wording of a system prompt can produce meaningful improvements in consistency and output quality. It is normal to go through several iterations before an assistant is ready for wider use. *** ### Step 7: Share Your Assistant Once you are satisfied with your assistant, you can make it available to your team. Depending on your permissions and interface configuration, you can share an agent with specific users, specific teams or groups, or make it available across your entire organisation. Sharing settings and access controls are managed through the role-based access control layer. If you need to share an agent beyond the scope your current permissions allow, contact your administrator. For guidance on managing shared agents and team access, see the Sharing Agents Across Your Team section. *** ### Tips for Effective Agent Configuration **Start simple and iterate.** A focused assistant with a clear, well-written system prompt will outperform a complex one with an overly ambitious scope. Build the core behaviour first, then add capabilities and knowledge as you develop a better understanding of how users interact with it. **Test with real users early.** Your assumptions about how the assistant will be used are rarely perfect. Getting real users to try it early in the process surfaces issues that are difficult to anticipate from the builder alone. **Review and refine over time.** Agents are not set-and-forget configurations. As your workflows evolve and you gather feedback from users, revisit the system prompt and configuration to keep the assistant performing at its best. **Document what your agent is for.** A clear name and description at the point of creation saves significant confusion later, particularly as your organisation builds a library of agents across multiple teams and use cases. # Tools & capabilities By default, an AI assistant generates responses based on its training, the system prompt you have written, and any documents or knowledge you have attached. Tools and capabilities extend this foundation by giving an assistant the ability to take actions, access live information, process different types of input, and produce a broader range of outputs. Understanding what tools are available, and when to use them, allows you to build assistants that go significantly further than text generation alone. *** ### What Tools Do A tool is a specific capability that an agent can invoke during a conversation to do something it could not do through language generation alone. When a user interacts with an agent that has a tool enabled, the agent can decide, based on the user's input, whether to use that tool as part of producing its response. This decision-making happens automatically. The user does not need to explicitly trigger a tool or know that one is being used. They simply interact with the assistant as normal, and the assistant uses the tools available to it whenever they are relevant to the task. *** ### Available Tools and Capabilities #### Web Search When web search is enabled, an agent can retrieve current information from the internet as part of generating its response. This is useful for assistants that need to answer questions about recent events, current regulations, live market data, or any other information that may have changed since the model's training cutoff. Web search is particularly valuable for compliance and regulatory assistants, where staying current with the latest guidance is important, and for research-focused workflows where up-to-date information is a core requirement. #### Document and Knowledge Retrieval Agents can be connected to specific documents or knowledge collections, enabling them to ground their responses in your organisation's own content. When a user asks a question, the agent retrieves the most relevant content from its attached knowledge and incorporates it into the response. This capability is at the heart of domain-specific knowledge assistants. Refer to the Knowledge & Data section for a full explanation of how document retrieval works within Workspace. #### Code Execution When code execution is enabled, an agent can write and run code as part of its workflow, returning not just the code itself but the result of executing it. This is useful for assistants designed to support data analysis, calculation-heavy tasks, structured data processing, or any workflow where the output of a piece of logic is more valuable than the logic itself. Code is executed in a secure, sandboxed environment. It does not have access to your broader system or data outside of what has been explicitly provided in the conversation. #### Image Generation Some interface configurations support image generation as a tool, allowing an agent to produce visual outputs based on a text description provided by the user. This is useful for creative workflows, content production, and visual communication tasks where generating an image as part of the AI response adds value. Image generation availability depends on the models and interface configuration enabled for your account. #### Vision and Image Analysis Agents connected to vision-capable models can accept image uploads as input and reason over their visual content. This enables use cases such as extracting text from images, analysing diagrams or charts, reviewing visual documents, and describing or categorising visual content. Vision capabilities are model-dependent. The agent builder will reflect which models support vision input when you are configuring your assistant. #### Structured Output Generation For assistants designed to produce data for downstream use, structured output tools enable the agent to return content in formats such as JSON or CSV alongside its natural language response. This is useful for assistants integrated into broader workflows, where the output needs to be consumed by another system or tool rather than simply read by a user. #### Actions and External Integrations Depending on your Workspace configuration, agents may be able to connect to external systems and perform actions beyond the chat interface. This includes integrating with third-party applications via APIs, triggering workflows in connected platforms, or retrieving live data from business systems. The availability of external integrations depends on the configuration set up by your administrator and the connections enabled for your organisation's Workspace environment. *** ### Choosing the Right Tools for Your Assistant More tools do not make a better assistant. An assistant configured with only the tools it genuinely needs for its purpose will be more reliable, more predictable, and easier to govern than one with a broad set of capabilities enabled by default. When deciding which tools to enable for an assistant, work from the use case outward. Ask what the assistant actually needs to do its job, and enable only those tools. If a capability is not required for the assistant's defined purpose, leave it disabled. This keeps the assistant focused and reduces the risk of unexpected or out-of-scope behaviour. *** ### Tool Availability and Governance The tools available to you when building an assistant are determined by the configuration your administrator has set for your account and organisation. Not all tools may be visible or enabled in your interface, and some tools may require additional configuration at the platform level before they can be used. If a tool you need is not available in the agent builder, contact your Workspace administrator to discuss enabling it for your use case. Tool usage within agents is subject to the same audit logging and access control policies that govern the rest of the Workspace environment, ensuring that any actions taken by an agent on behalf of a user remain visible, traceable, and within the boundaries your organisation has defined. # Sharing agents across teams Building a well-configured assistant is most valuable when it can be used by everyone who needs it. GLBNXT Workspace allows agents to be shared across individuals, teams, and the broader organisation, turning a single well-built configuration into a resource that delivers consistent value at scale. *** ### Why Sharing Agents Matters When an agent is shared, every user who has access to it benefits from the work that went into building it. They do not need to understand how to configure an AI model, write a system prompt, or attach the right knowledge. They simply open the assistant and start working. This is where agents move from being a personal productivity tool to an organisational capability. A legal team that builds a strong contract review assistant and shares it across the department multiplies its value immediately. A compliance team that publishes a regulatory guidance assistant removes the need for every individual to craft their own prompts for the same recurring task. Over time, a shared library of well-built agents becomes one of the most tangible expressions of AI maturity within an organisation. *** ### How Sharing Works Agents can be shared at different levels of scope depending on your permissions and the needs of the intended audience. **Individual sharing.** An agent can be shared directly with a specific colleague, giving that person access without making it available to anyone else. This is useful for handovers, collaboration between individuals, or giving a specific user access to a tool built for their role. **Team or group sharing.** Agents can be shared with a defined team or group within your organisation. Everyone in that group gains access simultaneously, making it straightforward to roll out a new assistant to an entire department or project team at once. **Organisation-wide sharing.** Agents can be published to the broader organisation, making them discoverable and accessible to all users within your Workspace environment. This is appropriate for assistants with broad applicability, such as a general writing assistant, a company policy guide, or a tool relevant to all employees regardless of role. The sharing options available to you depend on the permissions your administrator has configured for your account. *** ### The Agent Library As more agents are built and shared within your organisation, they become part of a collective agent library that users can browse and access from within the Workspace interface. Agents in the library are displayed with their name and description, allowing users to quickly identify which assistant is relevant to their task. This is why the name and description you give an agent at the point of creation matter. A clear, purposeful name and a concise description make an agent discoverable and immediately understandable to a colleague who encounters it for the first time. Agents without clear descriptions are rarely used by anyone other than the person who built them. *** ### Access Control and Permissions Sharing an agent does not mean giving users the ability to edit or reconfigure it. Access to an agent and the ability to modify it are governed separately through the role-based access control layer. By default, users who have access to a shared agent can use it in conversations but cannot change its system prompt, model configuration, knowledge attachments, or tool settings. Only users with the appropriate editing permissions can modify an agent's configuration. This separation between use and edit access is important for maintaining the integrity of shared agents. It ensures that a carefully configured assistant remains consistent for all users, regardless of who is using it or how frequently. Administrators can define and adjust these permission levels at the organisation, team, or individual level. *** ### Updating a Shared Agent When an agent is updated by someone with editing permissions, the changes take effect for all users who have access to it immediately. There is no need to re-share the agent or notify users manually. The next time a user opens the assistant, they are working with the updated configuration. This makes it straightforward to improve and iterate on shared agents over time based on user feedback, without disrupting access or requiring any action from end users. When making significant changes to a widely used agent, it is good practice to communicate the update to your team so users are aware of any changes in behaviour or scope. *** ### Retiring and Removing Agents Agents that are no longer needed can be unpublished or deleted by a user with the appropriate permissions. Unpublishing removes the agent from the shared library without deleting it permanently, which is useful if you want to take an agent offline temporarily while reconfiguring it. Deleting an agent removes it entirely and cannot be undone. Before retiring a shared agent that is in active use, it is good practice to notify the users who rely on it so they have time to find an alternative or transition their workflow. *** ### Tips for Managing a Shared Agent Library **Establish clear naming conventions early.** As the number of shared agents grows, a consistent naming approach makes the library much easier to navigate. A convention that includes the team, purpose, and scope, such as "Legal: Contract Review" or "HR: Policy Q\&A", scales well as the library expands. **Assign ownership.** Every shared agent should have a clear owner who is responsible for maintaining and iterating on it over time. Without ownership, agents become stale and lose effectiveness as the workflows they support evolve. **Review agents periodically.** Scheduled reviews of your shared agent library help identify assistants that are underperforming, outdated, or no longer needed. A smaller library of high-quality, well-maintained agents is more valuable than a large library full of inconsistent or abandoned configurations. **Gather user feedback actively.** The people using a shared agent every day will quickly develop a clear sense of where it works well and where it falls short. Building a lightweight feedback loop, even informally, accelerates improvement and keeps shared agents aligned with real user needs. # User roles & permissions GLBNXT Workspace uses a role-based access control system to manage what each user can see, access, and do within the platform. Rather than granting the same level of access to everyone, roles allow administrators to define precisely what each person or group of people can interact with, ensuring that the right people have the right access and nothing more. This is one of the foundational governance capabilities of Workspace, and it underpins how the platform is managed safely and consistently across an organisation of any size. *** ### What Role-Based Access Control Means in Practice When a user logs into Workspace, what they see and what they can do is determined by the role assigned to their account. Two users in the same organisation may have a very different experience of the platform depending on their roles. One may have access to a broad set of AI models, the ability to create and publish agents, and visibility of usage data across the team. Another may have access only to specific agents made available to their role, with no ability to modify configurations or view other users' activity. This is by design. Role-based access control allows Workspace to serve a wide range of users, from end users to power users to administrators, within a single governed environment, without exposing functionality or information to people who do not need it. *** ### Default Roles in Workspace Workspace comes with a set of default roles that cover the most common access patterns within an enterprise organisation. These roles can typically be customised and extended by administrators to match the specific structure and requirements of your organisation. #### End User The standard role for the majority of Workspace users. End users can access the chat interface, interact with AI models made available to them, upload documents within conversations, and use agents that have been shared with them. They cannot create or edit agents, access administrative settings, or view other users' activity. This is the appropriate role for knowledge workers, business professionals, and anyone whose primary use of Workspace is day-to-day AI-assisted work. #### Power User An extended role for users who need to do more than interact with existing configurations. Power users can typically create and edit agents, build and manage prompt templates, and share assistants with colleagues within the boundaries set by their permissions. They may also have access to a broader range of models or features than standard end users. This role is suited to team leads, AI champions, and individuals who are responsible for building and maintaining AI tools for their colleagues. #### Administrator The highest level of access within a Workspace environment. Administrators have full control over the platform configuration, including user management, role assignment, model availability, authentication settings, audit log access, and policy enforcement. They can create and manage all agents regardless of who built them, and have visibility of usage and activity across the entire organisation. This role is typically restricted to IT managers, platform owners, or designated Workspace administrators within your organisation. *** ### Permissions Within Roles Beyond the broad role categories, Workspace allows permissions to be defined at a more granular level. This means that access can be controlled not just at the role level but at the level of specific features, resources, and actions. Examples of permissions that can be configured independently of base role include: **Model access.** Specific AI models can be enabled or restricted for individual users, teams, or roles. An organisation may choose to make a broad range of models available to power users while restricting end users to a curated subset appropriate for their tasks. **Agent creation and publishing.** The ability to create agents, edit existing agents, and publish agents to the shared library can each be controlled independently, allowing organisations to define exactly who has the ability to build and distribute AI tools within the platform. **Knowledge and document management.** Permissions around which knowledge collections a user can access, upload to, or manage can be set at the user or group level. **Sharing permissions.** The scope at which a user can share agents, whether limited to individuals, restricted to their own team, or extended to the whole organisation, can be configured per role or per user. **Administrative access.** Specific administrative functions, such as viewing audit logs, managing user accounts, or configuring authentication settings, can be assigned independently, allowing organisations to distribute administrative responsibilities without granting full administrator access. *** ### Managing Users and Roles User and role management is handled through the administrative settings of the Workspace environment. Administrators can: * Create, edit, and deactivate user accounts * Assign and change roles for individual users * Create custom roles tailored to specific teams or functions within the organisation * Assign users to groups, which can then be used as the target for role assignments, agent sharing, and access policies * Review which users have access to which agents, models, and features at any point in time Changes to roles and permissions take effect immediately. When a user's role is updated, their access level reflects the new configuration the next time they interact with the platform. *** ### Groups and Teams In addition to individual role assignments, Workspace supports the use of groups to manage access at a team or department level. Rather than assigning permissions to each user individually, administrators can assign users to a group and manage access for the group as a whole. This significantly reduces the administrative overhead of managing access for large organisations. When a new user joins a team, adding them to the relevant group gives them the appropriate access immediately, without requiring individual permission configuration. Groups can also be used as the target for agent sharing, allowing agents to be made available to an entire department or project team through a single sharing action. *** ### The Principle of Least Privilege A widely adopted best practice in access management is the principle of least privilege: give each user only the access they genuinely need to do their job, and nothing more. This reduces the risk of accidental misuse, limits the potential impact of a compromised account, and makes it easier to maintain a clear and auditable picture of who has access to what. When designing your organisation's role structure in Workspace, it is worth applying this principle deliberately. Start from what each role actually needs to do, and grant access accordingly, rather than starting from a broad access level and restricting it after the fact. *** ### Getting Help with Role Configuration If you are an administrator setting up role-based access control for the first time, or if your organisation's access requirements have become more complex over time, the GLBNXT support team can assist with configuration guidance. For day-to-day role and user management questions, refer to the administrative settings documentation or contact your designated Workspace administrator. # SSO & authentication GLBNXT Workspace supports enterprise-grade authentication, allowing your organisation to manage how users log in to the platform in a way that is secure, consistent, and aligned with your existing identity infrastructure. Rather than requiring users to maintain a separate set of credentials for Workspace, you can connect the platform to your organisation's identity provider and let your existing authentication processes handle access. *** ### Why Authentication Matters at the Enterprise Level Authentication is the first line of defence in any secure platform. For an AI environment that may be handling sensitive documents, confidential business data, and proprietary knowledge, ensuring that only authorised users can access the platform, and that access is managed centrally, is a fundamental requirement. For most enterprise organisations, this means integrating Workspace with the identity management systems already in place, rather than introducing a new silo of credentials to manage. Single sign-on makes this possible, and it brings meaningful benefits for both users and administrators. *** ### Single Sign-On Single sign-on, commonly referred to as SSO, allows users to access GLBNXT Workspace using the same credentials they use for the rest of their organisation's applications. Rather than logging in with a separate username and password, users authenticate through your organisation's identity provider and are granted access to Workspace automatically as part of that process. From the user's perspective, SSO simplifies access considerably. There are no additional credentials to remember, no separate login page to navigate, and no risk of being locked out of Workspace independently of the rest of your organisation's systems. From an administrator's perspective, SSO centralises access management. When a user joins the organisation, they gain access to Workspace as part of the standard onboarding process. When a user leaves, revoking their access to your identity provider immediately removes their access to Workspace as well, without requiring a separate deprovisioning step. *** ### Supported Identity Providers and Protocols Workspace supports authentication via industry-standard protocols, allowing it to integrate with the identity providers most commonly used in enterprise environments. **OpenID Connect (OIDC)** is the primary protocol supported for SSO integration. OIDC is widely adopted and is the authentication layer used by most modern identity providers. **SAML 2.0** is supported for organisations using identity providers that rely on this standard, which remains common in larger enterprise environments and public sector organisations. Workspace is compatible with leading enterprise identity providers including but not limited to Microsoft Entra ID (formerly Azure Active Directory), Okta, Google Workspace, and other OIDC and SAML-compliant identity providers. If your organisation uses a different provider, contact your GLBNXT representative to confirm compatibility before configuration. *** ### Group and Role Synchronisation When SSO is configured, Workspace can synchronise group membership and role information from your identity provider. This means that the teams, departments, and roles you have already defined in your identity management system can be mapped directly to access levels and permissions within Workspace, without requiring administrators to manage group membership in two places separately. When a user's group membership changes in your identity provider, for example when they move to a different team or take on a new role, those changes can be reflected automatically in their Workspace access. This keeps access aligned with organisational reality without creating ongoing manual synchronisation work. *** ### Multi-Factor Authentication Workspace supports multi-factor authentication as an additional layer of security for user logins. When MFA is enabled, users are required to verify their identity through a second factor, such as an authenticator application or a one-time code, in addition to their primary credentials. For organisations using SSO, MFA is typically enforced at the identity provider level, meaning users are subject to the same MFA requirements in Workspace as they are across the rest of your organisation's applications. This is the recommended approach, as it allows MFA policy to be managed centrally rather than configured separately per application. For organisations not using SSO, MFA can be enabled directly within the Workspace authentication settings. *** ### Session Management Workspace supports configurable session management, allowing administrators to define how long an authenticated session remains active before a user is required to re-authenticate. This includes: **Session timeout.** The period of inactivity after which a session expires and the user must log in again. Setting an appropriate timeout reduces the risk of an unattended session being accessed by an unauthorised party. **Session duration limits.** The maximum length of an active session regardless of activity, after which re-authentication is required. This ensures that credentials are periodically revalidated even for users who remain actively engaged with the platform. These settings can be configured to match your organisation's broader session management policies and any applicable compliance requirements. *** ### Configuring Authentication Authentication configuration is handled through the administrative settings of the Workspace environment and is typically completed during the initial onboarding and setup process. The configuration requires input from both your GLBNXT administrator and your organisation's identity management team. For a step-by-step guide to configuring SSO for your specific identity provider, refer to the dedicated authentication configuration documentation or contact the GLBNXT support team for assistance. *** ### A Note on Sovereign Access Management All authentication flows within GLBNXT Workspace are processed on GLBNXT-owned EU infrastructure. Credentials and session data are never routed through or stored on third-party infrastructure outside the GLBNXT environment. This ensures that your organisation's access management remains within the same sovereign boundary as the rest of the platform, maintaining the integrity of your data governance posture end to end. # Audit logs & usage tracking GLBNXT Workspace provides administrators with full visibility into how the platform is being used across the organisation. Audit logs capture a detailed record of activity within the environment, and usage tracking gives administrators the data they need to understand adoption patterns, manage resources, and demonstrate compliance with internal policies and external regulatory requirements. Together, these capabilities ensure that AI adoption within your organisation is not just powerful, but accountable. *** ### Why Audit Logs Matter In an enterprise environment, knowing what happened, when it happened, and who did it is not optional. It is a governance requirement. For organisations operating under GDPR, NIS2, ISO 27001, or sector-specific regulatory frameworks, the ability to produce an accurate, tamper-evident record of platform activity is often a prerequisite for deploying AI at all. Audit logs in Workspace serve this need directly. They provide the evidentiary record that compliance teams, security teams, and external auditors require, and they give administrators the visibility they need to identify issues, investigate incidents, and demonstrate that the platform is being used in accordance with organisational policy. *** ### What Audit Logs Capture Workspace audit logs record activity across the platform at a configurable level of detail. The events captured typically include: **User access and authentication.** Every login, logout, failed authentication attempt, and session event is recorded, including the user, the timestamp, and the device or network origin of the access event. **Conversation activity.** The creation, continuation, and deletion of conversations is logged, including metadata such as the user, the model used, and the timestamp. Depending on your organisation's configuration and applicable data retention policies, the content of conversations may also be retained within the audit record. **Document and file activity.** Upload events, including the file name, type, size, user, and timestamp, are captured. Document deletion events are also recorded. **Agent activity.** The creation, modification, publication, and deletion of agents is logged, along with the user responsible for each action and the timestamp. Usage of shared agents by end users is tracked at the session level. **Administrative actions.** All changes to user accounts, role assignments, permission configurations, authentication settings, and platform policies are recorded, providing a complete history of how the platform has been configured and by whom. **Model usage.** Which models were accessed, by which users, and at what volume is captured as part of the usage tracking layer, providing visibility into model consumption across the organisation. *** ### Accessing Audit Logs Audit logs are accessible to administrators through the administrative settings of the Workspace environment. Logs can be viewed directly within the platform interface and can be filtered by date range, user, event type, or resource to allow administrators to locate specific events quickly. For organisations that require audit log data to be integrated with an existing security information and event management system, Workspace supports log export in standard formats. This allows audit data to flow into your organisation's broader monitoring and compliance infrastructure without requiring manual extraction. Access to audit logs is restricted to users with administrative permissions. The audit log itself is read-only and cannot be modified or deleted by any user within the platform, ensuring its integrity as an evidentiary record. *** ### Usage Tracking Beyond the compliance function of audit logs, Workspace provides a usage tracking layer that gives administrators a quantitative picture of how the platform is being used across the organisation. Usage tracking data includes: **User activity.** Which users are active on the platform, how frequently they are using it, and what features they are engaging with. This data is useful for identifying both high-engagement users who may benefit from additional capabilities and low-engagement users who may need additional support or training. **Model consumption.** The volume of usage per AI model across the organisation, broken down by user, team, or department depending on your configuration. This provides the data needed to manage model access, plan for capacity, and understand the cost distribution of AI usage across the business. **Agent usage.** Which shared agents are being used, by whom, and at what frequency. This helps administrators and agent owners understand which assistants are delivering value, which are underused, and where new agents might address unmet needs. **Feature adoption.** Usage data across the core features of Workspace, including document uploads, knowledge queries, and tool usage, giving administrators a view of which capabilities are being adopted and where there may be gaps in user awareness or training. *** ### Retention Policies How long audit log and usage data is retained within Workspace is configurable by your administrator and should be aligned with your organisation's data retention policies and any applicable regulatory requirements. For organisations subject to GDPR, the principle of data minimisation applies to retention as much as it does to data collection. Retaining audit data for longer than is necessary for its legitimate purpose is not advisable. At the same time, many regulatory frameworks specify minimum retention periods for access and activity logs that must be observed. Configuring retention policies that satisfy both of these considerations, retaining data long enough to meet regulatory and audit requirements without holding it beyond its useful life, is a decision best made in consultation with your compliance and legal teams. *** ### Using Audit Data for Compliance Reporting One of the most direct practical uses of Workspace audit logs is in supporting compliance reporting and audit processes. When an internal or external audit requires evidence of how AI tools are being used within the organisation, what data has been accessed, and what governance controls are in place, the audit log provides a structured, reliable source of that information. Administrators can export audit data in formats suitable for inclusion in compliance reports, and the filtering capabilities within the audit interface make it straightforward to produce a focused record of activity relevant to a specific audit scope, time period, or user group. *** ### A Note on Privacy and Audit Log Content Audit logs exist to support governance and compliance, not to enable surveillance of individual employees beyond what is necessary and proportionate for those purposes. When configuring the level of detail captured in audit logs, particularly with regard to conversation content, organisations should consider both their legitimate governance requirements and their obligations under applicable data protection law, including GDPR. The appropriate level of audit log detail will vary by organisation and by the nature of the data being processed in Workspace. Legal and compliance teams should be involved in defining the audit log configuration that is right for your organisation's specific context. # Data residency & compliance Data residency and regulatory compliance are not add-on features in GLBNXT Workspace. They are foundational to how the platform was designed and how it operates. For organisations subject to European data protection law and related regulatory frameworks, Workspace is built to meet these requirements by default, without requiring additional configuration or legal negotiation to achieve a compliant deployment. *** ### Data Residency Data residency refers to where data is physically stored and processed. For many organisations, particularly those operating in regulated industries or under European law, this is a critical consideration when evaluating any AI platform. All data within GLBNXT Workspace, including user conversations, uploaded documents, agent configurations, knowledge collections, and audit logs, is stored and processed exclusively on GLBNXT-owned infrastructure located within the European Union. No data is transferred to or processed on infrastructure outside EU jurisdiction at any point during normal platform operation. This applies not only to the content you create and upload, but also to the metadata associated with your usage of the platform, including authentication events, session data, and usage logs. #### No Data Leaves the EU GLBNXT owns and operates its own GPU clusters and data centres within the EU. This means that when you interact with locally hosted AI models through Workspace, your prompts, responses, and documents are processed entirely within this infrastructure. There is no routing of data through external cloud providers or third-party services for locally hosted model interactions. For interactions with cloud-hosted models from external providers, data routing is governed by the specific configuration of your Workspace environment. Your administrator and GLBNXT representative can clarify how external model interactions are handled within your specific deployment. #### Your Data is Not Used for Model Training GLBNXT does not use customer data, including conversations, uploaded documents, or any other content processed within Workspace, to train AI models, whether its own or those of third-party providers. Your data remains yours. It is used solely to deliver the service to your organisation. *** ### Regulatory Compliance #### GDPR The General Data Protection Regulation is the primary data protection framework governing the processing of personal data within the European Union. GLBNXT Workspace is designed and operated in full alignment with GDPR requirements. Key aspects of GDPR compliance within Workspace include: **Data processing agreements.** GLBNXT provides a Data Processing Agreement that governs the processing of personal data on behalf of your organisation, meeting the contractual requirements set out in Article 28 of the GDPR. **Data subject rights.** Workspace supports your organisation's obligations in relation to data subject rights, including the right of access, the right to erasure, and the right to data portability. Your administrator can assist with fulfilling data subject requests that involve data held within the platform. **Data minimisation.** The platform is designed to process only the data necessary to deliver its functionality. Audit log and retention configurations allow your organisation to align data retention practices with the minimisation principle. **Privacy by design.** Data protection considerations are embedded in the architecture and operation of the platform from the ground up, not applied as a layer on top of a system designed without them. #### NIS2 The Network and Information Security Directive 2 establishes cybersecurity requirements for operators of essential services and digital service providers across the European Union. GLBNXT operates its platform in alignment with NIS2 requirements, including maintaining appropriate technical and organisational measures to manage security risks, implementing incident detection and response capabilities, and supporting customers in meeting their own NIS2 obligations where Workspace forms part of their critical information infrastructure. #### ISO 27001 ISO 27001 is the internationally recognised standard for information security management systems. GLBNXT operates under ISO 27001 certification, demonstrating that its approach to managing information security risks is structured, systematic, and independently verified. For organisations that require their technology vendors to hold ISO 27001 certification as a condition of procurement, Workspace satisfies this requirement. Documentation of certification status is available from your GLBNXT representative. #### SOC 2 Type II SOC 2 Type II is an independent audit framework that evaluates whether a service organisation's controls relating to security, availability, processing integrity, confidentiality, and privacy are operating effectively over a sustained period. GLBNXT holds SOC 2 Type II attestation, providing independent verification that the platform's security and operational controls perform as documented over time, not just at a single point in time. #### EU AI Act The EU AI Act establishes a risk-based regulatory framework for artificial intelligence systems operating within the European Union. GLBNXT monitors the requirements of the EU AI Act and their applicability to the Workspace platform, and works with customers to support compliance with relevant obligations as the regulation comes into full effect. For organisations deploying Workspace in contexts that involve high-risk AI applications as defined by the Act, GLBNXT can provide guidance on how the platform's controls and documentation support your compliance posture. *** ### Shared Responsibility Compliance is a shared responsibility between GLBNXT and your organisation. GLBNXT is responsible for the security, operation, and compliance posture of the platform infrastructure. Your organisation is responsible for how Workspace is configured and used within your environment, including how user access is managed, what data is uploaded and processed, and how the platform is integrated into your broader business processes. Understanding the boundary between these responsibilities is important for any organisation conducting a compliance assessment of Workspace as part of their procurement or risk management process. GLBNXT provides documentation to support this assessment, including Data Processing Agreements, security certifications, and compliance statements. *** ### Compliance Documentation Organisations that require formal compliance documentation for procurement, audit, or regulatory purposes can request the following from their GLBNXT representative: * Data Processing Agreement * ISO 27001 certificate * SOC 2 Type II attestation report * Trust Centre documentation covering security practices, infrastructure, and privacy controls * GDPR compliance statement For further information on GLBNXT's compliance posture and to request documentation, visit the GLBNXT Trust Centre or contact your GLBNXT representative directly. # User compliance control The Usder compliance control center is a dedicated module within the GLBNXT platform that gives organizations full visibility and control over policy compliance across their workforce. Designed for enterprise environments where regulatory accountability is critical, it centralizes the entire compliance lifecycle, from policy creation and distribution to acknowledgment tracking and audit reporting, in one place. ### Overview As AI adoption accelerates, organizations face growing pressure to demonstrate that employees understand and adhere to internal policies and external regulations. The Compliance Control Center makes this manageable by providing administrators with the tools to publish policies, verify employee understanding, monitor compliance in real time, and produce audit-ready reports on demand. ### Key Features #### Policy Management Administrators can create and publish policies directly within the platform. Each policy includes a title, description, type classification (AI Regulation, Data Privacy, Security, or Custom), and an uploadable policy document (PDF or DOCX). Policies can be saved as drafts before publishing, and archived when no longer active. All active policies are visible to users and can be tracked individually. #### Control Questions For policies that require verified understanding, not just acknowledgment, administrators can attach control questions. These are configured at the time of policy creation and must be answered correctly by employees before their acknowledgment is recorded. This feature is particularly valuable for high-stakes compliance areas such as AI usage guidelines or GDPR data handling requirements. #### Compliance Tracking Matrix The Users tab provides a real-time compliance matrix showing every employee alongside each active policy. At a glance, administrators can see who has acknowledged which policies, who has outstanding actions, and which users are overdue. Each cell in the matrix is interactive, allowing administrators to drill into the details of an individual acknowledgment, including the exact date and time it was recorded. #### Individual User Visibility Administrators have full visibility into each individual user's compliance journey. For every employee, the platform displays a complete overview of which policies they have acknowledged, which are still pending, and their overall compliance progress as a percentage. Each user's acknowledgment history is detailed down to the exact date and time of each action, giving administrators a precise and reliable record of where every individual stands in the policy acceptance process. This level of granularity ensures that no employee falls through the cracks and that administrators can proactively follow up with users who have outstanding or overdue acknowledgments. #### Compliance Dashboard The dashboard provides an organization-wide view of compliance health. It includes key metrics such as total active policies, total users, overall compliance rate, and the number of pending actions. Trend charts show how compliance rates have evolved over time, while a policy-by-policy breakdown highlights where gaps exist and where attention is needed. #### Audit Reporting When compliance needs to be demonstrated to regulators, auditors, or leadership, the Reports tab allows administrators to generate tailored compliance reports. Reports can be scoped by date range, policy selection, and report type (full compliance, non-compliance, or policy-specific). Each report can include user details with acknowledgment timestamps and control question responses. Reports are exportable as PDF, CSV, or Excel. #### Audit Event Log Every significant action within the module, policy publications, acknowledgments, quiz completions, and policy updates, is recorded in a timestamped audit event log. This creates a reliable and tamper-evident record of compliance activity that can be referenced at any time. ### Who It's For The Compliance Control Center is built for compliance officers, HR teams, legal departments, and platform administrators who need a structured, auditable way to manage organizational policy adherence. It is especially relevant for organizations operating under AI-specific regulatory frameworks, data protection legislation such as GDPR, or internal governance requirements. ### Where to Find It The Compliance Control Center is accessible from the Platform Configuration section of the GLBNXT sidebar, directly beneath User Management. # OPEN WEBUI # What is Open WebUI Open WebUI is the AI chat interface in GLBNXT Workspace. Chat with multiple LLMs, upload documents for Q\&A, and keep data private in your organisation. Open WebUI is the AI chat interface inside GLBNXT Workspace. It is a web-based UI for chatting with AI language models (LLMs). It feels like ChatGPT or Claude, but runs in your organisation’s environment. Use Open WebUI to: * Chat with AI models for answers, drafting, and problem-solving * Upload files and run document Q\&A (PDF, Word, spreadsheets, and more) * Organise chat history using folders and projects * Switch between multiple LLMs depending on the task * Keep prompts, files, and outputs inside your GLBNXT Workspace ### Open WebUI at a glance Open WebUI is useful when you want a privately hosted, ChatGPT-style experience. It combines AI chat, document analysis, and conversation organisation in one place. #### Common keywords you may search for * Open WebUI in GLBNXT Workspace * AI chat interface for enterprise * Private LLM chat UI * Chat with documents / document Q\&A ### Your first login to Open WebUI When you open Open WebUI from GLBNXT Workspace, you land in the chat screen. The layout is designed for fast onboarding. #### What You'll See The interface has three main areas: **Left Sidebar** - This is your navigation panel where you'll find: * A "New Chat" button to start fresh conversations * Your chat history (initially empty) * Access to folders and workspace features * Settings menu (at the bottom) **Center Area** - The main chat window where: * You'll see a welcome message * A text input field at the bottom invites you to start typing * A model selector to choose which LLM you want to use **Top Bar** - Contains: * The currently selected AI model name * Additional options and controls #### Your First Steps 1. **Choose a model (LLM)**. Click the model name in the chat header. 2. **Start chatting**. Type a prompt and press Enter (or Send). 3. **Iterate**. Ask follow-ups. Upload a document. Try another model. ### What Open WebUI is used for #### It's Just Like Chatting If you've used any modern chat application, Open WebUI will feel familiar. Type your message, get a response, continue the conversation. Each chat remembers the context of your conversation, so you can ask follow-up questions naturally. #### Chat with multiple AI models (LLMs) Open WebUI lets you select the best model for the job. Use a fast model for quick answers. Use a stronger model for analysis and writing. #### Your Conversations Are Saved Every chat you start is automatically saved in the sidebar. You can return to any conversation later by clicking on it. Think of the sidebar as your conversation archive - everything stays there until you decide to delete or archive it. #### Document Q\&A and file-based chat Open WebUI supports uploading documents into a conversation. You can ask for summaries, extraction, and targeted questions. This is useful for PDFs, policies, reports, and spreadsheets. #### Privacy and data sovereignty Open WebUI is hosted inside your GLBNXT Workspace environment. That keeps your chats and documents in your organisation’s controlled infrastructure. #### You're in control * **New Chat, Fresh Start**: Each time you click "New Chat," you start with a clean slate. Previous conversations don't influence the new one. * **Privacy**: Your conversations are private to you within your GLBNXT Workspace. * **No Limits on Questions**: Ask as many questions as you like, in as many chats as you need. #### Common First-Time Scenarios **Scenario 1: Quick Question** You need a fast answer. Click "New Chat," ask your question, get your answer. Done. The chat saves automatically in your sidebar for future reference. **Scenario 2: Ongoing Project** You're working on something that needs multiple interactions. Keep the same chat open and continue the conversation over hours or even days. The AI remembers the context of your discussion. **Scenario 3: Document Analysis** You have a PDF or document you need help with. Upload it directly to the chat or use your workspace documents. Ask questions about the content, request summaries, or extract specific information. #### What Makes Open WebUI Different? Unlike public AI services: * **Your data stays in your workspace** - nothing is sent to external services * **You can work with your own documents** - upload files and reference them in conversations * **Multiple AI models available** - choose the one that fits your task * **Organization features** - folders, tags, and search help you stay organized * **Customization** - adjust settings and preferences to match your workflow ### Ready to Start? You can start chatting immediately. Next, learn the basics and go deeper: * [Your first conversation](/workspace/guides/open-webui/your-first-conversation) * [Working with documents](/workspace/guides/open-webui/working-with-documents) * [Basic settings](/workspace/guides/open-webui/basic-settings) *** **Quick Tip**: Don't overthink it! The best way to learn Open WebUI is simply to start chatting. Try asking: "What can you help me with?" or "How do I upload a document?" The AI can guide you through its own features. # Your first conversation Start your first AI chat in Open WebUI (GLBNXT Workspace). Create a new chat, pick an AI model (LLM), write better prompts, and manage responses. Open WebUI is the AI chat interface inside GLBNXT Workspace. This guide shows how to start your first AI conversation. You will create a chat, choose an LLM, and send your first prompt. #### Common keywords you may search for * Start a new chat in Open WebUI * Choose an AI model / LLM * Write a prompt and get a response * Regenerate response and edit prompt ### Starting a New Chat Starting a conversation in Open WebUI is as simple as clicking a button. **To begin:** 1. Look at the left sidebar 2. Click the **"+ New Chat"** button (usually at the top) 3. A fresh chat window opens in the center That's it! You now have a blank canvas ready for your conversation. **When to start a new chat:** * You're changing topics completely * You want a fresh start without previous context * You're working on a different project or task **Tip**: You don't need to start a new chat for every question. If your questions are related, keep using the same chat - the AI will remember the context and give better answers. ### Selecting an AI Model At the top of your chat window, you'll see the selected AI model (LLM). This model generates the responses to your prompts. **To change models:** 1. Click on the model name at the top of the chat window 2. A dropdown list appears showing available models 3. Click on the model you want to use 4. The model switches immediately **Which model should you choose?** For most everyday tasks, the default model works perfectly fine. You don't need to overthink this when you're starting out. Different models have different strengths: * Some are faster but simpler * Others are more powerful but take a bit longer * Some excel at coding, others at creative writing **Our recommendation**: Start with the default model. As you get more comfortable, you can experiment with different models to find which ones you prefer for specific tasks. **Note**: Model choice is saved per conversation. You can switch models if you need to. Start a new chat when you want a clean comparison. ### Writing prompts and getting responses Now for the fun part. Send a prompt and get an answer back. #### How to send a prompt 1. **Type your question** in the text field at the bottom of the screen 2. **Press Enter** or click the **send button** (arrow icon) 3. **Wait a few seconds** - you'll see the AI is "thinking" 4. **Read the response** - it appears in the chat window #### Writing good prompts The AI understands natural language. Write like you would to a helpful colleague. **Good examples:** * "Can you explain what blockchain is in simple terms?" * "I need to write an email to a client about a project delay. Can you help me draft it?" * "What are the main differences between Python and JavaScript?" **You don't need to:** * Use special commands or formal language * Be overly polite (though it doesn't hurt!) * Worry about spelling mistakes - the AI understands **Tips for better answers:** * **Be specific**: "How do I create a pivot table in Excel?" is better than "Help with Excel" * **Give context**: "I'm preparing a presentation for executives about our Q4 results" helps the AI tailor its response * **Ask follow-ups**: If the answer isn't quite what you need, just ask the AI to clarify or expand #### Continuing the Conversation The magic of Open WebUI is that each chat remembers your conversation history. You can ask follow-up questions naturally: **Example conversation:** * You: "What is machine learning?" * AI: \[Explains machine learning] * You: "Can you give me a simple example?" * AI: \[Provides an example based on the previous explanation] * You: "How would I use this in marketing?" * AI: \[Gives marketing-specific applications, remembering the context] Notice how you didn't need to repeat "machine learning" in every question - the AI remembers what you're discussing. #### While the AI is Responding When you send a message, you'll see the AI typing its response in real-time. You can: * **Read along** as it writes * **Stop the response** if you've got enough information (click the stop button) * **Wait for it to finish** before asking your next question ### Basic Chat Actions Open WebUI gives you simple tools to manage the conversation. You'll find these by hovering over or clicking on messages. #### Copy a Response Found something useful you want to save or use elsewhere? 1. **Hover over the AI's response** 2. **Click the copy icon** (usually looks like two overlapping squares) 3. The text is now copied to your clipboard 4. Paste it wherever you need it (email, document, notes) **Use this when:** * You want to save the AI's answer to a document * You need to share the response with a colleague * You're collecting research or information #### Regenerate an Answer Not satisfied with the response? Want a different take on the answer? 1. **Look for the regenerate icon** (usually a circular arrow) below the AI's message 2. **Click it** 3. The AI will generate a completely new response to your same question **Use this when:** * The answer wasn't quite what you were looking for * You want a different perspective or approach * The response was too technical (or not technical enough) **Note**: Each regeneration is different. The AI doesn't just rephrase - it genuinely rethinks the answer. #### Edit Your Question Realized you could have asked your question better? Made a typo? Want to refine what you asked? 1. **Hover over your own message** 2. **Click the edit icon** (usually a pencil) 3. **Modify your question** 4. **Press Enter or click save** 5. The AI generates a new response based on your edited question **Use this when:** * You made a typo or mistake * You want to clarify or improve your question * You realize you need to add important context **Important**: Editing a question removes all the responses that came after it in the conversation. Use this feature carefully if you've had a long discussion. #### Delete Messages Want to remove a message from the conversation? 1. **Hover over the message** (yours or the AI's) 2. **Click the delete icon** (usually a trash can) 3. **Confirm** if prompted 4. The message disappears from the chat **Use this when:** * You asked something by mistake * You want to clean up the conversation * You pasted sensitive information you didn't mean to share **Tip**: Be careful with deleting - this action usually can't be undone. ### Your Conversation Flow Here's what a typical session might look like: 1. **Start**: Click "New Chat" 2. **Select**: Choose your model (or stick with the default) 3. **Ask**: Type your first question 4. **Read**: Review the AI's response 5. **Continue**: Ask follow-ups, request clarification, or go deeper 6. **Use**: Copy useful responses, regenerate if needed 7. **Refine**: Edit questions if you want to improve them 8. **Finish**: Simply move on - your chat auto-saves in the sidebar ### Common Beginner Questions **Q: How long should I wait for a response?** A: Usually just a few seconds. Complex questions might take 10-20 seconds. If it takes longer than a minute, something might be wrong - try refreshing the page. **Q: Can I have multiple chats open at once?** A: You can have many chats saved in your sidebar, but you work in one at a time. Click between them to switch conversations. **Q: What happens if I close my browser?** A: Your chat is automatically saved. Just come back to Open WebUI and click on the chat in your sidebar to continue where you left off. **Q: Can I ask anything?** A: Almost! The AI can help with a huge range of topics, but it has limitations - it can't access external websites (unless you provide them), doesn't know real-time information, and won't help with harmful requests. **Q: Does the AI remember everything I say?** A: Within a single chat, yes - the AI remembers the entire conversation. But each new chat starts fresh with no memory of other conversations. ### Practice Exercise Try this simple exercise to get comfortable: 1. Start a new chat 2. Ask: "Can you help me write a professional out-of-office email message?" 3. Read the response 4. Click regenerate to see a different version 5. Ask a follow-up: "Can you make it more casual?" 6. Copy the response you like best 7. Try editing your original question to specify your industry or situation By the end of this exercise, you'll have used most of the basic features! *** **You're now ready to have real conversations with Open WebUI.** Next, go deeper: * [Working with documents](/workspace/guides/open-webui/working-with-documents) * [Organising your chats](/workspace/guides/open-webui/organising-your-chats) * [What is Open WebUI](/workspace/guides/open-webui/what-is-open-webui) # Working with documents ### Why Use Documents with AI? One of Open WebUI's most powerful features is the ability to work with your own documents. Instead of just having general conversations, you can give the AI access to your specific files and ask questions about them. **What does this mean in practice?** Imagine you have: * A 50-page contract you need to understand * A research paper with complex technical details * Meeting notes from the past six months * A spreadsheet full of data * Company policy documents Instead of reading through everything yourself, you can upload these documents to Open WebUI and ask questions like: * "What are the key terms in this contract?" * "Summarize the main findings of this research paper" * "What was decided about the budget in the March meeting?" * "What does our policy say about remote work?" The AI reads the document and answers based on its actual content - not just general knowledge. **This is called RAG (Retrieval-Augmented Generation)** - but you don't need to remember that term. Just think of it as "AI that reads your documents." ### Two Ways to Use Documents Open WebUI offers two simple methods for working with documents. Both are easy, and you can choose whichever fits your workflow. #### Method 1: Upload Files Directly to Your Chat This is the quickest way to work with a document for a one-time conversation. **How to do it:** 1. **Start a new chat** (or use an existing one) 2. **Look for the attachment icon** (usually a paperclip or plus sign) near the text input field 3. **Click it** and browse to your file 4. **Select your document** and click open 5. **Wait a moment** while the file uploads and processes 6. **Ask your question** about the document **Example:** * Upload: "2024\_Annual\_Report.pdf" * Ask: "What was our revenue growth this year?" * The AI reads the PDF and answers based on the actual numbers in the report **Best for:** * Quick, one-off document questions * When you're only working with one or two files * Documents you won't need to reference repeatedly #### Method 2: Use the # Command to Reference Documents If you or your administrator has set up documents in the Workspace, you can reference them using the # symbol. This method is great for documents you use frequently. **How to do it:** 1. **Start typing your question** in the chat 2. **Type the # symbol** (hashtag) 3. **A list of available documents appears** 4. **Select the document** you want to use 5. **Continue typing your question** and press Enter **Example:** * Type: "# \[select 'Employee Handbook'] What is the vacation policy?" * The AI uses the Employee Handbook to answer **You can also use # with URLs:** * Type: "# What are the main points?" * The AI will fetch and read the webpage content **Best for:** * Documents you reference regularly * Shared team resources stored in the Workspace * When you need to combine multiple documents in one question **Note**: If the # command doesn't show you any documents, your workspace might not have documents set up yet. Contact your administrator or stick with Method 1 (direct upload). ### Supported File Types Open WebUI can read and understand many common file formats: **Documents:** * PDF files (.pdf) * Word documents (.doc, .docx) * Text files (.txt) * Markdown files (.md) **Spreadsheets:** * Excel files (.xlsx, .xls) * CSV files (.csv) **Presentations:** * PowerPoint files (.ppt, .pptx) **Other:** * HTML files (.html) * Rich Text Format (.rtf) **File size considerations:** * Most everyday documents work fine * Very large files (100+ MB) might take longer to process * If a file is too large, try splitting it into smaller sections **What if my file type isn't listed?** Try converting it to PDF or text format first. PDF is the most universally supported format. ### Simple Example: Ask Questions About Your PDF Let's walk through a complete example from start to finish. #### Scenario You've received a 30-page technical proposal from a vendor. You need to understand the pricing, timeline, and key features, but you don't have time to read all 30 pages. #### Step-by-Step **Step 1: Start Fresh** * Click "New Chat" to begin * Choose your preferred AI model (the default is fine) **Step 2: Upload the Document** * Click the attachment icon near the text input * Browse to "Vendor\_Proposal\_2024.pdf" * Select it and wait for it to upload (you'll see a progress indicator) * Once uploaded, you'll see the filename appear in the chat **Step 3: Ask Your First Question** Type: "Can you summarize the key points of this proposal?" Press Enter and wait for the response. The AI will read through the entire 30-page document and provide a concise summary. **Step 4: Dig Deeper** Now ask specific questions: * "What is the total cost including all optional features?" * "What is the implementation timeline?" * "What support services are included?" * "Are there any potential risks or concerns I should be aware of?" **Step 5: Compare or Analyze** You can even ask the AI to analyze: * "What are the pros and cons of this proposal?" * "What questions should I ask the vendor about this?" * "Is the pricing competitive compared to typical market rates?" **Step 6: Extract Specific Information** Need something specific? * "List all the deliverables mentioned in the proposal" * "What are the payment terms?" * "Find all mentions of data security" #### The Result In just a few minutes, you've extracted all the critical information from a 30-page document without reading every word yourself. ### Tips for Working with Documents #### Ask Clear, Specific Questions **Good questions:** * "What does section 3 say about refund policies?" * "List all the deadlines mentioned in this document" * "Summarize the financial projections for 2024" **Less effective questions:** * "Tell me about this" (too vague) * "Everything about pricing" (too broad) #### Start Broad, Then Go Specific A good workflow: 1. First: "Summarize this document" 2. Then: "Tell me more about the section on implementation" 3. Finally: "What exactly does it say about data migration?" #### Verify Important Information The AI is very good at reading documents, but for critical decisions: * Double-check important numbers or dates yourself * Ask the AI to quote the exact text: "What is the exact wording about the warranty?" * For legal or financial documents, always verify with a professional #### Combine Multiple Documents You can upload or reference multiple documents in the same chat: * Upload: Contract.pdf * Upload: Amendment.pdf * Ask: "What changed between the original contract and the amendment?" #### Use Documents for Different Tasks **Summarization:** "Give me a 3-paragraph summary of this report" **Question Answering:** "What does this say about remote work policies?" **Data Extraction:** "Create a list of all action items from these meeting notes" **Comparison:** "Compare the recommendations in these two reports" **Translation/Simplification:** "Explain this technical document in simple terms" ### Common Questions **Q: Does the document stay in my chat forever?** A: The document is associated with that specific chat. As long as you keep the chat, you can continue asking questions about it. If you delete the chat, the uploaded document goes with it. **Q: Can other people see my uploaded documents?** A: No. Documents you upload directly to a chat are private to you. Only workspace documents (accessed via #) might be shared, depending on how your administrator has set things up. **Q: How many documents can I upload at once?** A: This varies, but typically you can upload several documents in a single chat. If you need to work with many documents, try uploading them one at a time or ask your administrator about workspace document storage. **Q: The AI gave me wrong information from my document. Why?** A: Occasionally the AI might misread or misinterpret something, especially in complex documents. Always verify critical information. You can ask: "Quote the exact text where it says that" to check the source. **Q: Can I upload images or scanned documents?** A: Yes, many scanned PDFs work fine. However, if the text in the image isn't clear, the AI might have trouble reading it. For best results, use documents with searchable text. **Q: How long does it take to process a document?** A: Small documents (a few pages) process in seconds. Larger documents (50+ pages) might take 30 seconds to a minute. You'll see a processing indicator while it works. ### Practice Exercise Try this to get comfortable with documents: 1. **Find a document** you have handy - a PDF report, a Word document, anything 2. **Start a new chat** in Open WebUI 3. **Upload the document** using the attachment icon 4. **Ask for a summary**: "Please summarize this document" 5. **Ask 3 specific questions** about the content 6. **Ask for something specific**: "List the key dates mentioned" or "What recommendations does this make?" After this exercise, you'll be ready to use documents for real work tasks! *** **You now know how to make Open WebUI read and analyze your documents.** This transforms the AI from a general assistant into a tool that understands your specific information. In the next section, we'll explore how to keep all your conversations organized. # Organising your chats ### Finding Past Conversations As you use Open WebUI more, you'll accumulate many conversations. Fortunately, finding them again is simple. #### The Chat Sidebar - Your Conversation Archive The left sidebar is your home base for all your chats. Every conversation you start is automatically saved here, listed from newest to oldest. **What you'll see:** * **Chat titles** - Open WebUI automatically creates a short title based on your first question * **Timestamps** - When you last used each chat * **Recent chats at the top** - The conversations you used most recently appear first **To open a past conversation:** 1. **Look at the left sidebar** 2. **Scroll through your chat list** if needed 3. **Click on the chat** you want to reopen 4. The conversation appears in the center - you can continue right where you left off **Tip**: If you have many chats, the most recent ones are almost always what you're looking for. They'll be right at the top. #### Understanding Chat Titles When you start a chat and ask your first question, Open WebUI automatically generates a title for it. **Examples:** * You ask: "How do I create a pivot table in Excel?" * Chat title might be: "Excel Pivot Table Tutorial" Or: * You ask: "Write an email to my team about the project delay" * Chat title might be: "Project Delay Email Draft" **These titles help you:** * Quickly identify what each conversation was about * Find the right chat when you need to return to it * Keep track of different topics and projects **Note**: The title is based on your first message, so starting with a clear, descriptive question helps you find the chat later. ### Archiving Old Chats As your chat list grows, older conversations you no longer need can clutter your sidebar. Archiving helps you keep things tidy without deleting conversations you might need later. #### What Is Archiving? Archiving is like moving chats to storage: * **Removes them from your main sidebar** - keeps your active list clean * **Doesn't delete them** - they're still saved and accessible * **Can be unarchived anytime** - bring them back if you need them Think of it like filing old emails - they're not gone, just out of your daily view. #### How to Archive a Chat **Option 1: Archive Individual Chats** 1. **Find the chat** you want to archive in the sidebar 2. **Right-click on it** (or look for a menu icon, usually three dots) 3. **Select "Archive"** from the menu 4. The chat disappears from your main list **Option 2: Archive Multiple Chats at Once** Some versions of Open WebUI let you select multiple chats and archive them together. Look for a "Select" or "Edit" mode in your sidebar. #### Viewing Archived Chats Your archived chats aren't gone - they're just hidden from your main view. **To see them:** 1. **Look for an "Archived" or "Archive" section** in your sidebar (might be at the bottom) 2. **Click on it** 3. **Your archived chats appear** 4. **Click any archived chat** to view or continue it #### Unarchiving a Chat Need an archived conversation back in your main list? 1. **Go to your archived chats** 2. **Find the conversation** you want to restore 3. **Right-click (or click the menu icon)** 4. **Select "Unarchive"** 5. The chat returns to your main sidebar #### When to Archive Chats **Good candidates for archiving:** * Completed projects you don't need daily access to * One-time questions you've already resolved * Experiments or tests that served their purpose * Old conversations from several months ago **Keep in your main list:** * Active projects you're still working on * Conversations you reference regularly * Recent work that's still relevant * Template chats you use as starting points **Tip**: Don't archive too aggressively. It's fine to have a reasonably long list of recent chats. Only archive when the sidebar starts feeling cluttered. ### Creating Folders (Optional) Folders are a powerful way to organize related conversations into groups. This is an optional feature - you can work perfectly well without folders, but they're helpful for staying organized if you work on different projects or topics. #### What Are Folders? Folders let you group related chats together, like folders on your computer: * **Sales** folder - all conversations about sales topics * **Marketing Campaign** folder - chats related to a specific campaign * **Personal Learning** folder - conversations where you're learning new skills * **Team Project** folder - chats related to a team initiative #### When to Use Folders Folders are most useful when: * You work on distinct projects that each need multiple conversations * You want to separate work topics from personal use * You collaborate with others and need to organize shared information * You have ongoing, long-term activities that generate many chats **You probably don't need folders if:** * You're just getting started * You only have a few conversations * Your work doesn't divide into clear categories * The search function meets your needs #### Creating a Folder **To create a folder:** 1. **Look in your sidebar** for a "+ New Folder" button or option (often near the top or in a menu) 2. **Click it** 3. **Give your folder a name** (e.g., "Q1 Marketing Project") 4. **Click "Save" or "Create"** 5. The folder appears in your sidebar #### Moving Chats into Folders Once you have folders, you can organize your chats: **Method 1: Drag and Drop** 1. **Click and hold** on a chat in your sidebar 2. **Drag it** over to the folder name 3. **Release** when the folder is highlighted 4. The chat moves into the folder **Method 2: Right-Click Menu** 1. **Right-click** on the chat you want to move 2. **Select "Move to Folder"** (or similar option) 3. **Choose the destination folder** 4. The chat moves #### Working with Folders **To see chats in a folder:** * **Click on the folder name** - it expands to show the chats inside **To collapse a folder:** * **Click on it again** - the chats hide, keeping your sidebar tidy **To rename or delete a folder:** * **Right-click on the folder name** * **Select "Rename" or "Delete"** from the menu * If you delete a folder, the chats inside aren't deleted - they move back to your main chat list #### Advanced: Folder Settings Some folders in Open WebUI can have special settings: * **System prompts** that apply to all chats in the folder * **Attached knowledge** that's available to every conversation * **Default models** for that folder's chats These are advanced features. As a beginner, just use folders for organization. You can explore these capabilities later. **Tip**: Start simple. Create just 2-3 folders for your main activities. You can always add more as your needs grow. ### Using the Search Function When you have many conversations, searching becomes your best friend for finding specific chats or information. #### Where to Find Search Look for a **search box or search icon** in your sidebar, usually near the top of your chat list. #### How to Search 1. **Click on the search box** 2. **Type what you're looking for** 3. **Results appear** as you type, showing matching chats 4. **Click on a result** to open that conversation #### What Can You Search? The search function looks through: * **Chat titles** - the automatically generated names * **Your messages** - questions you've asked * **AI responses** - answers the AI gave you * **Document names** - if you've uploaded files #### Search Tips **Search for topics:** * Type: "budget" - finds all chats mentioning budgets * Type: "email draft" - finds conversations about writing emails **Search for specific terms:** * Type: "Q4 2024" - finds references to that time period * Type: "contract analysis" - finds chats about contracts **Use specific words:** * Better: "pivot table" * Less effective: "Excel stuff" **Combine terms:** * "marketing campaign social media" * "project timeline delay" #### Filtering Your Search Some versions of Open WebUI let you filter searches: * **By date range** - "Show only chats from last month" * **By folder** - "Search only in the Sales folder" * **By model** - "Find chats that used Model X" Look for filter options near the search box. #### When Search Doesn't Find It If you can't find what you're looking for: **Try different words:** * Instead of "car," try "vehicle" or "automobile" * Instead of "budget," try "cost" or "expense" **Try shorter searches:** * Instead of "how to create marketing email," try just "marketing" **Browse manually:** * Sometimes scrolling through your recent chats is faster * Look at the chat titles to jog your memory **Check archived chats:** * The search might only look in active chats * Switch to archived view and search there ### Keeping Your Workspace Organized: Best Practices Here are simple habits that keep your chats manageable: #### Daily Habits **Use descriptive first questions:** * Good: "How do I analyze customer survey data in Excel?" * Less helpful: "Help with Excel" The better your first question, the better the automatic title, the easier it is to find later. **Start new chats for new topics:** * Don't keep adding unrelated questions to the same chat * Each distinct topic gets its own conversation * This keeps things clear and searchable #### Weekly Habits **Quick review:** * Once a week, scroll through your sidebar * Archive anything you've finished with * Notice any chats that should go in folders **This takes 2 minutes and prevents clutter.** #### Monthly Habits **Deeper cleanup:** * Review archived chats - delete anything you definitely don't need * Reorganize folders if your projects have changed * Check if your folder structure still makes sense **You don't need to do this often - just when things feel messy.** ### Common Questions **Q: How many chats can I have?** A: There's no practical limit. You can have hundreds of chats. Just archive the old ones to keep your active list manageable. **Q: If I delete a chat, is it gone forever?** A: Yes. Deleted chats cannot be recovered. That's why archiving is safer - it hides chats without deleting them. **Q: Can I rename a chat to something more useful?** A: Yes! Right-click on the chat and look for a "Rename" option. Give it a name that will help you find it later. **Q: Do folders slow down Open WebUI?** A: No. Folders are just organizational tools - they don't affect performance. **Q: Can I share a folder with a colleague?** A: This depends on your organization's Open WebUI setup. Contact your administrator to learn about sharing and collaboration features. **Q: What's the difference between archiving and deleting?** A: Archiving hides a chat from your main list but keeps it accessible. Deleting permanently removes it. When in doubt, archive. **Q: Can I search inside a specific chat?** A: The main search finds which chats contain your terms. Once you open a chat, you can use your browser's search (Ctrl+F or Cmd+F) to find specific text within that conversation. ### Practice Exercise Let's practice organizing: 1. **Look at your sidebar** - how many chats do you have? 2. **Try searching** for a word you know appears in one of your chats 3. **Archive one old chat** you don't need active anymore 4. **View your archived chats** to confirm it's there 5. **If you have several chats**, create one folder and move related chats into it 6. **Start a new chat with a clear, descriptive first question** - notice how this creates a better title After this exercise, your workspace should feel more organized! *** **You now have the tools to keep your Open WebUI workspace tidy and your conversations easy to find.** In the next section, we'll explore the basic settings you can adjust to personalize your experience. # Basic settings ### Accessing Your Settings Open WebUI lets you customize a few key preferences to make your experience more comfortable. Don't worry - you don't need to change anything if the defaults work for you, but knowing where these settings are can be helpful. **To open your settings:** 1. **Look at the bottom-left corner** of your Open WebUI screen 2. **Find your profile icon or username** (usually shows your initials or a small avatar) 3. **Click on it** 4. **Select "Settings"** from the menu that appears 5. A settings window opens **Alternative access:** Some versions of Open WebUI have a settings icon (gear symbol) that you can click directly. **What you'll see:** The settings window typically has several tabs or sections. As a basic user, you only need to know about a few of them. The rest are for advanced users or administrators. ### Changing the Theme (Dark/Light Mode) The theme controls how Open WebUI looks - specifically whether it uses a dark background or a light one. This is purely personal preference and doesn't affect how the AI works. #### Available Themes Open WebUI typically offers these visual themes: **Light Mode** * White or light gray background * Dark text * Good for bright environments or if you prefer traditional document-style appearance * Easier on the eyes in well-lit rooms **Dark Mode** * Dark gray or black background * Light text * Reduces eye strain in low-light conditions * Popular for extended screen time * Uses less power on OLED screens **OLED Dark Mode** * Pure black background (specifically for OLED screens) * Maximum contrast * Saves battery on phones and laptops with OLED displays **System Theme** * Automatically matches your computer or device's theme setting * Switches between light and dark based on your operating system preferences * Useful if your device changes themes based on time of day #### How to Change Your Theme 1. **Open Settings** (click your profile icon → Settings) 2. **Look for "General" or "Interface" tab** 3. **Find the "Theme" section** 4. **Click on the theme dropdown** or theme options 5. **Select your preferred theme:** * Light * Dark * OLED Dark * System 6. **The change applies immediately** - no need to save or refresh **Try them out!** Switch between themes to see which one you prefer. There's no right answer - it's all about what's comfortable for your eyes. #### Tips for Choosing a Theme **Use Light Mode if:** * You work in a bright office or near windows * You prefer reading on white backgrounds * You're printing or sharing screenshots (they'll look more traditional) **Use Dark Mode if:** * You work in dimly lit environments * You spend many hours per day in Open WebUI * You find bright screens cause eye strain * You work late at night **Use System Theme if:** * Your computer already switches themes automatically * You want Open WebUI to match your other apps * You like automatic day/night adjustments **Most popular choice:** Many users prefer dark mode for daily work, but it's entirely personal preference. ### Setting Your Preferred Default Model Remember how you select an AI model at the top of each chat? You can set which model appears by default when you start a new conversation. This saves you from selecting it every time. #### Why Set a Default Model? **Without a default:** * Every new chat starts with whatever model the system chooses * You need to manually switch to your preferred model each time * Takes an extra step before you can start working **With a default:** * New chats automatically use your favorite model * Start asking questions immediately * Still can change models anytime - the default is just a starting point #### How to Set Your Default Model There are usually two ways to set your default model: **Method 1: From Settings** 1. **Open Settings** (profile icon → Settings) 2. **Look for "Interface" or "Models" tab** 3. **Find "Default Model" section** 4. **Click the dropdown menu** 5. **Select your preferred model** 6. **Click "Save"** if needed **Method 2: From a Chat Window** 1. **Start any chat** (new or existing) 2. **Click on the model name** at the top 3. **Browse the available models** 4. **Look for "Set as Default" option** next to model names 5. **Click "Set as Default"** on your preferred model 6. A checkmark or indicator shows it's now your default #### Choosing Your Default Model **Which model should you choose?** For most users, the model that's already set as default when you first log in is a good choice. But here's how to think about it: **Consider your most common tasks:** * Do you mostly write content? Choose a model good at writing * Do you work with code frequently? Choose a model optimized for programming * Do you ask general questions? Choose a well-rounded, general-purpose model **Consider speed vs. power:** * Faster models respond more quickly but may be less sophisticated * More powerful models take a bit longer but handle complex tasks better * For everyday questions, faster models are usually fine **Ask for advice:** If you're not sure, you can actually ask the AI: "Which model should I use as my default for general business tasks?" The AI can explain the differences between available models. **Don't overthink it:** * You can change your default anytime * You can still use other models whenever you want * There's no wrong choice - pick one and try it out #### Testing Different Models Before setting a default, you might want to test a few: 1. **Start a new chat** 2. **Ask the same question with different models** 3. **Compare the responses** 4. **Notice which one gives you the style and depth you prefer** **Example test question:** "Explain the concept of supply and demand in simple terms" Try this with 2-3 different models and see which response you like best. ### Language Preferences Open WebUI supports multiple languages. You can use the interface in your preferred language. #### What Changes When You Change Language? **Interface elements change:** * Button labels * Menu items * Settings names * System messages **What doesn't change:** * Your conversations with the AI (it will respond in whatever language you use to ask questions) * Chat content you've already created * Document names or content **Note:** Even if you set the interface to English, you can still have conversations with the AI in Spanish, French, German, or any other language the AI supports. The language setting is just for the buttons and menus. #### How to Change Language 1. **Open Settings** (profile icon → Settings) 2. **Look for "General" or "Interface" tab** 3. **Find "Language" section** 4. **Click the language dropdown** 5. **Select your preferred language** from the list 6. **The interface updates immediately** #### Available Languages Open WebUI typically supports many languages, including: * English * Spanish * French * German * Portuguese * Chinese * Japanese * And many others The exact list depends on your organization's setup. #### Tips for Language Settings **If you're multilingual:** * Set the interface to your primary language * You can still ask questions in any language * The AI will respond in whatever language you use **If you're learning a language:** * Keep the interface in your native language for clarity * Practice by having conversations with the AI in the language you're learning **If the language changes unexpectedly:** * You might have accidentally changed it * Open Settings and switch it back * The settings icon and location stay in the same place regardless of language ### Other Basic Settings You Might See While exploring your settings, you might notice other options. Here's what a few common ones do: #### Chat History **Setting:** Enable/disable chat history **What it does:** Controls whether your conversations are saved **Recommendation:** Keep this ON unless you have a specific privacy need #### Notifications **Setting:** Enable/disable notifications\ **What it does:** Controls whether you get alerts when chats complete **Recommendation:** Useful if you multitask while waiting for responses #### Text Input Style **Setting:** Rich text vs. plain text input **What it does:** Changes whether the input box has formatting buttons **Recommendation:** Plain text is simpler; rich text allows formatting **As a beginner, you can safely ignore most other settings.** They're either for advanced users or will make sense once you're more experienced. ### Your Settings Summary Here's a quick reference for the main settings: | Setting | Where to Find It | What to Choose | | ----------------- | ------------------------------------------------ | --------------------------------- | | **Theme** | Settings → General/Interface | Dark, Light, OLED Dark, or System | | **Default Model** | Settings → Interface OR click model name in chat | Your most-used model | | **Language** | Settings → General/Interface | Your preferred interface language | ### Resetting to Defaults Changed something and want to go back to how it was? **To reset individual settings:** * Just change them back manually to the original value **To reset everything:** * Look for a "Reset to Default" or "Restore Defaults" button in Settings * Or contact your administrator if you're really stuck **Can't find a setting anymore?** * Look through all the tabs in Settings - it's probably just in a different section * Ask your administrator for help ### Common Questions **Q: Will changing my theme affect my colleagues?** A: No. All settings are personal to your account. Your theme choice doesn't affect anyone else. **Q: If I change my default model, will it change my existing chats?** A: No. Existing chats keep using whatever model they started with. The default only affects new chats you create. **Q: Can I have different default models for different folders?** A: This is an advanced feature. As a basic user, stick with one default model for all chats. **Q: I changed the language by accident and can't read the menus anymore. Help!** A: The Settings icon location doesn't change. Click it, look for the tab you were in before (same position), find the dropdown you changed, and select English or your language. If truly stuck, ask a colleague or administrator. **Q: Do I need to save my settings changes?** A: Most settings apply immediately. Some might have a "Save" button - click it if you see it. When in doubt, click Save before closing the settings window. **Q: Why don't I see some settings that are mentioned in tutorials?** A: Your administrator might have hidden certain settings that regular users don't need. This is normal and helps keep things simple. **Q: Can I customize the colors beyond the preset themes?** A: Not in basic settings. The preset themes are designed to work well. Custom colors are an advanced feature. ### Practice Exercise Take 5 minutes to explore your settings: 1. **Open Settings** by clicking your profile icon 2. **Try switching themes** - change to dark mode, then light mode, then back to your preference 3. **Look at your default model** - is it the one you want? Change it if needed 4. **Check your language setting** - make sure it's correct 5. **Browse the other tabs** just to see what's there (you don't need to change anything) 6. **Close Settings** when you're done After this exercise, you'll know exactly where to go when you want to adjust something! *** **You've now personalized your Open WebUI experience with the basic settings that matter most.** In the final section, we'll show you where to find additional help and resources when you need them. # Getting more help ### This Is Just the Beginning Congratulations! You've learned the essential features of Open WebUI that will get you started and productive right away. You now know how to: * Start conversations and select models * Ask questions and manage responses * Work with your documents using RAG * Organize your chats with folders and search * Customize your basic settings **But there's much more to Open WebUI than what we've covered here.** This quick start guide focuses on the fundamentals - what you need to know in your first days and weeks of use. As you become more comfortable, you may want to explore advanced features like: * Creating custom models with specific behaviors * Using tools and functions to extend the AI's capabilities * Working with web search integration * Setting up complex workflows with system prompts * Using Python functions and custom integrations * Image generation capabilities * Advanced document processing and knowledge management * Multi-model conversations * Collaboration features **When you're ready to learn more, the full documentation is available.** ### The Full Open WebUI Manual For comprehensive information about all of Open WebUI's features and capabilities, visit the official documentation: [**https://docs.openwebui.com**](https://docs.openwebui.com) The full manual includes: * Detailed explanations of every feature * Step-by-step tutorials for advanced tasks * Technical documentation for developers * Configuration guides for administrators * Community tips and best practices * Video tutorials and examples **When to use the full manual:** * You want to explore features beyond the basics * You need detailed technical information * You're trying to do something complex or specialized * You're curious about what else Open WebUI can do * You encounter an advanced setting or option you don't understand **Bookmark this resource** - it's your comprehensive reference for everything Open WebUI can do. ### GLBNXT Workspace Support For questions specific to your GLBNXT Workspace setup, your organization provides dedicated support. #### When to Contact GLBNXT Support **Contact your GLBNXT Workspace administrator or support team for:** * **Access issues** - can't log in, forgot password, account problems * **Setup questions** - how Open WebUI is configured in your organization * **Permission questions** - features you can't access or need enabled * **Technical problems** - errors, crashes, or things not working as expected * **Organization-specific policies** - what you can and cannot do * **Integration questions** - how Open WebUI connects with other GLBNXT tools * **Model availability** - which AI models are available to you * **Storage limits** - how many chats or documents you can have * **Collaboration features** - sharing with colleagues, team workspaces #### How to Get Support Your organization will have provided you with support contact information. This might be: * An internal help desk or IT support system * A dedicated GLBNXT support email address * A support portal or ticketing system * A Slack channel or Teams group for GLBNXT questions * Direct contact with your GLBNXT administrator **When contacting support, include:** * Your username or email * What you were trying to do * What happened instead * Any error messages you saw (take a screenshot if possible) * Which browser you're using ### Common Questions and Answers Here are answers to frequently asked questions from new users: #### Getting Started Questions **Q: I'm not sure what to ask the AI. Where do I start?** A: Start with real questions you have or tasks you need to do. Try: "Help me write an email to...", "Explain what \[term] means", "Summarize this document", or "Give me ideas for...". The AI works best when you have a genuine task in mind. **Q: How is this different from ChatGPT or other AI tools?** A: Open WebUI is similar to ChatGPT in how you interact with it, but it runs within your GLBNXT Workspace environment. Your data stays private within your organization, you have access to different models, and you can work with your organization's specific documents and resources. **Q: Can I use Open WebUI on my phone?** A: Yes! Open WebUI works in your mobile browser. The interface adapts to smaller screens, though some features are easier to use on a desktop or laptop. **Q: Is there a limit to how many questions I can ask?** A: This depends on your organization's policies. For most users, there are generous limits that won't affect normal daily use. Contact your administrator if you need to know specific limits. #### Using Open WebUI Questions **Q: The AI gave me incorrect information. What should I do?** A: AI models can make mistakes. Always verify important information from authoritative sources. You can also try regenerating the response, being more specific in your question, or trying a different model. For critical decisions, treat AI responses as a helpful starting point, not the final answer. **Q: Can I use Open WebUI for confidential or sensitive information?** A: Your conversations stay within your GLBNXT Workspace, but always follow your organization's data handling policies. If you're unsure whether something is appropriate to discuss with the AI, check with your supervisor or compliance team. **Q: How long are my chats saved?** A: Your chats are saved indefinitely unless you delete them or your organization has specific retention policies. Check with your administrator about your organization's data retention rules. **Q: Can my manager or IT team see my conversations?** A: This depends on your organization's policies. In most setups, your chats are private, but administrators may have access for security or compliance purposes. Ask your administrator about your organization's privacy policies. **Q: I accidentally deleted an important chat. Can I get it back?** A: Usually no - deleted chats are permanently removed. This is why archiving is safer than deleting. If this happens, contact your administrator immediately; in some cases, they may be able to recover recent deletions. #### Technical Questions **Q: Open WebUI is running slowly. What can I do?** A: Try these steps: 1. Refresh your browser page 2. Clear your browser cache 3. Close other browser tabs 4. Try a different browser 5. If still slow, contact GLBNXT support - there may be a system issue **Q: I got an error message. What does it mean?** A: Take a screenshot of the error and contact GLBNXT support. They can help diagnose the issue. Common causes include connection problems, system maintenance, or browser issues. **Q: Can I use Open WebUI offline?** A: No. Open WebUI requires an internet connection to access the AI models and your workspace data. **Q: Which browser works best?** A: Open WebUI works well in modern browsers like Chrome, Firefox, Safari, and Edge. Use an up-to-date version for the best experience. #### Document and Organization Questions **Q: What's the largest document I can upload?** A: File size limits vary by organization. Most users can upload documents up to 50-100 MB. For larger files, try splitting them into smaller parts or contact your administrator. **Q: Can I share a chat with a colleague?** A: Sharing capabilities depend on your organization's setup. Some organizations enable chat sharing, others don't. Check the documentation or ask your administrator about collaboration features. **Q: Why can't I see any documents when I use the # command?** A: The # command shows documents in your Workspace. If nothing appears, documents may not be set up yet. Either upload files directly to chats or ask your administrator about adding documents to the Workspace. **Q: Do I need to organize my chats, or can I just let them pile up?** A: You can work either way! Some users keep everything in one long list; others prefer folders and archiving. Do what feels natural. If your sidebar gets cluttered and hard to navigate, that's when organization becomes useful. ### Tips for Learning More #### Learn by Doing **The best way to learn Open WebUI is to use it for real work:** * Have actual conversations instead of test queries * Upload real documents you need to work with * Use it for tasks you do regularly * Experiment with different approaches **Every conversation teaches you something new** about how to ask better questions and use the features effectively. #### Explore Gradually **You don't need to learn everything at once:** * Start with basic chat (which you already know!) * Add document work when you need it * Explore folders when your chat list gets long * Try advanced features as you encounter needs for them **There's no rush.** Learn features as they become relevant to your work. #### Watch What Colleagues Do If other people in your organization use Open WebUI: * Ask them how they use it * Look at how they organize their workspace * Learn what models they prefer for different tasks * Share tips and discoveries **Community learning is powerful** - your colleagues may know tricks that aren't in any manual. #### Experiment Safely **Don't be afraid to try things:** * You can't break Open WebUI by clicking around * Chats can be deleted if you don't like them * Settings can be changed back * The worst that happens is a conversation doesn't work out - just start a new one **Experimentation is encouraged!** That's how you discover what works best for you. ### Quick Reference: Where to Find Help | What You Need | Where to Go | | ---------------------------------------- | ----------------------------- | | **Learn advanced Open WebUI features** | | | **Technical problems or access issues** | GLBNXT Workspace Support | | **Organization policies or permissions** | Your administrator or IT team | | **Forgot how to do something basic** | Review this quick start guide | | **Want to try something new** | Experiment in a test chat | | **Questions about what's possible** | Ask the AI itself! | ### Asking the AI for Help **Here's a helpful tip:** You can ask Open WebUI itself for help! **Try these questions:** * "What's the best way to organize many documents in Open WebUI?" * "How can I write better prompts to get more useful answers?" * "What should I do if you give me incorrect information?" * "Can you explain what RAG is and when I should use it?" **The AI can:** * Explain features you don't understand * Suggest workflows for specific tasks * Help you troubleshoot problems * Guide you through processes **This is often the fastest way to get help with basic questions.** ### Final Thoughts You now have everything you need to be productive with Open WebUI: ✓ You can start conversations and get useful answers\ ✓ You know how to work with documents\ ✓ You can organize and find your chats\ ✓ You've personalized your basic settings\ ✓ You know where to find more help **What's next?** 1. **Start using Open WebUI for real work** - the best learning happens through actual use 2. **Explore gradually** - try one new feature at a time as you need it 3. **Refer back to this guide** when you need a reminder 4. **Visit the full documentation** when you're ready for advanced features 5. **Contact support** whenever you need help **Remember:** Open WebUI is a tool to make your work easier and more efficient. Use it in whatever way serves you best. There's no "right" way to use it - only what works for your needs. **Welcome to Open WebUI, and happy chatting!** *** ### Additional Resources **Official Open WebUI Documentation**\ **GLBNXT Workspace Support**\ Contact your organization's administrator or support team for assistance specific to your setup. *** *This quick start guide covers the essential features for new users. For comprehensive documentation of all Open WebUI capabilities, please refer to the official documentation at docs.openwebui.com.* # LIBRECHAT # Welcome to LibreChat ### What is LibreChat? LibreChat is an AI chat interface that gives you access to powerful language models through a clean, feature-rich environment. Hosted by GLBNXT within your sovereign workspace, LibreChat lets you have natural conversations with AI, work with documents, use intelligent agents, and search the web, all without your data leaving the GLBNXT environment. Whether you need help drafting content, analysing documents, answering complex questions, or automating repetitive thinking tasks, LibreChat is designed to support a wide range of everyday professional work. ### What to Expect on First Login When you first open LibreChat, you will land on a clean home screen with a central message input and a sidebar on the left. There are no complicated setup steps, you can start a conversation immediately. A few things you will notice straight away: **The sidebar** runs along the left side of the screen. This is where all your past conversations are stored. It also gives you access to agents and presets, which you will explore in later chapters. **The model selector** appears near the message input area. GLBNXT makes a curated set of AI models available to you, you can switch between them depending on the task at hand. **The message input** is the large text box at the bottom of the screen. This is where you type your questions, instructions, or requests. You can also attach files directly from here. ### A Brief Tour of the Interface LibreChat's interface is intentionally straightforward. The key areas you will use regularly are: * **Sidebar (left)** - your conversation history, agents, and navigation * **Main chat area (centre)** - where your conversations happen * **Model and settings bar (top)** - switch models, access conversation options, and toggle features like web search * **Message input (bottom)** - type messages, attach files, and send your requests You do not need to explore every menu before getting started. Most of what you need is visible by default. ### Your Conversations Are Private Because LibreChat runs within the GLBNXT platform, your conversations remain inside your organisation's environment. Nothing is shared with external AI providers or public services. This is especially relevant if you are working with sensitive business content or internal documents. ### Ready to Begin? The best way to get comfortable with LibreChat is simply to start using it. In the next chapter, you will learn how to start your first conversation, choose the right model, and use the basic chat actions you will rely on every day. # Your first conversation ### Starting a New Chat To begin a conversation, click the **"New Chat"** button at the top of the left sidebar. A blank chat window opens in the centre of the screen and you are ready to type. Each new chat starts with a clean context. Previous conversations do not influence it, which is useful when switching between topics or tasks. **When to start a new chat:** * You are moving to a completely different topic * You want the AI to focus only on the current task * You are starting a new project or document ### Selecting a Model Before or after typing your first message, you can choose which AI model to use. The model selector is visible near the top of the chat window. GLBNXT provides a curated set of models, each suited to different types of work. If you are unsure which model to pick, start with the default. You can always switch models mid-conversation if you want to compare responses or try a different approach. ### Typing Your First Message Click inside the message input box at the bottom of the screen and start typing. When you are ready, press **Enter** or click the send button. A few tips for getting useful responses: **Be specific.** Instead of "summarise this", try "summarise this in three bullet points for a non-technical audience." **Give context.** The more relevant background you provide, the more accurate and useful the response will be. **Ask follow-up questions.** LibreChat remembers the context of your current conversation, so you can build on previous messages naturally. ### Basic Chat Actions Once the AI responds, you have several options for working with that response: **Copy** - Use the copy icon beneath a response to copy the full text to your clipboard. **Regenerate** - If the response is not quite right, click regenerate to ask LibreChat to try again with the same prompt. **Edit your message** - Click the edit icon on your own message to revise what you sent and resubmit it. This replaces the original message and generates a new response. **Fork the conversation** - If you want to explore a different direction without losing your current thread, use the fork option to create a copy of the conversation from that point onwards. ### Sharing a Conversation If you want to share a conversation with a colleague, LibreChat can generate a shareable link. Look for the share option in the conversation menu at the top of the chat window. The recipient can view the conversation without needing to log in to your account. ### Your Conversations Are Saved Automatically Every conversation is saved automatically and appears in the left sidebar. You can return to any previous chat at any time by clicking on it. Conversations are listed in chronological order with the most recent at the top. ### Ready to Go Further? Now that you know how to start and manage a conversation, the next chapter covers working with files and documents, so you can bring your own content into the conversation and ask the AI questions directly about it. # Working with files and knowledge ### Why Use Files in a Conversation? LibreChat allows you to bring your own documents into a conversation and ask the AI questions directly about the content. This is useful when you need to analyse a report, summarise a policy document, extract key information from a contract, or work through any material that would take time to read and process manually. Because LibreChat runs within the GLBNXT environment, the files you upload stay inside your organisation's infrastructure and are not sent to external services. ### Uploading a File to Your Chat To upload a file, click the attachment icon in the message input bar at the bottom of the chat window. Select the file you want to use from your device. Once uploaded, the file appears above your message input and is included in the conversation context. You can then ask the AI questions about the file directly, for example: * "Summarise the key findings in this report." * "What are the payment terms mentioned in this contract?" * "List all action items from this meeting transcript." LibreChat supports common file formats including PDF, Word documents, plain text files, and images. If you are unsure whether your file type is supported, try uploading it and LibreChat will indicate if it cannot process the content. ### What Happens When You Upload a File? When you upload a document, LibreChat reads the content and makes it available as context for your conversation. The AI can then reference specific sections, quote relevant passages, and answer questions based on what is in the document. For longer documents, LibreChat uses a file search capability that retrieves the most relevant sections of your document in response to each question you ask. This means you do not need to worry about document length in most cases. ### Using Web Search LibreChat can also search the web to supplement its responses with current information. This is useful when you are asking about recent events, looking for up to date figures, or want the AI to ground its answer in publicly available sources. To use web search, look for the web search toggle in the message input area or the settings bar at the top of the chat window. When enabled, LibreChat will search the web as part of generating its response and will reference the sources it used. **When web search is useful:** * Researching topics where recent information matters * Fact-checking claims against public sources * Getting current data such as market figures, news, or regulatory updates **When web search is not needed:** * Working with documents you have already uploaded * Tasks based on your own content or internal knowledge * General writing, drafting, or reasoning tasks ### Combining Files and Web Search You can use both file uploads and web search in the same conversation. For example, you could upload an internal strategy document and ask LibreChat to compare it against recent industry trends, with web search providing the external context. ### A Note on File Privacy Files you upload are used only within your current conversation. GLBNXT does not use your uploaded content to train AI models or share it outside your environment. If you are working with confidential documents, LibreChat within GLBNXT is the appropriate place to do so. ### Ready to Continue? In the next chapter, you will learn about Agents and Presets, which allow you to work with purpose-built AI assistants and save your preferred settings for different types of tasks. # Agents and presets ### What Are Agents? Agents are purpose-built AI assistants that have been configured for specific tasks or workflows. Unlike a standard chat conversation where you start from scratch each time, an agent comes with predefined instructions, a selected model, and a set of tools that make it immediately useful for a particular type of work. GLBNXT may provide a set of pre-built agents tailored to your organisation's needs. These could include agents for summarising documents, drafting communications, answering questions about internal policies, or supporting specific business processes. ### Finding and Using an Agent Agents are accessible from the left sidebar. Look for the Agents section or use the endpoint selector at the top of the chat window to switch from a standard model conversation to an agent. When you start a conversation with an agent, it behaves like a regular chat but with a focused purpose. You do not need to provide lengthy instructions or context each time because the agent already knows what it is designed to do. **Examples of how agents can help:** * A document review agent that is pre-configured to extract key clauses from contracts * A communications agent that drafts emails in your organisation's preferred tone * A research agent that combines web search with structured summarisation * A policy assistant that is pre-loaded with your internal guidelines and procedures ### What Can Agents Do? Depending on how an agent has been configured, it may have access to one or more of the following capabilities: **File search** - The agent can search through documents to find relevant information and reference it in its responses. **Web search** - The agent can retrieve current information from the web as part of answering your questions. **Code interpreter** - The agent can write and run code to perform calculations, process data, or generate outputs. **File context** - The agent has been given specific documents as part of its instructions, meaning it already has background knowledge built in. Not all agents will have all capabilities. GLBNXT administrators configure what each agent can access based on its intended purpose. ### What Are Presets? Presets are saved configurations for standard model conversations. If you find yourself regularly adjusting the same settings each time you start a chat, a preset allows you to save those preferences and apply them instantly to any new conversation. A preset can include: * A specific model selection * A system prompt that sets the tone or role for the AI * Model parameters such as response style or output length ### Creating a Preset To create a preset, open the preset menu from the top of the chat window. Give your preset a name that makes it easy to identify, configure the settings you want to save, and click save. The preset will then appear in your presets list and can be applied to any new conversation with a single click. **Practical examples of useful presets:** * A preset with a system prompt that instructs the AI to always respond concisely and in plain language * A preset configured for a specific model you prefer for technical tasks * A preset with a prompt that sets the AI up as a writing assistant for your preferred communication style ### Agents vs Presets Both agents and presets help you work more efficiently, but they serve different purposes. Agents are built and maintained by administrators and are designed for specific organisational workflows. Presets are personal configurations you create yourself to match your individual working style. If your organisation has provided agents for specific tasks, start there. Use presets to complement your personal workflow in standard conversations. ### Ready to Continue? In the next chapter, you will learn how to manage and organise your conversations so you can find past chats easily and keep your workspace tidy. # Managing your conversations ### Your Conversation History Every conversation you have in LibreChat is saved automatically and listed in the left sidebar in chronological order, with the most recent at the top. You can return to any past conversation at any time simply by clicking on it. Over time your sidebar will fill up with conversations across different topics and tasks. LibreChat provides several tools to help you stay organised and find what you need quickly. ### Searching Your Conversations If you are looking for a specific past conversation, use the search function at the top of the sidebar. Type a keyword or phrase related to the topic you discussed and LibreChat will filter your conversation list to show matching results. This is the fastest way to locate a specific discussion without scrolling through your full history. ### Renaming Conversations By default, LibreChat gives each conversation an automatically generated title based on your first message. If the title is not descriptive enough, you can rename it to something more meaningful. To rename a conversation, hover over it in the sidebar, click the options menu that appears, and select rename. Type your preferred title and confirm. Clear, descriptive names make it much easier to find specific conversations later. ### Bookmarking Conversations For conversations you want to return to regularly, LibreChat offers a bookmark feature. Bookmarked conversations are easy to locate and can serve as a reference library for ongoing projects or frequently used workflows. To bookmark a conversation, open the options menu for that conversation in the sidebar and select the bookmark option. You can view all your bookmarked conversations from the sidebar navigation. ### Deleting Conversations If you no longer need a conversation, you can delete it to keep your sidebar tidy. Open the options menu for the conversation in the sidebar and select delete. Please note that deleted conversations cannot be recovered, so only delete what you are certain you no longer need. ### Temporary Chat Mode If you want to have a conversation that is not saved to your history at all, LibreChat offers a temporary chat mode. This is useful for quick one-off questions, sensitive topics you do not want stored, or simply keeping your sidebar uncluttered. To start a temporary chat, look for the temporary chat option in the top menu of the chat window. The conversation will not appear in your sidebar after the session ends. ### Forking a Conversation If you are mid-conversation and want to explore a different direction without losing your current thread, you can fork the conversation. Forking creates a copy of the conversation from a chosen point, allowing you to take it in a new direction while keeping the original intact. This is particularly useful when you want to test different approaches to the same problem or compare how a conversation develops with different follow-up questions. ### Importing Conversations LibreChat also supports importing conversations from other sources. If you have conversation exports from another AI platform, you may be able to import them into LibreChat to continue working with that content. Look for the import option in the sidebar menu for details on supported formats. ### Keeping Your Workspace Tidy A few simple habits will help you keep your conversation history manageable: * Rename conversations immediately after starting them if the topic is important * Bookmark conversations linked to ongoing projects * Delete one-off or test conversations you no longer need * Use temporary chat for quick questions that do not need to be saved ### Ready to Continue? In the final chapter, you will find guidance on where to get further help, how to contact GLBNXT support, and where to go when you are ready to explore more advanced LibreChat features. # Getting more help ### You Are Ready to Use LibreChat If you have worked through this guide, you now have everything you need to be productive with LibreChat on GLBNXT. You can start conversations, work with documents, use agents and presets, search the web, and keep your workspace organised. The best way to build confidence from here is simply to use LibreChat for real work. Try it for tasks you would normally handle manually and see where it adds value for you. ### When You Need Guidance **For questions about LibreChat features and functionality**, the official LibreChat documentation covers the full range of capabilities in detail, including advanced configuration, agents, integrations, and more. Official documentation: [librechat.ai/docs](https://www.librechat.ai/docs) **For questions specific to your GLBNXT environment**, such as which models are available, how agents have been configured, or access and permissions issues, contact your GLBNXT administrator or the GLBNXT support team. These are platform-level questions that the official LibreChat documentation will not cover. **For organisation-specific guidance**, such as how your team uses LibreChat, which agents are recommended for specific tasks, or internal policies around AI usage, speak with your team lead or the person responsible for AI tools in your organisation. ### Ask the AI Itself One of the most practical ways to get quick answers is to ask LibreChat directly. The AI can explain its own features, suggest workflows, and guide you through tasks you are unsure about. Some useful questions to try: * "How do I get better results when uploading documents?" * "What is the difference between an agent and a standard chat?" * "How should I write a prompt to get a concise summary?" * "What can you help me with in a professional context?" ### Quick Reference | What You Need | Where to Go | | ----------------------------------------- | -------------------------------------------------- | | Full LibreChat feature documentation | [librechat.ai/docs](https://www.librechat.ai/docs) | | Model availability and platform questions | GLBNXT Administrator | | Access issues or technical problems | GLBNXT Support | | Organisation policies on AI usage | Your team lead or IT department | ### A Few Final Tips **Start simple.** You do not need to use every feature from day one. Begin with basic conversations and add capabilities like file uploads, agents, and presets as you become more comfortable. **Iterate your prompts.** If a response is not quite what you needed, refine your question and try again. A small change in wording can make a significant difference to the quality of the output. **Use the right tool for the task.** A standard conversation works well for most tasks. Agents are there for structured, repeatable workflows. Presets save you time when you have a regular working pattern. Temporary chat is there when you do not want a conversation saved. **Your data stays with GLBNXT.** Whatever you work on within LibreChat remains inside your organisation's environment. Use it with confidence for professional and sensitive work. ### Welcome to LibreChat on GLBNXT You are all set. Start a conversation, explore at your own pace, and make use of the support resources above whenever you need them. *** *This guide covers the essentials for new LibreChat users on GLBNXT. For the complete feature reference, visit the official documentation at* [*librechat.ai/docs*](https://www.librechat.ai/docs)*.* # README GLBNXT Platform is a fully managed AI platform built for development teams. It brings together the world's best open-source tools, from model serving and vector databases to workflow automation and frontend interfaces, into a single, enterprise-ready environment that is sovereign, secure, and orchestrated end-to-end. Most organisations are slowed down by fragmented stacks, broken integrations, and the operational burden of managing open-source infrastructure themselves. GLBNXT Platform removes that complexity entirely. Compute, networking, orchestration, secrets management, observability, compliance, and model routing are all handled at the platform level, so your engineers can focus on building AI products rather than maintaining the stack behind them. The platform operates around a clear division of responsibility. GLBNXT manages the foundation: GPU and CPU compute, Kubernetes orchestration, storage, backups, security controls, and audit trails. Your development team builds the solutions on top: RAG pipelines, AI assistants, multi-agent workflows, APIs, and user-facing applications. A single platform orchestrates the layer beneath it all, so everything works together by default. {% columns %} {% column %} The platform operates around a clear division of responsibility. GLBNXT manages the foundation: GPU and CPU compute, Kubernetes orchestration, storage, backups, security controls, and audit trails. Your development team builds the solutions on top: RAG pipelines, AI assistants, multi-agent workflows, APIs, and user-facing applications. A single platform orchestrates the layer beneath it all, so everything works together by default. {% endcolumn %} {% column %}
{% endcolumn %} {% endcolumns %} GLBNXT Platform is built on open standards and open-source technologies. There is no vendor lock-in, no proprietary black-box layer, and no dependency on US hyperscaler infrastructure. All compute runs within the EU, with data residency guarantees and compliance alignment for GDPR, ISO 27001, and sector-specific regulatory requirements. ### Who This Documentation Is For This documentation is written for the teams that build on GLBNXT Platform: * **ML Engineers and Data Scientists** deploying and evaluating models, building inference pipelines, and integrating AI capabilities into applications * **Data Engineers** designing RAG systems, managing vector databases, and building data pipelines that feed AI workloads * **DevOps and IT Architects** responsible for access control, environment configuration, security posture, and operational governance * **Product Leaders and CTOs** evaluating the platform's capabilities, compliance profile, and strategic fit for their organisation Whether you are onboarding for the first time or building your first production AI application, this documentation will guide you through platform capabilities and help you get to value quickly. ### Jump right in

:bolt:

QuickstartCreate your first site/pages/7FvWQMF0kTK7HGhlQfmo

:leaf:

Editor basicsLearn the basics of GitBookhttps://github.com/GitbookIO/gitbook-templates/blob/main/product-docs/broken-reference/README.md

:globe-pointer:

Publish your docsShare your docs online/pages/QPzbTvC6XsT5gERiU43E
# GLBNXT Platform n8n is a visual workflow automation platform that enables developers and technical teams to build complex, event-driven AI pipelines. By combining standard API nodes with native LangChain nodes, n8n bridges the gap between raw LLM capabilities and your internal stack—allowing you to trigger agents via webhooks, interact with databases, and automate multi-step technical workflows without writing boilerplate glue code. In this section, you'll learn how to integrate n8n into your infrastructure to automate AI-driven operational tasks. This guide covers connecting API developer keys, configuring sovereign model nodes, and executing structured tool calling. # Introduction ### What is GLBNXT Platform? GLBNXT Platform is a fully managed AI platform built for development teams. It delivers the world's best open-source tools for model serving, vector databases, workflow automation, and frontend interfaces in a single enterprise-ready environment that is sovereign, secure, and orchestrated end-to-end. Most organisations building with AI are slowed down by fragmented stacks, broken integrations, and the operational burden of managing open-source infrastructure themselves. GLBNXT Platform removes that complexity. Compute, networking, orchestration, secrets management, observability, compliance, and model routing are all handled at the platform level, so your engineers focus entirely on building AI products rather than maintaining the stack beneath them. ### How It Works The platform is structured around a clear division of responsibility between GLBNXT and your development team. **What GLBNXT manages:** * GPU and CPU compute * Kubernetes orchestration * Networking and security * Storage and backups * Secrets and credential vault * Observability and monitoring * Compliance and audit trails * Model routing **What your team builds:** * AI assistants and chat interfaces * RAG pipelines and knowledge systems * Multi-agent workflows and automation * APIs and functions * User-facing applications A single platform orchestrates the layer beneath it all, so every component works together by default. No glue code, no infrastructure incidents, no time lost on DevOps. ### Platform vs. Workspace GLBNXT offers two distinct products serving different audiences within an organisation. **GLBNXT Platform** is designed for development teams. It provides the full AI infrastructure stack for engineers, data scientists, and architects who build and deploy AI-powered applications and services. **GLBNXT Workspace** is designed for knowledge workers and business teams. It provides a governed, compliant AI environment for employees who use AI to do their work, without needing to build anything. Both products share the same commitment to European data sovereignty and enterprise-grade compliance. If you are looking for documentation on GLBNXT Workspace, visit the Workspace documentation. ### Key Principles **Sovereign by design.** All compute runs within the EU. There are no dependencies on US hyperscaler infrastructure, with full data residency guarantees for every deployment. **Open, not locked in.** The platform is built on open-source technologies and open standards. No proprietary layers, no black-box components, and no lock-in to a single vendor or model provider. **Managed, not DIY.** GLBNXT handles every operational concern so your team does not have to. Infrastructure, security, compliance, and orchestration are platform responsibilities, not yours. **Built for builders.** Every capability on the platform is designed to reduce time-to-value for development teams. From prototype to production in days, not months. # How GLBNXT Platform works GLBNXT Platform operates on a simple principle: GLBNXT manages the infrastructure, and your team builds the solutions. Every capability on the platform is designed around this division, so development teams never have to context-switch between building AI products and maintaining the stack that runs them. ### The Two-Layer Model The platform is structured around two distinct layers that work together seamlessly. #### Managed Platform Layer The Managed Platform Layer is everything GLBNXT operates on your behalf. It forms the complete enterprise-grade foundation that your AI solutions run on, handling every operational concern that would otherwise fall to your DevOps and infrastructure teams. This layer includes: * **Compute** - GPU and CPU resources provisioned and scaled on demand, optimised for AI inference and training workloads * **Kubernetes orchestration** - containerised workloads managed, scheduled, and scaled automatically across your environment * **Networking and security** - isolated network environments, firewall rules, ingress controls, and secure communication between services * **Secrets and credential vault** - credentials, API keys, and sensitive configuration managed securely and injected into applications at runtime * **Storage and backups** - persistent storage, object storage, and automated backup policies across all data services * **Observability and monitoring** - infrastructure metrics, health checks, alerting, and performance visibility across the full stack * **Compliance and audit trails** - complete logs of platform activity, query history, and data access events to support regulatory requirements * **Model routing** - intelligent routing of inference requests to the appropriate models and compute resources based on configuration #### Solution Layer The Solution Layer is where your development team works. With the managed foundation in place, engineers, data scientists, and architects have direct access to every component needed to design, build, and deploy production-grade AI applications. This layer includes: * **Vector databases** - for semantic search, retrieval-augmented generation, and embedding storage * **RAG pipelines** - end-to-end retrieval and generation workflows connected to your data sources * **Agents and memory** - multi-agent systems with persistent memory, tool use, and reasoning capabilities * **Workflows and triggers** - automated processes connecting AI models, APIs, data sources, and external services * **Functions and APIs** - exposing AI capabilities as programmable endpoints for downstream applications * **Webchat components** - configurable chat interfaces and assistant frontends for end users * **User-facing applications** - complete AI-powered products deployed and hosted within the platform environment ### From Prototype to Production GLBNXT Platform is designed to compress the time between an idea and a working production deployment. Because the infrastructure is already in place, teams can move directly from designing a solution to building it, without waiting on environment setup, security reviews, or DevOps provisioning cycles. A typical journey on the platform looks like this: 1. **Access your environment** - your platform environment is provisioned and ready from day one, with models, databases, and services available immediately 2. **Select your approach** - choose a low-code path using visual builders and pre-built templates, or a full-code path using direct APIs and custom logic, or combine both within the same project 3. **Build your solution** - connect models, data sources, workflows, and interfaces using the platform components available in your stack 4. **Deploy and monitor** - publish your application within the platform environment, with observability, audit logging, and scaling handled automatically ### Low-Code and Full-Code Flexibility GLBNXT Platform supports teams working at different levels of technical depth, and allows both approaches to coexist within the same environment. **Low-code** approaches are suited for teams that want to move fast using visual builders, workflow automation, and pre-built solution templates. This path is particularly effective for agencies and consultancies delivering AI solutions to clients without requiring deep ML expertise on every project. **Full-code** approaches give engineers direct access to platform APIs, model endpoints, database connections, and infrastructure primitives. This path supports custom logic, complex architectures, and integrations that require precise control. Most production environments on GLBNXT Platform use a combination of both, applying the right tool to each part of the solution. ### Open-Source at the Core Every component in the GLBNXT Platform stack is built on open-source technology. GLBNXT takes the world's best open tools, makes them enterprise-ready, and delivers them as a cohesive managed platform. There are no proprietary formats, no hidden layers, and no lock-in to GLBNXT as a vendor. If your organisation ever needs to take a component in a different direction, the underlying technology remains fully accessible and portable. # Platform versus Workspace GLBNXT offers two distinct products that serve different audiences and purposes within an organisation. While both are built on the same commitment to European data sovereignty and enterprise-grade security, they are designed for fundamentally different use cases and user profiles. Understanding the distinction helps teams identify which product they are working with, where to find the right documentation, and how the two products can complement each other within the same organisation. ### GLBNXT Platform GLBNXT Platform is built for development teams. It provides the complete AI infrastructure stack that engineers, data scientists, and architects need to design, build, and deploy AI-powered applications and services. Platform users are builders. They work with model endpoints, vector databases, workflow automation, APIs, and application components to create AI solutions for their organisation or for clients. The platform gives them a managed, sovereign environment where all infrastructure concerns are handled by GLBNXT, and all building capabilities are available from day one. **Typical Platform users include:** * ML Engineers and Data Scientists building inference pipelines and AI-powered services * Data Engineers designing RAG systems and managing data pipelines * DevOps and IT Architects configuring environments, access controls, and security posture * Product Leaders and CTOs overseeing AI solution delivery and platform governance ### GLBNXT Workspace GLBNXT Workspace is built for knowledge workers and business teams. It provides a governed, compliant AI environment for employees who use AI to do their work, without needing to understand or interact with the infrastructure behind it. Workspace users are consumers of AI capability. They work with AI assistants, document analysis tools, knowledge search, and productivity features within a secure, policy-controlled environment. Workspace abstracts away all technical complexity so that business users can benefit from AI without requiring any technical background. **Typical Workspace users include:** * Business analysts and consultants working with documents and data * Legal, compliance, and finance teams using AI for research and review * Operations and HR teams automating routine knowledge work * Any employee using AI tools within a governed enterprise environment ### Choosing the Right Product The two products are not mutually exclusive. Many organisations use both: development teams build AI solutions and services on Platform, while business teams consume AI capabilities through Workspace. In this model, Platform is where solutions are created and Workspace is where they are used. | | GLBNXT Platform | GLBNXT Workspace | | ---------------------------- | ------------------------------------------- | -------------------------------------------------- | | **Primary audience** | Development teams | Knowledge workers | | **Primary activity** | Building AI solutions | Using AI capabilities | | **Technical depth required** | Medium to high | None | | **Key capabilities** | Model serving, RAG, agents, workflows, APIs | AI assistants, document analysis, knowledge search | | **Governance model** | Infrastructure and deployment controls | Usage policies and data access controls | | **Deployment** | Managed infrastructure environment | Managed workspace environment | ### Where to Go From Here If you are a developer, data scientist, or architect building AI solutions, you are in the right place. Continue with the Getting Started section to begin working with GLBNXT Platform. If you are a business user or knowledge worker looking to use AI within a governed environment, visit the GLBNXT Workspace documentation. # Who this documentation is for This documentation is written for the development teams that build on GLBNXT Platform. It covers platform architecture, solution building, security and compliance, model management, and day-to-day operations for engineers and technical leaders working within a GLBNXT Platform environment. Whether you are onboarding for the first time, building your first production AI application, or configuring enterprise-wide governance controls, this documentation is designed to help you move quickly and work with confidence. ### Roles and Personas GLBNXT Platform serves multiple roles within a development organisation. The documentation is structured to be useful across all of them, with relevant sections highlighted below for each profile. #### ML Engineers and Data Scientists You work with models, inference pipelines, and AI-powered services. GLBNXT Platform gives you immediate access to GPU compute, managed model endpoints, and evaluation tooling without waiting on infrastructure provisioning. The sections most relevant to you cover the Model Hub, Building AI Solutions, and Observability and Monitoring. #### Data Engineers You design and manage the data layer that AI solutions depend on. This includes RAG pipelines, vector database configuration, embedding workflows, and integration with enterprise data sources. The sections most relevant to you cover RAG and Knowledge Systems, Storage and the Data Layer, and Integration Patterns. #### DevOps and IT Architects You are responsible for the security posture, environment configuration, access controls, and operational governance of the platform. GLBNXT manages the infrastructure layer, but you define how teams access it and how it is governed within your organisation. The sections most relevant to you cover Security and Compliance, Access Control and Identity, Environment Management, and the Shared Responsibility Model. #### Product Leaders and CTOs You are evaluating the platform's capabilities, assessing its compliance profile, or overseeing AI solution delivery across your organisation or client base. You need a clear picture of what GLBNXT handles, what your team is responsible for, and how the platform supports your strategic objectives. The sections most relevant to you cover the Introduction, Platform Architecture, Security and Compliance, and the FAQ. ### What This Documentation Does Not Cover This documentation focuses on GLBNXT Platform. It does not cover GLBNXT Workspace, which has its own dedicated documentation for business users and knowledge workers. For advanced configuration and deep technical reference on specific open-source components integrated within the platform, this documentation provides context and guidance relevant to the GLBNXT environment and links out to official upstream documentation where appropriate. If you are unsure whether you are in the right place, visit the Platform vs. Workspace section for a clear overview of both products. # Onboarding overview Getting started on GLBNXT Platform is designed to be fast and low-friction. Because GLBNXT manages the infrastructure layer, there is no environment setup, no infrastructure provisioning, and no DevOps preparation required before your team can begin building. Your platform environment is ready from day one. This section walks you through what to expect during onboarding, what GLBNXT prepares for you, and what your team needs to do to get up and running quickly. ### What Happens Before You Log In Once your organisation signs up for GLBNXT Platform, the GLBNXT team provisions your dedicated environment. This includes configuring your compute resources, deploying the core platform services, setting up your isolated network environment, applying your agreed security and access controls, and validating that all components are operational before handover. You will receive access credentials, a link to your platform environment, and an onboarding summary that confirms which services and models are available in your deployment. ### Your First 30 Days Onboarding is structured around three phases that progressively move your team from access to productive development. #### Phase 1: Access and Orientation (Days 1 to 7) The first week is about getting your team oriented within the platform environment. Key activities during this phase include: * Logging in and navigating the platform console * Confirming user access and role assignments for your team * Reviewing the services, models, and components available in your environment * Connecting your identity provider if SSO integration is part of your configuration * Completing a first walkthrough of the platform with your GLBNXT onboarding contact By the end of the first week, every team member should be able to log in, understand what is available, and know where to find what they need. #### Phase 2: First Build (Days 8 to 21) The second phase focuses on getting your first AI application or workflow running in the platform. The goal is not a production deployment at this stage, but a working proof of concept that demonstrates the full stack end-to-end. Key activities during this phase include: * Connecting to a model endpoint and running your first inference request * Setting up a vector database and indexing a test dataset * Building a basic RAG pipeline or workflow using the tools available in your environment * Reviewing observability outputs and audit logs generated by your activity * Identifying any additional configuration or tooling your specific use case requires GLBNXT provides solution templates and pre-built patterns to accelerate this phase. Your onboarding contact is available to support technical questions and environment-specific configuration during this period. #### Phase 3: Production Readiness (Days 22 to 30) The final phase prepares your team and your first solution for production. Key activities during this phase include: * Reviewing access control and permission configuration for your deployment * Confirming compliance requirements are met and audit logging is correctly configured * Conducting a lightweight architecture review of your first solution with your GLBNXT contact * Establishing your team's internal processes for ongoing development, deployment, and monitoring on the platform Most teams are ready to deploy their first production workload by the end of the 30-day onboarding period. ### What You Need to Prepare GLBNXT handles the infrastructure, but there are a small number of things your team should have ready before or during onboarding: * **Team access list:** the names, roles, and email addresses of team members who need platform access * **Identity provider details:** if your organisation uses SSO, your identity provider configuration for SAML or OAuth integration * **Use case brief:** a short description of the first solution you plan to build, so your onboarding contact can confirm the right components and models are available in your environment * **Compliance requirements:** any specific regulatory, data handling, or audit requirements your organisation needs the platform to support from day one ### Getting Support During Onboarding Every GLBNXT Platform onboarding includes a dedicated onboarding contact who supports your team through the first 30 days. They are your first point of contact for environment questions, configuration guidance, and technical support during the onboarding period. After onboarding, ongoing support is available through the GLBNXT support channels described in the Support and Escalation section of this documentation. # Accessing your platform environment Once your GLBNXT Platform environment has been provisioned, your team can access it immediately through the platform console. This section covers how to log in, how to navigate the environment, and what you can expect to find when you first arrive. ### Logging In GLBNXT Platform is accessed via the platform console at platform.glbnxt.com. Depending on the configuration agreed during onboarding, you will log in using one of the following methods: * **SSO via your identity provider:** if your organisation uses Azure AD, Okta, or Google Workspace, login is handled through your existing identity provider. Your credentials are the same ones you use across your organisation's other tools and services. * **Direct login:** if SSO has not been configured for your environment, you will log in using the credentials provided to you during onboarding. It is recommended to update your password on first login and to enable multi-factor authentication immediately. If you are unable to log in or have not received your credentials, contact your GLBNXT onboarding contact or reach out via the support channels described in the Support and Escalation section. ### Navigating the Console The platform console is your central access point for all services, tools, and administrative functions available in your environment. When you log in for the first time, you will see an overview of the components and services that have been deployed for your organisation. The console is organised around the following areas: * **Applications:** the AI tools, interfaces, and services deployed within your environment, including chat frontends, workflow builders, and any pre-configured solutions * **Model Hub:** the models available for inference in your environment, including open-source models and any custom or fine-tuned models deployed for your organisation * **Data Services:** your vector databases, object storage, and relational database instances * **Monitoring and Observability:** dashboards and logs covering platform health, model usage, and audit activity * **Settings and Administration:** user management, access controls, identity provider configuration, and environment-level settings Not all areas of the console are visible to every user. What you see depends on the role assigned to your account. Administrators have full visibility across all areas, while developers and standard users see the components relevant to their work. ### User Roles and Permissions GLBNXT Platform uses role-based access control to manage what each user can see and do within the environment. Roles are assigned during onboarding based on the access list provided by your organisation. Common roles include: * **Administrator:** full access to all platform components, user management, and environment configuration * **Developer:** access to applications, model endpoints, data services, and development tools, without administrative controls * **Viewer:** read-only access to selected components and dashboards, suited for stakeholders who need visibility without making changes Role assignments can be updated at any time by your platform administrator. For guidance on managing users and permissions, see the Team and User Management section. ### Multi-Factor Authentication Multi-factor authentication is strongly recommended for all platform users and is enforced by default for administrator accounts. If your organisation uses SSO, MFA is handled by your identity provider. If you are using direct login, MFA can be enabled within your account settings in the platform console. ### First Steps After Logging In Once you have logged in and confirmed your access, the recommended first steps are: 1. Review the applications and services available in your environment and confirm they match your onboarding summary 2. Check that all team members who require access have been provisioned with the correct roles 3. Connect to a model endpoint and run a test inference request to confirm your environment is operational 4. Review your observability dashboard to confirm that logging and monitoring are active If anything in your environment does not match what was agreed during onboarding, contact your GLBNXT onboarding contact before proceeding with any development work. # Your first AI application Building your first AI application on GLBNXT Platform is designed to be straightforward. The infrastructure is already in place, models are available immediately, and the platform components needed to connect data, logic, and interfaces are ready to use from day one. This section walks you through the process of going from a blank canvas to a working AI application running in your platform environment. ### Before You Start Before building your first application, confirm the following: * You have logged in to the platform console and can access your environment * Your team roles and permissions have been assigned correctly * You know which models are available in your Model Hub * You have a clear idea of the type of application you want to build If you are unsure which application type fits your use case, the Solution Architecture Patterns section provides an overview of the three flagship categories available on the platform: AI Assistants and Chat Interfaces, RAG and Knowledge Systems, and Multi-Agent Workflows and Automation. ### Choosing Your Approach GLBNXT Platform supports both low-code and full-code development paths. Before you start building, it is worth deciding which approach is right for your team and your use case. **Low-code** is the fastest path to a working application. It uses visual builders, pre-built templates, and drag-and-drop configuration to connect models, data sources, and interfaces without writing significant amounts of code. This approach is well suited for teams who want to demonstrate value quickly or who are building solutions that follow established patterns. **Full-code** gives engineers direct access to model APIs, database connections, and platform primitives. It is suited for custom architectures, complex integrations, or solutions that require precise control over logic and data flow. Both paths are available within the same platform environment, and most production applications combine elements of both. Start with the approach that matches your team's strengths and the complexity of your first use case. ### Building a Simple AI Assistant The quickest way to understand how the platform works end-to-end is to build a simple AI assistant. The following steps guide you through connecting a model, configuring a chat interface, and running your first conversation. #### Step 1: Select a Model Navigate to the Model Hub in your platform console. You will see a list of models available in your environment. Select a model appropriate for conversational use. If you are unsure which model to choose, your GLBNXT onboarding contact can advise based on your specific requirements. Note the model endpoint URL displayed in the model details. You will need this in the next step. #### Step 2: Configure a Chat Interface Navigate to the Applications area of the console. Depending on your environment configuration, you will have access to a hosted chat interface that can be connected to any model available in your Model Hub. Open the configuration settings for the chat interface and set the model endpoint to the URL you noted in Step 1. Set a system prompt that defines the assistant's behaviour and scope. Save your configuration. #### Step 3: Test Your Application Launch the chat interface from the Applications area. Send a test message and confirm that the model responds correctly. Review the response quality against your system prompt configuration and adjust as needed. Once you are satisfied with the behaviour, your first AI application is running. #### Step 4: Review Your Observability Output Navigate to the Monitoring and Observability area of the console. You should see logs and usage data generated by the test conversation you just ran. Confirm that logging is active and that your interactions are being captured in the audit trail. This is an important step before any production deployment. GLBNXT Platform captures a complete record of model interactions, and confirming this is working correctly from the start ensures your compliance posture is in place from day one. ### Going Further A simple chat assistant is the starting point, not the end goal. From here, your team can extend the application in several directions depending on your use case: * **Add a knowledge base:** connect a vector database and a document ingestion pipeline to give your assistant access to your organisation's own data through RAG * **Add workflow automation:** connect your assistant to external systems, APIs, and data sources using workflow automation tools available in your environment * **Build a multi-agent system:** extend your application with additional agents that handle specific tasks, reason over tools, and collaborate to complete complex processes Each of these directions is covered in detail in the Building AI Solutions section of this documentation. ### Getting Help If you encounter issues during your first build, your GLBNXT onboarding contact is your first point of support during the onboarding period. For questions about specific platform components, refer to the relevant sections of this documentation. For issues with the environment itself, use the support channels described in the Support and Escalation section. # Low-code vs. Full-code GLBNXT Platform is built to support development teams working at different levels of technical depth. Whether your team prefers visual builders and pre-built templates or direct API access and custom code, the platform accommodates both approaches within the same environment. You are not required to choose one path and stay on it. Most production solutions on GLBNXT Platform combine elements of both. This section explains what each approach covers, when to use each one, and how to decide which is right for your team and your use case. ### The Low-Code Path The low-code path is designed for teams who want to move fast, reduce development overhead, and deliver working AI solutions without requiring deep engineering effort at every layer of the stack. Low-code development on GLBNXT Platform is built around visual builders, workflow automation tools, and pre-configured solution templates. Teams can connect models, data sources, APIs, and interfaces through configuration rather than code, dramatically reducing the time from idea to working application. **Low-code is well suited for:** * Agencies and consultancies delivering AI solutions to clients across multiple industries * Teams building solutions that follow established patterns such as AI assistants, document Q\&A, or automated reporting * Proof of concept and prototype development where speed to demonstration matters * Business-facing applications where the logic is straightforward and the primary value is in the AI capability itself * Teams with strong domain expertise but limited ML or backend engineering resources **What the low-code path gives you:** * Visual workflow builders for connecting models, triggers, APIs, and data sources without writing custom integration code * Pre-built solution templates for common use cases that can be configured and deployed in hours rather than days * Hosted chat interface configuration for deploying AI assistants with drag-and-drop setup * Managed connectors to external services and data sources that require no custom development to activate ### The Full-Code Path The full-code path is designed for engineers who need precise control over every layer of their application. It provides direct access to model APIs, database connections, platform primitives, and infrastructure configuration, giving development teams the flexibility to build exactly what their use case requires. **Full-code is well suited for:** * Solutions with complex or non-standard architectures that do not map to pre-built templates * Integrations with existing enterprise systems, proprietary APIs, or legacy data sources that require custom logic * High-performance applications where fine-grained control over inference, retrieval, or data processing is necessary * Teams with strong engineering capability who prefer working directly with APIs and code * Production systems where every component needs to be precisely specified and version-controlled **What the full-code path gives you:** * Direct access to model endpoints via standard APIs compatible with common AI development frameworks * Native database connections to vector stores, relational databases, and object storage * Full control over RAG pipeline construction, agent logic, memory management, and tool integration * Programmable workflow triggers and function endpoints that can be called from any external system * Access to platform observability data and audit logs via API for integration into existing monitoring tooling ### Combining Both Approaches The most effective solutions on GLBNXT Platform often use both paths together. A common pattern is to use full-code for the core AI logic, such as a custom RAG pipeline or a multi-agent reasoning layer, and low-code for the surrounding automation, such as triggering workflows, routing outputs, or delivering results to end users through a configured interface. There is no architectural boundary between the two approaches within the platform. Components built through visual builders and components built through code operate on the same underlying infrastructure and can be connected, combined, and extended freely. ### Choosing Your Starting Point If you are new to GLBNXT Platform, starting with the low-code path is recommended regardless of your team's technical depth. The low-code tools give you a fast end-to-end view of how the platform components connect, and they make it easy to validate your use case before investing in a custom architecture. From there, you can progressively replace or extend low-code components with custom code as your requirements demand. Most teams find that some parts of their solution benefit from staying in the low-code layer long-term, while others naturally evolve toward full-code implementations as complexity grows. The decision does not need to be made upfront. GLBNXT Platform is designed to let you start fast and scale with precision. # Managed infrastructure layer The Managed Infrastructure Layer is the foundation that every solution built on GLBNXT Platform runs on. It encompasses all compute, networking, orchestration, storage, security, and compliance capabilities that GLBNXT operates on your behalf. Your development team never needs to provision, configure, or maintain any part of this layer. GLBNXT handles it entirely so your engineers can focus on building AI products rather than managing the infrastructure beneath them. This section explains what the Managed Infrastructure Layer includes, how each component works, and what it means for your team in practice. ### Compute GLBNXT Platform provides on-demand GPU and CPU compute resources optimised for AI workloads. GPU resources are available immediately for inference, fine-tuning, and training tasks without any provisioning delay. CPU resources handle supporting services, orchestration workloads, and non-GPU compute tasks across the environment. Compute resources are scaled automatically based on workload demand. Your team does not need to manage resource allocation, scaling policies, or capacity planning. GLBNXT monitors compute usage continuously and ensures that resources are available when your applications need them. ### Kubernetes Orchestration All workloads on GLBNXT Platform run on a managed Kubernetes environment. Container scheduling, deployment management, scaling, health monitoring, and failover are handled automatically at the orchestration layer. Your team deploys applications and services without needing to interact with Kubernetes directly unless you choose to. The orchestration layer ensures that every component in your stack runs reliably, recovers automatically from failures, and scales in response to load without manual intervention. GLBNXT manages the Kubernetes control plane, node health, and cluster configuration as part of the platform service. ### Networking and Security Your platform environment runs within an isolated network boundary. All internal service communication is encrypted, and external access is controlled through managed ingress points with configurable rules. GLBNXT configures and maintains firewall policies, network segmentation, and traffic routing for your environment. Network isolation ensures that your workloads are separated from other platform tenants at the infrastructure level. Outbound connectivity to approved external services is available and configurable, while all inbound access is controlled and audited. ### Secrets and Credential Vault All credentials, API keys, tokens, and sensitive configuration values are managed through the platform's built-in secrets vault. Secrets are never stored in code, configuration files, or environment variables that are accessible to application developers. Instead, they are injected securely into application workloads at runtime by the platform. This approach eliminates a common source of security incidents in AI development environments, where credentials for model APIs, databases, and external services are frequently handled insecurely. On GLBNXT Platform, credential management is a platform responsibility rather than a developer responsibility. ### Storage and Backups GLBNXT Platform provides multiple storage types to support the data needs of AI applications. Object storage is available for large unstructured data such as documents, media files, and model artefacts. Relational database storage supports structured data and application state. Vector storage is provisioned alongside the vector database services available in your environment. All data stored on the platform is backed up automatically according to the backup policies configured for your environment. Backup frequency, retention periods, and recovery procedures are defined at the platform level. Your team does not need to manage backup infrastructure or monitor backup health. ### Observability and Monitoring GLBNXT Platform provides full-stack observability across all infrastructure components and application workloads in your environment. Infrastructure metrics, application health, model usage, and performance data are collected continuously and made available through the monitoring dashboards in your platform console. Alerting is configured at the platform level to detect and respond to infrastructure issues before they affect your applications. GLBNXT monitors the health of every component in the stack and manages incident response for infrastructure-level events. Your team receives visibility into platform health without carrying the operational burden of managing the monitoring infrastructure itself. ### Compliance and Audit Trails Every action taken within the platform environment is logged. This includes user access events, API calls, model inference requests, data access operations, and administrative changes. Audit logs are immutable, timestamped, and retained according to the compliance requirements agreed for your environment. Audit data is available through the Monitoring and Observability area of the platform console and can be exported for integration with your organisation's existing compliance and SIEM tooling. GLBNXT maintains the audit infrastructure and ensures that log completeness and integrity are preserved at all times. ### Model Routing Model routing manages how inference requests are directed to the appropriate model and compute resources within your environment. When your application makes an inference request, the routing layer handles model selection, load balancing across available compute, and failover if a serving instance becomes unavailable. Model routing is transparent to application developers. Your application calls a model endpoint and the routing layer handles everything behind it. As your environment grows and more models are added, routing configuration can be updated centrally without changes to your application code. ### What This Means for Your Team The Managed Infrastructure Layer means that your development team starts every project on a fully operational, enterprise-grade foundation. There are no infrastructure tickets to raise before beginning development, no waiting periods for environment provisioning, and no ongoing operational work required to keep the platform running. The practical outcome is that engineering effort on GLBNXT Platform goes almost entirely into building AI solutions. The infrastructure concerns that typically consume significant DevOps and platform engineering time are a platform responsibility, not a team responsibility. Your engineers build. GLBNXT operates. # Model serving & routing Model serving and routing is the layer of GLBNXT Platform that makes AI models accessible to your applications. It handles everything between an inference request leaving your application and a response being returned: model loading, compute allocation, request routing, load balancing, and failover. Your development team interacts with a clean, stable model endpoint. The platform manages everything behind it. This section explains how model serving works on GLBNXT Platform, how routing is configured, and what your team needs to understand to work effectively with models in your environment. ### How Model Serving Works Every model available in your environment is served through a managed inference layer. When a model is made available in your Model Hub, GLBNXT handles the deployment of that model onto the appropriate compute resources, the configuration of the serving runtime, and the exposure of a stable API endpoint that your applications can call. Model serving on GLBNXT Platform is built on open-source inference runtimes. Depending on the model type and the performance requirements of your use case, models are served through Ollama for open-source language models or NVIDIA NIM for production inference workloads that require optimised throughput and latency. Both are managed entirely at the platform level. Your application does not need to know which serving runtime is being used. It calls an endpoint, and the platform returns a response. ### Model Endpoints Each model available in your environment is accessible via a dedicated API endpoint. Endpoints follow a consistent format and are compatible with standard AI development frameworks and tooling, meaning that code written to call a GLBNXT-hosted model can be migrated or adapted with minimal changes if your requirements evolve. Endpoints are listed in the Model Hub area of your platform console, along with the model name, version, and any relevant configuration details. Access to individual endpoints is governed by the role-based access controls configured for your environment. ### Model Routing Model routing manages how inference requests are directed across available compute resources and model instances. When your application sends a request to a model endpoint, the routing layer handles the following automatically: * **Load balancing:** requests are distributed across available model instances to ensure consistent response times under load * **Failover:** if a model instance becomes unavailable, requests are automatically redirected to a healthy instance without interruption to your application * **Resource allocation:** inference requests are matched to the appropriate compute resources based on model requirements and available capacity * **Priority handling:** in environments with multiple teams or applications sharing compute, routing can be configured to apply priority rules that ensure critical workloads receive resources first Routing configuration is managed centrally by GLBNXT and can be updated as your environment grows or your workload requirements change. Application code does not need to be updated when routing configuration changes. ### Ollama for Open-Source Models Ollama is the primary serving runtime for open-source language models on GLBNXT Platform. It supports a wide range of models from the open-source ecosystem and makes them available through a consistent API interface. Models served through Ollama can be used for conversational applications, document analysis, code generation, summarisation, and any other language task your use case requires. GLBNXT manages Ollama deployment, model loading, and version management. When a new model version is available or a model update is required, GLBNXT handles the update without requiring changes to your application configuration. ### NVIDIA NIM for Production Inference For workloads that require optimised inference performance, GLBNXT Platform includes support for NVIDIA NIM. NIM provides hardware-optimised model serving on NVIDIA GPU infrastructure, delivering lower latency and higher throughput than standard serving runtimes for demanding production workloads. NIM is suited for use cases where response time is critical, such as real-time user-facing applications, high-volume API services, or workloads processing large numbers of concurrent requests. Your GLBNXT contact can advise on when NIM is the appropriate serving configuration for your specific requirements. ### Adding and Updating Models The models available in your environment are configured during onboarding based on your use case requirements. If your team needs access to additional models or wants to update a model to a newer version, this is managed through a request to your GLBNXT contact. GLBNXT validates, deploys, and tests new models before making them available in your Model Hub, ensuring that every model endpoint your team works with is stable and correctly configured. Custom or fine-tuned models developed by your team can also be deployed into the serving layer. See the Model Hub section for further guidance on custom model deployment. ### What Your Team Needs to Know For most development work on GLBNXT Platform, model serving and routing operates transparently in the background. Your team works with model endpoints in the same way it would work with any API, without needing to understand the infrastructure behind them. The key points to keep in mind are: * Model endpoints are stable and consistent. Routing and failover changes do not affect endpoint addresses or API behaviour. * Access to model endpoints is governed by role-based access controls. If your team cannot access a model it expects to see, check role assignments with your platform administrator. * Performance characteristics of a given model may vary based on current compute load. If your use case has strict latency requirements, discuss serving configuration options with your GLBNXT contact during onboarding. * All inference requests are logged by the platform. Model usage is visible in the Monitoring and Observability area of the console and forms part of your environment's audit trail. # Storage & data layer The storage and data layer on GLBNXT Platform provides every data service your AI applications need, managed and operated by GLBNXT as part of the platform foundation. Relational databases, object storage, and vector databases are all provisioned within your environment, configured to work together, and maintained without any operational overhead falling to your development team. This section explains what storage services are available, when to use each one, and how they integrate with the AI applications and pipelines your team builds on the platform. ### Storage Services Overview GLBNXT Platform provides three categories of storage, each serving a distinct role in AI application architectures. **Relational database storage** handles structured data, application state, user data, and transactional workloads. Postgres is the relational database available on the platform, suitable for any use case that requires structured querying, relational data models, or ACID-compliant transactions. **Object storage** handles large volumes of unstructured data such as documents, images, audio files, model artefacts, and other binary content. MinIO provides S3-compatible object storage within your environment, giving your applications a familiar interface for storing and retrieving large files without any dependency on external cloud storage services. **Vector storage** handles high-dimensional embeddings used for semantic search, retrieval-augmented generation, and similarity matching. GLBNXT Platform supports Postgres, Weaviate and Qdrant as vector database options, with the appropriate choice configured for your environment based on your use case requirements. All three categories of storage run entirely within your platform environment, within EU infrastructure, and with no data leaving your sovereign boundary. ### Postgres Postgres is the relational database service available on GLBNXT Platform. It is suited for structured data that requires querying with SQL, relational modelling, or transactional consistency. Common uses in AI application architectures include storing user profiles and conversation history, managing application configuration and metadata, logging structured outputs from AI workflows, and maintaining reference data that models or agents query at runtime. GLBNXT manages Postgres provisioning, configuration, patching, and backup. Your team connects to Postgres using standard database connection libraries and tools. Connection credentials are managed through the platform secrets vault and injected into your applications securely at runtime. ### MinIO MinIO provides S3-compatible object storage within your GLBNXT Platform environment. It is designed for storing and retrieving large unstructured files and is the primary storage layer for document ingestion pipelines, RAG systems, and any application that works with file-based content. Common uses include storing source documents before and after ingestion into a RAG pipeline, holding model artefacts and fine-tuned weights, archiving conversation logs and output files, and staging data between workflow steps. Because MinIO uses the S3 API, any tool or library that works with S3 will work with MinIO on GLBNXT Platform without modification. GLBNXT manages MinIO provisioning, access controls, and storage policies. Bucket configuration and access permissions for individual applications are managed through the platform console or via the MinIO API depending on your team's preferred approach. ### Vector Databases Vector databases are a core component of AI applications that involve semantic search, document retrieval, or retrieval-augmented generation. They store embeddings, which are numerical representations of text, images, or other content, and enable fast similarity search across large datasets that relational databases are not designed to handle efficiently. GLBNXT Platform supports multiple vector database options: Postgres, Weaviate and Qdrant (and others). Both are available within your platform environment. The choice between them is typically made during onboarding based on your specific use case requirements, and your GLBNXT contact can advise on which is the better fit for your architecture. #### Weaviate Weaviate is a vector database well suited to use cases that require rich semantic search capabilities, multi-modal data handling, and tight integration with AI models for automatic vectorisation at ingestion time. It supports hybrid search combining vector similarity with structured filtering, making it a strong choice for knowledge bases and document retrieval systems that need to combine semantic and keyword-based search. #### Qdrant Qdrant is a high-performance vector database optimised for speed and efficiency at scale. It is well suited to applications that process large volumes of embeddings and require low-latency retrieval under high query loads. Qdrant is a strong choice for production RAG pipelines and real-time AI applications where retrieval performance is a critical requirement. ### Elasticsearch For use cases that require full-text search, log analytics, or hybrid retrieval combining keyword and vector search, GLBNXT Platform includes Elasticsearch. Elasticsearch is particularly suited to applications that need to search across large document sets using both structured queries and full-text matching, and to observability use cases where log data needs to be indexed and queried efficiently. Elasticsearch on GLBNXT Platform is managed as part of the platform stack. Your team can connect to Elasticsearch for application-level search requirements without managing the underlying cluster, index configuration, or scaling. ### Backup and Data Retention All data stored on GLBNXT Platform is backed up automatically. Backup policies are configured at the platform level for each storage service and are aligned with the data retention requirements agreed for your environment during onboarding. GLBNXT monitors backup health and manages recovery procedures. Your team does not carry any operational responsibility for backup infrastructure. If your organisation has specific data retention or deletion requirements driven by GDPR or other regulatory obligations, these are implemented at the platform level and documented in your data processing agreement with GLBNXT. ### Data Sovereignty and Residency All storage services on GLBNXT Platform run within EU infrastructure. No data stored in Postgres, MinIO, Weaviate, Qdrant, or Elasticsearch leaves the European Union at any point. This applies equally to data at rest and data in transit between platform components. Data residency guarantees are documented in your GLBNXT service agreement and data processing agreement. If your organisation operates under specific data localisation requirements, your GLBNXT contact can confirm the exact infrastructure region used for your environment. ### Choosing the Right Storage for Your Use Case Different parts of an AI application typically require different storage types, and many production solutions on GLBNXT Platform use all three categories together. A common pattern for a RAG-based AI assistant would use MinIO to store source documents, Weaviate or Qdrant to store the embeddings generated from those documents, and Postgres to store conversation history, user data, and application metadata. If you are unsure which storage services are appropriate for your use case, the Building AI Solutions section covers common data architecture patterns for each solution category available on the platform. # Observability & monitoring Observability and monitoring on GLBNXT Platform gives your development team continuous visibility into the health, performance, and behaviour of your platform environment and the AI applications running within it. GLBNXT manages the monitoring infrastructure, collects data across the full stack, and ensures that your team always has the information needed to understand what is happening in the environment, identify issues early, and maintain confidence in production workloads. This section explains what is monitored, what visibility your team has, and how observability data supports both operational and compliance requirements. ### What Observability Covers Observability on GLBNXT Platform spans four interconnected layers, each providing a different view of the environment. **Infrastructure observability** covers the health and performance of the underlying compute, networking, storage, and orchestration components that GLBNXT manages. This includes CPU and GPU utilisation, memory consumption, disk usage, network throughput, and the operational status of Kubernetes workloads and platform services. **Application observability** covers the behaviour of the AI applications and services your team deploys on the platform. This includes request volumes, response times, error rates, and availability metrics for the endpoints and interfaces your applications expose. **Model observability** covers the performance and behaviour of AI models serving inference requests within your environment. This includes request latency, token throughput, model error rates, and usage patterns across the models available in your Model Hub. **Audit observability** covers the complete record of user activity, data access events, API calls, and administrative actions within your environment. Audit data is captured for compliance purposes and is kept separate from operational monitoring data to ensure its integrity. ### Infrastructure Monitoring GLBNXT monitors the infrastructure layer of your environment continuously. Compute health, storage availability, network performance, and Kubernetes cluster status are all observed in real time. Alerting is configured at the platform level to detect infrastructure anomalies and trigger remediation before they affect application availability. Your team has visibility into infrastructure metrics through the Monitoring and Observability area of the platform console. This gives you the context needed to understand whether application behaviour is driven by platform conditions or application logic, without requiring you to manage the monitoring infrastructure itself. Infrastructure incidents are managed by GLBNXT. When a platform-level issue is detected, GLBNXT's operational team responds directly. Your team is notified of incidents that affect your environment through the support and communication channels agreed during onboarding. ### Model Performance Monitoring Model observability is particularly important in production AI environments where inference quality, latency, and throughput directly affect the end user experience. GLBNXT Platform captures detailed metrics for every model serving inference requests in your environment. Key model metrics available through the platform console include: * Inference request volume over time * Average and percentile response latency * Token input and output volumes * Error rates and timeout frequencies * Compute utilisation per model instance These metrics allow your team to understand how models are performing under real usage conditions, identify models that may need configuration adjustments, and plan for capacity as your application usage grows. ### LLM Tracing and Evaluation Beyond infrastructure and model metrics, GLBNXT Platform supports deep observability into the behaviour of AI workflows and language model chains through integration with LLM tracing tools available in your environment. These tools capture the full trace of an AI workflow execution, including each step in a chain, the inputs and outputs at every stage, latency at each step, and the final output delivered to the application. LLM tracing is particularly valuable for debugging complex RAG pipelines, multi-agent workflows, and any AI application where intermediate steps affect the quality of the final output. Traces give your team the ability to inspect exactly what happened inside a workflow execution, identify where quality or performance issues originate, and iterate with precision. Evaluation capabilities allow your team to measure model and pipeline quality systematically, running assessments against defined criteria and tracking quality metrics over time as models are updated or pipeline configurations change. ### Application Logs All application workloads running on GLBNXT Platform produce logs that are captured and made available through the observability layer. Application logs give your team visibility into the runtime behaviour of the services you deploy, including errors, warnings, and diagnostic output generated by your own application code. Logs are searchable and filterable through the platform console. For teams that need to integrate log data with existing monitoring or SIEM tooling, log export is available through the platform API. Your GLBNXT contact can advise on the appropriate integration pattern for your organisation's tooling. ### Audit Trails Audit trails on GLBNXT Platform provide a complete, immutable record of all significant events within your environment. Audit data includes user login and access events, model inference requests, data access operations, administrative changes to environment configuration, secrets vault access events, and API calls made by platform services and applications. Audit logs are timestamped, tamper-evident, and retained according to the compliance requirements agreed for your environment. They are available through the Monitoring and Observability area of the platform console and can be exported for integration with your organisation's compliance, audit, and reporting processes. For organisations subject to GDPR, ISO 27001, NIS2, or sector-specific regulatory requirements, the audit trail provides the evidence base needed to demonstrate that data access and processing activities comply with applicable obligations. See the Compliance Frameworks section for further guidance on how audit data supports your compliance posture. ### Alerting and Incident Notification GLBNXT configures alerting across the platform stack to detect and respond to conditions that could affect your environment. Alerts are triggered by infrastructure health events, resource threshold breaches, service availability changes, and security-relevant events such as repeated authentication failures. Infrastructure-level alerts are handled directly by GLBNXT's operational team. Where an alert has potential impact on your applications or your team's work, GLBNXT communicates through the incident notification channels agreed during onboarding. Your team can configure application-level alerting for conditions relevant to your specific workloads through the platform console. If your organisation requires integration with an existing alerting or incident management platform, your GLBNXT contact can advise on available integration options. ### What Your Team Can See All observability data relevant to your environment and your applications is accessible to your team through the Monitoring and Observability area of the platform console. What individual users can see is governed by the role-based access controls configured for your environment. Developers typically have access to application and model metrics relevant to their work, while administrators have full visibility across infrastructure, audit, and security monitoring data. If your team needs additional observability capabilities or custom dashboards for specific workloads, discuss your requirements with your GLBNXT contact. The platform observability layer is designed to be extensible and can be configured to surface the data that matters most for your specific use cases. # Architecture patterns GLBNXT Platform is designed to support a wide range of AI application architectures. Rather than prescribing a single way to build, the platform provides the components and managed services that underpin every common AI solution pattern, and gives your team the flexibility to apply them in the way that best fits your use case. This section introduces the three flagship solution categories available on the platform, describes the architectural patterns that underpin each one, and helps your team identify the right starting point for the solution you are building. ### The Three Solution Categories Every AI application built on GLBNXT Platform falls into one or more of the following categories. Understanding which category your use case belongs to shapes the architecture decisions, component choices, and development approach you should take. #### AI Assistants and Chat Interfaces AI assistants are conversational applications that give users access to AI capabilities through a natural language interface. They range from simple single-turn question and answer tools to sophisticated multi-turn agents that can reason, retrieve information, use tools, and maintain context across a conversation. Common use cases in this category include internal knowledge assistants, customer support automation, compliance and legal Q\&A tools, and sector-specific assistants for public sector, healthcare, and financial services organisations. The core architectural pattern for this category involves a language model connected to a managed chat interface, with optional extensions for knowledge retrieval, tool use, and memory. The complexity of the architecture scales with the capabilities the assistant needs to deliver. #### RAG and Knowledge Systems Retrieval-augmented generation systems give AI models access to your organisation's own data at inference time, enabling them to answer questions, analyse documents, and surface insights from information they were not trained on. RAG is the foundational pattern for any AI application that needs to work with proprietary, domain-specific, or frequently updated information. Common use cases in this category include contract review and analysis, financial document search, internal knowledge base search, policy analysis, and any application where the quality of the AI output depends on access to accurate, up-to-date organisational data. The core architectural pattern for this category involves a document ingestion pipeline that processes source content into embeddings stored in a vector database, a retrieval layer that identifies the most relevant content for a given query, and a language model that generates responses grounded in the retrieved context. #### Multi-Agent Workflows and Automation Multi-agent systems coordinate multiple AI models and automated processes to complete complex tasks that require reasoning, decision-making, and action across multiple steps. Unlike single-model applications, multi-agent architectures decompose complex problems into subtasks handled by specialised agents, with orchestration logic managing how agents interact and how outputs flow between them. Common use cases in this category include automated reporting and analytics, document routing and processing pipelines, case management workflows, and financial or technical analysis tasks that involve multiple stages of reasoning and data access. The core architectural pattern for this category involves an orchestration layer that manages agent coordination, individual agents equipped with specific tools and capabilities, workflow automation connecting agents to external systems and data sources, and memory and state management that allows agents to maintain context across a multi-step process. ### Architectural Building Blocks Regardless of which solution category your use case falls into, every AI application on GLBNXT Platform is built from a consistent set of architectural building blocks. Understanding these components and how they relate to each other is the foundation of effective solution design on the platform. #### Language Models The core reasoning and generation capability in any AI application. Models are served through the platform's managed inference layer and accessed via stable API endpoints. Your architecture connects models to the context, tools, and interfaces appropriate for your use case. #### Vector Databases The storage and retrieval layer for semantic search and RAG. Vector databases hold the embeddings that enable your application to find relevant information at query time. Weaviate and Qdrant are available in your environment depending on your configuration. #### Data Pipelines The processes that move information from source systems into a form your AI application can use. For RAG systems, this means document ingestion, chunking, embedding generation, and indexing. For workflow automation, this means connecting data sources, transforming outputs, and routing information between steps. #### Workflow Automation The orchestration layer that connects models, agents, data sources, APIs, and interfaces into coherent end-to-end processes. Workflow automation handles triggers, conditional logic, error handling, and the movement of data between components in a way that does not require custom integration code for every connection. #### Chat Interfaces and Frontends The user-facing layer of conversational and assistant applications. Chat interfaces connect to model endpoints and present AI capabilities to end users through a managed, configurable interface. For applications that require a custom frontend, the platform provides the API layer that custom interfaces connect to. #### APIs and Functions The programmable layer that exposes AI capabilities to downstream systems and external integrations. APIs and function endpoints allow your AI application to be called from other services, embedded in existing workflows, or consumed by client applications outside the platform environment. #### Memory and State The layer that enables AI applications to maintain context across multiple interactions or workflow steps. Memory can be implemented at the session level for conversational applications or at the process level for long-running agent workflows. ### Choosing the Right Pattern Most production AI applications on GLBNXT Platform combine elements from more than one solution category. A knowledge assistant, for example, is an AI assistant pattern extended with a RAG architecture to ground responses in organisational data. An automated reporting system might combine a RAG layer for data retrieval with a multi-agent workflow for analysis and output generation. When approaching a new use case, a useful starting point is to ask three questions: **Where does the knowledge come from?** If the application needs to work with your organisation's own data, a RAG layer is almost always part of the architecture. If the application relies entirely on the model's trained capabilities, a simpler assistant pattern may be sufficient. **How complex is the process?** If the task can be completed in a single model interaction, a straightforward assistant architecture is appropriate. If the task requires multiple steps, external tool use, or coordination between different capabilities, a multi-agent or workflow architecture is likely needed. **Who is the end user?** If the application is user-facing and conversational, the architecture needs a chat interface layer. If the application is process-facing and automated, the architecture needs workflow automation and API endpoints rather than a conversational frontend. The answers to these questions will point you toward the right combination of building blocks for your solution. The Building AI Solutions section of this documentation covers each solution category in detail, with guidance on component selection, data architecture, and implementation patterns for each use case type. # AI assistants & Chat interfaces AI assistants and chat interfaces are the most direct way to put AI capability in the hands of users. They provide a conversational layer through which users can ask questions, retrieve information, complete tasks, and interact with the knowledge and tools your organisation has made available. On GLBNXT Platform, assistants and chat interfaces are built on managed model endpoints, configurable frontend components, and optional extensions for retrieval, tool use, and memory that allow you to shape exactly what the assistant can do and what it has access to. This section covers the architectural patterns, platform components, and implementation guidance for building AI assistants and chat interfaces on GLBNXT Platform. ### What This Pattern Is For AI assistants and chat interfaces are the right architectural choice when the primary interaction model is conversational and the primary output is a response generated by a language model. This covers a broad range of use cases, from simple single-turn question and answer tools to sophisticated multi-turn agents that maintain context, retrieve information, and take action on behalf of the user. Common use cases in this category include: * Internal knowledge assistants that help employees find information, navigate policies, or get answers from organisational data * Compliance and legal Q\&A tools that provide guidance grounded in regulatory documents, internal policies, or legal reference material * Customer support automation that handles routine enquiries, escalates complex cases, and maintains conversation history across interactions * Tender analysis and procurement assistants that help teams review, compare, and summarise large volumes of structured documentation * Sector-specific assistants for public sector, healthcare, and financial services organisations operating under strict compliance requirements ### Core Architecture The foundational architecture for an AI assistant on GLBNXT Platform consists of three components working together: a language model, a system prompt, and a chat interface. This is the simplest working configuration and the recommended starting point for any assistant use case. The language model provides the reasoning and generation capability. The system prompt defines the assistant's role, scope, tone, and behavioural boundaries. The chat interface provides the conversational frontend through which users interact with the assistant. From this foundation, the architecture can be extended in several directions depending on what the assistant needs to do. ### Extending the Base Architecture #### Adding Knowledge Retrieval When your assistant needs to answer questions based on your organisation's own data rather than relying solely on the model's trained knowledge, a retrieval layer is added to the architecture. This connects the assistant to a vector database containing embeddings of your source documents, enabling the model to ground its responses in retrieved context at query time. This extended pattern is a RAG-based assistant. The user's query is used to retrieve the most relevant content from the vector database, the retrieved content is injected into the model's context alongside the query, and the model generates a response grounded in that specific information. The result is an assistant that answers accurately from your data without the model needing to have been trained on it. For detailed guidance on building the retrieval layer, see the RAG and Knowledge Systems section. #### Adding Tool Use When your assistant needs to do more than generate text, tools extend its capabilities to include actions. A tool-enabled assistant can query a database, call an external API, retrieve a file, run a calculation, or trigger a workflow as part of responding to a user request. The model decides when to use a tool, calls it with the appropriate inputs, receives the result, and incorporates it into its response. Tool use transforms an assistant from a text generation interface into an active participant that can interact with your systems and data in real time. This pattern is appropriate for use cases where the value of the assistant depends on its ability to take action, not just produce text. #### Adding Memory By default, language models do not retain information between separate conversations. Each session starts without any knowledge of previous interactions. For many use cases this is sufficient, but for applications where continuity matters, memory can be added to the architecture. Session memory maintains context within a single conversation, allowing the assistant to refer back to earlier parts of the exchange without the user repeating themselves. Persistent memory retains selected information across multiple sessions, enabling the assistant to build a picture of the user's context, preferences, or prior requests over time. Memory management on GLBNXT Platform is implemented at the application layer, with storage provided by Postgres for structured memory and vector databases for semantic retrieval of past context. #### Adding Agent Capabilities When the task a user brings to the assistant is too complex for a single model interaction, agent capabilities extend the architecture to support multi-step reasoning, planning, and execution. An agent-enabled assistant can break a complex request into subtasks, work through them sequentially or in parallel, use tools at each step, and synthesise a final response once the process is complete. Agent architectures require more careful design than simple assistant configurations, particularly around tool access, error handling, and the boundaries of what the agent is permitted to do autonomously. For detailed guidance, see the Multi-Agent Workflows and Automation section. ### Platform Components Building an AI assistant on GLBNXT Platform draws on the following managed components. **Chat interface:** a hosted, configurable conversational frontend available in your platform environment. It connects to any model endpoint in your Model Hub and supports system prompt configuration, conversation history management, and basic access control without requiring custom frontend development. For applications that require a custom interface, the platform provides the API layer that custom frontends connect to. **Model endpoints:** the inference layer that serves language model responses. Your assistant connects to a model endpoint in your Model Hub. The choice of model affects response quality, latency, and capability. Your GLBNXT contact can advise on model selection for specific assistant use cases. **Vector database:** required if your assistant uses retrieval-augmented generation. Weaviate and Qdrant are available in your environment. The vector database stores the embeddings of your source documents and serves retrieval queries at inference time. **Postgres:** used for storing conversation history, user data, memory, and any structured application state your assistant requires across sessions. **Workflow automation:** connects your assistant to external systems, APIs, and data sources. Used when your assistant needs to trigger processes, retrieve live data, or hand off tasks to downstream systems as part of handling a user request. ### Compliance Considerations AI assistants deployed in enterprise environments, particularly in regulated sectors, require careful attention to compliance from the start of the design process. GLBNXT Platform provides the controls needed to deploy assistants that meet enterprise and regulatory requirements. Key compliance considerations for assistant deployments include: **Data access boundaries:** defining clearly which data sources the assistant can access and ensuring that retrieval and tool use respect the access controls applied to those sources. Users should not be able to retrieve information through the assistant that they would not be permitted to access directly. **Audit logging:** all model inference requests are logged by the platform as part of the audit trail. For regulated use cases, ensure that your assistant configuration does not strip query or response content from logs in ways that would reduce audit completeness. **System prompt governance:** the system prompt defines the assistant's behaviour and scope. In regulated environments, system prompts should be version-controlled, reviewed, and approved through an appropriate governance process before deployment. Changes to system prompts should be treated as changes to the application, not as routine configuration updates. **Output review for high-stakes use cases:** for assistants used in legal, compliance, medical, or financial contexts, consider whether the application design should include a human review step for outputs before they are acted upon. The assistant can accelerate and inform decision-making, but the governance model for the use case should define where human judgement remains in the loop. ### Getting Started The fastest path to a working AI assistant on GLBNXT Platform is to begin with the base architecture and extend it incrementally as your requirements become clear. Start by configuring a chat interface connected to a model in your Model Hub with a system prompt that defines the assistant's role and scope. Test the base configuration with representative queries from your intended users. Once the base behaviour is correct, add retrieval, tool use, or memory as your use case requires. For step-by-step guidance on deploying your first assistant, see the Your First AI Application section. For guidance on adding a retrieval layer, see RAG and Knowledge Systems. # RAG & Knowledge systems Retrieval-augmented generation is the architectural pattern that enables AI models to work with your organisation's own data. Rather than relying solely on what a model learned during training, RAG systems retrieve relevant information from your data sources at query time and provide it as context to the model, grounding responses in accurate, current, and domain-specific content that the model was never trained on. On GLBNXT Platform, every component needed to build a production RAG system is available as a managed service. Document ingestion, embedding generation, vector storage, retrieval configuration, and language model integration are all supported within your platform environment, with the infrastructure managed by GLBNXT and the solution design in the hands of your team. This section explains how RAG works, how to implement it on GLBNXT Platform, and the architectural considerations that determine how well a RAG system performs in production. ### What This Pattern Is For RAG and knowledge systems are the right architectural choice when the quality and accuracy of your AI application's outputs depends on access to specific information that exists in your organisation's data rather than in a model's trained knowledge. Common use cases in this category include: * Contract review and analysis using your organisation's existing agreements and legal reference material * Financial document search and analysis across reports, filings, and internal financial data * Internal knowledge base search giving employees access to policies, procedures, and operational documentation * Compliance and regulatory research grounded in current regulatory texts and internal compliance frameworks * Tender and procurement analysis working across large volumes of structured proposal and specification documents * Policy analysis for public sector and regulated industry organisations that need to work with complex, frequently updated policy documentation If your use case requires the AI to answer questions, summarise content, or generate outputs based on documents or data your organisation owns, RAG is the foundational pattern. ### How RAG Works A RAG system operates in two distinct phases: ingestion and retrieval. Understanding both phases is essential for designing a system that performs well. #### Ingestion Phase The ingestion phase processes your source documents into a form that enables fast and accurate retrieval at query time. This is a preparation step that runs before the RAG system is available to users, and it needs to be re-run whenever source documents are added, updated, or removed. The ingestion pipeline follows these steps: 1. **Document loading:** source documents are loaded from their storage location, which on GLBNXT Platform is typically MinIO object storage or a connected external data source 2. **Chunking:** documents are split into smaller segments of a defined size. Chunk size affects retrieval quality significantly. Chunks that are too large reduce retrieval precision. Chunks that are too small lose the surrounding context needed for coherent answers. 3. **Embedding generation:** each chunk is passed through an embedding model that converts the text into a numerical vector representing its semantic meaning. These vectors are what enable similarity-based retrieval. 4. **Indexing:** the embeddings, along with metadata about their source document and position, are stored in the vector database. The index built during this step is what the retrieval layer searches at query time. #### Retrieval Phase The retrieval phase runs at query time, every time a user submits a request to the RAG system. It follows these steps: 1. **Query embedding:** the user's query is passed through the same embedding model used during ingestion, generating a vector representation of the query 2. **Similarity search:** the query vector is compared against the indexed document embeddings in the vector database. The most semantically similar chunks are identified and retrieved. 3. **Context assembly:** the retrieved chunks are assembled into a context block that is provided to the language model alongside the original query 4. **Response generation:** the language model generates a response grounded in the retrieved context. Because the relevant information is provided directly in the prompt, the model can answer accurately from your data without having been trained on it. ### Platform Components for RAG Building a RAG system on GLBNXT Platform uses the following managed components. **MinIO object storage** is the primary location for source documents before and after ingestion. Raw documents are stored in MinIO, and processed artefacts such as chunked content and metadata can be staged there between pipeline steps. **Weaviate or Qdrant** provides the vector database layer where embeddings are stored and similarity search is performed. The choice between them depends on your use case requirements. Weaviate is well suited to applications that need hybrid search combining vector similarity with structured metadata filtering. Qdrant is well suited to high-performance applications where retrieval latency under load is a critical requirement. Your GLBNXT contact can advise on the appropriate choice for your environment. **Embedding models** are available through the Model Hub in your environment. The embedding model used during ingestion must be the same model used to embed queries at retrieval time. Changing the embedding model requires re-ingesting all source documents to ensure consistency. **Language models** are connected to the retrieval output to generate responses. The language model receives the retrieved context and the user query and produces the final output. Model selection affects response quality, reasoning capability, and latency. Larger models generally produce higher quality responses but at greater inference cost and latency. **Langflow** provides a visual builder for constructing and testing RAG pipeline configurations without writing custom code for every connection. It is particularly useful for prototyping pipeline variations and testing different chunking strategies, retrieval configurations, and prompt designs before committing to a production architecture. **Elasticsearch** supports hybrid retrieval configurations where semantic vector search is combined with full-text keyword matching. This is valuable for use cases where users may search using exact terms, document identifiers, or structured queries that benefit from keyword precision alongside semantic relevance. ### Chunking Strategy Chunking is one of the most consequential design decisions in a RAG system. It determines the granularity of the information units being indexed and retrieved, and it has a direct impact on both retrieval accuracy and response quality. There is no universally correct chunk size. The right approach depends on your documents and your queries. As a general principle: * Short, specific queries benefit from smaller, more precise chunks that contain targeted information * Broad, analytical queries benefit from larger chunks that preserve more surrounding context * Documents with strong structural organisation, such as contracts or policy documents, often benefit from chunk boundaries that respect the document structure rather than fixed character counts A common approach is to start with a moderate chunk size and evaluate retrieval quality against a representative set of test queries before tuning. The Building AI Solutions section includes guidance on evaluation patterns that can help you assess and improve RAG system quality systematically. ### Retrieval Configuration Beyond chunk size, several retrieval parameters affect the quality and performance of a RAG system. **Top-k retrieval** determines how many chunks are retrieved for each query. Retrieving more chunks gives the model more context to work with but increases the size of the prompt and the cost of each inference call. A top-k value between three and ten is common for most use cases. **Similarity threshold** sets a minimum relevance score below which retrieved chunks are excluded from the context, even if they are among the top-k results. Setting a similarity threshold prevents low-relevance content from polluting the model's context when no highly relevant chunks exist for a given query. **Hybrid search configuration** determines the balance between vector similarity and keyword matching when both are used. For use cases involving precise terminology, document references, or structured identifiers, weighting keyword matching more heavily can improve retrieval accuracy for specific query types. **Metadata filtering** allows retrieval to be scoped to a subset of the indexed content based on document metadata such as source type, date, department, or access classification. This is important for use cases where different users should be able to retrieve information only from documents relevant to their role or context. ### Data Freshness and Re-ingestion A RAG system is only as current as its most recent ingestion run. If source documents are updated and the index is not refreshed, the system will retrieve outdated content and generate responses based on stale information. Designing an ingestion strategy that keeps the index current is an important operational consideration for production RAG systems. Common approaches include scheduled ingestion runs that process new or updated documents on a defined cadence, event-driven ingestion triggered by document update events in the source system, and incremental ingestion that processes only changed documents rather than re-ingesting the entire corpus on each run. Workflow automation available in your platform environment can be used to implement any of these patterns, connecting document update events or schedules to ingestion pipeline executions without requiring custom infrastructure. ### Compliance and Data Access RAG systems that operate on sensitive organisational data require careful attention to data access governance. The retrieval layer does not inherently enforce document-level access controls. If a user submits a query, the system retrieves the most relevant chunks from the index regardless of whether the user would be permitted to access the source documents directly. For deployments where different users should have access to different subsets of the knowledge base, access control must be implemented explicitly in the RAG architecture. Common approaches include maintaining separate indexes for different access tiers, applying metadata filters at retrieval time based on the authenticated user's role or permissions, and scoping vector database collections by access classification. Your GLBNXT contact can advise on the appropriate access control pattern for your specific compliance requirements. For a broader overview of compliance considerations on the platform, see the Security and Compliance section. ### Getting Started The recommended path to building your first RAG system on GLBNXT Platform is to begin with a small, well-defined document corpus and a clear set of test queries. This allows you to evaluate retrieval quality and iterate on chunking and retrieval configuration before scaling to your full document set. A practical first build follows this sequence: 1. Upload a representative sample of your source documents to MinIO 2. Configure an ingestion pipeline that chunks, embeds, and indexes the documents into your vector database 3. Connect the vector database to a language model endpoint in your Model Hub 4. Test the system against your representative queries and evaluate retrieval quality and response accuracy 5. Iterate on chunking strategy, retrieval configuration, and prompt design until quality meets your requirements 6. Scale ingestion to your full document corpus and configure ongoing data freshness processes For guidance on connecting your RAG layer to a conversational assistant interface, see the AI Assistants and Chat Interfaces section. # Workflow automation Workflow automation is the layer of GLBNXT Platform that connects AI capabilities to the processes, systems, and data sources your organisation already operates. It enables your team to build end-to-end AI-powered processes that move information between components, trigger actions based on events or conditions, and coordinate model interactions, data retrieval, and external system calls into coherent automated workflows without writing custom integration code for every connection. On GLBNXT Platform, workflow automation is available as a managed service within your environment. Your team focuses on designing and building workflows. GLBNXT handles the infrastructure that runs them. This section explains what workflow automation covers on GLBNXT Platform, the patterns it enables, and how to approach building workflows that are reliable, maintainable, and ready for production. ### What Workflow Automation Is For Workflow automation is the right architectural choice when your use case involves multiple steps, multiple systems, or processes that need to run automatically in response to events, schedules, or conditions rather than direct user interaction. Common use cases in this category include: * Automated document processing pipelines that ingest, classify, summarise, and route incoming documents without manual handling * Scheduled reporting workflows that retrieve data, run AI-powered analysis, and distribute outputs to stakeholders on a defined cadence * Event-driven notification and escalation systems that monitor data sources and trigger AI-generated communications when defined conditions are met * Data enrichment pipelines that pass records through AI processing steps and write enriched outputs back to source systems * Multi-step approval and case management workflows that combine AI reasoning with human review checkpoints and downstream system updates * Integration workflows that synchronise AI-generated outputs with CRM, ERP, or other enterprise systems your organisation uses If your use case requires AI to participate in a process rather than simply respond to a query, workflow automation is the layer that makes it possible. ### Core Concepts #### Triggers Every workflow begins with a trigger. A trigger is the event or condition that causes a workflow to start executing. Triggers can be time-based, such as a scheduled run at a defined interval, event-based, such as a new file arriving in a storage location or a webhook received from an external system, or manual, initiated by a user action in the platform console or an API call from another system. Choosing the right trigger type for a workflow is the first design decision. Time-based triggers are appropriate for processes that run on a predictable cadence. Event-based triggers are appropriate for processes that need to respond to real-world events as they occur. Manual triggers are appropriate for processes that should run on demand rather than automatically. #### Steps and Nodes Workflows are composed of steps, each of which performs a discrete action. A step might call a model endpoint to generate a summary, query a database to retrieve a record, call an external API to fetch live data, transform the structure of a data payload, apply conditional logic to determine which path the workflow should follow, or write an output to a storage location or downstream system. Steps are connected in sequence to form the workflow. The output of one step becomes the input to the next, with data flowing through the workflow as it executes. Conditional branching allows workflows to follow different paths based on the content or result of a previous step. #### Credentials and Integrations Workflow automation frequently involves calling external services that require authentication. On GLBNXT Platform, all credentials used by workflows are managed through the platform secrets vault. Workflows reference credentials by name rather than by value, and the vault injects the actual credential at runtime. Your workflow definitions never contain sensitive values, and credential rotation does not require changes to workflow configuration. GLBNXT Platform workflows support integration with a broad range of external services through managed connectors. These connectors handle the authentication, request formatting, and response parsing required to interact with external APIs, reducing the work required to connect a workflow to a new system to a matter of configuration rather than custom code. #### Error Handling and Retry Logic Production workflows need to handle failures gracefully. External services are sometimes unavailable, API calls occasionally time out, and data inputs do not always conform to expected formats. Workflows built on GLBNXT Platform should include explicit error handling at steps where failures are likely, with retry logic configured for transient failures and fallback paths or error notifications defined for failures that cannot be recovered automatically. Building error handling into workflows from the start is significantly less effort than adding it after a production incident. Every workflow that calls an external system or processes user-supplied data should have a considered approach to what happens when that step fails. ### Building Workflows on GLBNXT Platform #### Visual Workflow Builders The primary low-code approach to workflow automation on GLBNXT Platform is through visual workflow builders available in your environment. These tools provide a node-based interface where each step in a workflow is represented as a node that can be configured, connected, and tested interactively. Visual builders are well suited for building and iterating on workflow logic quickly, for processes that follow well-established patterns, and for teams who want to deliver working automation without writing significant amounts of custom code. They provide a clear visual representation of workflow structure that makes complex multi-step processes easier to understand, review, and maintain. Pre-built node types cover a wide range of common actions including HTTP requests, database queries, file operations, conditional logic, data transformation, and integration with popular external services. Model endpoint calls are available as native node types, making it straightforward to incorporate AI reasoning, summarisation, classification, or generation steps into any workflow. #### Full-Code Workflow Development For workflows that require custom logic not covered by pre-built node types, complex data transformations, or precise control over execution behaviour, the platform supports full-code workflow development. Custom code steps can be inserted at any point in a workflow, receiving the current data payload as input and returning a transformed payload for the next step. Full-code development is appropriate when the logic of a workflow step cannot be expressed through configuration alone, when performance requirements demand optimised custom processing, or when a workflow needs to interact with a proprietary system that does not have a pre-built connector available. As with other areas of the platform, low-code and full-code approaches can be combined freely within the same workflow. A workflow might use pre-built connectors for standard integrations, a custom code step for a specific data transformation, and a pre-built model node for AI processing, all within a single automated process. ### AI Integration Patterns in Workflows Incorporating AI model calls into automated workflows creates a range of powerful patterns that are not possible with traditional automation alone. #### Classification and Routing A language model can classify incoming data, documents, or messages and route them to different workflow paths based on the classification output. An incoming support request might be classified by topic, urgency, and required expertise before being routed to the appropriate handling process. A document ingestion pipeline might classify files by type and apply different processing logic to each category. Classification and routing patterns remove the need for manually defined rules for every possible input type, replacing brittle rule-based logic with model-driven categorisation that generalises across inputs that rule sets would not anticipate. #### Summarisation and Extraction Workflows can pass documents, records, or data payloads to a model for summarisation, structured data extraction, or key information identification as part of an automated process. The extracted or summarised output can then be written to a database, included in a notification, or passed to the next step in the workflow. This pattern is particularly valuable for document-heavy processes where the volume of incoming content makes manual review impractical, and where downstream steps require structured information that is embedded within unstructured documents. #### Generation and Drafting Workflows can use model generation capabilities to produce first-draft outputs such as email responses, report sections, analysis summaries, or structured documents as part of an automated process. Generated drafts can be written to a staging location for human review before sending, or delivered directly to recipients in workflows where review is not required. Generation patterns work well in combination with retrieval, where the workflow first retrieves relevant context from a knowledge base or data source and then passes that context to the model to ground the generated output in accurate information. #### Evaluation and Quality Checking Workflows can include model-powered evaluation steps that assess the quality, completeness, or compliance of outputs generated earlier in the process. An evaluation step might check whether a generated response meets defined quality criteria before it is delivered, flag content that falls outside defined boundaries for human review, or score outputs against a rubric and route them accordingly. Evaluation steps add a quality gate to automated processes that would otherwise rely entirely on the output of a single model call. ### Connecting Workflows to the Broader Platform Workflows on GLBNXT Platform do not operate in isolation. They connect to and coordinate with the other components available in your environment. Workflows can trigger RAG retrieval to ground AI steps in organisational knowledge. They can read from and write to Postgres for structured data and state management. They can store and retrieve files from MinIO at any step in the process. They can call model endpoints in the Model Hub for any AI processing step. And they can expose webhook endpoints that other systems can call to trigger a workflow from outside the platform. This connectivity means that workflows are not a separate automation layer sitting alongside your AI applications. They are the orchestration fabric that binds platform components together into complete end-to-end solutions. ### Operational Considerations #### Testing and Validation Workflows should be tested with representative inputs before being deployed to production. Visual workflow builders provide execution history and step-by-step output visibility that makes it straightforward to trace exactly what happened during a test run and identify where logic needs adjustment. Testing should cover not only the happy path but also edge cases and error conditions. How does the workflow behave when an external API is unavailable? What happens when a model returns an unexpected output format? What is the behaviour when a database query returns no results? Answering these questions during testing prevents production incidents caused by inputs or conditions that were not anticipated during design. #### Monitoring and Alerting All workflow executions on GLBNXT Platform are logged and visible through the Monitoring and Observability area of the platform console. Execution history, step-level outputs, error events, and performance metrics are available for every workflow run. This visibility makes it straightforward to identify patterns of failure, monitor throughput for high-volume workflows, and investigate individual executions when an unexpected outcome occurs. For critical production workflows, configure alerting on failure events so that your team is notified immediately when a workflow encounters an error that requires attention. See the Observability and Monitoring section for guidance on configuring workflow-level alerting in your environment. #### Version Control and Change Management Workflows that run in production are software artefacts and should be treated accordingly. Changes to workflow logic, prompt configurations, model selections, and integration settings should be reviewed and approved before being applied to production. Maintaining version history for workflow configurations allows your team to roll back to a previous state if a change introduces unexpected behaviour. For workflows that process sensitive data or operate in regulated contexts, change management for workflow configurations should align with the governance processes your organisation applies to other software changes. ### Getting Started The recommended starting point for workflow automation on GLBNXT Platform is to identify a well-defined, repeatable process in your organisation that currently involves manual steps and would benefit from automation with AI capability added at one or more points. A practical first workflow follows this sequence: 1. Map the current manual process step by step, identifying inputs, outputs, decisions, and the systems involved at each stage 2. Identify which steps involve AI capability, such as classification, summarisation, extraction, or generation, and which are data movement or integration steps 3. Build the workflow in the visual builder, starting with the data flow and integration connections before adding AI steps 4. Test the workflow with representative inputs and validate outputs at each step before proceeding to the next 5. Add error handling and retry logic for steps that call external systems or process variable inputs 6. Deploy to production and monitor execution history through the platform console during the initial production period For use cases that combine workflow automation with conversational AI, see the AI Assistants and Chat Interfaces section. For workflows that incorporate retrieval from organisational knowledge, see the RAG and Knowledge Systems section. # Agents & memory Agents represent a significant step beyond single-turn model interactions. Where a standard AI assistant responds to a query in a single model call, an agent reasons about what needs to be done, decides which tools or actions to use, executes those actions, evaluates the results, and continues reasoning until the task is complete. Memory extends this capability by giving agents and assistants access to information from prior interactions, enabling continuity and context-awareness across conversations, sessions, and long-running processes. On GLBNXT Platform, the components needed to build agent systems and implement memory are available as managed services within your environment. This section explains how agents work, the memory patterns available on the platform, and how to design agent architectures that are reliable, controllable, and ready for production. ### What Agents Are For Agents are the right architectural choice when a task is too complex to complete in a single model interaction, requires access to external information or systems, involves multiple steps that depend on each other, or needs to adapt its approach based on intermediate results. Common use cases for agent architectures include: * Research and analysis tasks that require retrieving information from multiple sources, synthesising findings, and producing a structured output * Technical support agents that diagnose issues by querying system data, running checks, and proposing or executing remediation steps * Financial and legal analysis agents that work through complex documents, cross-reference multiple sources, and produce annotated summaries or recommendations * Case management agents that gather information, apply reasoning to determine the appropriate course of action, and update downstream systems accordingly * Automated reporting agents that retrieve data, perform analysis, generate narrative content, and assemble complete reports without manual coordination of each step If your use case requires AI to plan, act, observe, and adapt rather than simply respond, an agent architecture is the appropriate choice. ### How Agents Work An agent operates through a reasoning loop. At each step in the loop, the agent receives the current state of the task, reasons about what action to take next, executes that action using an available tool, observes the result, and then repeats the loop until the task is complete or a stopping condition is reached. This loop is often described as a think-act-observe cycle. The agent thinks about what to do next based on the task goal and the information available to it. It acts by calling a tool, retrieving information, or generating an intermediate output. It observes the result of that action and uses it to inform the next iteration of reasoning. The key difference between an agent and a standard model call is that the agent drives the process. It decides which tools to use, in what order, and when the task is sufficiently complete. The developer defines the tools available, the boundaries within which the agent operates, and the goal it is working toward. The agent determines how to get there. ### Tools and Tool Use Tools are the mechanism through which agents interact with the world outside the language model. A tool is a defined capability that the agent can invoke as part of its reasoning process. When the agent decides that a tool is needed, it generates a structured call to that tool with the appropriate inputs, the tool executes and returns a result, and the agent incorporates that result into its next reasoning step. Tools available to agents on GLBNXT Platform can include: * Vector database search for retrieving relevant information from indexed knowledge sources * Database queries for accessing structured data in Postgres or other connected data stores * API calls to external services for retrieving live data or triggering actions in third-party systems * File operations for reading from and writing to object storage * Workflow triggers for initiating automated processes as part of an agent task * Custom functions developed by your team that encapsulate specific business logic or proprietary data access The set of tools an agent has access to defines what it is capable of doing. Designing the right tool set for an agent is one of the most important decisions in agent architecture. Tools should be precise in what they do, well-documented in how they are called, and scoped to what the agent genuinely needs to accomplish its task. Giving an agent access to tools it does not need increases the risk of unintended actions and makes the agent's behaviour harder to predict and control. ### Single-Agent vs. Multi-Agent Architectures #### Single-Agent Systems A single-agent system uses one agent with access to a defined set of tools to complete a task end-to-end. This is the right starting point for most agent use cases. Single-agent systems are simpler to design, easier to debug, and sufficient for a wide range of tasks that involve sequential reasoning and tool use without requiring coordination between multiple specialised capabilities. Single agents work well when the task has a clear goal that can be pursued by one reasoning process, when the tools required are manageable in number and scope, and when the complexity of the task does not exceed what a single context window can handle effectively. #### Multi-Agent Systems Multi-agent systems coordinate multiple agents, each with a defined role and specialised set of tools, to complete tasks that are too complex or too large for a single agent to handle well. An orchestrator agent typically manages the overall task, delegating subtasks to specialist agents and synthesising their outputs into a final result. Multi-agent architectures are appropriate when a task can be clearly decomposed into subtasks that benefit from specialised handling, when different parts of a task require different tool sets or reasoning approaches, when the total context required for the full task exceeds what can be managed in a single agent loop, or when parallel execution of independent subtasks would meaningfully reduce the time to completion. Common multi-agent patterns on GLBNXT Platform include: * **Orchestrator and worker:** an orchestrator agent receives the top-level task, decomposes it into subtasks, delegates each subtask to a worker agent, collects the results, and produces the final output * **Pipeline agents:** agents arranged in sequence where the output of one agent becomes the input to the next, each applying a different kind of processing or reasoning to the data as it passes through * **Parallel agents:** independent agents working on different aspects of a task simultaneously, with results aggregated by an orchestrator once all agents have completed their work * **Supervisor and specialist:** a supervisor agent monitors the outputs of specialist agents and applies quality checks, routing, or escalation logic based on what the specialists produce Multi-agent systems introduce additional complexity around coordination, state management, and error propagation. They should be introduced when there is a clear need for them, not as a default architecture for every agent use case. ### Memory Memory gives agents and assistants the ability to retain and recall information across interactions. Without memory, every conversation or agent execution starts from scratch, with no awareness of what has happened before. With memory, agents can build on prior context, maintain continuity across sessions, and adapt their behaviour based on accumulated information about a user, a task, or an environment. On GLBNXT Platform, memory is implemented at the application layer using the storage services available in your environment. There is no single memory system that works for every use case. The right memory pattern depends on what information needs to be retained, for how long, and how it needs to be retrieved. #### Session Memory Session memory retains context within a single conversation or agent execution. It allows a conversational assistant to refer back to what was said earlier in the same exchange, or an agent to maintain awareness of the steps it has already taken within a single task execution, without storing that information beyond the end of the session. Session memory is typically implemented by maintaining the conversation history or execution trace in the model's context window during an active session. When the session ends, the session memory is not retained. This is the simplest form of memory and is appropriate for use cases where continuity within a session is valuable but cross-session persistence is not required. #### Persistent Memory Persistent memory retains selected information across multiple sessions, giving agents and assistants access to context that accumulates over time. This might include facts about a user, the outcomes of previous tasks, preferences established in prior interactions, or the state of a long-running process that spans multiple sessions. Persistent memory is implemented using Postgres for structured memory and vector databases for semantic memory. Structured memory stores discrete facts, preferences, or state as rows in a database that can be retrieved by key or queried by attribute. Semantic memory stores richer information as embeddings in a vector database, enabling the agent to retrieve relevant prior context through similarity search rather than exact lookup. When implementing persistent memory, it is important to design what information is stored and what is discarded. Not everything that happens in a session is worth retaining. Storing too much creates noise that reduces the quality of retrieved context. Storing too little loses information that would have been genuinely useful in future interactions. Designing a thoughtful memory selection strategy is as important as the storage implementation itself. #### External Memory and Knowledge In addition to session and persistent memory, agents can access external knowledge through the retrieval patterns described in the RAG and Knowledge Systems section. The distinction between memory and retrieval is conceptual rather than technical: memory refers to information derived from the agent's own prior interactions and experiences, while retrieval refers to access to a broader knowledge base that exists independently of the agent's interaction history. In practice, many production agent systems combine both. The agent retrieves relevant knowledge from an indexed knowledge base to ground its reasoning, and also draws on persistent memory of prior interactions to personalise or contextualise its responses. ### Guardrails and Control Agents that can take actions in external systems introduce risks that are not present in simpler AI applications. An agent that can write to a database, send API requests, or trigger workflows has the ability to cause real effects, and those effects may be difficult to reverse. Designing appropriate guardrails and control mechanisms is an essential part of building safe and reliable agent systems. Key considerations for agent safety and control include: **Scope of tool access:** agents should have access only to the tools they need for their defined task. Every additional tool is an additional surface area for unintended actions. Review tool permissions carefully and apply the principle of least privilege to agent tool access in the same way it is applied to user access controls. **Confirmation checkpoints:** for agent actions that are irreversible or that affect external systems, consider building confirmation steps into the agent workflow that pause execution and present the proposed action to a human operator before proceeding. This is particularly important during the initial deployment of a new agent system before its behaviour is well understood in production conditions. **Output validation:** validate agent outputs before they are acted upon or delivered to users. This can be implemented as an evaluation step in the agent loop or as a post-processing step that applies defined quality and safety criteria to the agent's final output. **Execution limits:** define limits on the number of tool calls, loop iterations, or tokens consumed in a single agent execution. Without these limits, a poorly prompted agent or an unexpected input can cause an agent to run indefinitely, consuming compute resources and potentially taking repeated unintended actions. **Audit logging:** all agent actions, tool calls, and intermediate outputs are logged by the platform as part of the audit trail. Review agent execution logs during development and initial production to build confidence in the agent's behaviour before reducing human oversight. ### Getting Started The recommended path to building your first agent on GLBNXT Platform is to start with a single-agent system with a small, well-defined tool set and a clear, bounded task. This gives you a working agent quickly and allows you to build understanding of how the agent behaves before introducing additional complexity. A practical first agent build follows this sequence: 1. Define the task the agent needs to complete and the goal it should work toward 2. Identify the minimum set of tools the agent needs to complete that task and nothing more 3. Build and configure each tool, ensuring that each one is well-documented so the agent can use it effectively 4. Configure the agent with its system prompt, tool set, and any relevant memory 5. Test the agent with representative task inputs, reviewing execution traces to understand how the agent reasons and where it makes suboptimal decisions 6. Refine the system prompt, tool definitions, and memory configuration based on what testing reveals 7. Add guardrails appropriate to the tools available and the context in which the agent will operate 8. Deploy to production and monitor execution logs closely during the initial production period For use cases that require multiple coordinating agents, begin by building and validating each agent individually before introducing orchestration. A multi-agent system whose individual agents are not yet reliable will be significantly harder to debug and improve than a system built on validated components. For guidance on connecting agent systems to conversational interfaces, see the AI Assistants and Chat Interfaces section. For guidance on incorporating retrieval into agent tool sets, see the RAG and Knowledge Systems section. # APIs & Functions APIs and functions are the layer of GLBNXT Platform that makes AI capabilities programmable and composable. They allow the AI applications and model capabilities running in your platform environment to be called from external systems, embedded in existing products, consumed by client applications, and integrated into the broader technology landscape of your organisation or your clients. Where chat interfaces expose AI to human users through a conversational frontend, APIs and functions expose AI to other systems through programmable endpoints. This distinction is fundamental to how AI capabilities move from isolated applications into the fabric of how an organisation operates. On GLBNXT Platform, APIs and functions are built on the same managed infrastructure that underpins every other solution component. Your team designs and deploys the logic. GLBNXT handles the infrastructure that runs it, the networking that exposes it securely, and the observability that gives you visibility into how it performs. ### What APIs and Functions Are For APIs and functions are the right architectural choice when an AI capability needs to be consumed by a system rather than a user, when an AI application needs to be embedded in a product that already exists, or when the output of an AI process needs to flow automatically into another part of your technology stack. Common use cases in this category include: * Exposing a model inference capability as a REST endpoint that an existing web application or mobile app can call to enrich its functionality with AI * Building a document processing API that accepts file uploads, runs AI extraction or summarisation, and returns structured outputs to the calling system * Creating a classification endpoint that external systems can call to categorise incoming data, requests, or content in real time * Developing a generation API that produces text, code, or structured content on demand for downstream consumption by other services * Wrapping a complex RAG pipeline in a simple API endpoint so that consuming applications do not need to understand the retrieval architecture behind it * Providing webhook endpoints that external systems can call to trigger agent workflows, data processing pipelines, or AI-powered automation sequences If your use case involves making AI capabilities available to systems rather than directly to users, APIs and functions are the appropriate solution layer. ### API Design on GLBNXT Platform APIs built on GLBNXT Platform follow standard REST principles and are accessed over HTTPS with authentication required on every request. Endpoints are exposed through the platform's managed networking layer, which handles routing, SSL termination, and access control at the infrastructure level. Your team implements the business logic of the API. The platform handles the infrastructure concerns that make it reachable and secure. When designing an API that exposes AI capabilities, the following principles lead to more reliable, maintainable, and easy-to-consume endpoints. #### Keep Endpoints Focused Each API endpoint should do one thing well. An endpoint that accepts a document and returns a summary should not also classify the document, extract entities, and trigger a downstream workflow in the same call. Composing focused endpoints gives consuming applications the flexibility to use each capability independently and makes individual endpoints easier to test, monitor, and improve over time. #### Design for the Consumer The interface your API exposes should be designed from the perspective of the system that will call it, not the perspective of the AI pipeline that runs behind it. A consuming application cares about the inputs it needs to provide and the outputs it will receive. It should not need to understand how the model is called, how retrieval is configured, or how the prompt is constructed. These are implementation details that belong inside the API, not in its interface. #### Handle Asynchronous Processing AI operations, particularly those involving complex reasoning, multi-step agent execution, or large document processing, often take longer than the timeout limits of synchronous HTTP requests. For operations that may take more than a few seconds to complete, design the API as an asynchronous endpoint. The initial request returns a job identifier immediately. The consuming application polls a status endpoint or receives a webhook notification when processing is complete and the result is available. This pattern prevents timeout failures in consuming applications, makes the API more robust under variable processing times, and allows long-running AI tasks to run to completion without forcing the calling system to maintain an open connection. #### Version Your APIs API interfaces change as your AI applications evolve. A consuming application that is built against a specific API version should not break when you update the underlying AI logic or change the output format of a newer version. Versioning your APIs from the start, using path-based versioning such as `/v1/` and `/v2/` prefixes, allows you to evolve your AI capabilities without breaking existing integrations. ### Functions Functions are lightweight, single-purpose code units that can be triggered by events, called by workflows, or invoked by agents as tools. They are the building blocks of custom logic within the GLBNXT Platform environment, handling the specific data transformations, integrations, and processing steps that do not map to pre-built workflow nodes or platform components. Functions on GLBNXT Platform are containerised and managed by the platform infrastructure. Your team writes the function logic. GLBNXT handles deployment, scaling, and execution. Functions can be invoked synchronously, returning a result to the caller immediately, or asynchronously, executing in the background and writing their output to a storage location or triggering a subsequent workflow step. #### Common Function Patterns **Data transformation functions** accept a data payload in one format and return it in another. They are used at integration points between systems that represent the same information differently, or between pipeline steps that expect different input structures. **Validation and enrichment functions** accept a record or document, apply business logic or AI processing to validate or enrich it, and return the result. These functions are frequently used as steps in ingestion pipelines, workflow automation sequences, and agent tool sets. **Connector functions** wrap the authentication and request logic required to call a specific external API, presenting a clean interface to the workflow or agent that calls them without exposing the complexity of the underlying integration. **Evaluation functions** assess the quality, safety, or compliance of AI-generated outputs against defined criteria. They are used as quality gates in automated pipelines and as tool calls within agent reasoning loops. ### Authentication and Access Control Every API endpoint and function on GLBNXT Platform requires authentication. Unauthenticated requests are rejected at the networking layer before they reach your application logic. Authentication is implemented using API keys or token-based authentication depending on the consuming application's requirements and the sensitivity of the endpoint. API keys for external consumers are managed through the platform secrets vault. Keys can be scoped to specific endpoints or sets of capabilities, ensuring that a consuming application can only call the endpoints it is explicitly authorised to use. Key rotation is handled through the vault without requiring changes to your API implementation. For internal consumers within the platform environment, service-to-service authentication uses platform-managed tokens that are injected at runtime through the same secrets management mechanism used by other platform workloads. ### Rate Limiting and Quota Management APIs that expose AI model calls need to account for the cost and performance implications of model inference. Unconstrained API usage can consume compute resources unexpectedly and affect the performance of other workloads in your environment. Implementing rate limiting on your API endpoints protects against both unintentional overuse and deliberate abuse. Rate limiting can be applied at the platform networking layer for coarse-grained protection, and within your application logic for fine-grained per-consumer or per-endpoint control. Your GLBNXT contact can advise on the appropriate rate limiting configuration for your environment based on your expected usage patterns and compute allocation. ### Observability for APIs and Functions All API calls and function invocations on GLBNXT Platform are logged as part of the platform audit trail. Request volumes, response times, error rates, and authentication events are captured automatically and visible through the Monitoring and Observability area of the platform console. For APIs that expose AI model calls, request and response payloads can be included in the audit log depending on the compliance requirements of your environment. This supports use cases where a complete record of what was requested and what was returned is required for regulatory or governance purposes. Function execution logs capture runtime output including errors, warnings, and diagnostic information generated by your function code. These logs are searchable through the platform console and can be exported for integration with your organisation's existing log management tooling. ### Connecting APIs and Functions to the Platform APIs and functions on GLBNXT Platform are not standalone components. They connect to and draw on all of the other managed services available in your environment. An API endpoint can call a model in the Model Hub for inference, query a vector database for retrieval, read from and write to Postgres for structured data, retrieve files from MinIO, trigger a workflow automation sequence, or invoke an agent. The platform handles authentication and connectivity between these components. Your API logic assembles them into the capability it exposes. This connectivity means that a well-designed API endpoint on GLBNXT Platform can represent a complete AI capability rather than a thin wrapper around a single model call. The complexity of the underlying architecture is hidden behind the API interface, and consuming applications benefit from the full power of the platform stack through a simple, stable endpoint. ### Getting Started The recommended starting point for building APIs and functions on GLBNXT Platform is to identify an AI capability that already exists in your environment and expose it as a stable endpoint that a consuming application can call. A practical first API build follows this sequence: 1. Identify the AI capability you want to expose and define the interface from the consumer's perspective, specifying the inputs the endpoint accepts and the outputs it returns 2. Implement the endpoint logic that accepts the request, calls the appropriate platform components, and assembles the response 3. Configure authentication for the endpoint using the platform secrets vault 4. Test the endpoint with representative inputs, validating that outputs are correct and that error cases are handled appropriately 5. Review the observability output in the platform console to confirm that logging and monitoring are capturing the information you need 6. Share the endpoint with the consuming application and monitor usage during the initial integration period For APIs that expose agent capabilities or multi-step AI processing, implement the asynchronous request pattern from the start rather than adding it later. The effort required to retrofit asynchronous handling into a synchronous API design after consumers have already integrated against it is considerably greater than designing for it upfront. For guidance on using APIs as integration points within workflow automation, see the Workflow Automation section. For guidance on exposing agent capabilities through API endpoints, see the Agents and Memory section. # Frontend & Webchat components Frontend and webchat components are the user-facing layer of AI applications built on GLBNXT Platform. They provide the interfaces through which end users interact with the AI capabilities your team has built, whether that is a conversational assistant embedded in a web application, a standalone chat interface deployed for an internal team, or a custom-branded AI product delivered to a client. On GLBNXT Platform, frontend and webchat components are available as managed, configurable services that can be deployed and customised without requiring significant frontend development effort. For teams that need a fully custom interface, the platform provides the API layer that custom frontends connect to, giving engineering teams complete control over the user experience while GLBNXT manages the infrastructure behind it. This section explains what frontend and webchat components are available on the platform, how they are configured and deployed, and how to approach the decision between managed components and custom frontend development. ### What Frontend and Webchat Components Are For Frontend and webchat components are the right choice when an AI capability needs to be accessible to users through a visual interface rather than through an API consumed by another system. They bridge the gap between the AI capabilities running in your platform environment and the people who benefit from those capabilities in their day-to-day work. Common use cases in this category include: * Internal AI assistants deployed for employees to interact with organisational knowledge, policies, or data through a conversational interface * Client-facing AI tools embedded in a web application or portal, providing AI-powered support, guidance, or analysis to external users * Sector-specific AI interfaces for regulated industries such as healthcare, legal, and financial services, where the interface needs to reflect compliance requirements and professional context * Standalone AI workspaces deployed for teams that need a governed, managed environment for AI-assisted work without requiring integration with an existing product * Embedded webchat widgets integrated into existing websites or applications, adding AI capability to a product that was not originally built around AI If your use case involves putting AI capability directly in front of human users, frontend and webchat components are the appropriate solution layer. ### Managed Chat Interface GLBNXT Platform provides a hosted, configurable chat interface available within your environment. It connects directly to any model endpoint in your Model Hub and provides a complete conversational frontend that can be configured and deployed without writing custom frontend code. The managed chat interface is the fastest path to a working user-facing AI application. It is well suited for internal deployments, proof of concept demonstrations, and use cases where the conversational experience itself is the primary requirement and custom branding or interface design is not a priority. #### Configuration The managed chat interface is configured through the platform console. Key configuration options include: * **Model selection:** the model endpoint the interface connects to, selected from the models available in your Model Hub * **System prompt:** the instruction set that defines the assistant's role, scope, tone, and behavioural boundaries for every conversation conducted through the interface * **Conversation history:** whether the interface retains conversation history within a session, how many prior turns are included in the model context, and whether history is persisted across sessions * **Access controls:** which users or user groups are permitted to access the interface, managed through the role-based access controls configured for your environment * **Interface customisation:** basic visual customisation options including the assistant name, introductory message, and input placeholder text #### Extending the Managed Interface The managed chat interface can be extended with additional platform capabilities by connecting it to other components in your environment. Connecting a vector database and retrieval pipeline transforms the interface into a RAG-based assistant that grounds responses in your organisational data. Connecting workflow automation allows the interface to trigger processes, retrieve live data, or interact with external systems as part of handling user requests. These extensions are configured at the platform level and take effect without changes to the interface itself. ### Webchat Widgets For teams that want to embed AI conversational capability within an existing website or web application, GLBNXT Platform provides webchat widget components that can be integrated into external web properties with minimal development effort. A webchat widget is a self-contained conversational interface delivered as an embeddable component. It is placed on an existing web page using a script tag or component integration, and it communicates with the AI backend in your platform environment through the platform API layer. The external website or application does not need to implement any AI logic itself. It simply hosts the widget. Webchat widgets are suited for use cases where AI capability needs to be added to an existing product or website without a full redesign of the frontend, or where a client wants to offer AI-powered support or assistance to their own users through their existing web presence. #### Integration Embedding a webchat widget involves three steps. First, configure the widget in your platform environment, specifying the model endpoint, system prompt, access controls, and any visual customisation options. Second, generate the widget embed code from the platform console. Third, place the embed code in the target website or application at the point where the widget should appear. The widget handles session management, conversation history, and communication with the platform API automatically. The host website is responsible only for placing the widget and, if authentication is required, passing the user identity to the widget through the integration configuration. #### Authentication and User Context For widgets deployed in authenticated web applications, user identity can be passed to the widget at initialisation time. This allows the widget to apply access controls based on the authenticated user, personalise the assistant experience based on user context, and attribute conversation activity in the audit trail to specific users rather than anonymous sessions. For public-facing widgets deployed on unauthenticated web pages, the widget operates without user identity. In these configurations, rate limiting and abuse prevention should be considered to protect against unintended high-volume usage of the underlying model endpoint. ### Custom Frontend Development For use cases that require a fully customised user interface, specific interaction patterns not supported by the managed components, deep integration with an existing product design system, or complete control over the user experience, GLBNXT Platform provides the API layer that custom frontends connect to. Custom frontend development allows your team to build any interface experience while relying on GLBNXT Platform for everything behind it: model serving, retrieval, agent execution, secrets management, observability, and compliance. The frontend communicates with the platform through standard REST API calls, and the platform returns responses in consistent, documented formats. #### When to Choose Custom Frontend Development Custom frontend development is appropriate when: * The user experience requirements are specific enough that the managed chat interface cannot meet them through configuration alone * The AI capability needs to be deeply integrated into an existing product interface where introducing a separate chat component would create a disjointed user experience * The interface needs to present AI outputs in formats other than conversational text, such as structured data visualisations, document annotations, comparison views, or interactive outputs * Branding, accessibility, or design system requirements mandate that the interface is built within the organisation's existing frontend architecture Custom frontend development is not necessary for most internal deployments or proof of concept builds. The managed chat interface and webchat widgets cover the majority of common use cases without requiring frontend engineering effort. #### Connecting a Custom Frontend to the Platform A custom frontend communicates with GLBNXT Platform through API endpoints that your team defines and deploys within the platform environment. The custom frontend calls these endpoints over HTTPS with the appropriate authentication credentials, and the platform API handles all backend AI processing, retrieval, and data management. This architecture keeps the AI logic and the frontend logic cleanly separated. Changes to the AI backend, such as updating a model, adjusting a system prompt, or modifying retrieval configuration, do not require frontend changes. Changes to the interface, such as redesigning the layout or adding new interaction patterns, do not require changes to the AI backend. Each layer can evolve independently. For guidance on designing and building the API layer that a custom frontend connects to, see the APIs and Functions section. ### Compliance and Governance for User Interfaces User-facing interfaces for AI applications in enterprise environments require specific compliance and governance considerations, particularly in regulated sectors. #### Data Handling in the Interface Conversational interfaces frequently receive sensitive information from users, either because users deliberately provide it as part of their query or because the nature of the use case involves sensitive subject matter. The interface configuration should reflect the data handling requirements that apply to the content passing through it. For deployments subject to GDPR or sector-specific data protection requirements, conversation data retention policies should be defined explicitly and aligned with your organisation's data processing agreements. #### User Transparency Users interacting with AI interfaces should understand that they are interacting with an AI system. Interface design and configuration should make this clear through appropriate labelling, introductory messaging, and any required disclosures that apply in your sector or jurisdiction. For interfaces operating in regulated sectors such as healthcare or financial services, the specific transparency requirements may be defined by applicable regulation or professional standards. #### Conversation History and Data Retention Conversation history retained by the interface is subject to data protection obligations in the same way as any other personal data processed by your organisation. Define retention periods for conversation history that are appropriate for the use case and compliant with applicable data protection requirements. Configure the interface to apply those retention periods automatically rather than retaining conversation data indefinitely. #### Access Controls Every interface deployed through GLBNXT Platform should have access controls configured that restrict usage to authorised users. For internal deployments this typically means authentication through your organisation's identity provider. For client-facing deployments this means authentication through the client's own identity management or through access controls configured for the specific deployment. Unrestricted access to AI interfaces that connect to sensitive data sources, execute agent workflows, or consume significant compute resources creates both security and operational risks. Access controls are not optional for production deployments. ### Getting Started The recommended starting point for frontend and webchat development on GLBNXT Platform is to use the managed chat interface for the initial deployment and validate the AI capability and user experience before investing in custom frontend development. A practical first frontend deployment follows this sequence: 1. Configure the managed chat interface in the platform console, connecting it to the appropriate model endpoint and defining the system prompt for your use case 2. Extend the interface with retrieval or tool capabilities if your use case requires them 3. Test the interface with representative users from your target audience, gathering feedback on the conversational experience and the quality of AI outputs 4. Identify any interface requirements that cannot be met through configuration of the managed component 5. If custom frontend development is justified by the requirements identified, design the API layer that the custom frontend will connect to before beginning frontend implementation 6. Deploy the custom frontend, connecting it to the platform API layer and validating end-to-end behaviour before releasing to users For guidance on connecting frontend interfaces to AI assistant architectures, see the AI Assistants and Chat Interfaces section. For guidance on the API layer that custom frontends connect to, see the APIs and Functions section. # Overview of the Model hub The Model Hub is the central location in your GLBNXT Platform environment where AI models are managed, accessed, and monitored. It provides your development team with a unified view of every model available in your environment, along with the endpoints, configuration details, and usage information needed to integrate those models into your applications. Every model available through the Model Hub is served through the platform's managed inference layer. GLBNXT handles model deployment, serving runtime configuration, and endpoint management. Your team connects to a stable, authenticated endpoint and the platform takes care of everything behind it. ### What the Model Hub Contains The Model Hub gives your team visibility into the full set of models available in your environment. For each model, the Hub provides: * The model name, version, and a brief description of its capabilities and intended use cases * The API endpoint URL used to call the model from your applications or workflows * The serving runtime in use, either Ollama for open-source models or NVIDIA NIM for optimised production inference * Current availability status and any active usage or performance alerts * Usage metrics including request volume, average latency, and token consumption over time ### Model Categories Models in the Hub are organised by category to help your team identify the right model for a given use case. **Language models** handle text generation, reasoning, summarisation, classification, question answering, and conversational tasks. These are the core models most AI applications on the platform are built around. **Embedding models** convert text into numerical vector representations used for semantic search and retrieval-augmented generation. The embedding model used during document ingestion must match the model used at retrieval time. **Specialised models** cover specific capabilities such as code generation, structured data extraction, or domain-specific reasoning. Availability depends on your environment configuration. ### Accessing Model Endpoints Model endpoints are listed in the Model Hub with the full endpoint URL and authentication requirements. All endpoints require authentication using credentials managed through the platform secrets vault. Your application references the credential by name and the platform injects the actual value at runtime. Endpoints follow a consistent API format compatible with standard AI development frameworks, meaning that applications built against GLBNXT-hosted model endpoints can be adapted with minimal changes if model selection changes over time. ### Adding and Updating Models The models available in your environment are configured during onboarding based on your use case requirements. If your team needs access to additional models or a newer version of an existing model, this is handled through a request to your GLBNXT contact. GLBNXT validates, deploys, and tests the model before it appears in your Model Hub. Custom or fine-tuned models developed by your team can also be deployed into the Model Hub. Contact your GLBNXT contact to discuss the process for bringing a custom model into your environment. ### Model Transparency Every model in the Model Hub is clearly attributed. Your team can see which model is serving a given endpoint, which version is deployed, and what the model's training origin is. GLBNXT does not use your data to train or fine-tune models. Outputs generated by models in the Hub are never used to update or modify the underlying model weights. For further guidance on model serving and routing, see the Model Serving and Routing section. For guidance on embedding models and their role in RAG pipelines, see the RAG and Knowledge Systems section. # Running open-source models GLBNXT Platform makes a broad range of open-source language models available within your environment through a managed inference layer. Open-source models are served through Ollama, which handles model loading, serving runtime configuration, and endpoint management on your behalf. Your team connects to a stable model endpoint and works with open-source models in exactly the same way it works with any other model in the Model Hub, without any additional infrastructure or configuration required. This section explains how open-source models are made available on GLBNXT Platform, how to connect to them, and the considerations that apply when choosing and working with open-source models in production environments. ### How Open-Source Models Are Served Open-source models on GLBNXT Platform are served through Ollama, a managed inference runtime that supports a wide range of models from the open-source ecosystem. When a model is added to your environment, GLBNXT pulls the model, configures the serving runtime, allocates the appropriate compute resources, and exposes a stable API endpoint through the Model Hub. Your team does not interact with Ollama directly. It is a platform-managed component that operates transparently behind the model endpoints your applications call. All open-source models run entirely within your platform environment, within EU infrastructure. Model weights are loaded and served on compute resources dedicated to your environment and do not pass through any external system. Inference requests and responses stay within your sovereign boundary at all times. ### Connecting to an Open-Source Model Open-source models are accessed through the same endpoint structure as all other models in the Model Hub. To connect to a model, navigate to the Model Hub in your platform console and locate the model you want to use. The endpoint URL and authentication requirements are listed in the model details. Endpoints for open-source models served through Ollama are compatible with the OpenAI API format, meaning that applications and libraries built against the OpenAI API can connect to GLBNXT-hosted open-source models with minimal configuration changes. Replace the base URL with the endpoint URL from your Model Hub and provide the appropriate authentication credential. The rest of your application code requires no modification. ### Choosing the Right Open-Source Model Open-source models vary significantly in capability, size, and performance characteristics. The right choice for a given use case depends on the nature of the task, the quality requirements of the output, and the latency and throughput constraints of the application. As a general guide: **Larger models** produce higher quality outputs, handle complex reasoning tasks more reliably, and generalise better across a wide range of inputs. They consume more compute resources and have higher inference latency than smaller models. **Smaller models** respond faster, consume fewer compute resources, and are well suited for high-volume use cases where a simpler task is being performed at scale. They are less capable on complex reasoning tasks but often perform well on focused, well-defined tasks such as classification, extraction, or summarisation with a clear prompt. **Instruction-tuned models** are fine-tuned to follow natural language instructions and are the most appropriate choice for conversational assistants, question answering, and task-directed applications. Base models without instruction tuning are more suited for specialised fine-tuning use cases. If you are unsure which model is the best fit for your use case, your GLBNXT contact can advise based on your specific requirements and the models available in your environment. ### Model Availability and Requests The open-source models available in your environment are configured during onboarding. If your team requires access to a model that is not currently in your Model Hub, submit a request to your GLBNXT contact. GLBNXT reviews the request, validates the model, and deploys it into your environment before making the endpoint available in the Hub. GLBNXT maintains responsibility for validating that models added to your environment are appropriate for production use, correctly configured, and operating on compute resources that meet the performance requirements of your workloads. ### Model Updates and Versioning Open-source models are updated regularly by their maintainers. New versions may offer improved quality, expanded capabilities, or better performance characteristics compared to the version currently deployed in your environment. Model updates are managed by GLBNXT. When a new version of a model in your Hub is available and appropriate for production, GLBNXT can update the deployment following a review and validation process. Because a model update may affect the outputs your application produces, version changes are communicated in advance so your team can test against the new version before it is promoted to the production endpoint. If your application has strict consistency requirements, discuss model versioning and update policies with your GLBNXT contact during onboarding. ### Prompt Engineering for Open-Source Models Open-source models vary in how they respond to different prompting approaches. A prompt that works well with one model may produce different results with another, even for the same task. When building applications on GLBNXT Platform that use open-source models, it is worth investing time in prompt design and testing across your target model to understand how it responds to your specific inputs. Key prompt engineering practices that apply across most open-source models include being explicit about the task and the expected output format, providing examples where the desired behaviour is specific or nuanced, using system prompts to set consistent context and behavioural boundaries for conversational applications, and testing with a representative set of real inputs rather than idealised examples. For a broader introduction to effective prompting practices, refer to the Anthropic prompting documentation at docs.claude.ai. ### Observability and Usage All inference requests made to open-source model endpoints are logged by the platform and visible through the Monitoring and Observability area of the platform console. Request volumes, response latency, token consumption, and error rates are available for each model in the Hub. This data supports capacity planning, cost management, and compliance reporting for your environment. For guidance on how model usage data integrates with the broader observability and audit capabilities of the platform, see the Observability and Monitoring section. # Model evaluation & Versioning Model evaluation and versioning are the practices that ensure the AI models powering your applications continue to perform well over time. Evaluation gives your team a systematic way to measure model quality against defined criteria, identify regressions when models are updated, and compare models before deciding which to use in production. Versioning provides the control and traceability needed to manage model changes safely in environments where output quality and consistency matter. On GLBNXT Platform, evaluation and versioning capabilities are available through the observability and model management layer of your environment, with tooling that captures the data needed to assess model behaviour and the processes needed to manage model changes without disrupting production workloads. ### Why Evaluation Matters Deploying a model that works well in testing is the beginning, not the end, of managing model quality. AI models do not behave identically across all inputs. Edge cases, distribution shifts in real user queries, and changes introduced by model updates can all affect output quality in ways that are not visible from aggregate metrics alone. Systematic evaluation gives your team confidence that a model is performing as expected across the range of inputs it will encounter in production, and provides an early warning system when performance degrades. Without evaluation, model quality issues are typically discovered through user complaints or downstream effects rather than through proactive monitoring. ### Evaluation Approaches #### Offline Evaluation Offline evaluation assesses model performance against a fixed dataset of test cases before a model is deployed or updated. It is the primary quality gate for new models and model versions entering your environment. An offline evaluation dataset consists of representative inputs paired with expected outputs or quality criteria. The model being evaluated is run against each test case, and its outputs are scored against the defined criteria. Scores are compared against a baseline, typically the current production model, to determine whether the new model meets the quality bar required for deployment. Effective evaluation datasets are built from real inputs drawn from production usage rather than synthetic examples constructed during development. Real inputs capture the distribution of queries and edge cases that matter in your specific use case. Synthetic datasets tend to overrepresent idealised inputs and miss the long tail of real user behaviour. #### Online Evaluation Online evaluation assesses model performance in production using real user interactions as they occur. It complements offline evaluation by capturing quality signals that only emerge under real usage conditions, including inputs that were not anticipated during dataset construction and quality dimensions that are difficult to assess without real user context. Online evaluation on GLBNXT Platform is supported through LLM tracing tools available in your environment. These tools capture the full trace of each model interaction, including the input, the model output, and intermediate steps in any pipeline or agent workflow. Traces can be reviewed manually, scored using automated evaluation criteria, or sampled for human review on a defined schedule. #### Automated Evaluation For use cases where manual review of model outputs at scale is impractical, automated evaluation uses a secondary model or defined scoring functions to assess the quality of outputs produced by the primary model. Automated evaluation can measure dimensions such as factual accuracy against a reference, adherence to a defined output format, relevance of retrieved context in a RAG system, or compliance with behavioural guidelines defined in a system prompt. Automated evaluation is not a complete substitute for human judgement, particularly for use cases where quality is subjective or context-dependent. It is most effective as a high-volume screening mechanism that identifies outputs requiring closer review, combined with periodic human evaluation of a sampled subset. ### Evaluation Tooling on GLBNXT Platform GLBNXT Platform supports model evaluation through Langfuse and Opik, both available as managed services within your environment depending on your configuration. **Langfuse** provides LLM tracing, evaluation scoring, and dataset management for AI applications and pipelines. It captures traces of model interactions, allows evaluation scores to be attached to individual traces, and provides dashboards for tracking quality metrics over time. Langfuse is well suited for teams that want a comprehensive view of model performance across their applications with both automated and human evaluation workflows. **Opik** provides evaluation and observability capabilities focused on pipeline quality and output assessment. It supports the construction of evaluation datasets, automated scoring against defined criteria, and comparison of model versions across evaluation runs. Opik is well suited for teams running structured evaluation experiments as part of a model selection or update process. Both tools integrate with the model endpoints and application pipelines in your platform environment. Instrumentation is added at the application layer to capture the interaction data that evaluation workflows operate on. ### Model Versioning Model versioning provides the traceability and control needed to manage model changes safely. Every model in your Model Hub has a version that identifies the specific weights, configuration, and serving runtime in use. When a model is updated, the previous version is retained until the new version has been validated and promoted to production. #### Version Management Process When a new version of a model becomes available, whether through an update to an open-source model, a new release from a model provider, or a custom fine-tuned model developed by your team, GLBNXT follows a defined process before the new version reaches your production endpoint. The process follows these steps: 1. **Staging deployment:** the new model version is deployed to a staging endpoint within your environment that is separate from the production endpoint your applications currently use 2. **Evaluation:** your team runs offline evaluation against the staged version using your evaluation dataset, comparing scores against the current production baseline 3. **Review:** evaluation results are reviewed against the quality bar defined for your use case. Any regressions in key quality dimensions are investigated before proceeding 4. **Promotion:** once the new version meets the required quality bar, it is promoted to the production endpoint. The transition is managed by GLBNXT without requiring changes to your application configuration. 5. **Rollback retention:** the previous version remains available for a defined period after promotion, allowing your team to request a rollback if unexpected issues emerge in production #### Application Impact of Version Changes Because GLBNXT Platform manages model endpoints as stable API addresses, a model version update does not change the endpoint URL your applications call. Your application continues to call the same endpoint before and after a version update. The change is transparent at the infrastructure level. However, a model version update may change the outputs your application produces, even for identical inputs. This is the reason evaluation is required before promotion. For applications where output consistency is critical, such as those subject to regulatory requirements or integrated into downstream processes that depend on specific output formats, model version updates should be treated as controlled changes subject to your organisation's change management processes. #### Custom and Fine-Tuned Model Versioning If your team develops custom or fine-tuned models to deploy into the Model Hub, the same versioning principles apply. Each iteration of a custom model should be treated as a distinct version, evaluated against your quality criteria before deployment, and managed through the staging and promotion process rather than deployed directly to production endpoints. Maintaining a clear version history for custom models provides the traceability needed to understand how model behaviour has changed over time, identify the version responsible for a specific output if an issue is raised, and roll back to a previous version if a new iteration performs worse than expected. ### Building an Evaluation Practice Model evaluation delivers the most value when it is a consistent practice embedded in the development and deployment process rather than an occasional activity. The following principles support an effective evaluation practice on GLBNXT Platform. **Start with a small, high-quality dataset.** A focused set of representative test cases covering the core tasks and key edge cases of your use case is more valuable than a large dataset of low-quality or poorly representative examples. Grow the dataset over time by adding real production cases that surface quality issues. **Define quality criteria before deploying.** Agreeing what good looks like before a model goes into production gives your team a clear standard to evaluate against and prevents subjective judgements from varying across evaluation runs. **Evaluate before every significant change.** Model updates, prompt changes, retrieval configuration changes, and system prompt modifications can all affect output quality. Treating evaluation as a prerequisite for any significant change to the AI layer of an application catches regressions before they reach users. **Track quality metrics over time.** Point-in-time evaluation scores are less informative than trend data. Tracking evaluation metrics across model versions and over time provides the longitudinal view needed to understand whether model quality is improving, stable, or degrading as your application and its usage patterns evolve. For guidance on the observability tooling that supports evaluation workflows, see the Observability and Monitoring section. For guidance on how model serving and version management works at the infrastructure level, see the Model Serving and Routing section. # Security architecture Security on GLBNXT Platform is not a feature layer added on top of the infrastructure. It is built into the architecture at every level, from the physical data centre through to the application endpoints your team deploys. Every component in the platform stack operates within a security model designed to protect your data, your users, and your organisation's obligations to the people whose information you process. This section explains how the GLBNXT Platform security architecture is structured, what controls are in place at each layer, and how the shared responsibility model defines the boundary between what GLBNXT manages and what your organisation is responsible for. ### Defense in Depth GLBNXT Platform applies a defense-in-depth approach to security. Rather than relying on a single perimeter control, multiple independent layers of security controls are applied across the platform stack. A failure or bypass at one layer does not compromise the security of the system as a whole, because additional controls are in place at every layer beneath and beyond it. The security layers applied across the platform include physical infrastructure security, network isolation and access controls, identity and authentication controls, application-level access policies, secrets and credential management, audit and monitoring, and data protection at rest and in transit. Each layer is managed independently and assessed against the security requirements appropriate to its position in the stack. ### Physical and Infrastructure Security GLBNXT Platform runs entirely on EU-based infrastructure operated by data centre providers certified to recognised physical security standards. Physical access to the facilities hosting your environment is restricted to authorised personnel through multi-factor physical access controls. GLBNXT does not operate its own data centre facilities. It operates on infrastructure provided by certified European data center partners whose physical security posture is assessed as part of the GLBNXT vendor management process. All compute, storage, and networking components that form your platform environment run within this physically secured infrastructure boundary. No workloads, data, or network traffic leave the EU at any point in the processing of your requests. ### Network Security and Isolation Every platform environment is deployed within an isolated network boundary. Network segmentation ensures that your workloads are separated from other platform tenants at the infrastructure level. Internal service communication within your environment is encrypted in transit. External access to your environment is routed through managed ingress points with configurable access rules. Firewall policies, network access controls, and traffic routing for your environment are configured and maintained by GLBNXT. Outbound connectivity to approved external services is available and configurable for use cases that require integration with systems outside the platform. All inbound and outbound traffic is subject to the access controls and logging policies applied at the network layer. Distributed denial of service protection is applied at the network boundary. Traffic anomalies that indicate potential abuse or attack are detected and mitigated at the infrastructure level before they reach your application workloads. ### Identity and Authentication Access to GLBNXT Platform is controlled through a managed identity layer that supports integration with enterprise identity providers. Single sign-on via SAML and OAuth is available for organisations using Azure AD, Okta, Google Workspace, or other compatible identity providers. Users authenticate through their existing organisational identity, and platform access is governed by the roles and policies configured for their account. Multi-factor authentication is available and can enforced for all access to the platform and is strongly recommended for all user accounts. For environments using SSO, MFA is handled by the identity provider and applies the same policies as the rest of the organisation's access controls. Service-to-service authentication within the platform uses platform-managed tokens that are issued, rotated, and validated by the platform identity layer. Application workloads do not handle service authentication credentials directly. ### Role-Based Access Control Access to platform components, data services, model endpoints, and administrative functions is governed by role-based access control policies configured for your environment. Each user account is assigned a role that define the resources they can access and the actions they can perform. Role assignments are managed by your platform administrator through the platform console. The principle of least privilege applies to all role assignments: users and service accounts are granted access only to the resources they specifically require for their work. Roles are reviewed as part of the onboarding process and should be reviewed again whenever team membership or responsibilities change. For a detailed guide to configuring and managing roles in your environment, see the Access Control and Identity section. ### Data Protection Data in transit between platform components, between the platform and your users, and between the platform and authorised external services is encrypted using TLS 1.2 or higher. Unencrypted communication is not permitted within the platform environment. Certificate management and renewal is handled by GLBNXT. Data at rest and in transit within the platform never leaves the EU. Data residency guarantees are documented in your GLBNXT service agreement and data processing agreement. ### Vulnerability and Patch Management GLBNXT maintains responsibility for patching and updating all platform-managed components, including the operating systems, container runtimes, orchestration layer, database services, and platform application components that run within your environment. Security patches for critical and high-severity vulnerabilities in platform components are applied on an expedited basis following discovery and validation. Patch management for application-layer components developed by your team, including custom code, application containers, and third-party libraries used within your workloads, is a responsibility of your development team. GLBNXT can provide guidance on vulnerability scanning and dependency management practices appropriate for your environment. ### Penetration Testing and Security Assessment GLBNXT conducts regular security assessments of the platform infrastructure, including penetration testing by independent third-party security specialists. Assessment findings are reviewed and remediated according to their severity. Summary findings from platform-level assessments are available to enterprise customers as part of the GLBNXT Trust Centre documentation. If your organisation requires a penetration test of your specific platform environment, contact your GLBNXT contact to discuss the scope, process, and conditions applicable to customer-initiated security testing. ### Security Incident Response GLBNXT maintains a security incident response process that defines how platform-level security events are detected, contained, investigated, and resolved. The process includes defined responsibilities, escalation paths, and communication timelines for incidents affecting platform infrastructure and customer environments. In the event of a security incident affecting your environment, GLBNXT will notify your organisation through the contact channels defined during onboarding within the timeframes required by applicable data protection regulation, including GDPR Article 33 notification obligations where a personal data breach has occurred or cannot be ruled out. Your organisation maintains responsibility for incident response activities within the application layer, including investigating incidents that originate within your own application code, managing communications with your users and regulators, and fulfilling any notification obligations that arise from incidents within your sphere of responsibility. ### Shared Responsibility Model Security on GLBNXT Platform operates under a shared responsibility model. Understanding the boundary between GLBNXT's responsibilities and your organisation's responsibilities is essential for maintaining a complete and coherent security posture. **GLBNXT is responsible for:** * Physical infrastructure security * Network isolation, firewall management, and DDoS protection * Platform component patching and vulnerability management * Encryption at rest and in transit for platform-managed data * Secrets vault infrastructure and access policy enforcement * Identity provider integration and MFA for platform access * Security monitoring, alerting, and incident response for platform-level events * Compliance certifications and audit evidence for the platform layer **Your organisation is responsible for:** * Role assignments and access control configuration for your team * Security of application code and custom workloads deployed on the platform * Patch management for dependencies and libraries within your application containers * Data classification and handling policies for data processed by your applications * User awareness and secure use of platform access credentials * Compliance obligations specific to your industry, jurisdiction, and data processing activities * Security review and governance of the AI applications and workflows you build and deploy Neither party's responsibilities can substitute for the other's. A platform that is securely operated by GLBNXT but accessed through poorly managed credentials, or that runs well-secured infrastructure beneath poorly designed application code, does not achieve the security outcomes either party intends. The shared responsibility model works when both sides fulfill their obligations consistently. For guidance on the compliance frameworks that build on this security architecture, see the Compliance Frameworks section. For guidance on configuring access controls within your environment, see the Access Control and Identity section. # Access control & Identity Access control and identity management are the mechanisms that determine who can access your GLBNXT Platform environment, what they can do within it, and how those permissions are enforced consistently across every component. A well-configured access control model ensures that users, service accounts, and application workloads have exactly the access they need and nothing more, reducing the risk of both accidental misuse and deliberate exploitation of overprivileged accounts. On GLBNXT Platform, access control is applied at every layer of the environment: the platform console, model endpoints, data services, application workloads, and administrative functions. Identity management integrates with your organisation's existing identity provider, so platform access aligns with the same policies and controls that govern the rest of your technology estate. ### Identity and Authentication Every user accessing GLBNXT Platform authenticates through a managed identity layer before reaching any platform resource. Authentication can be configured in two ways depending on your organisation's setup. #### SSO Integration For organisations using an enterprise identity provider, GLBNXT Platform supports single sign-on via SAML and OAuth 2.0. Supported identity providers include Azure Active Directory, Okta, and Google Workspace. When SSO is configured, users authenticate through their existing organisational identity and are granted platform access based on the roles assigned to their account. Password management, MFA enforcement, and session policies are handled by the identity provider and apply the same standards as the rest of your organisation's systems. SSO integration is the recommended configuration for all enterprise deployments. It ensures that platform access is governed by your organisation's centralised identity and access management policies, that user accounts are automatically deprovisioned when an employee leaves, and that MFA and session controls are enforced consistently without requiring separate configuration in the platform. #### Direct Login For environments where SSO has not been configured, users log in using credentials issued directly by GLBNXT. Direct login credentials are managed through the platform console. Users should update their password on first login and enable multi-factor authentication immediately. Direct login is appropriate for initial onboarding and evaluation environments but should be replaced with SSO integration for production deployments. ### Multi-Factor Authentication Multi-factor authentication is enforced by default for all administrator accounts on GLBNXT Platform and strongly recommended for all user accounts. For environments using SSO, MFA is handled by the identity provider. For direct login accounts, MFA is configured through the account settings in the platform console. MFA significantly reduces the risk of account compromise from credential theft. In regulated environments or environments processing sensitive data, MFA should be treated as a mandatory control for all accounts regardless of role. ### Role-Based Access Control Access to platform resources is governed by role-based access control. Roles define the combination of resources a user can access and the actions they can perform on those resources. Users are assigned one or more roles that reflect their responsibilities within the platform environment. GLBNXT Platform provides a set of standard roles applicable to most development team configurations. **Administrator** has full access to all platform components, user management, environment configuration, and administrative functions. Administrator access should be limited to the smallest number of individuals who genuinely require it. Administrative actions are logged in full as part of the platform audit trail. **Developer** has access to applications, model endpoints, data services, workflow builders, and development tooling. Developers can build, configure, and test solutions within the platform but do not have access to user management or environment-level administrative controls. **Data Engineer** has access to data services, ingestion pipelines, vector database configuration, and storage components relevant to data engineering work. Access to model endpoints and application frontends may be included depending on your environment configuration. **Viewer** has read-only access to selected platform components and dashboards. This role is suited for stakeholders who need visibility into platform activity or application outputs without making changes to any configuration or workload. Custom roles can be configured for organisations whose access requirements do not map to the standard role set. Contact your GLBNXT contact to discuss custom role configuration for your environment. ### Principle of Least Privilege All role assignments on GLBNXT Platform should follow the principle of least privilege. Every user account and service account should be granted access only to the resources it specifically requires to fulfil its defined purpose. Overprivileged accounts increase the potential impact of a compromised credential and create unnecessary risk from accidental misconfiguration or misuse. Applying least privilege in practice means resisting the temptation to assign broad roles for convenience. A developer who needs access to a specific set of model endpoints and a specific database instance should be granted access to those specific resources, not given platform-wide developer access because it is easier to configure. The additional configuration effort is small. The reduction in risk is significant. ### Service Account Access Application workloads running on GLBNXT Platform authenticate to platform services using service accounts rather than user credentials. Service accounts are identities assigned to application workloads that grant them access to the specific platform resources they need to function, such as a model endpoint, a database connection, or a storage bucket. Service account credentials are managed through the platform secrets vault and injected into workloads at runtime. Application code never handles service account credentials directly. This ensures that credentials cannot be accidentally exposed in source code or configuration files, and that credential rotation does not require changes to application logic. Service accounts should follow the same least privilege principle as user accounts. Each application workload should have a dedicated service account with access scoped to exactly the resources that workload requires. ### User Provisioning and Deprovisioning User accounts on GLBNXT Platform are provisioned during onboarding based on the access list provided by your organisation. For environments using SSO, provisioning and deprovisioning can be automated through your identity provider's user lifecycle management capabilities, ensuring that platform access is granted and revoked in synchronisation with the rest of your organisation's systems. For environments using direct login, user provisioning and deprovisioning is managed through the platform console by your platform administrator. Deprovisioning should be performed promptly when a team member leaves the organisation or changes role. Accounts that are no longer required but remain active represent an unnecessary security risk. Conducting a periodic access review to verify that all active accounts have appropriate role assignments for their current responsibilities is recommended practice for any production platform environment. ### Access Logs and Auditability All access events on GLBNXT Platform are logged as part of the platform audit trail. This includes user login and logout events, failed authentication attempts, role assignment changes, access to model endpoints and data services, administrative actions, and service account authentication events. Access logs are immutable, timestamped, and retained according to the compliance requirements of your environment. They are available through the Monitoring and Observability area of the platform console and can be exported for integration with your organisation's SIEM, compliance, or audit tooling. For regulated environments, access logs form part of the evidence base that demonstrates compliance with data protection and information security obligations. Ensuring that logging is active and correctly configured for your environment should be verified as part of the onboarding process and reviewed periodically. ### Configuring Access Controls for Your Environment Access control configuration for your environment is established during onboarding in collaboration with your GLBNXT contact. The recommended steps for configuring access controls are: 1. Define the roles required for your team based on the responsibilities of each member and the access each role needs 2. Configure SSO integration with your identity provider before provisioning user accounts 3. Create user accounts and assign roles based on the access list agreed during onboarding 4. Configure service accounts for each application workload with access scoped to the specific resources that workload requires 5. Enable MFA for all accounts where it is not already enforced through your identity provider 6. Verify that access logs are active and capturing events correctly 7. Schedule a periodic access review to keep role assignments aligned with current team responsibilities For guidance on the security architecture that access control operates within, see the Security Architecture section. For guidance on secrets management and service account credential handling, see the Secrets and Credential Management section. # Data sovereignity Data sovereignty is one of the foundational principles of GLBNXT Platform. It means that your organisation retains full control over where your data is stored, how it is processed, and who can access it. Every architectural decision in the platform is made with sovereignty as a non-negotiable constraint. No data processed on GLBNXT Platform leaves the European Union, and no component of the platform creates a dependency on infrastructure or services outside the EU. For European organisations operating under GDPR, NIS2, or sector-specific data protection obligations, and for organisations that have made explicit commitments to their clients about data residency, GLBNXT Platform provides the infrastructure foundation and contractual guarantees needed to meet those obligations with confidence. ### What Data Sovereignty Means on GLBNXT Platform Data sovereignty on GLBNXT Platform covers four dimensions that together ensure your organisation maintains genuine control over its data. **Geographic residency** means that all data stored and processed on the platform remains physically within the European Union at all times. This applies to data at rest in databases, object storage, and vector databases, and to data in transit between platform components during processing. No inference request, document, conversation, or application payload passes through infrastructure located outside the EU. **No third-party model training** means that data processed through GLBNXT Platform is never used to train, fine-tune, or improve AI models operated by third parties. Inference requests sent to models in your Model Hub are processed within your environment and do not flow to any external model provider. GLBNXT does not use your data for any purpose beyond delivering the platform services you have contracted for. ### EU Infrastructure GLBNXT Platform runs on data centre infrastructure located within the European Union. The specific infrastructure region used for your environment is confirmed during onboarding and documented in your service agreement. If your organisation operates under requirements that specify a particular EU member state for data residency, discuss this with your GLBNXT contact during onboarding. Deployments can be scoped to specific geographic regions within the EU where requirements demand it. All data centre facilities hosting GLBNXT Platform infrastructure are operated by European providers certified to recognised security and compliance standards. Physical security, environmental controls, and operational procedures for these facilities are assessed as part of the GLBNXT vendor management process. ### Compliance with NIS2 The Network and Information Security Directive 2 imposes security and resilience obligations on operators of essential and important services across the EU. GLBNXT Platform supports NIS2 compliance through its managed security architecture, incident response capabilities, supply chain security practices, and the audit and reporting capabilities available in your environment. For organisations in scope for NIS2, your GLBNXT contact can provide documentation of the platform's security measures relevant to NIS2 obligations, and can advise on how platform capabilities support your organisation's own NIS2 compliance programme. # Data Location Is Not Data Control A common assumption in cloud security is that storing data in a European data centre is sufficient to guarantee European data sovereignty. It is not. The physical location of data and the legal control over that data are two fundamentally different things, and conflating them creates a false sense of compliance. When an organisation stores data with a provider headquartered in the United States, that data remains subject to US jurisdiction regardless of where it is physically hosted. This is the direct consequence of the US Clarifying Lawful Overseas Use of Data Act, commonly known as the CLOUD Act, enacted in March 2018. The CLOUD Act grants US law enforcement agencies the authority to compel any US based company to disclose data in its possession, custody, or control, even when that data resides on servers located in the European Union. The law applies to the corporate entity, not the data centre address. This creates an irreconcilable conflict with the European General Data Protection Regulation. Article 48 of the GDPR explicitly states that court orders or judgments from third country authorities are not, in themselves, a lawful basis for transferring personal data out of the EU. The European Data Protection Board has confirmed this position, concluding that service providers subject to EU law cannot legally base the disclosure of personal data to US authorities on CLOUD Act requests alone. Yet the CLOUD Act requires precisely that, and it does so without requiring notification to the affected data subject or cooperation with European judicial authorities. The practical consequence is stark. A US headquartered cloud provider operating data centres in Frankfurt, Amsterdam, or Paris is still legally obligated to comply with a US government data access request. Contractual commitments to challenge such requests, while commercially reassuring, are subordinate to the provider's obligations under US federal law. The CJEU's Schrems II ruling invalidated the EU US Privacy Shield on exactly this basis: US surveillance law provides access to European personal data in ways that are incompatible with GDPR, and European citizens lack effective judicial redress within the US legal system. #### Why GLBNXT Works Exclusively with European Vendors GLBNXT addresses this structural conflict at its root. Rather than relying on contractual workarounds or data residency configurations layered on top of US controlled infrastructure, GLBNXT exclusively partners with technology vendors that are headquartered in Europe and operate under European legal jurisdiction. This is a deliberate architectural decision, not a preference. When every vendor in the supply chain is a European legal entity, no component of the platform is subject to the CLOUD Act or any equivalent extraterritorial data access legislation from non European governments. There is no corporate parent in a foreign jurisdiction that could be compelled to hand over data. There is no legal mechanism through which a non European authority can bypass European courts to demand access to information processed on the GLBNXT platform. This approach delivers sovereignty that is structural rather than contractual. It means that GDPR, NIS2, and other European regulatory frameworks are the sole applicable data protection regime, without conflict from foreign legislation. It means that data access requests can only be made through proper European legal channels, with full judicial oversight and due process protections for data subjects. And it means that the organisations using GLBNXT do not inherit the compliance risk that comes with any dependency on a US controlled provider. For organisations operating in regulated sectors, handling sensitive public sector data, or simply taking their GDPR obligations seriously, this distinction between data location and data control is not academic. It is the difference between a sovereignty claim and a sovereignty guarantee. # Audit logs & Query history Audit logs and query history provide the complete, tamper-evident record of activity within your GLBNXT Platform environment. Every significant action taken by users, applications, and platform services is captured, timestamped, and retained as part of an immutable audit trail. This record supports regulatory compliance, internal governance, security incident investigation, and the operational visibility your team needs to understand exactly what has happened in your environment at any point in time. On GLBNXT Platform, audit logging is active by default from the moment your environment is provisioned. There is no configuration required to begin capturing audit data, and no activity that falls outside the scope of the audit trail by default. ### What Is Logged The audit trail on GLBNXT Platform captures events across every layer of the environment. Log coverage includes the following categories. **Authentication and access events** capture every login attempt, successful or failed, along with session establishment and termination, MFA verification outcomes, and SSO authentication events processed through your identity provider integration. **User and administrative actions** capture changes made to user accounts, role assignments, environment configuration, access control policies, and any other administrative action performed through the platform console or the platform API. **Model inference requests** capture a record of every request made to a model endpoint within your environment, including the timestamp, the requesting user or service account, the model endpoint called, and, depending on your compliance configuration, the request and response content. **Data access events** capture access to data services within your environment, including queries to Postgres databases, retrieval operations against vector databases, and read and write operations to MinIO object storage. **Secrets vault access** captures every instance of a workload or service authenticating to the secrets vault and retrieving a credential, along with the identity of the requesting entity and the secret name accessed. **Workflow and agent executions** capture the initiation, progress, and completion of workflow automation runs and agent task executions, including the steps taken, tools called, and outcomes produced at each stage. **API calls** capture requests made to platform API endpoints from external systems, including the calling identity, the endpoint accessed, and the response status. ### Audit Log Integrity Audit logs on GLBNXT Platform are immutable once written. No user, including platform administrators, can modify or delete audit log entries. This immutability is a requirement for audit logs to serve as reliable evidence in compliance assessments, regulatory enquiries, or internal investigations. Log integrity is maintained through the platform's centralised log management infrastructure, which is separate from the application and operational components of the environment. The separation ensures that a security incident affecting application workloads cannot affect the completeness or integrity of the audit record. ### Query History Query history provides a detailed record of the questions, prompts, and interactions that users and applications have submitted to AI models within your environment. For organisations subject to regulatory requirements that mandate records of AI system inputs and outputs, query history provides the evidence base needed to demonstrate that AI processing activities are traceable and reviewable. Query history captures the following for each model interaction: * Timestamp of the request * Identifier of the user or service account that submitted the request * The model endpoint called * The input submitted to the model * The output returned by the model * Latency and token consumption for the interaction The retention of input and output content in query history is configurable based on your compliance requirements and data protection obligations. For environments processing personal data through AI model interactions, query history retention policies should be aligned with your data processing agreement and your organisation's data minimisation obligations under GDPR. ### Accessing Audit Logs Audit logs are accessible through the Monitoring and Observability area of the platform console. Logs are searchable and filterable by event type, time range, user identity, resource accessed, and other relevant attributes. This allows your compliance, security, or operations teams to retrieve specific log records quickly without needing to review the full audit stream. Access to audit logs within the platform console is governed by role-based access controls. Administrator accounts have full access to the complete audit trail. Developer and standard user accounts do not have access to audit log data by default, preventing application team members from viewing the activity records of their colleagues or modifying their own access history. ### Exporting Audit Logs For organisations that need to integrate audit log data with existing compliance, SIEM, or log management tooling, GLBNXT Platform supports audit log export. Logs can be exported in structured formats compatible with common log management platforms and SIEM solutions. Log export can be configured as a continuous stream that forwards new audit events to your external tooling in near real time, or as a scheduled batch export that delivers log data at defined intervals. Contact your GLBNXT contact to discuss the appropriate export configuration for your environment and your tooling. ### Retention Policies Audit logs are retained for a minimum period defined in your service agreement, aligned with the regulatory requirements applicable to your environment. The default retention period is designed to satisfy common compliance frameworks including GDPR, ISO 27001, and NIS2. If your organisation requires a longer retention period to satisfy sector-specific regulatory obligations or internal governance requirements, extended retention can be configured for your environment. Discuss your retention requirements with your GLBNXT contact during onboarding to ensure that the retention policy applied to your environment meets your obligations from day one. Log data that has passed its retention period is deleted permanently and securely in accordance with the data destruction standards applied across the GLBNXT Platform infrastructure. ### Using Audit Logs for Compliance Audit logs on GLBNXT Platform are designed to support the evidence requirements of common compliance frameworks and regulatory obligations. **GDPR** requires organisations to maintain records of processing activities and to be able to demonstrate that personal data is processed lawfully, fairly, and transparently. Audit logs provide evidence of who accessed personal data, when, and for what purpose, supporting both internal accountability and regulatory enquiry responses. **ISO 27001** requires organisations to maintain audit logs of user activities, exceptions, and information security events, and to protect log information from tampering and unauthorised access. The platform's immutable, access-controlled audit trail directly satisfies these requirements at the platform layer. **NIS2** requires operators of essential and important services to maintain logging and monitoring capabilities sufficient to detect and investigate security incidents. The platform's comprehensive audit coverage and SIEM integration capabilities support NIS2 incident detection and reporting obligations. **Sector-specific regulations** in financial services, healthcare, and public sector frequently impose additional logging and record-keeping requirements. If your organisation operates under sector-specific obligations that go beyond the default platform logging configuration, contact your GLBNXT contact to confirm that your environment is configured to meet those requirements. ### Using Audit Logs for Security Investigation In the event of a suspected security incident, the audit trail provides the primary data source for investigating what happened, when, and which resources were affected. The combination of authentication events, data access records, API call history, and secrets vault access logs gives your security team the forensic visibility needed to reconstruct the sequence of events leading to and following a security incident. When investigating a security event, the recommended approach is to begin with the authentication logs for the relevant time window, identify any anomalous access patterns, cross-reference those patterns with data access and API call logs, and trace the activity of any suspicious identities across the full audit trail for the period in question. For platform-level security incidents, GLBNXT's security team will conduct its own investigation using the platform audit infrastructure and share relevant findings with your organisation through the incident response process described in the Security Architecture section. # Model transparency controls Model transparency is a core principle of GLBNXT Platform. Every AI model serving inference requests in your environment is clearly attributed, its provenance is documented, and your organisation retains full visibility into which model produced which output. There are no black-box AI layers operating behind anonymous endpoints, no undisclosed model substitutions, and no scenario in which your applications are routing requests to a model your team has not explicitly selected and approved. For organisations deploying AI in regulated sectors, for teams building products that must meet emerging AI governance requirements, and for any organisation that takes its accountability obligations seriously, model transparency is not an optional extra. It is a prerequisite for responsible AI deployment. GLBNXT Platform is designed to make it straightforward to achieve. ### Model Attribution Every model available in your environment through the Model Hub is clearly identified. For each model, the following information is available. **Model identity:** the name, version, and family of the model, identifying precisely which model is serving requests on a given endpoint. There is no scenario in which a request you believe is being processed by one model is silently routed to a different one. **Model provenance:** the origin of the model, including its developer, training approach, and the source from which it was obtained, whether that is the open-source community, a model provider, or a custom training run conducted by your team. **Serving runtime:** the inference runtime through which the model is served, either Ollama for open-source models or NVIDIA NIM for optimised production inference, along with the version of the serving runtime in use. **Version history:** a record of previous model versions deployed on each endpoint in your environment, supporting traceability for any output produced during a prior version's deployment period. Model attribution information is available in the Model Hub area of the platform console and is captured in the audit trail for every inference request. ### No Training on Your Data GLBNXT Platform does not use data processed through your environment to train, fine-tune, evaluate, or improve any AI model. Inference requests submitted by your applications and users are processed within your environment and returned to the requesting application. They do not flow to any external model provider, do not contribute to any training dataset, and do not result in any modification to model weights. This guarantee applies to all models served through the platform, including open-source models served through Ollama, models served through NVIDIA NIM, and any custom models deployed into your environment. The data your organisation processes through AI models on GLBNXT Platform remains yours and is used exclusively to serve the requests you submit. For organisations with contractual obligations to clients about how client data is handled in AI systems, this guarantee provides the foundation for those commitments. It is documented in the GLBNXT data processing agreement and service contract. ### Explainability and Output Traceability Transparent AI deployment requires not only knowing which model produced an output but being able to trace how that output was produced. GLBNXT Platform supports output traceability through the audit logging and LLM tracing capabilities available in your environment. For every model interaction, the audit trail captures the model endpoint called, the input submitted, and the output returned. This creates a complete, immutable record of every AI-generated output produced in your environment, linked to the specific model version that produced it. If a question is raised about a specific output, your team can retrieve the exact input, model, and context that produced it. For applications built on RAG pipelines or agent workflows, LLM tracing provides a deeper level of output traceability. Traces capture not only the final model output but every intermediate step: the retrieval results that were used as context, the tool calls the model made, the intermediate outputs produced at each reasoning step, and the full chain of events that led to the final response. This level of traceability is particularly important for regulated use cases where the basis for an AI-assisted decision may need to be explained and justified. ### Model Governance Model transparency controls extend to how models enter and change within your environment. GLBNXT Platform applies a managed model governance process that ensures your team always knows what is running in your environment and has approved it before it goes into production. **Model onboarding review:** before a new model is made available in your Model Hub, GLBNXT validates the model against defined criteria covering its provenance, capability, and suitability for the platform environment. Models are not added to production environments without a review and deployment process that your team participates in. **Version change notification:** when a model version in your environment is being updated, your team is notified in advance. Version changes are not applied silently. Your team has the opportunity to evaluate the new version against your quality criteria before it is promoted to the production endpoint. **Custom model governance:** custom or fine-tuned models developed by your team and deployed into the Model Hub are subject to the same versioning and promotion process as other models. Each version is distinct, tracked, and deployed through a controlled process rather than pushed directly to production endpoints. ### AI Act Alignment The EU AI Act introduces a risk-based regulatory framework for AI systems, with transparency and documentation requirements that apply to providers and deployers of AI across different risk categories. GLBNXT Platform's model transparency controls are designed to support compliance with AI Act obligations as the regulation comes into effect. Relevant capabilities that support AI Act alignment include: **Technical documentation:** model attribution, provenance documentation, and version history provide the basis for the technical documentation requirements that apply to AI systems under the AI Act. **Logging and auditability:** the platform's comprehensive audit trail and LLM tracing capabilities support the record-keeping requirements for high-risk AI systems, including the ability to demonstrate that AI outputs are traceable to specific model versions and inputs. **Human oversight:** the platform architecture supports the implementation of human oversight mechanisms for AI systems where the AI Act requires that human review is possible and that outputs are not acted upon automatically in high-risk contexts. **Transparency to users:** for AI systems deployed to end users, the platform's frontend and API components support the implementation of transparency measures required by the AI Act, including disclosure that users are interacting with an AI system. The AI Act's requirements are phased in over time and apply differently depending on the risk category of the AI system in question. Your legal and compliance teams should assess the specific obligations applicable to each AI application your organisation deploys and ensure that application-level controls address those obligations in addition to the platform-level transparency controls described in this section. ### Responsible AI Practices Model transparency controls are one dimension of responsible AI deployment. GLBNXT Platform provides the technical foundation for transparent, accountable AI. Your organisation is responsible for the governance practices that make use of that foundation effectively. Practices that complement the platform's transparency controls and contribute to responsible AI deployment include: **Maintaining an AI system register:** documenting each AI application deployed on the platform, the model or models it uses, the purpose for which it is deployed, the data it processes, and the users or processes it affects. This register provides the organisational visibility that complements the technical audit trail. **Defining acceptable use policies:** establishing clear guidelines for how AI applications in your environment should and should not be used, communicated to users and enforced through system prompt configuration and access controls. **Conducting pre-deployment risk assessments:** evaluating the potential impacts of a new AI application before it is deployed to users, particularly for applications used in high-stakes contexts such as hiring, lending, healthcare, or legal processes. **Reviewing AI outputs in high-stakes contexts:** implementing human review checkpoints for AI-assisted decisions that have significant consequences for individuals, ensuring that the efficiency benefits of AI do not come at the cost of appropriate human accountability. **Monitoring for bias and quality drift:** using the evaluation and monitoring capabilities of the platform to track model output quality over time and identify patterns that may indicate bias, degradation, or unexpected behaviour in production. For guidance on the audit and logging capabilities that underpin model transparency on GLBNXT Platform, see the Audit Logs and Query History section. For guidance on evaluation tooling that supports ongoing model quality monitoring, see the Model Evaluation and Versioning section. # Supported open-source tools GLBNXT Platform is built on open-source technology. Every component in the platform stack is drawn from the open-source ecosystem, made enterprise-ready, and delivered as a managed service within your environment. Your team works with the best open tools available without carrying the operational burden of deploying, configuring, patching, and maintaining them. GLBNXT handles that entirely. This section provides an overview of the open-source tools available on GLBNXT Platform, organised by the role each plays in the platform stack. Not every tool listed here is available in every environment by default. The specific stack configured for your organisation is agreed during onboarding based on your use case requirements. Contact your GLBNXT contact if you need a tool that is not currently available in your environment. ### Open-Source Tools by Category | Tool | Category | Description | | -------------------- | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **OpenWebUI** | AI Assistants and Chat Interfaces | Self-hosted chat interface for interacting with language models, supporting multi-model conversations and RAG-based chat | | **LibreChat** | AI Assistants and Chat Interfaces | Flexible open-source chat interface supporting multiple AI backends, conversation management, and agent capabilities | | **Jupyter Notebook** | Development and Experimentation | Interactive computing environment for data science, model experimentation, and AI development workflows | | **n8n** | Workflow Automation and Orchestration | Visual workflow automation platform connecting AI models, APIs, databases, and external services through a node-based interface | | **Langflow** | Workflow Automation and Orchestration | Visual builder for AI pipelines and RAG workflows, suited for prototyping and iterating on language model chains | | **LangChain** | AI Development Framework | Open-source framework for building applications with language models, supporting chains, agents, and retrieval workflows | | **LiteLLM Proxy** | Model Serving and Routing | Unified API proxy that standardises access to multiple language model providers behind a single consistent interface | | **Langfuse** | Observability and Monitoring | LLM tracing, evaluation scoring, and dataset management for tracking model quality and performance across AI applications | | **PostgreSQL** | Data Storage and Management | Relational database for structured data storage, application state, conversation history, and transactional workloads | | **PGVector** | Vector Storage and Retrieval | PostgreSQL extension enabling vector similarity search directly within a relational database, suited for lightweight RAG use cases | | **Weaviate** | Vector Storage and Retrieval | Dedicated vector database designed for semantic search, hybrid retrieval, and multi-modal data handling at scale | | **Qdrant** | Vector Storage and Retrieval | High-performance vector database optimised for low-latency retrieval under high query loads in production RAG pipelines | | **Elasticsearch** | Search and Analytics | Full-text search and analytics engine supporting hybrid retrieval combining keyword and vector search across large document sets | | **MinIO** | Data Storage and Management | S3-compatible object storage for documents, model artefacts, binary files, and unstructured content within the platform environment | ### Model Serving and Inference **Ollama** is the primary inference runtime for open-source language and embedding models on the platform. It supports a wide range of models from the open-source ecosystem and exposes them through a consistent API compatible with standard AI development frameworks. GLBNXT manages Ollama deployment, model loading, and version management within your environment. **NVIDIA NIM** provides hardware-optimised model serving for production inference workloads that require high throughput and low latency. NIM runs on NVIDIA GPU infrastructure and is suited for user-facing applications and high-volume API services where inference performance is a critical requirement. **Hugging Face** provides access to the open-source model registry from which models can be pulled and deployed into your environment. Models sourced from Hugging Face are validated and served through the platform's managed inference layer rather than called externally, keeping all inference within your sovereign boundary. ### AI Assistants and Chat Interfaces **Open WebUI** is a feature-rich, self-hosted chat interface that provides a conversational frontend for interacting with language models. It supports multi-model conversations, document uploads, retrieval-augmented chat, and a range of configuration options for assistant behaviour. Open WebUI is available as a managed application within your environment and is the primary chat interface for GLBNXT Workspace deployments. **LibreChat** is an open-source chat interface that supports multi-model interaction, conversation management, and integration with a range of AI backends. It is suited for deployments requiring a flexible, configurable chat experience with support for multiple models and agent capabilities within the same interface. ### Workflow Automation and Orchestration **n8n** is a workflow automation platform that enables teams to build complex automated processes connecting AI models, APIs, databases, and external services through a visual node-based interface. It supports over one thousand service integrations and is the primary low-code workflow automation tool on GLBNXT Platform. **Langflow** is a visual builder for AI pipelines and workflows with a focus on language model chains, RAG systems, and agent configurations. It is particularly suited for prototyping and iterating on AI pipeline designs before committing to a production architecture, and for teams who prefer a visual approach to constructing model chains and retrieval workflows. ### Vector Databases **Weaviate** is a vector database designed for semantic search, multi-modal data handling, and hybrid retrieval combining vector similarity with structured metadata filtering. It supports automatic vectorisation at ingestion time and is well suited for knowledge base applications and document retrieval systems that require both semantic and keyword-based search. **Qdrant** is a high-performance vector database optimised for low-latency retrieval at scale. It is suited for production RAG pipelines and real-time AI applications where retrieval speed under load is a critical requirement. ### Data Storage and Management **Postgres** is the relational database service available on GLBNXT Platform, used for structured data storage, application state management, conversation history, and any use case requiring SQL querying, relational data models, or transactional consistency. Postgres is a foundational component of most AI application architectures on the platform. **Supabase** provides a developer-friendly layer on top of Postgres, adding authentication, real-time data subscriptions, and a REST API that makes it straightforward to build data-backed applications without writing custom database access layers. It is suited for teams who want the power of Postgres with a more accessible developer interface. **MinIO** provides S3-compatible object storage within your platform environment for storing large unstructured data including documents, images, model artefacts, and binary files. Any tool or library that works with the S3 API works with MinIO on GLBNXT Platform without modification. **Elasticsearch** provides full-text search, log analytics, and hybrid retrieval capabilities combining keyword and vector search. It is suited for applications that need to search across large document sets using structured queries and full-text matching, and for observability use cases where log data needs to be indexed and queried efficiently. ### Observability and Monitoring **Langfuse** provides LLM tracing, evaluation scoring, and dataset management for AI applications and pipelines. It captures traces of model interactions, supports automated and human evaluation workflows, and provides dashboards for tracking quality and performance metrics over time. Langfuse is the primary LLM observability tool on GLBNXT Platform. **Opik** provides evaluation and observability capabilities focused on pipeline quality and output assessment. It supports evaluation dataset construction, automated scoring against defined criteria, and comparison of model versions across evaluation runs, making it well suited for structured model evaluation and selection processes. ### Kubernetes Orchestration and Infrastructure **Rancher** is the Kubernetes management platform used by GLBNXT to orchestrate containerised workloads across the platform infrastructure. It provides the control plane for container scheduling, deployment management, scaling, and cluster health monitoring across your environment. Rancher is a platform-managed component that operates transparently beneath your applications. ### Open Standards and No Lock-In Every tool in the GLBNXT Platform stack is open-source and built on open standards. There are no proprietary data formats, no black-box components, and no lock-in to GLBNXT as a vendor at the tool level. If your organisation's requirements change, the underlying technology remains fully accessible and portable. GLBNXT's role is to take these tools, make them enterprise-ready, integrate them into a coherent managed platform, and operate them reliably within a sovereign, compliant environment. The value GLBNXT adds is in the orchestration, the operational management, and the security and compliance layer that sits across the full stack. The tools themselves remain open. As the open-source AI ecosystem evolves rapidly, GLBNXT continuously evaluates new tools and updates the platform stack to include components that meet the quality, security, and reliability standards required for enterprise production environments. If your team is working with an open-source tool not listed here that you would like to see available in your environment, contact your GLBNXT contact to discuss its suitability for inclusion. # Integration patterns AI applications built on GLBNXT Platform rarely operate in isolation. They connect to existing enterprise systems, consume data from sources outside the platform, push outputs to downstream processes, and interact with the broader technology landscape of your organisation or your clients. Integration patterns are the established approaches for making these connections reliably, securely, and in ways that are maintainable as both the platform and the systems it connects to evolve over time. This section describes the most common integration patterns used in GLBNXT Platform deployments, the considerations that apply to each, and guidance on choosing the right pattern for your use case. ### Inbound Data Integration Inbound data integration covers the patterns by which data from systems outside the platform is brought into your environment for use by AI applications. The right pattern depends on the volume and velocity of data involved, the nature of the source system, and whether data needs to be available in real time or can be processed in batches. #### Batch Ingestion Batch ingestion processes data from a source system at defined intervals rather than continuously. A scheduled process retrieves data from the source, transforms it into the format required by the platform component that will consume it, and loads it into the appropriate storage layer, whether that is MinIO for unstructured documents, Postgres for structured records, or a vector database for content that will be retrieved semantically. Batch ingestion is the most straightforward integration pattern and is appropriate for use cases where data does not need to be available immediately after it is created or updated in the source system. Document-based knowledge bases, reference datasets, and reporting pipelines that run on a defined cadence are all well suited to batch ingestion. Workflow automation is the primary tool for implementing batch ingestion on GLBNXT Platform. Scheduled triggers initiate the ingestion workflow, which retrieves data from the source, applies any required transformation, and loads it into the target storage layer. Error handling and retry logic can be configured within the workflow to manage source system unavailability or data quality issues without manual intervention. #### Event-Driven Ingestion Event-driven ingestion processes data as soon as it is created or updated in the source system, rather than waiting for a scheduled batch run. The source system emits an event when data changes, a webhook or message queue listener in the platform receives the event, and an ingestion workflow processes the new or updated data immediately. Event-driven ingestion is appropriate for use cases where data freshness is important, such as RAG systems that need to reflect recent document updates, real-time classification pipelines, and AI-assisted processes where decisions are made shortly after data is created. Implementing event-driven ingestion requires the source system to support webhook delivery or message queue publishing. Where source systems do not support these mechanisms natively, a polling approach, in which the platform periodically checks for new or updated records, can approximate event-driven behaviour with a defined latency trade-off. #### API-Based Data Retrieval For AI applications that need access to live data at query time rather than indexed data retrieved from a platform-managed store, API-based data retrieval calls the source system directly as part of processing a user request or agent task. A model or workflow step makes an authenticated API call to the source system, receives the current data, and incorporates it into the AI processing step. This pattern is suited for data that changes frequently enough that ingesting it into a platform store would create unacceptable staleness, or for data that is large or sensitive enough that storing it in the platform is undesirable. API-based retrieval introduces a dependency on the source system's availability and latency at query time, which should be accounted for in the application design. ### Outbound Data Integration Outbound data integration covers the patterns by which AI-generated outputs, decisions, or actions are delivered to systems outside the platform. These patterns determine how AI capability moves from the platform into the downstream processes and systems that act on it. #### Webhook Delivery Webhook delivery pushes AI-generated outputs to an external system as soon as they are produced. When a workflow completes, an agent finishes a task, or an application produces an output, the platform makes an HTTP POST request to a configured endpoint in the receiving system, delivering the output payload. Webhook delivery is suited for real-time notification use cases, for systems that need to react immediately to AI outputs, and for integration with external platforms that support inbound webhook handling. Most modern SaaS platforms and enterprise applications support webhook ingestion, making this a broadly applicable outbound integration pattern. #### API Push API push sends AI-generated outputs to an external system by calling that system's API directly from a workflow or function within the platform. Unlike webhook delivery, which is triggered by the platform and received passively by the external system, API push is an active call from the platform to a defined external endpoint. API push is appropriate when the external system does not support inbound webhooks but does expose an API for writing data, when the output needs to be delivered to a specific record or endpoint within the external system that is determined at runtime, or when the integration requires error handling and retry logic beyond what a simple webhook delivers. Credentials for external API calls made from platform workflows are managed through the secrets vault, ensuring that integration credentials are not exposed in workflow configuration. #### Database Write-Back Database write-back stores AI-generated outputs directly in an external database or data warehouse as part of a workflow execution. This pattern is suited for use cases where AI outputs need to be combined with existing enterprise data for reporting, analysis, or downstream processing, and where the receiving system is a database rather than an application with an API. Write-back integrations require careful attention to data schema alignment between the AI output format and the target database structure, and to access control for the credentials used to write to the external database. #### File and Document Delivery File and document delivery places AI-generated outputs into a shared file system, document management platform, or collaboration tool for consumption by users or downstream processes. This pattern is suited for document generation workflows, report automation, and any use case where the output of AI processing is a file that needs to be placed in an existing document workflow. Common destinations include SharePoint, Google Drive, S3-compatible storage, and enterprise content management platforms. File delivery is typically implemented through workflow automation using the appropriate connector for the target platform, with credentials managed through the secrets vault. ### Internal Platform Integration Beyond external system integration, GLBNXT Platform components integrate with each other to form coherent end-to-end AI architectures. Understanding how internal integration works is as important as understanding external integration patterns. #### Component Chaining Component chaining connects platform services in sequence so that the output of one component becomes the input to the next. A document ingestion pipeline chains MinIO object storage, an embedding model, and a vector database. A RAG assistant chains a vector database retrieval step, a prompt assembly step, and a language model inference call. A reporting workflow chains a database query, a summarisation model call, and a document generation step. Component chaining on GLBNXT Platform is implemented through workflow automation for multi-step processes, through direct API calls between platform services for tightly coupled application components, and through agent tool use for dynamic chaining within a reasoning loop. #### Event-Driven Internal Integration Platform components can communicate through events as well as direct calls. A document uploaded to MinIO can trigger an ingestion workflow. A workflow completion can trigger a notification or a downstream process. An agent task result can trigger a quality evaluation step. Event-driven internal integration allows platform components to react to each other without tight coupling, making architectures more resilient and easier to extend. #### Shared Data Services Multiple applications and workflows within a platform environment can share access to common data services including Postgres databases, vector database collections, and MinIO storage buckets. Shared data services allow different AI applications to draw on the same underlying data without duplicating it, and enable outputs from one application to be consumed as inputs by another. Access control policies applied to shared data services determine which applications and workloads can read from and write to each resource, ensuring that data sharing does not compromise the access boundaries appropriate for your environment. ### Identity and Authentication Integration #### SSO and Identity Provider Integration GLBNXT Platform integrates with enterprise identity providers through SAML and OAuth 2.0, allowing platform access to be governed by your organisation's existing identity and access management policies. For AI applications that include user-facing frontends, identity provider integration can be extended to authenticate end users of those applications through the same organisational identity, providing a consistent single sign-on experience across the platform and the applications built on it. #### User Context Propagation For AI applications where the identity of the requesting user should influence the behaviour of the application, such as personalised assistants or applications that enforce data access policies based on user role, user identity can be propagated from the authentication layer through the application stack to the AI processing layer. This allows models, retrieval systems, and workflow steps to receive user context and apply appropriate access and personalisation logic. ### Enterprise System Integration #### CRM and ERP Integration AI workflows on GLBNXT Platform can integrate with enterprise CRM and ERP systems to retrieve customer, transaction, and operational data at processing time, and to write AI-generated insights, recommendations, or actions back to those systems. Integration is implemented through the API connectors and workflow automation tools available in your environment, with credentials managed through the secrets vault. #### Document Management Integration Enterprise document management platforms including SharePoint, Confluence, and Notion can be connected to GLBNXT Platform as document sources for RAG pipelines or as destinations for AI-generated outputs. Document management integration typically involves a combination of batch or event-driven ingestion for indexing document content, and file delivery for writing outputs back to the document management platform. #### Communication Platform Integration AI workflows can integrate with communication platforms including email, Slack, Microsoft Teams, and others to deliver AI-generated notifications, summaries, and outputs to users through the channels they already use. Communication platform integration is commonly used in workflow automation for escalation notifications, scheduled report delivery, and event-driven alerts. ### Security Considerations for Integrations Every integration point is a potential security boundary that requires attention. The following considerations apply across all integration patterns on GLBNXT Platform. **Credential management:** all credentials used by integrations are managed through the platform secrets vault. Integration credentials are never stored in workflow configuration, application code, or any location accessible to developers. Credentials are rotated through the vault without requiring changes to integration logic. **Least privilege for integration accounts:** service accounts and API keys used by platform integrations to access external systems should be scoped to the minimum permissions required for the integration to function. Integration accounts should not hold broad administrative access to external systems simply for convenience. **Data validation at integration boundaries:** data received from external systems at inbound integration points should be validated before being processed by AI components. Unvalidated external data introduces risks ranging from data quality issues to prompt injection attacks in AI applications that incorporate external content into model inputs. **Audit coverage for integration traffic:** integration traffic flowing through workflow automation and API endpoints is logged as part of the platform audit trail. Ensure that integration logging is configured to capture the information required to trace data flows across integration boundaries for compliance and investigation purposes. For guidance on building the API and function layer that supports outbound integration patterns, see the APIs and Functions section. For guidance on workflow automation tools used to implement integration patterns, see the Workflow Automation section. # Partner & custom deployments GLBNXT Platform is designed to be deployed and delivered at scale through partners. System integrators, technology consultancies, AI agencies, and managed service providers working with GLBNXT can deploy the platform for their clients as a fully configured, client-specific environment tailored to the use cases, compliance requirements, and technical constraints of each engagement. This model allows partners to deliver sophisticated AI capability to their clients without building or operating AI infrastructure themselves. This section explains how partner deployments work, what customisation is available at the environment level, and how partners and their clients should approach the deployment model to get the most from the platform. ### The Partner Deployment Model In a partner deployment, GLBNXT works directly with the partner organisation to provision and configure a platform environment on behalf of a client. The partner takes responsibility for the solution layer, designing and building the AI applications and workflows that meet the client's requirements. GLBNXT takes responsibility for the platform layer, managing the infrastructure, security, compliance, and operational foundation that the partner's solutions run on. This model allows partners to offer clients a complete AI solution that includes both the applications their team builds and the enterprise-grade managed infrastructure those applications run on, without requiring the partner to develop or maintain infrastructure capability themselves. Partners typically interact with GLBNXT at two levels. At the account level, the partner manages the commercial relationship, onboarding process, and ongoing engagement for each client deployment. At the technical level, the partner's development team works within the client's platform environment to build and deploy solutions, using the same platform capabilities and documentation available to any GLBNXT Platform development team. ### Environment Configuration for Partner Deployments Every client environment deployed through a partner is a dedicated, isolated platform environment. Client environments are not shared with other clients or with the partner organisation itself. Each environment has its own compute allocation, storage, network boundary, access controls, and audit trail. During onboarding, the environment is configured in collaboration with the partner based on the requirements of the specific client engagement. Configuration decisions made during onboarding include the following. **Stack selection:** the specific set of platform tools and services deployed in the client environment. GLBNXT configures each partner deployment with the precise stack the client's use cases require, without deploying unused components that add operational complexity and cost. A client requiring RAG-based assistants and workflow automation receives a stack configured for those capabilities. A client requiring high-performance model inference for a user-facing application receives a stack optimised for that workload. **Compute allocation:** the GPU and CPU resources allocated to the environment based on the anticipated workload. Compute allocation is agreed during onboarding and can be adjusted as the client's usage grows or their workload requirements change. **Model selection:** the models deployed in the client's Model Hub, selected based on the use cases the partner will be building and the quality, latency, and capability requirements of the client's applications. **Compliance configuration:** the security controls, audit logging configuration, data retention policies, and compliance documentation applicable to the client's regulatory environment. For clients in regulated sectors, compliance configuration is a first-priority activity during onboarding. **Access and identity configuration:** the identity provider integration, user roles, and access policies configured for the client's team and for the partner's development team where the partner requires access to build and maintain solutions. ### White-Label and Branded Deployments For partners who deliver AI solutions under their own brand or under a client-specific brand, GLBNXT Platform supports white-label deployment configurations. In a white-label deployment, the platform environment and any managed frontend components are presented to end users under the partner's or client's brand rather than under the GLBNXT brand. White-label configuration options include custom domain names for the platform console and hosted application interfaces, custom visual branding applied to managed chat interfaces and webchat components, and custom naming for the environment that aligns with the partner's or client's product identity. White-label deployments do not affect the underlying platform capabilities, security controls, or compliance posture of the environment. The infrastructure and operational layer remains fully managed by GLBNXT regardless of the branding applied at the interface level. ### Multi-Client Management for Partners Partners managing multiple client environments through GLBNXT have access to a partner management layer that provides visibility and control across their client portfolio without requiring separate login sessions for each environment. Through the partner management layer, partners can view the operational status of each client environment, manage onboarding and offboarding processes for new and departing clients, review usage and consumption data across their portfolio, and coordinate with GLBNXT on support and escalation activities for specific client environments. Each client environment remains isolated from every other client environment. The partner management layer provides visibility and administration capability without creating any connectivity or data sharing between individual client environments. ### Custom Infrastructure and Deployment Topologies Beyond the standard managed cloud deployment, GLBNXT Platform supports custom deployment topologies for clients and partners with requirements that go beyond what the standard model provides. #### On-Premise Deployment For clients with the most stringent data sovereignty requirements, GLBNXT Platform can be deployed on-premise within the client's own infrastructure. On-premise deployments place every component of the platform stack within the client's data centre or private cloud, under their direct operational control. GLBNXT supports the deployment, configuration, and ongoing maintenance of on-premise environments in collaboration with the client's infrastructure team. On-premise deployments are suited for public sector and government clients, financial services clients under specific data localisation obligations, and any client that has made binding commitments about infrastructure ownership and control that cannot be satisfied by a managed cloud deployment. #### Hybrid Deployment Hybrid deployments combine on-premise components with managed cloud components, placing the most sensitive workloads and data within the client's own infrastructure while using managed cloud infrastructure for workloads with less stringent residency requirements. Hybrid deployments allow clients to benefit from the operational simplicity of managed cloud infrastructure for the majority of their workloads while satisfying specific sovereignty requirements for sensitive components. #### Dedicated Cloud Infrastructure For clients who require the isolation of on-premise deployment but prefer not to manage their own physical infrastructure, GLBNXT can deploy the platform on dedicated cloud infrastructure within a specified EU region. Dedicated infrastructure provides complete isolation from other platform tenants at the compute and networking layer, with the operational management remaining with GLBNXT. ### Solution Templates and Accelerators GLBNXT maintains a library of pre-built solution templates and configuration accelerators that partners can use to reduce the time required to deliver common AI use cases for their clients. Templates cover the most frequently implemented solution patterns on the platform, providing a validated starting point that partners can customise for each client engagement rather than building from scratch. Available templates cover use cases including RAG-based internal knowledge assistants, document review and analysis workflows, customer support automation, automated reporting pipelines, and compliance Q\&A systems. Each template includes a pre-configured application architecture, sample prompts and system configurations, ingestion pipeline setup, and deployment guidance. Partners who develop effective solution configurations for a specific industry or use case can work with GLBNXT to contribute those configurations to the template library, making them available across the partner network and reducing delivery time for similar engagements in the future. ### Partner Technical Enablement GLBNXT provides technical enablement resources for partner development teams working with the platform. Enablement covers platform architecture and capabilities, solution design patterns, compliance and governance requirements for common sectors, and the delivery practices that lead to successful client deployments. Technical enablement is available through the following channels. **Onboarding support:** dedicated technical support for the first client environment a new partner delivers, including access to a GLBNXT technical contact throughout the onboarding and initial build phase. **Partner documentation:** access to this documentation and any partner-specific technical guidance relevant to the delivery model, solution templates, and compliance requirements applicable to the partner's target sectors. **Solution design reviews:** GLBNXT technical team availability to review the architecture of complex or high-stakes solution designs before development begins, providing feedback on approach, component selection, and potential risks. **Escalation support:** access to GLBNXT's technical and operational teams for escalating issues that arise during client engagements and require platform-level investigation or remediation. ### Responsibilities in a Partner Deployment Partner deployments involve three parties with distinct responsibilities: GLBNXT, the partner, and the client. Understanding these responsibilities clearly is essential for ensuring that governance, support, and compliance obligations are fulfilled without gaps or ambiguity. **GLBNXT is responsible for:** platform infrastructure and operations, managed component availability and performance, security and compliance controls at the platform layer, incident response for platform-level events, and the contractual and documentation obligations that support the client's compliance posture. **The partner is responsible for:** solution architecture and application design, the quality and behaviour of the AI applications and workflows deployed in the client environment, client-facing communication and relationship management, compliance of application-layer design with applicable regulatory requirements, and first-line technical support for the client on solution-related matters. **The client is responsible for:** defining and communicating their use case requirements, compliance, and governance obligations to the partner, managing user access and organisational policies for use of the deployed applications, responding to any data subject rights requests related to personal data processed through the applications, and fulfilling regulatory obligations that go beyond what the platform and partner can address on their behalf. Where responsibilities overlap or are ambiguous for a specific client engagement, these should be discussed and documented during onboarding. Clear responsibility allocation from the start of a deployment prevents gaps in governance and support that become problems in production. For guidance on the technical capabilities available in partner-deployed environments, the rest of this documentation applies equally to partner deployments as to direct client deployments. For guidance on compliance and data sovereignty in partner deployments involving regulated sector clients, see the Compliance Frameworks and Data Sovereignty sections. # Team & user management Managing your team on GLBNXT Platform means ensuring that every person who needs access to the environment has it, that their access is scoped appropriately to their role, and that accounts are kept current as your team changes over time. Well-managed team access reduces security risk, supports compliance obligations, and ensures that the right people can do their work without unnecessary friction. This section covers how to add and manage users in your environment, how to assign and maintain roles, how to manage access for teams working across multiple environments, and the practices that keep your team access configuration healthy over time. ### User Accounts Every individual accessing GLBNXT Platform has a dedicated user account. User accounts are the identity anchor for all activity within the environment. Every action taken in the platform, from a model inference request to an administrative configuration change, is attributed to the authenticated user account that performed it. This attribution is captured in the audit trail and is the basis for access control enforcement across the environment. User accounts are provisioned in one of two ways depending on your environment configuration. **SSO-provisioned accounts** are created and managed through your organisation's identity provider. When SSO integration is configured, user accounts in the platform are linked to the corresponding identity provider identity. Provisioning and deprovisioning are managed through the identity provider, ensuring that platform access stays synchronised with your organisation's broader user lifecycle management. When an employee leaves and their identity provider account is deactivated, their platform access is revoked automatically. **Directly provisioned accounts** are created by your platform administrator through the platform console. Direct provisioning is appropriate for environments where SSO has not been configured, for external collaborators who do not have an account in your identity provider, and for service accounts used by application workloads. Directly provisioned accounts require manual deprovisioning when no longer needed. ### Adding Users New users are added to your environment by your platform administrator through the user management area of the platform console. When adding a user, the administrator specifies the user's identity, either by linking to their identity provider account or by creating a direct login credential, and assigns the role or roles appropriate for their work in the environment. For environments onboarding a large team at launch, user provisioning can be completed in bulk through the access list provided to your GLBNXT contact during onboarding. Individual users can be added at any time after initial provisioning by your platform administrator. New users added to the environment with direct login credentials should be advised to update their password on first login and to enable multi-factor authentication immediately. For SSO-provisioned users, MFA is enforced by the identity provider according to your organisation's existing policies. ### Roles and Role Assignment Roles define what a user can see and do within the platform environment. Every user account is assigned one or more roles at the time of provisioning. The roles available in a GLBNXT Platform environment and how they are assigned are covered in detail in the Access Control and Identity section. The key principle to apply when assigning roles is least privilege: every user receives the minimum access needed to fulfil their responsibilities within the platform, and no more. Role assignments should be reviewed whenever a team member changes role, moves to a different project, or takes on responsibilities that require different platform access. Accounts that retain roles from previous assignments accumulate permissions that are no longer appropriate, creating unnecessary security exposure. ### Teams and Grouped Access For organisations where multiple team members share the same access requirements, roles can be assigned at the group level rather than individually. Group-based access assignment links a set of roles to a defined group, and adds users to that group to grant them the appropriate access. When a new team member joins who requires the same access as an existing group, they are added to the group rather than having roles configured individually. Group-based access management is particularly effective in SSO-configured environments where groups can be managed in the identity provider and synchronised automatically to the platform. Changes to group membership in the identity provider are reflected in platform access without requiring manual updates by the platform administrator. ### External Collaborators and Partner Access Engagements involving external collaborators, such as partner development teams, consultants, or contractors, require careful access configuration. External collaborators should be provisioned with the minimum access required for their specific contribution and should have access revoked promptly when their engagement ends. For partner teams working within a client environment, access is typically configured during onboarding with the scope agreed between the client organisation and the partner. Partner access should be scoped to the specific components the partner team needs to build and maintain their solutions, without granting visibility of other parts of the environment that are not relevant to their work. External collaborator accounts provisioned with direct login credentials require particular attention during offboarding. Because deprovisioning is manual for direct accounts, a clear process should be in place to ensure that contractor and partner accounts are revoked at the end of an engagement rather than left dormant. ### Service Accounts Application workloads running on GLBNXT Platform authenticate to platform services using service accounts rather than user credentials. Each application workload that needs to access platform resources, such as a model endpoint, a database, or a storage bucket, should have a dedicated service account scoped to exactly the resources it requires. Service accounts are created by your platform administrator through the platform console. Credentials for service accounts are managed through the platform secrets vault and injected into application workloads at runtime. Developers building applications on the platform do not handle service account credentials directly. Service accounts should be named descriptively to make their purpose clear in audit logs and access reviews. An account named after the specific application or workload it serves is significantly easier to manage and audit than a generic credential shared across multiple applications. ### Offboarding Users Prompt deprovisioning of user accounts when team members leave or change role is one of the most important hygiene practices for platform security. Dormant accounts with active credentials represent an unnecessary risk, particularly for accounts with elevated roles such as administrator or developer access. For SSO-configured environments, offboarding a user from the identity provider automatically revokes their platform access. No additional action is required in the platform itself. For directly provisioned accounts, offboarding requires the platform administrator to deactivate or delete the user account through the platform console. A process should be in place to ensure that account deprovisioning is initiated promptly when an employee leaves the organisation or when a contractor or partner engagement ends. When a user with an administrator role leaves, confirm that at least one other active administrator account exists in the environment before the departing user's account is deprovisioned. An environment with no active administrator account cannot be managed through the console and requires GLBNXT intervention to restore administrative access. ### Access Reviews A periodic access review verifies that every active account in the environment has role assignments appropriate to the account holder's current responsibilities. Access reviews catch accumulated permissions from role changes that were not cleaned up, identify dormant accounts that should have been deprovisioned, and confirm that service account scoping remains appropriate as applications evolve. The recommended cadence for access reviews depends on the pace of change in your team and the sensitivity of the data processed in your environment. Quarterly reviews are appropriate for most production environments. Environments handling highly sensitive data or subject to strict regulatory requirements may warrant more frequent reviews. Access review outputs should be documented and any corrections made promptly. For regulated environments, access review records may form part of the evidence base for compliance assessments and should be retained accordingly. ### User Management in Multi-Environment Deployments Organisations operating multiple GLBNXT Platform environments, such as separate environments for development, staging, and production, or separate environments for different business units or client deployments, manage user access independently in each environment. A user's role in one environment does not automatically grant them any access in another. For teams that work across multiple environments, role assignments in each environment should reflect the access appropriate for that specific context. A developer who requires broad access in a development environment to build and test solutions may need more restricted access in a production environment where they are monitoring and supporting deployed applications rather than actively building. For guidance on the access control policies that govern what users can do within their assigned roles, see the Access Control and Identity section. For guidance on the audit logging that captures user activity across the environment, see the Audit Logs and Query History section. # Environment management An environment on GLBNXT Platform is the complete, isolated deployment of the platform stack allocated to your organisation or to a specific project, team, or client. It contains your compute resources, deployed services, model endpoints, data stores, access controls, and audit trail. Everything your team builds and operates on the platform lives within the boundary of your environment. Managing your environment well means understanding how it is structured, how to keep it aligned with your team's evolving needs, and how to operate multiple environments effectively when your delivery model requires it. This section covers the structure of GLBNXT Platform environments, how to manage environment configuration over time, and the patterns for organising environments across development, staging, and production workloads. ### Environment Structure Every GLBNXT Platform environment is a dedicated, isolated deployment. At the infrastructure level, your environment has its own compute allocation, network boundary, storage instances, and Kubernetes namespace. No infrastructure resources are shared with other environments or other organisations. Isolation is enforced at the platform layer, not just through access controls. Within your environment, the components deployed during onboarding form the baseline stack. This includes the model endpoints available in your Model Hub, the data services provisioned for your use cases, the workflow automation tools available to your team, and the frontend components configured for your applications. The specific composition of your stack reflects the requirements agreed during onboarding. Your environment has its own access control configuration, with user accounts, roles, and service accounts managed independently of any other environment. Audit logs and query history are scoped to your environment. There is no cross-environment visibility of activity, data, or configuration. ### Environment Configuration Environment configuration covers the settings, parameters, and policies that determine how your environment behaves. Configuration is established during onboarding and can be updated over time as your requirements evolve. Key areas of environment configuration include the following. **Compute allocation** defines the GPU and CPU resources available for workloads in your environment. The initial allocation is agreed during onboarding based on your anticipated workload. As your applications grow and usage increases, compute allocation can be reviewed and adjusted through your GLBNXT contact. Monitoring compute utilisation through the Observability and Monitoring area of the platform console gives your team the visibility needed to identify when allocation adjustments are appropriate. **Model configuration** defines which models are deployed in your Model Hub, the serving runtime applied to each, and the endpoint configuration your applications use to access them. Model configuration changes, including adding new models, updating model versions, or removing models that are no longer needed, are managed through your GLBNXT contact following the model governance process described in the Model Evaluation and Versioning section. **Data service configuration** covers the storage instances provisioned in your environment, including database sizes, object storage capacity, and vector database collection configuration. Data service configuration should be reviewed as your data volumes grow to ensure that storage capacity and performance remain appropriate for your workloads. **Security and access configuration** covers identity provider integration, role definitions, MFA policies, and network access rules for your environment. Changes to security configuration should be treated as controlled changes and reviewed against your security requirements before being applied. **Compliance configuration** covers audit log retention periods, data retention policies, and any compliance-specific settings applied to your environment. Compliance configuration changes should be reviewed against your regulatory obligations before being applied and documented for audit purposes. ### Development, Staging, and Production Environments For organisations building production AI applications on GLBNXT Platform, a multi-environment model separates development and testing activity from production workloads. The standard pattern uses three environments. #### Development Environment The development environment is where your team builds, experiments, and iterates. It is configured to support active development work with access to the platform components needed to build your solutions. The development environment does not need to mirror the production environment exactly in terms of compute allocation or data volumes. It is optimised for development velocity rather than production reliability. In the development environment, your team can build and test new solutions, try different model configurations and prompt designs, experiment with retrieval and pipeline architectures, and iterate rapidly without risk of affecting production workloads or production data. Data used in the development environment should be representative of production data in structure and format but should not be actual production data containing personal information or sensitive organisational content unless appropriate data protection measures are in place. Using synthetic or anonymised data in development reduces the risk of accidental exposure and simplifies compliance with data minimisation obligations. #### Staging Environment The staging environment is a pre-production environment that mirrors the production environment as closely as possible in terms of configuration, compute allocation, and data setup. It is used to validate that a solution behaves correctly in a production-equivalent environment before it is promoted to production. Testing in staging should cover functional validation of the solution against real or production-representative data, performance testing under realistic load conditions, security and access control validation, and compliance review of audit logging and data handling behaviour. Issues identified in staging are resolved before promotion to production, not after. Maintaining parity between staging and production environments requires discipline. Configuration drift, where staging and production diverge over time due to changes applied to one but not the other, reduces the reliability of staging as a pre-production validation environment. Changes to production configuration should be validated in staging first, and changes applied to staging should be applied to production promptly rather than allowed to accumulate as unreviewed differences. #### Production Environment The production environment runs live workloads serving real users and real processes. It is configured for reliability, performance, and compliance rather than development convenience. Access to the production environment is more tightly controlled than in development and staging, with role assignments reflecting the distinction between building solutions and operating them. Changes to production workloads, model configurations, data services, and environment settings are managed as controlled changes. No change should be applied to production that has not been tested in staging. Unplanned changes to production environments are a common source of incidents in AI application deployments and should be prevented through clear change management processes, not just good intentions. ### Environment Lifecycle Management #### Provisioning New Environments New environments are provisioned by GLBNXT in collaboration with your team. The provisioning process follows the same onboarding steps described in the Onboarding Overview section, with the stack, compute allocation, model selection, and compliance configuration agreed before the environment is made available. For organisations operating a multi-environment model, new environments can be provisioned to match an existing environment's configuration as a baseline, reducing the setup effort for staging and development environments that are intended to reflect a production configuration. #### Updating Environment Configuration Requests to update environment configuration are submitted to your GLBNXT contact. Configuration changes are reviewed, validated, and applied during an agreed maintenance window or, for urgent changes, through an expedited process with appropriate review. Your team should maintain a record of environment configuration decisions and changes, documenting what was changed, why, and when. This record supports troubleshooting when unexpected behaviour follows a configuration change, and provides the change history needed to support audit and compliance requirements. #### Decommissioning Environments When an environment is no longer required, decommissioning should follow a defined process to ensure that data is handled correctly, access is revoked, and resources are released. The decommissioning process includes exporting or confirming deletion of any data that must be retained for compliance purposes, revoking all user accounts and service accounts associated with the environment, confirming that any dependent systems or integrations are updated to remove references to the decommissioned environment, and notifying GLBNXT to release the infrastructure resources allocated to the environment. For client environments being decommissioned at the end of a partner deployment, data deletion should be confirmed in writing and documented as evidence that data has been handled in accordance with the applicable data processing agreement. ### Environment Observability The operational health of your environment is visible through the Monitoring and Observability area of the platform console. Infrastructure metrics, service availability, compute utilisation, and audit activity are all scoped to your specific environment, giving your team the visibility needed to manage the environment effectively without access to broader platform infrastructure. For teams operating multiple environments, observability data is maintained separately in each environment. Your team has visibility into the environments they are authorised to access based on their role assignments. Cross-environment reporting, such as aggregated usage data across development, staging, and production, is available through your GLBNXT contact for environments within the same account. For guidance on the access control configuration that governs who can view and modify environment settings, see the Access Control and Identity section. For guidance on the monitoring and observability capabilities available within your environment, see the Observability and Monitoring section. # Resource & compute management Compute resources are the foundation that AI workloads run on. Managing them well means ensuring that your applications have the resources they need to perform reliably, that resources are allocated efficiently across the workloads in your environment, and that your team has the visibility needed to understand consumption patterns and plan for growth. On GLBNXT Platform, GLBNXT manages the compute infrastructure, but your team plays an important role in understanding how resources are used and communicating when allocation adjustments are needed. This section explains how compute resources are structured on GLBNXT Platform, how resource allocation works, how to monitor consumption, and how to approach capacity planning as your workloads grow. ### Compute Resource Types GLBNXT Platform provides two categories of compute resource that underpin all workloads in your environment. **GPU compute** is the primary resource for AI inference, model serving, and training workloads. Language models, embedding models, and other AI components require GPU acceleration to serve requests at the latency and throughput levels that production applications demand. GPU resources are allocated to your environment based on the model serving requirements agreed during onboarding and are managed by GLBNXT to ensure availability for your inference workloads. **CPU compute** handles the supporting workloads that do not require GPU acceleration, including workflow automation execution, API processing, database operations, ingestion pipelines, observability components, and the Kubernetes orchestration layer that manages all containerised workloads in your environment. CPU resources are provisioned alongside GPU resources as part of your environment's complete compute allocation. Both resource types are provisioned exclusively for your environment. Your workloads do not compete for compute resources with other organisations on the platform. Isolation is enforced at the infrastructure level. ### How Resource Allocation Works Your compute allocation is configured during onboarding based on the workloads your team plans to run in the environment. The allocation reflects your anticipated model serving requirements, the number and complexity of concurrent workflows, the data volumes your pipelines will process, and the number of users and applications that will generate requests against your environment. GLBNXT monitors resource utilisation continuously and manages the allocation to ensure that your workloads have the capacity they need. Autoscaling is applied within your allocation to handle fluctuations in workload demand, distributing available resources dynamically across competing workloads based on their priority and resource requirements. When demand consistently approaches the limits of your current allocation, GLBNXT will advise your team and work with you to adjust the allocation to match your actual usage patterns. Resource allocation adjustments are managed through your GLBNXT contact and take effect following a brief provisioning process. ### GPU Resource Management GPU resources are the most constrained and most critical resource in an AI platform environment. Managing GPU allocation effectively has a direct impact on the inference performance of your applications and the cost efficiency of your environment. #### Model Serving and GPU Allocation Each model deployed in your Model Hub is allocated GPU resources sufficient to serve inference requests at the performance levels required for your use case. The serving runtime, model size, and expected request throughput all influence how much GPU resource is required for a given model deployment. Larger models require more GPU memory and typically more compute per inference request than smaller models. Running multiple large models simultaneously in the same environment requires proportionally more GPU resource. During onboarding, GLBNXT works with your team to configure model deployments and GPU allocation in a way that balances performance requirements with resource efficiency. #### Concurrent Workload Management In environments where multiple models and applications are running concurrently, GPU resources are shared across active inference workloads within your allocation. The platform's model routing layer manages request distribution to ensure that workloads receive GPU resources in accordance with their priority configuration. High-priority production inference requests are served ahead of lower-priority background processing tasks. If your environment runs both user-facing applications with strict latency requirements and background processing workloads with more flexible timing, discuss priority configuration with your GLBNXT contact during onboarding to ensure that resource allocation reflects the relative importance of each workload. #### GPU Scaling for Variable Workloads Some workloads have predictable usage patterns with clear peaks and troughs, while others have variable demand that is difficult to forecast. For environments with predictable patterns, compute allocation can be configured to align with anticipated peak demand. For environments with highly variable demand, GLBNXT can advise on allocation strategies that balance performance during peak periods with cost efficiency during quieter periods. ### CPU Resource Management CPU resources support the non-inference workloads that run alongside your AI applications. These include workflow automation, API request handling, data ingestion pipelines, observability components, and the platform services that manage orchestration and routing. CPU resource consumption is generally more predictable and more gradual in its growth than GPU consumption. As you add more workflows, more users, and more API integrations, CPU demand grows proportionally. GLBNXT monitors CPU utilisation as part of the continuous infrastructure observability layer and manages scaling within your allocation to accommodate growing workloads. For environments running high-volume workflow automation or data ingestion at scale, CPU resource requirements can become significant. If your use case involves processing large document volumes, running many concurrent workflow executions, or serving high API request volumes, discuss CPU allocation requirements with your GLBNXT contact during the solution design phase rather than after performance issues emerge in production. ### Storage Resource Management In addition to compute, your environment's storage capacity is a managed resource that requires attention as your data volumes grow. Object storage capacity in MinIO, database storage in Postgres, and vector database storage in Weaviate or Qdrant are all provisioned based on your anticipated data volumes. As your knowledge bases grow, your conversation history accumulates, and your application data expands, storage consumption increases. GLBNXT monitors storage utilisation and alerts your team when consumption approaches the limits of your current provisioning. Storage capacity adjustments are managed through your GLBNXT contact. For environments with rapidly growing data volumes, establishing a regular cadence for reviewing storage consumption and projecting future requirements helps avoid last-minute capacity requests. Data that is no longer needed should be removed from platform storage rather than retained indefinitely. Accumulated redundant data increases storage costs, reduces retrieval quality in vector databases, and can complicate compliance with data retention obligations. Implementing data lifecycle policies that archive or delete data according to defined retention schedules keeps storage consumption under control and supports your data minimisation obligations. ### Monitoring Resource Consumption Resource consumption data is visible through the Monitoring and Observability area of the platform console. Key metrics available for your environment include the following. **GPU utilisation** shows the percentage of allocated GPU resources consumed by active inference workloads over time. Consistently high GPU utilisation across your allocation indicates that workloads are resource-constrained and that a capacity review may be appropriate. **CPU utilisation** shows consumption across your CPU allocation by workload type, including model serving infrastructure, workflow automation, API processing, and platform services. Spikes in CPU utilisation that correlate with workflow execution peaks or ingestion pipeline runs help identify where CPU demand is concentrated. **Memory consumption** shows RAM utilisation across your compute allocation. High memory pressure, particularly during large model loading or high-concurrency inference periods, can affect performance and should be reviewed if it occurs consistently. **Storage consumption** shows used and available capacity across each storage service in your environment, including object storage, relational database storage, and vector database storage. **Model inference metrics** show request volumes, average latency, token consumption, and error rates for each model endpoint in your Model Hub. These metrics are the primary signal for assessing whether model serving resources are appropriately sized for your inference workload. Your team should review resource consumption metrics regularly, not only when performance issues arise. Understanding your environment's normal consumption patterns makes it significantly easier to identify anomalies, plan for growth, and make informed decisions about when allocation adjustments are needed. ### Capacity Planning Capacity planning is the practice of anticipating future resource requirements based on current consumption trends and projected workload growth. Proactive capacity planning avoids situations where resource constraints cause performance degradation or service disruption in production environments. A practical capacity planning approach for GLBNXT Platform environments involves the following. **Establish consumption baselines** during the initial weeks of production operation, documenting normal resource utilisation patterns across GPU, CPU, memory, and storage. Baselines give you the reference point needed to identify growth trends and detect anomalies. **Project growth from known drivers** such as planned increases in user numbers, new applications being deployed, higher document ingestion volumes, or additional models being added to your Model Hub. Map each growth driver to its resource implications and estimate the timeline over which increased demand will materialise. **Request allocation adjustments ahead of need** rather than reactively when performance is already affected. Compute allocation changes require a provisioning process. Engaging your GLBNXT contact when consumption reaches a defined threshold, such as sustained utilisation above seventy percent of your current allocation, gives adequate lead time for the adjustment to be in place before resources become a constraint. **Review capacity after significant changes** such as deploying a new application, adding a large model to the Model Hub, onboarding a major new user group, or running a high-volume batch process. Significant changes can shift resource consumption patterns materially and should prompt a review of whether the current allocation remains appropriate. For guidance on the observability tooling that surfaces resource consumption data, see the Observability and Monitoring section. For guidance on model serving configuration and its relationship to GPU resource requirements, see the Model Serving and Routing section. # Backup & recovery Backup and recovery on GLBNXT Platform ensures that the data your applications depend on is protected against loss and that your environment can be restored to a known good state in the event of a data corruption event, an accidental deletion, or a platform-level incident. GLBNXT manages the backup infrastructure, executes backup processes automatically, and maintains the recovery capabilities needed to restore your data and your environment with minimal disruption. This section explains what is backed up, how backup processes work, what recovery capabilities are available, and what your team needs to understand to operate confidently with the knowledge that your data is protected. ### What Is Backed Up GLBNXT Platform applies automated backup coverage across all data services within your environment. The following components are included in the standard backup scope. **Postgres databases** containing application data, conversation history, user data, workflow state, and any other structured data stored by your applications are backed up on a defined schedule. Database backups capture a consistent snapshot of the full database state, allowing restoration to a specific point in time. **MinIO object storage** containing source documents, processed files, model artefacts, and any other binary or unstructured content stored by your applications and ingestion pipelines is backed up to ensure that document corpora and application assets can be restored without requiring re-ingestion from source systems. **Vector database collections** in Weaviate or Qdrant containing the embeddings that power your RAG systems and semantic search capabilities are backed up to protect against index corruption or accidental deletion. Restoring a vector database from backup avoids the need to re-run ingestion pipelines across your full document corpus to rebuild the index. **Environment configuration** including platform service configuration, workflow automation definitions, and application settings is captured as part of the environment backup scope. Configuration backup ensures that the way your environment is set up can be restored alongside the data it manages. **Audit logs** are retained separately from operational data under a protection policy that prevents them from being modified or deleted. Audit log retention is treated as a compliance obligation rather than a standard backup activity. See the Audit Logs and Query History section for guidance on audit log retention policies. ### Backup Schedule and Retention Backups run automatically on a defined schedule without any action required from your team. The default backup configuration applies the following schedule. **Daily backups** capture a full snapshot of all covered data services within your environment. Daily backups are retained for a period defined in your service agreement, providing a rolling window of restore points from which your team can recover data from any point within the retention window. **Transaction log backups** for Postgres databases capture incremental changes between daily snapshots, enabling point-in-time recovery to any moment within the retention window rather than only to the time of the most recent daily backup. This granularity is important for environments where even a small amount of data loss following an incident is unacceptable. Backup retention periods are configured during onboarding based on your recovery requirements and any applicable regulatory obligations. For environments subject to data retention requirements that specify minimum periods for which data must be recoverable, retention periods are aligned to those requirements from day one. Extended retention periods beyond the default are available and can be configured through your GLBNXT contact. Extended retention increases storage consumption and is reflected in the resource allocation of your environment. ### Recovery Capabilities Recovery from a backup event restores data or environment configuration to a previous state. GLBNXT Platform supports recovery at several levels of granularity depending on the nature and scope of the event requiring recovery. #### Point-in-Time Database Recovery For Postgres databases, point-in-time recovery allows your environment to be restored to any moment within the transaction log retention window. This capability is used when data corruption or an erroneous operation affects database content and a restore to the exact state before the incident is required. Point-in-time recovery is initiated by raising a recovery request with your GLBNXT contact, specifying the database to be restored and the target point in time. GLBNXT executes the recovery process and confirms completion. The duration of the recovery process depends on the volume of data in the database and the distance in time between the target restore point and the most recent daily backup. #### Object Storage Recovery Recovery of MinIO object storage restores buckets or individual objects to a previous state from the most recent backup that captured them. Object storage recovery is used when documents or files are accidentally deleted, overwritten with incorrect content, or corrupted in a way that cannot be resolved by reprocessing from source. Individual object recovery, where a specific file or document is restored without affecting the rest of the bucket, is available where the backup record captures sufficient granularity to support it. Full bucket recovery restores all objects in a bucket to their state at the time of the backup. #### Vector Database Recovery Recovery of a vector database collection restores the embeddings index to the state captured in the most recent backup. Vector database recovery is used when an index is corrupted, when a collection is accidentally deleted, or when a problematic ingestion run populates the index with incorrect or inconsistent data that cannot be efficiently corrected in place. Following vector database recovery, any documents ingested between the backup restore point and the time of the recovery request will not be reflected in the restored index. Depending on the freshness requirements of your RAG system, a targeted re-ingestion of documents added since the restore point may be needed after recovery to bring the index back to a current state. #### Environment Configuration Recovery Recovery of environment configuration restores platform service settings, workflow automation definitions, and application configuration to a previous state. Configuration recovery is used when a configuration change introduces unexpected behaviour and the change cannot be reversed by re-applying the previous settings manually, or when configuration is accidentally deleted or overwritten. ### Recovery Time and Recovery Point Objectives Recovery time objective and recovery point objective are the two key parameters that define the recovery capabilities of a backup and recovery system. **Recovery point objective** is the maximum amount of data loss that is acceptable following an incident, measured as the age of the most recent recoverable backup. For Postgres databases with transaction log backup, the recovery point objective on GLBNXT Platform is measured in minutes. For object storage and vector databases relying on daily snapshots, the recovery point objective is up to twenty-four hours depending on when within the backup cycle an incident occurs. **Recovery time objective** is the maximum acceptable time to restore service following an incident requiring a recovery operation. Recovery time on GLBNXT Platform depends on the scope of the recovery, the volume of data being restored, and the complexity of the environment configuration. Your GLBNXT contact can provide guidance on expected recovery times for specific recovery scenarios relevant to your environment during onboarding. For environments where strict recovery time and recovery point requirements apply, such as environments supporting critical operational processes or regulated sector deployments with specific business continuity obligations, discuss your requirements with your GLBNXT contact during onboarding to ensure that your backup configuration and recovery capabilities align with those requirements from day one. ### Your Team's Responsibilities GLBNXT manages the backup infrastructure and executes backup processes automatically. Your team has specific responsibilities that complement the platform backup capability and ensure that recovery is effective when needed. **Understanding your recovery requirements:** your team should define the recovery point and recovery time requirements for each application and data set in your environment before they go into production. Requirements that are unclear until an incident occurs are requirements that may not be met by the default configuration. **Avoiding destructive operations without verification:** accidental deletion or overwrite of data is one of the most common scenarios requiring a recovery operation. Before performing bulk delete operations, schema migrations, or data replacement processes in production, verify that a recent backup exists and that you understand what recovery would look like if the operation produces an unexpected result. **Testing recovery processes:** knowing that backups exist is not the same as knowing that recovery works. Periodically testing that a recovery can be completed successfully from backup for critical data services gives your team confidence in the recovery capability and surfaces any gaps before they matter. Discuss recovery testing options and scheduling with your GLBNXT contact. **Reporting incidents promptly:** the sooner a data loss or corruption event is reported to GLBNXT, the sooner a recovery process can begin and the more restore point options are likely to be available. If your team identifies a potential data integrity issue, contact your GLBNXT contact immediately rather than waiting to investigate further before raising the issue. **Application-layer data management:** GLBNXT's backup coverage protects platform-managed data services. Data managed by your applications at the application layer, such as data cached in application memory, data written to temporary locations outside platform-managed storage, or data processed by your applications that has not yet been written to a persistent storage layer, is not covered by platform backups. Your team is responsible for ensuring that application design does not create data persistence gaps that fall outside the platform backup scope. ### Disaster Recovery For environments where business continuity planning requires documented disaster recovery capabilities, GLBNXT can provide a disaster recovery assessment covering your environment's recovery architecture, the scenarios covered, and the recovery time and recovery point characteristics applicable to each scenario. Disaster recovery documentation is available to enterprise customers and partners on request and can be incorporated into your organisation's broader business continuity planning and regulatory compliance documentation. For guidance on the high availability and resilience capabilities of the platform infrastructure that complement the backup and recovery layer, see the Security Architecture section. For guidance on the compliance frameworks that may impose specific business continuity and recovery requirements on your environment, see the Compliance Frameworks section. # Support & escalation GLBNXT provides structured support for every organisation running on the platform. Whether your team has a technical question during development, encounters unexpected behaviour in a production application, or needs to escalate a platform-level incident, knowing how support works and how to engage it effectively ensures that issues are resolved as quickly as possible with minimal impact on your team and your users. This section explains how support is structured, what to expect from each level of support, how to raise and escalate issues, and the responsibilities that sit with your team in the support model. ### Support Structure GLBNXT Platform support operates across three tiers that reflect the nature and urgency of different issue types. #### Onboarding Support During the onboarding period, every new environment has a dedicated GLBNXT onboarding contact who is your primary point of support through the first thirty days. The onboarding contact supports environment orientation, initial configuration questions, first build guidance, and any issues that arise during the onboarding phases described in the Onboarding Overview section. Onboarding support is the most hands-on level of engagement GLBNXT provides. Your onboarding contact is available for direct communication throughout the onboarding period and can coordinate with GLBNXT's technical and operations teams on your behalf for any issues that require deeper investigation. After the onboarding period, ongoing support transitions to the standard support channels described below. #### Standard Support Standard support covers the ongoing technical and operational questions that arise during day-to-day development and operation on the platform. Standard support is available to all GLBNXT Platform customers through the designated support channels configured for your environment. Standard support covers the following categories of request. **Technical questions** about platform capabilities, component behaviour, configuration options, and integration patterns. If your team has a question about how a platform component works or how to approach a specific implementation challenge, standard support is the appropriate channel. **Configuration requests** for changes to your environment that require GLBNXT involvement, such as adding a new model to your Model Hub, adjusting compute allocation, updating compliance configuration, or modifying identity provider integration settings. **Bug reports** for unexpected platform behaviour that affects your applications or workflows. When your team identifies behaviour that appears to be a platform-level issue rather than an application-level issue, a bug report through standard support initiates the investigation and resolution process. **Documentation feedback** on gaps, inaccuracies, or areas where the documentation does not adequately address your team's needs. #### Incident Support Incident support covers situations where a platform-level issue is actively affecting your production environment. Platform incidents include service unavailability, significant performance degradation, data access failures, security events, and any other condition that prevents your applications from functioning as expected due to a platform-layer issue. Incident support is available outside standard business hours for production-affecting events. The contact method and response time commitments for incident support are defined in your service level agreement and communicated during onboarding. Ensure that your team has the incident support contact details available before your first production deployment, not at the moment an incident occurs. ### Raising a Support Request Support requests are raised through the channels configured for your environment during onboarding. Depending on your service tier, these may include a dedicated support portal, a direct email channel, a shared Slack or Teams workspace with your GLBNXT contact, or a combination of these. When raising a support request, providing the following information at the outset reduces the time required for GLBNXT to investigate and respond. **Environment identifier:** confirm which environment the issue affects, particularly for organisations operating multiple environments such as development, staging, and production. **Issue description:** a clear description of what is happening, what you expected to happen, and how the two differ. Avoid describing symptoms only. If you have already investigated the issue and formed a hypothesis about its cause, include that hypothesis along with the evidence that supports it. **Reproduction steps:** the specific sequence of actions or conditions that produce the issue. An issue that can be reproduced reliably is significantly easier to investigate than one that appears intermittently without a clear pattern. **Timing and frequency:** when the issue first appeared, whether it is ongoing or intermittent, and whether anything changed in your environment around the time it appeared, such as a new deployment, a configuration change, or an increase in usage. **Impact assessment:** the effect the issue is having on your team, your applications, and your users. An honest impact assessment helps GLBNXT prioritise your request appropriately relative to other open requests. **Relevant logs or error output:** any error messages, stack traces, or log excerpts from the platform console or your application that are relevant to the issue. Including this information with the initial request avoids the round-trip of GLBNXT asking for it before investigation can begin. ### Escalation When a support request is not progressing at the pace required by the impact of the issue, escalation is the mechanism for increasing priority and engaging additional GLBNXT resources. Escalation is appropriate when a production-affecting issue has not been acknowledged within the response time committed in your service level agreement, when an issue is taking longer to resolve than the impact justifies, or when you have information suggesting that the issue is more serious than its current priority reflects. Escalation contacts and the escalation process are defined in your service agreement and communicated during onboarding. The escalation path typically moves from the standard support channel to a named GLBNXT account or operations contact with the authority to prioritise the issue and coordinate the appropriate internal resources. When escalating, clearly state that you are escalating, why you are escalating, and what outcome you need within what timeframe. An escalation that explains the business impact driving the urgency is more effective than one that simply expresses frustration with the pace of progress. ### Incident Communication For platform-level incidents affecting your environment, GLBNXT communicates through the incident notification channels agreed during onboarding. Incident communication follows a defined pattern. **Initial notification** is sent when GLBNXT confirms that a platform-level incident is occurring and affecting your environment. The initial notification confirms that the issue is known and under active investigation. **Progress updates** are sent at defined intervals while the incident is open, confirming the current status of the investigation and any actions being taken. Update frequency during active incidents is defined in your service agreement. **Resolution notification** is sent when the incident is resolved, confirming what was affected, what caused the issue, and what was done to resolve it. **Post-incident review** documentation is provided for significant incidents, covering the root cause, the timeline of detection and response, the impact on your environment, and the actions being taken to prevent recurrence. Post-incident review documentation is typically available within a defined number of business days following resolution. ### Responsibilities in the Support Model Effective support depends on both GLBNXT and your team fulfilling their responsibilities within the model. **GLBNXT is responsible for:** responding to support requests within the timeframes committed in your service agreement, investigating and resolving platform-level issues, communicating clearly and promptly during active incidents, maintaining the support infrastructure and channels through which requests are raised, and providing post-incident documentation for significant events. **Your team is responsible for:** raising support requests promptly when issues are identified rather than attempting to resolve platform-level issues without engaging GLBNXT, providing the information needed for effective investigation when raising a request, distinguishing between platform-level issues and application-level issues before escalating to GLBNXT, maintaining up-to-date contact information for the people in your organisation who should receive incident notifications, and ensuring that your team knows how to access support channels before they are needed. The distinction between platform-level issues and application-level issues is worth particular attention. GLBNXT support covers issues originating in the managed platform layer. Issues originating in your application code, your workflow logic, your prompt design, or your data are application-level issues that your team is responsible for investigating and resolving. When the root cause of an issue is unclear, raising a support request to confirm whether the platform layer is involved is always appropriate. GLBNXT will advise on whether the issue has a platform-level component or whether the investigation should focus on the application layer. ### Service Level Agreements Response time commitments, availability targets, and escalation timeframes are defined in your service level agreement. Service level commitments vary by service tier and by the priority classification of each support request or incident. Your service agreement is provided during onboarding and should be reviewed by your team before going into production so that everyone understands what to expect from GLBNXT and within what timeframes. If your organisation's support requirements are not met by the standard service level tiers, discuss your requirements with your GLBNXT contact during onboarding. Custom service level arrangements are available for enterprise customers and partner deployments with specific support needs. ### Self-Service Resources In addition to direct support, the following self-service resources are available to your team. **This documentation** covers platform architecture, solution building, security and compliance, administration, and operational guidance. The documentation is the first place to look for answers to technical questions about platform capabilities and configuration. **The GLBNXT Trust Centre** provides security, compliance, and assurance documentation including available certifications, security assessment summaries, and compliance documentation for your team and for your clients or regulators who require evidence of the platform's security posture. **Video tutorials** on the GLBNXT YouTube channel provide guided walkthroughs of common platform tasks and solution patterns. If a self-service resource does not address your question or if you identify a gap in the available documentation, raise a support request. Documentation feedback is welcomed and used to improve the resources available to all GLBNXT Platform customers. # README Tutorials provide step-by-step guidance for building specific solutions and completing common tasks on GLBNXT Platform. They complement the conceptual documentation in this knowledge base by walking you through practical implementations from start to finish, giving you working results you can build on. **Video tutorials** are published on the GLBNXT YouTube channel and cover platform walkthroughs, solution builds, and feature demonstrations led by the GLBNXT team. New videos are added regularly as the platform evolves. **Written guides** provide detailed step-by-step instructions for specific tasks and use cases, with configuration examples, code snippets, and screenshots where relevant. Each guide is self-contained and links to the relevant conceptual documentation for readers who want a deeper understanding of the components involved. ### Jump right in
:mobile-signal-out:AI chat on mobileAI should not stop at your desk/pages/7FvWQMF0kTK7HGhlQfmo
:earth-europe:Secure EU chatAI without security risk/pages/jBTjvatcJMAyOmNToOvf
:book:Chat with your docsUse corporate data securely/pages/fuBqiFpqfYiD97QNIOjR
# Using GLBNXT AI on Mobile ### **Secure Enterprise AI in Your Pocket** Enterprise AI shouldn't stop at your desk. Your team works from everywhere, trains, airports, and between meetings. Often, working on the go leads to the use of "shadow apps," risking data leaks to unknown locations. The GLBNXT mobile platform solves this by providing the exact same secure environment you use on your desktop, directly in your pocket. {% embed url="" %} ### AI Chat via mobile phone * **Unified Security:** The mobile dashboard mirrors the desktop version, meaning the same high-level security protocols apply. * **EU-Hosted Infrastructure:** All mobile interactions are processed via the same EU-hosted infrastructure, ensuring data sovereignty. * **Cross-Device Sync:** Conversations started on mobile automatically sync to your desktop environment. ### Step-by-Step Guide #### 1. Accessing the Dashboard Open the GLBNXT platform on your mobile device. You will see the same dashboard and configured assistants that are available on your desktop version. #### 2. Using Voice Commands Typing long, complex prompts on a mobile screen isn't always practical. GLBNXT Mobile allows for voice dictation. * **Tap the Microphone icon.** * **Dictate your prompt.** * *Example Scenario:* "What are the key risks that I should look for when I want to review a non-disclosure agreement or NDA?" * **Tap "Speak and Send".** The audio is automatically converted to text and sent to the assistant. #### 3. Reviewing Answers on the Go The AI assistant will generate a response (e.g., an NDA checklist) immediately. This allows you to identify key risks or get advice while traveling or in meetings. #### 4. Seamless Synchronization You can stop working on your mobile at any time. When you return to the office and open your desktop environment, the conversation, including the generated NDA checklist, will be waiting for you. Nothing gets lost; everything stays in sync. # Build a Sovereign Deep Research Agent ### **Protecting Your Competitive Advantage While Using AI** Enterprises frequently use AI to perform deep online research—scanning legislation, competitor reports, academic papers, and patents. However, a critical problem exists: these research findings are often proprietary. When you use standard AI tools for this research, you risk exposing your strategies to foreign vendors who may log your data or use it to train future models. The GLBNXT platform allows you to run open-weight LLMs in a fully sovereign European environment. This ensures your insights remain strictly inside your organization. {% embed url="" %} ### The Deep Research Agent Workflow In this tutorial, we utilize **n8n** on the GLBNXT dashboard to create an agent that automates complex research tasks without external data leakage. The agent is structured in three distinct stages: #### 1. The Planning Stage * **Input:** You provide a specific query or research topic. * **Action:** An LLM analyzes the request and breaks it down into relevant sub-topics or "chapters" to investigate. * **Configuration:** You can specify the depth of the report (e.g., requesting a 5-chapter analysis). #### 2. The Content Stage * **Action:** The agent executes the research plan step-by-step. * **Deep Dive:** It investigates each identified topic individually, gathering data from available sources. * **Traceability:** You can monitor the execution flow in real-time to see exactly what the agent is researching. #### 3. The Finalize Stage * **Compilation:** All collected information is synthesized into a cohesive document. * **Formatting:** The system generates a polished PDF report. * **Delivery:** The final report is automatically emailed directly to your inbox. ### Real-World Example: EU Data Act Analysis In the video demonstration, we task the agent with a complex query: **"Investigate the impact of the EU Data Act on the Dutch hosting market."** **The Result:** * The agent successfully split the query into five distinct research topics. * It automatically generated an **18-page PDF report**. * Crucially, the report included **cited sources** at the end, making the AI's findings verifiable for the organization. ### Why Build This on GLBNXT? * **Zero Data Leakage:** There are no external APIs transferring your research strategies to third parties. * **No Model Training:** Your proprietary findings are never used to train the model for other users. * **Sovereign Infrastructure:** The entire process—from query to PDF generation—runs securely inside a European sovereign platform. # Chat with Your Own Documents (RAG Flow) ### **Unlock Generative AI for Corporate Data with Zero Risk** Many organizations want to leverage Generative AI to query their internal corporate data. However, a critical concern remains: How do you do this without exposing sensitive documents to third-party governments or public cloud providers like OpenAI, Google, or Microsoft? The GLBNXT platform solves this by allowing you to build **Retrieval Augmented Generation (RAG)** pipelines that are fully local, modular, and EU-compliant. Your data is processed, stored, and retrieved without ever leaving your sovereign infrastructure. {% embed url="" %} ### The Sovereign Tech Stack In this tutorial, we build a modular agent using open components available on the GLBNXT platform: * **Storage:** **MinIO** for storing raw documents (PDFs, images, text). * **Vector Database:** **PostgreSQL** with **pgvector** to store searchable data embeddings. * **LLM:** Local GPU-accelerated models (e.g., **Mistral**, Gemma, or Llama) to handle reasoning and OCR. * **Orchestration:** **n8n** to handle the ingestion, pre-processing, and retrieval logic. ### Step-by-Step Workflow #### 1. The Ingestion Pipeline Before chatting, data must be processed. The n8n workflow handles this automatically: * **Loop & Download:** The system retrieves files uploaded to your private MinIO bucket. * **Decision Logic:** It checks the file type. If it is an image or scanned document, it uses the **Mistral LLM** for OCR (Optical Character Recognition) to extract text. * **Vectorization:** The extracted content is converted into vectors and stored in the PostgreSQL database. #### 2. The Retrieval (Chat) Interface Once the data is vectorized, you can interact with it via a chat interface. The AI agent is configured with specific **tool calls** that determine when and how to fetch information. #### 3. Context-Aware Responses The agent is capable of "switching context" within a single conversation. * *Example:* You can ask for a summary of a technical manual (e.g., ISPMA software product management). * *Follow-up:* In the same chat, you can ask about a specific person's education from a completely different file (e.g., a resume for "Leyon Vandervort"). * **Result:** The agent intelligently retrieves the correct document for each specific question. #### 4. Full Traceability Unlike "black box" public AI tools, GLBNXT provides full transparency. You can view the execution logs in real-time to see exactly: * Which tool the agent called. * Which documents were retrieved from the vector storage. * How the answer was constructed. ### Why Build This on GLBNXT? * **100% Data Sovereignty:** Your corporate knowledge base never leaves the EU. * **Model Agnostic:** Swap models (Mistral, Llama, etc.) based on your specific requirements. * **Secure Orchestration:** Manage complex logic and permissions locally without external API dependencies. # Chat with Web Search ### **Eliminate Hallucinations with Real-Time Data Access** Large language models are highly powerful, but they share a fundamental limitation: they only know what they were trained on up to a specific date. If you ask them about recent events, they often hallucinate, making up answers that sound incredibly convincing but are completely wrong. The **Global Next Workspace** solves this by integrating a built-in web search directly into the chat environment, giving you access to real-time, up-to-date information. {% embed url="" %} ### The Business Value of Real-Time Search Why does this matter for your organization? Business teams rely on accurate data to perform critical tasks such as: * Researching competitors. * Checking current market data. * Verifying changing regulations. * Finding updated technical documentation. Without web search, AI models will confidently generate factually incorrect answers for these tasks. With GLBNXT's web search integration, your team gets accurate, reliable information without ever having to leave the governed workspace. ### Step-by-Step Guide: See the Difference #### 1. The Limitation (Without Web Search) In the Global Next chat interface, you can select powerful models like **GPTOSS 120B**. * If you leave the web search option **switched off** and ask a question about recent events (e.g., "Who's the current CEO of Oracle?"), the AI generates an answer that sounds confident. * However, if you check the AI's reasoning, you will see it struggling . It knows its knowledge cutoff is June 2024, reasons through the possibilities, but ultimately provides an incorrect or outdated answer (such as Safra Catz). #### 2. Enabling Web Search To fix this, simply **switch on the web search capabilities** in the chat options \[1]. This enables the model to actively look up the current state of events on the internet \[1]. #### 3. Getting Accurate Answers * Ask the exact same question again. * You will now see the model actively searching the web in real time, and the interface will even show you the specific **search terms** it is using. * **The Result:** The AI synthesizes the real-time sources it found and provides a completely different, factual, and correct answer. By using the exact same AI model but augmenting it with real-time web access, you instantly transform a tool that might hallucinate into a reliable research assistant. # Exploring the Model Hub ### **All the Models You Need, Zero Vendor Lock-In** Choosing an AI model usually means choosing a specific vendor and getting locked into their ecosystem. With the Global Next platform, you get access to models from every major provider, including Anthropic, OpenAI, Mistral, IBM, Nvidia, and many more, all in one place. You can use a mixture of open-source models, commercial frontier models, and efficient alternatives across your entire platform, allowing you to switch models whenever you want without having to switch vendors. {% embed url="" %} ### Key Capabilities * **Zero Lock-In:** Switch between different models and providers instantly. * **Curated Recommendations:** The platform highlights and recommends models based on performance, value, and fit for common customer use cases. * **Standardized Access:** All models are standardized and ready to use immediately. ### Step-by-Step Guide #### 1. Accessing the Model Hub To get started, simply open the **Model Hub** directly from the Global Next dashboard. Here, you will find a comprehensive overview of all available models. If you are unsure where to begin, the recommended models section is always a good starting point. #### 2. Filtering for Specific Use Cases If you need a model for a highly specific task, you can easily use the built-in filters. * **By Task:** For example, if you need a coding model, select "coding" as your use case to immediately see models optimized for software engineering. * **By Region:** If you are building a RAG (Retrieval-Augmented Generation) pipeline and require an embedding model that strictly runs in Europe, you can filter by "hosting region" to only see models hosted on EU-based infrastructure. #### 3. Reviewing Model Specifications Models have many parameters and specifications. To view the details of any model, simply click on it . This pulls up a detailed view containing: * A general description. * The Model ID, creator, and specific hosting location. * The supported input and output modalities. #### 4. Deep Dive into Technical Details For advanced users who want to study a model in depth, you can access the full technical specification under the **Model Card**. This section allows you to explore the capabilities the model supports and review specific parameters, helping you tweak the model exactly to your intended application and solution. # Secure, European Chat ### **Say Yes to AI Without the Security Risk** Your teams are already using AI, but the critical question is: do you know where that data is going? With the Global Next Workspace, you can provide your employees with the AI tools they need in an environment that is fully governed and entirely under your control. {% embed url="" %} ### Key Capabilities * **EU-Hosted Infrastructure:** All AI assistants are securely hosted on European infrastructure, guaranteeing that no company data ever leaves your controlled environment. * **Specialized Assistants:** Access role-specific experts (such as Legal, HR, and Marketing) that are preconfigured and trained on your specific company guidelines and brand voice. * **Workflow Organization:** Automatically save, organize, download, and share your chat history without compliance headaches. ### Step-by-Step Guide #### 1. Access the Dashboard Sign in to the Global Next platform. From this single unified dashboard, your teams can access all their AI applications, including the secure chat environment running on Open Web UI. #### 2. Chat with Specialized Assistants Instead of using a generic AI, your organization can configure specialized assistants tailored for different teams. * **HR Policy Expert:** Ask routine questions and get clear, helpful answers based directly on your own company documentation. You can type your question or use pre-suggested prompts, eliminating the wait time for HR to respond. * **Marketing Specialist:** Need to draft a product announcement? Switch to the marketing expert. Because it is pre-trained on your brand terminology and specific tone of voice, it generates professional, on-brand copy in seconds. #### 3. Organize Your Workspace The platform is designed for continuous work: * **Auto-Save:** Every conversation is automatically saved, allowing you to easily pick up where you left off. * **Folders:** Organize your work by dragging and dropping conversations into specific folders, such as "marketing campaigns" or "marketing assets". * **Export and Share:** If needed, you can download a conversation to keep in your records or share it directly with a colleague. # Log In with Identity Providers (SSO) ### **Seamless AI Access with Centralized IT Control** What if your teams could access enterprise AI without managing yet another password? Every new platform typically means another login to remember, creating IT overhead for password resets and introducing new security risks. With the Global Next Workspace, you do not need to create new credentials; the platform integrates directly with your existing identity provider, such as Microsoft Entra ID. This ensures enterprise AI fits into your existing infrastructure rather than creating new complexity. {% embed url="" %} ### Key Benefits for IT and Security Integrating GLBNXT with your existing identity landscape provides complete, centralized control: * **Automatic Policy Inheritance:** Your existing security policies, such as Multi-Factor Authentication (MFA), password complexity, and conditional access, apply automatically to the GLBNXT platform. * **Zero Deprovisioning Effort:** When an employee leaves the organization and their Entra ID is disabled, they immediately lose access to GLBNXT. * **Centralized Auditing:** You manage access through the tools you already use, keeping all your audit logs in one secure place. * **Frictionless Adoption:** Employees face one less barrier to using AI productivity tools because there are no new passwords to remember. ### Step-by-Step Guide: The Login Experience The login process is identical to how your employees already access Office 365, Teams, and other business applications. #### 1. Access the Login Page Navigate to the Global Next platform login page. Instead of typing a separate username and password, you will use the Single Sign-On (SSO) option. #### 2. Authenticate via Your Provider * Click the **"Sign in with Microsoft"** button. * You will be securely redirected to your organization's familiar Microsoft Entra ID login environment. #### 3. Verify Your Identity * Authenticate using your standard company password. * If your organization requires it, you will be prompted to complete **Multi-Factor Authentication (MFA)**, such as receiving and entering a verification code. #### 4. Enter the Workspace Once verified, you are immediately logged into the Global Next platform and ready to use your AI tools. There are no separate credentials to store or manage, just a seamless, secure connection. # Prompt Engineering Fundamentals ### A Technical Guide for AI Power Users *** ### Introduction There is a widespread assumption that interacting with a large language model requires no particular skill. You type a question, the model answers. The interface is conversational, the responses are fluent, and the friction is low enough that most users never question whether they could be getting significantly better results with a different approach. That assumption is expensive. The difference between a naive prompt and a well-engineered one is not marginal. It is the difference between output you need to heavily revise and output you can use directly. Between a model that misses the point of your request and one that anticipates the nuance behind it. Between a tool that occasionally surprises you and a tool that reliably performs. Prompt engineering is the discipline of constructing inputs to language models in ways that reliably produce high-quality outputs. It is not guesswork, and it is not intuition dressed up with technical terminology. It is a set of principled techniques grounded in how these models actually process text, informed by empirical evidence about what works and why, and refined through systematic testing. This tutorial is the companion piece to the GLBNXT Workspace guide on building system prompts. Where that guide focused on persistent configuration, this one focuses on query construction: the craft of writing individual prompts and prompt sequences that extract maximum value from the model you are working with. The two skills are complementary. A well-designed system prompt creates the conditions for good interaction. Well-engineered prompts make the most of those conditions. The treatment here is deliberately technical. Understanding why techniques work is more durable knowledge than memorising a list of tricks. A user who understands the underlying mechanics can adapt to new models, new contexts, and novel tasks. A user who only knows the tricks will find their prompts breaking in ways they cannot diagnose. # How a Model Reads Your Input The first step toward prompt engineering is developing an accurate mental model of what happens between the moment you press send and the moment the first token of a response appears. The gap between how this process is popularly described and how it actually works is significant, and closing that gap changes how you think about prompt construction fundamentally. #### Tokenisation Before a language model processes your text, it converts it into a sequence of tokens. Tokens are not words. They are subword units derived from a vocabulary constructed during training using algorithms such as Byte Pair Encoding (BPE) or SentencePiece. Common words are typically represented as a single token. Uncommon words, technical terms, proper nouns, and non-English text are often split across multiple tokens. This has several practical implications. First, the model does not read your prompt the way a human reads it. There are no sentences or paragraphs in the model's representation of your input, only a sequence of token IDs passed through an embedding layer. The semantic structure you perceive when you read your own prompt must be recovered by the model through learned statistical patterns, not through syntactic parsing. Second, token boundaries can affect model behaviour in ways that are not always predictable. Splitting a technical term across tokens can subtly reduce the model's confidence in applying knowledge associated with that term. Writing certain types of structured output, such as code or formatted tables, is more reliable when the expected format matches patterns the model encountered frequently during training, because those patterns are reinforced by token-level statistics. Third, token count is the operative unit for context window limits, not word count or character count. A useful approximation is that one token equals approximately four characters of English text, or roughly three quarters of a word. However, this ratio varies significantly for non-English languages, specialised vocabulary, and code, where token-to-character ratios can be substantially higher. #### The Forward Pass and Probability Distribution Once your input is tokenised and embedded, the model processes it through a deep neural network consisting of stacked transformer blocks. Each block applies a self-attention mechanism followed by a feed-forward network. The self-attention mechanism computes, for each token in the sequence, a weighted sum of representations from all other tokens. The weights, called attention scores, reflect how relevant each token is to the current one given the context of the full sequence. This is the mechanism by which the model develops a contextualised representation of your input. The word "bank" in the phrase "river bank" receives different attention-weighted context than "bank" in "central bank," because the surrounding tokens shift the attention distribution toward semantically relevant parts of the input. After processing through all transformer blocks, the model produces a probability distribution over its full vocabulary for the next token to generate. This distribution reflects the model's learned beliefs, given everything in the context window, about what token is most likely to follow. The model then samples from this distribution according to a temperature parameter, and the process repeats for each subsequent token until the response is complete. The key insight here is that the model is not retrieving a pre-formed answer. It is constructing a response token by token, where each token is conditioned on everything that came before it, including your entire prompt and all tokens generated so far. The quality of your prompt determines the quality of the probability distribution the model starts from. A precise, well-contextualised prompt shifts the distribution toward high-quality outputs from the very first token. #### Temperature, Top-P, and Sampling The sampling parameters exposed in most AI interfaces, including GLBNXT Workspace, directly control how the model selects tokens from the probability distribution. **Temperature** scales the distribution before sampling. A temperature of 1.0 samples from the raw distribution. Values below 1.0 sharpen the distribution, making high-probability tokens more likely and suppressing low-probability ones. This produces more deterministic, conservative output. Values above 1.0 flatten the distribution, increasing diversity and creativity at the cost of coherence and reliability. **Top-P sampling** (also called nucleus sampling) restricts sampling to the smallest set of tokens whose cumulative probability exceeds a threshold P. Setting top-P to 0.9 means the model only samples from tokens that together account for 90% of the probability mass, ignoring low-probability tail tokens regardless of temperature. For tasks requiring precision, consistency, and factual accuracy, lower temperature values and conservative top-P settings are appropriate. For creative tasks where variation and novelty are desirable, higher temperature is warranted. Understanding this relationship allows you to set sampling parameters deliberately rather than accepting defaults that may not suit your use case. #### Why Phrasing Choices Have Measurable Effects Given the statistical nature of token prediction, it follows that the specific words you use in a prompt are not interchangeable with synonyms, even when the semantic intent is identical. The model's training data contains patterns associating certain phrasings with certain response types. A prompt phrased as a question activates patterns associated with explanatory, informational responses. A prompt phrased as a directive activates patterns associated with task execution. A prompt that includes domain-specific vocabulary signals to the model that the response should operate at a domain-expert level. This is not a quirk or a limitation. It is the mechanism by which prompts work. Understanding it means understanding that prompt engineering is not about finding magic words. It is about aligning the statistical priors embedded in the model's training with the output characteristics you actually want. # The Anatomy of a Well-Formed Prompt A prompt is not simply a question or an instruction. A well-formed prompt is a structured input containing several distinct components, each of which contributes to the model's ability to produce a useful response. Identifying these components and understanding their function is the foundation of systematic prompt construction. #### Component 1: Task Instruction The task instruction is the core directive. It tells the model what you want it to do. This is the component most users treat as the entire prompt, and doing so is the most common source of underperformance. An effective task instruction is explicit about the action required, the object of that action, and the purpose or intended use of the output. Compare: **Weak:** "Summarise this report." **Strong:** "Produce a five-sentence executive summary of the following report. The summary will be included in a board briefing. Prioritise financial implications and strategic risks over operational detail." The second instruction specifies the action (produce a summary), the form (five sentences), the audience (board level), the intended use (briefing), and the content priorities. None of this information requires special knowledge. It simply requires the discipline of making implicit intentions explicit. #### Component 2: Context Context is information the model needs to understand the situation surrounding the task. It is distinct from the input data (the thing you want the model to act on) and from the task instruction (what you want done). Context answers the question: what does the model need to know about the broader situation to perform this task well? Relevant context might include: * The user's role and expertise level * The intended audience for the output * Prior decisions or constraints that should be respected * The relationship between this task and a broader project or workflow * Organisational or domain-specific conventions Context is particularly important when the same task instruction might yield different appropriate responses depending on circumstances. "Write a response to this complaint" means something very different for a frontline customer service agent versus a senior legal counsel. Without context, the model defaults to a generalised interpretation. #### Component 3: Input Data Input data is the material the model is being asked to act on. It might be a document to summarise, a dataset to analyse, a piece of code to review, a draft to edit, or a set of facts to synthesise. In longer prompts, clearly delineating the input data from the task instruction and context is essential for model comprehension. A reliable technique is to use explicit delimiters. Triple backticks, XML-style tags, or clearly labelled sections all work well. The goal is to ensure the model does not confuse your instructions with the content it is being asked to process. **Example using XML-style delimiters:** ``` Analyse the following customer feedback for recurring themes. Group themes by frequency and note any that indicate urgency. [paste feedback here] ``` Delimiters become especially important in longer prompts where multiple pieces of input data are present, or where the input data itself contains text that resembles instructions. #### Component 4: Output Specification Output specification tells the model exactly what the response should look like. This component is frequently absent from prompts written by users who assume the model will infer an appropriate format. Sometimes it does. But consistent, predictable formatting requires explicit specification. Output specification can address: * Format (prose, list, table, JSON, markdown, code) * Length (word count, sentence count, number of items) * Structure (specific sections, labels, or headings) * Tone and register (formal, technical, conversational) * What to include and what to exclude The more precisely you specify the output, the more directly usable the response will be. This is especially important in GLBNXT Workspace workflows where model output feeds into downstream documents, communications, or automated processes. #### Component 5: Constraints and Negative Instructions Constraints define what the model should not do. Negative instructions are often more precise than positive ones for certain types of requirement. "Do not include implementation details" is more precise than "keep it high level." "Do not use passive voice" is more actionable than "write clearly." A common oversight is to omit constraints entirely, then be frustrated when the model includes content you did not want. Every assumption you make about what the model will obviously not do is an opportunity for a constraint. #### Putting the Components Together Not every prompt requires all five components. A short, simple request to a well-configured model may need only a task instruction and an output specification. But for complex, high-stakes, or repeated tasks, assembling all five components is the most reliable path to consistent output. A useful drafting habit is to run through the five components as a checklist before submitting a prompt, asking: have I specified the task, provided the necessary context, delimited the input data, defined the output format, and identified the constraints? Any absent component is a potential source of variance in the response. --- [Next Page](/llms-full.txt/1)