Glossary · Noxus Academy

Glossary

Every term the Academy uses, in two lists: the platform's own words, and the general vocabulary the courses lean on.

The words you will meet across the Academy, each in a few lines. Lessons link to these entries the first time a term comes up after it has been introduced, and show the same definition when you hover over the word.

Noxus terms

The platform's own objects and screens, spelled the way the interface spells them.

Agent: A model given instructions, context and a set of tools, working towards an objective and choosing its own next step from what it finds. In Noxus, an Agent can be used in conversation, where a person asks it questions, or inside a Process, where it performs a task.See also Instructions, Context, Tools, Flow.Documentation: Agents (concept) ↗
Agent node: The node that hands a task to an Agent inside a Flow, with a request and the context it needs, and takes the Agent’s answer back as outputs. The Flow decides where the Agent’s work belongs and what happens to its result.See also Agent, Agentic step.Documentation: Agents in Flows ↗
Agent Sandbox: An isolated environment where code run by an Agent, and plugins, execute away from the rest of the platform. Present only when the installation is configured with one.See also Plugin, Run Code node.
Agentic step: A step in a Flow where a model or Agent has some discretion over how to finish the task, such as choosing which passages to retrieve. The Flow still decides where that step sits and what is done with its result.See also Agent node, Flow.
Analytics: Patterns across many runs: activity, errors, duration, model usage and what it costs. Where to look when something has changed over time rather than in one case.See also Run details, Token.Documentation: Analytics ↗
App: A Flow made available to people as a form: they fill in its inputs and see its outputs, without opening the Flow editor.See also Flow, Trigger.Documentation: Deploying a Flow as a form ↗
Audit logs: The platform’s own record of who did what, and when. Administrators set how long entries are kept and can export a period.See also Run details, Analytics.Documentation: Auditability ↗
Build section: The group of pages in the side navigation where builders create and manage their tools: Flows, Agents, Data (Knowledge Bases and Tables) and the App library. Earlier versions of the Platform called it the Workshop.See also Workspace.Documentation: The visual editor ↗
Case: One instance of a Process: one supplier being onboarded, one claim, one complaint. The case carries the data, documents, tasks, results and history of that piece of work, and the Process reads it to decide what happens next.See also Process, Task, Work Queue.
Conditional node: The node that sends the run down one of two paths depending on whether a condition is true. The simplest form of branching in a Flow.See also Switch node.Documentation: Conditionals and branching ↗
Connection: The configured account and credentials an integration uses to reach an external system. It decides what Noxus itself may do there, separately from what any person may do.See also Integration.Documentation: Integrations ↗
Context: The information available to a model for the task in front of it: the case data, the retrieved passages, the values a Flow has produced so far. The instructions say what to do; the context is what to do it with.See also Agent, Retrieval.
Evaluation suite: A set of test inputs with expected results, run against a Flow to show whether a change to a model, a prompt or the logic still produces the right answers before it reaches the operation.See also Version.Documentation: Tests and evaluators ↗
Extract from Structured node: The node that pulls named fields out of a structured value such as a JSON object, so later nodes can use each field on its own.See also JSON, Schema.Documentation: Data and file nodes ↗
Flow: A defined sequence of operations, built from nodes connected in order. A Flow has named inputs and outputs, so other components can use it without knowing the steps inside. It can mix exact logic with model steps, and can call or be called by an Agent.See also Node, Flow run, Subflow.Documentation: Flows (concept) ↗
Flow run: One execution of a Flow: its inputs, its outputs and a record of what every node did. The run is to a Flow what a case is to a Process. The Past runs tab lists them.See also Flow, Past runs.
Generate Text node: The node that sends a prompt and context to a language model and returns its answer. Used to read documents, extract values and draft text. It can return separate named fields instead of one block of text.See also Prompt, Language model, Extract from Structured node.Documentation: Text generation ↗
Guardrails: Limits placed around an agent so that it stays on its task: what it may read, what it may change, which systems it may call and what it must refuse. In Noxus, an Agent’s instructions and the tools it is given set these limits.See also Agent, Instructions.Documentation: Agent best practices ↗
Ingestion: The step that takes a file into a Knowledge Base: processing it, breaking it into passages and indexing them so they can be searched. A document that fails ingestion cannot be found later.See also Knowledge Base, Retrieval.Documentation: Supported files and sources ↗
Input node: The node where a Flow receives a value from outside: a file, a piece of text, a number. Each Input node is one named input of the Flow.See also Output node, Flow.Documentation: Inputs and outputs ↗
Insert Table Row node: The node that writes one record into a Table, binding each column to a value from the run. The register of submissions in the Associate course is filled this way.See also Table, Query Table.Documentation: Data Tables ↗
Instructions: The text that defines an Agent’s role, its task and its boundaries: what it is for, what it may do, and how it should use the evidence it is given.See also Agent, Prompt.Documentation: Prompts and instructions ↗
Integration: Access to an external application or service, such as the client’s ERP, so a Flow or Agent can read its records and write results back. A configured connection supplies the account and permissions used.See also Connection, API.Documentation: Integrations ↗
Knowledge Base: A collection of documents made available for retrieval by Agents and Flows: policies, procedures, manuals, contracts. Files are ingested and indexed, then relevant passages are retrieved in response to a question.See also Ingestion, Retrieval, Embedding model.Documentation: Knowledge Bases ↗
Make API Request node: The node that calls an external system over its API: a GET to read a record, a POST to write one. The response is mapped to named outputs the rest of the Flow can use.See also API, API endpoint, Integration.Documentation: Integration nodes ↗
Model Picker: The control on an Agent or a model node where the builder chooses a specific model or a preset.See also Preset, Provider.Documentation: Models and providers ↗
Node: One step in a Flow, with its own inputs and outputs. A node can receive an input, read a document, call a model, apply a rule, query a Table, invoke an Agent or call an external system. Connections between nodes set the order and pass values along.See also Flow.Documentation: Flows ↗
Organisation: The client’s whole Noxus installation, holding its users, its workspaces and its platform settings. The interface spells it Organization.See also Workspace, Organisation role.
Organisation role: A role that controls administration across the whole installation: users, identity, providers and settings. Separate from any workspace role the same person holds.See also Workspace role, Organisation.Documentation: Permissions and roles ↗
Output node: The node where a Flow hands a value back. Each Output node is one named output, and together they are what another Flow, an Agent or an App sees when it uses this Flow.See also Input node, Flow.Documentation: Inputs and outputs ↗
Partial run: Running a Flow only up to a chosen node, to check the values so far without executing everything after it.See also Flow run.
Past runs: The tab on a Flow or Agent that lists its previous runs, each with its inputs, outputs and the record of every node. Where you go to see what actually happened.See also Flow run.
Plugin: An installable extension that adds specialised nodes or integrations to the platform.See also Integration, Agent Sandbox.
Preset: A named, reusable set of model choices, such as Cost-Effective Models or High-Performance Models, that builders pick instead of a single model. Changing a shared preset changes every component that uses it.See also Provider, AI model.Documentation: Model presets ↗
Process: The reusable definition of how one kind of work gets done, from the event that starts it to the outcome the organisation needs. It names the activities, the decisions that choose a route, and who or what performs each step. Built in Process Builder; every time the work happens it produces a case.See also Case, Process Builder, Work Queue.
Process Builder: Where a Process is defined: its activities, how each one runs, who performs it, and what happens when work fails or needs a person. A task in the design can have an automation Flow attached.See also Process, Flow.
Prompt Improver: A platform feature that rewrites a draft prompt or set of instructions into a clearer, more complete version for the builder to review.See also Prompt, Instructions.
Provider: The company that trains a model and serves it over an API, such as OpenAI, Anthropic or Google. In Noxus, also the service models are reached through, such as Azure AI Foundry, Azure OpenAI or Google Vertex AI: the platform team connects a provider, and importing a model makes it selectable for Agents and Flows.See also AI model, Preset.Documentation: Models and providers ↗
Query Table: Asking a Table a question: which rows match a filter, in what order, how many. Available as a node in a Flow and as a tool for an Agent.See also Table, SQL.Documentation: SQL queries on Tables ↗
Rate limits: Caps on how many requests the platform’s public API accepts in a period, for operations such as starting runs or searching knowledge. Platform limits, separate from a model provider’s own quotas.See also API.Documentation: Rate limiting ↗
Retrieval: Finding the passages relevant to a question in a larger body of material, by meaning, so a passage matches when its words differ from the question. The passages then become context for a model, and embedding models and rerankers do the finding. In Noxus, retrieval runs over a Knowledge Base.See also Knowledge Base, Embedding model, Reranker.Documentation: Search and retrieval settings ↗
Run Code node: The node that runs a short piece of code written by the builder. Used for exact checks a model should not be trusted with, such as comparing two dates or validating an identifier.See also Deterministic, Conditional node.Documentation: Logic and control nodes ↗
Run details: The record of how one automated step executed: the inputs each node received, what it produced and how long it took. Where to look when a reading error is suspected.See also Flow run, Audit logs.
Self-hosted: A platform installation the client controls, in its own cloud account or on its own infrastructure. It describes who runs the platform and says nothing about where the models run: a self-hosted Noxus can still call an external model service.See also Worker, Model endpoint.Documentation: Deploying Noxus ↗
Subflow: A Flow used as a node inside another Flow. Its inputs and outputs become the interface the outer Flow sees, so a piece of work can be built once and reused.See also Flow.Documentation: Subflows ↗
Switch node: The node that sends the run down one of several named paths depending on a value, such as an outcome of Compliant, Not compliant or Cannot tell. Each path can end differently.See also Conditional node.Documentation: The Switch node ↗
Table: Structured records in rows with typed columns, for information a Flow or Agent needs to read, filter, query or update: reference values, supplier records, dates, results. Prose belongs in a Knowledge Base; records belong in a Table.See also Knowledge Base, Insert Table Row node, Query Table.Documentation: Data Tables ↗
Task: One piece of work that moves a case forward, with a purpose, its inputs, an expected result and someone or something responsible for it. A person, an Agent, a Flow or a connected system can hold a task. Finishing a task does not finish the case.See also Case.
Tools: The capabilities a model may invoke beyond producing text: an API, a database query, a document store, a calculation, an action in another system. In Noxus, what an Agent can reach beyond its own model: knowledge it can search, Tables it can query, Flows it can call and connected systems it can use, which the platform calls the Agent’s actions.See also Agent, Knowledge Base, Table, Flow.Documentation: Agent tools ↗
Trigger: An event that starts a Flow run without a person pressing a button, such as an email arriving in a watched mailbox.See also App, Flow run.Documentation: Triggers ↗
Version: A saved state of a Flow, Agent or Process that can be returned to. The live version is kept apart from drafts, and a case records which version it ran under.See also Evaluation suite.
Widget: An Agent embedded in another website or application as a chat window, so people can use it where they already work.See also Agent.Documentation: Chat and widget deployment ↗
Work Queue: The operational surface of one Process: the list of its cases in progress, their status and assignment, and the human work waiting to be picked up. The team runs the Process from here. Older screens label it Inbox.See also Process, Case.
Worker: One of the four parts of an installation: the services that actually perform Flow and Agent runs, as distinct from the application people use, the backend that coordinates work, and the storage that keeps records.See also Self-hosted.
Workspace: A bounded area of a Noxus installation holding one set of resources, the Flows, Agents, Knowledge Bases, Tables and Work Queues of one area of work, and the people who work with them.See also Organisation, Workspace role.Documentation: Workspaces ↗
Workspace role: A role that controls what a person can do inside the workspaces they belong to. The built-in roles are Case Worker, Runner, Editor and Admin, from working cases only up to full workspace access.See also Organisation role, Workspace.Documentation: Permissions and roles ↗
Workspace variables: Named values set once for a workspace and read by its Flows, such as an ERP address. Secrets are the same idea for values that must not be shown, such as an API key.See also Workspace.Documentation: Variables and secrets ↗

Other terms

The general vocabulary the courses lean on: AI, software, and the business words of the running example.

Agent loop: How an agent works: understand the objective, decide the next step, pick a tool, act, read the result, decide again, until the task is done or needs a person. A business process adds state, explicit logic, exact rules, permissions and human intervention around the loop.See also Agent, Tools.
AI model: A trained system that takes in text, and sometimes images or files, and produces an output: an answer, an extracted value, a classification, a choice. Noxus does not train models; it connects to models that providers serve.See also Language model, Provider.
API: Application programming interface: the way one piece of software asks another for data or tells it to do something, without a person in between. Noxus has one for starting work from outside, and calls those of the client’s systems.See also API endpoint, Make API Request node.Documentation: REST API reference ↗
API endpoint: One address an API exposes for one kind of request, such as reading a supplier record. A GET request asks for data; a POST request sends some.See also API, Status code.
BYOK: Bring your own key: the organisation supplies the credentials or the approved endpoint a platform uses to call a model, so the model relationship, its contract and its data terms stay with the organisation rather than the platform.See also Provider, Sovereignty.
Context window: The amount of text a language model can take into account for one request: instructions, the question, retrieved passages, earlier turns, tool results. It is finite, and a fact that never enters it is a fact the model cannot use, which is why retrieval exists.See also Retrieval, Retrieval-augmented generation, Token.Documentation: Model selection guide ↗
Data residency: Where data is stored and processed. The platform, the operational data and the model calls can each carry a separate requirement, and the terms depend on the provider, the service, the region and the contract.See also Sovereignty, Self-hosted.
Decision model: A model that reads language or images and answers only in typed shapes: a choice from a set, a score on given levels, or a yes or no, each with a probability. It writes no text. Used for the steps of a process that route, classify or gate, with a threshold deciding when a person looks. TypeSafe's Jev is the best-known example.See also AI model, Language model.
Deterministic: Producing the same output for the same input every time. A rule in code is deterministic; a model reading a document is not. The courses put exact checks in code and interpretation in models for this reason.See also Run Code node, Hallucination.
Embedding model: A model that turns text into numbers in such a way that related meanings land close together. It is what lets a Knowledge Base find the passage about accepted standards from a question that uses different words.See also Retrieval, Reranker.
ERP: Enterprise Resource Planning: the system a company runs its core operations in, holding its suppliers, materials, orders and records. In the running example the ERP is the system of record for which supplier and material an order concerns.See also System of record, Integration.
Frontier model: One of the most capable general-purpose models available at the time. Worth its cost on ambiguous evidence and complex reasoning; a smaller model does narrow, repeatable work for less.See also Reasoning model, AI model.
Hallucination: A fluent answer from a language model that is not supported by the evidence it was given. The reason a judgement should quote the passage behind it, and why a date comparison belongs in code rather than a model.See also Deterministic, Retrieval.
JSON: A plain-text format for structured data, written as named fields in braces. The common currency between Flows, APIs and models when they exchange more than one value.See also Schema, API.
Kubernetes: A system that runs software packaged as containers across several machines, restarting and scaling pieces independently. The hosting option for installations that need workers and services to grow separately.See also Virtual machine, Worker.Documentation: Kubernetes deployment ↗
Language model: A model that reads and writes language. It can classify an email, extract values from a document, draft an explanation or help an Agent choose a tool. Often abbreviated LLM, for large language model.See also AI model, Prompt.
Model endpoint: The address a model is served from, in a provider’s cloud or inside the client’s network. Importing a model into Noxus does not move it: the model keeps running at its endpoint, and document content sent to it is processed there.See also Provider, Self-hosted.
Model independence: Keeping model access separate from the business process, so that swapping the model for a step is a configuration change rather than a redesign. Providers release, retire, reprice and occasionally fail; the process should survive all four.See also Provider, Preset.
Multimodal model: A language model that can take inputs beyond text, such as an image of a scanned certificate.See also Language model.
Parameters: The adjustable numbers inside a model, millions or billions of them, that training sets from examples. After training they stop changing, and together they hold the patterns the model applies to new inputs. Nobody writes them by hand.See also Training, AI model.
Primary key: The column, or combination of columns, whose value identifies one row of a Table and no other, such as a submission number.See also Table, Schema.
Procurement policy: In the running example, the manufacturer’s written rules for which supplier certificates are acceptable for which materials. It lives in a Knowledge Base, and the judgement is made against it.See also Knowledge Base, ERP.
Prompt: The text sent to a language model to tell it what to do: the task, the format of the answer and any rules. In a Generate Text node the prompt is written by the builder; an Agent’s instructions are a prompt that applies to every conversation.See also Generate Text node, Instructions.
Reasoning model: A language model built to work through harder analysis step by step, such as weighing several policy requirements at once. Slower and dearer than a general model, so used where the task needs it.See also Language model, Frontier model.
Reranker: A model that takes the passages a search found and puts the most relevant first, so the language model sees the best evidence.See also Embedding model, Retrieval.
Retrieval-augmented generation: Fetching the passages that matter for the current request from a document collection and placing them in the model's context before it answers. An embedding model and a reranker usually do the fetching. In Noxus, a Knowledge Base is where this happens.See also Retrieval, Embedding model, Reranker, Knowledge Base.Documentation: Knowledge Bases ↗
Schema: The declared shape of some data: which fields or columns exist, what type each one has, and which are required. A Table has a schema; so does a structured output.See also Structured output, Table.
Single sign on: Signing in to Noxus with the identity a person already uses at work, through the company’s identity provider, instead of a separate password.See also Organisation role.Documentation: Authentication ↗
Sovereignty: An organisation's control over the environment a system runs in: where the runtime and the data sit, which providers and services it depends on, how those dependencies are permitted, how updates enter, and whether the organisation can keep operating the system on infrastructure it controls.See also Self-hosted, Data residency, Model independence.
SQL: The standard language for asking questions of tabular data: which rows match, sorted how, counted or summed. Querying a Table in Noxus follows the same ideas.See also Query Table, Table.
Status code: The three-digit number an API returns with every response to say how the request went: 200 for success, 404 for not found, 500 for a failure on the other side. A Flow reads it to decide whether to trust the response.See also API endpoint.
Structured output: A model answer returned as named fields in a fixed shape rather than free text, so the next step can use each value directly. Separate field outputs on a Generate Text node are this.See also Schema, JSON.
System of record: The one system that holds the authoritative copy of a piece of information. If the ERP owns supplier identifiers, a Flow establishes identity from its record, not from a name printed on a document.See also ERP.
Token: The unit a language model reads and writes in, roughly three quarters of a word. Models are priced per token, which is why a long prompt or a long document costs more to process.See also Analytics, Language model.
Training: The process that sets a model's parameters from examples: show the model inputs with the right answers attached, adjust the parameters a little each time it is wrong, repeat. It happens before anyone uses the model. Giving a model a document as context does not train it.See also Parameters, Context window.
Virtual machine: One rented machine in a cloud, running every Noxus service together. The simplest hosting option, with capacity and availability shaped by that single machine.See also Kubernetes, Self-hosted.Documentation: Virtual machine deployment ↗
VPN: Virtual private network: a company’s private network connection for its staff. An application reachable only through the VPN is invisible from the open internet but can still call approved cloud services.See also Self-hosted.

Glossary

Every term the Academy uses, in two lists: the platform's own words, and the general vocabulary the courses lean on.

Noxus terms

The platform's own objects and screens, spelled the way the interface spells them.

Agent: A model given instructions, context and a set of tools, working towards an objective and choosing its own next step from what it finds. In Noxus, an Agent can be used in conversation, where a person asks it questions, or inside a Process, where it performs a task.See also Instructions, Context, Tools, Flow.Documentation: Agents (concept) ↗
Agent node: The node that hands a task to an Agent inside a Flow, with a request and the context it needs, and takes the Agent’s answer back as outputs. The Flow decides where the Agent’s work belongs and what happens to its result.See also Agent, Agentic step.Documentation: Agents in Flows ↗
Agent Sandbox: An isolated environment where code run by an Agent, and plugins, execute away from the rest of the platform. Present only when the installation is configured with one.See also Plugin, Run Code node.
Agentic step: A step in a Flow where a model or Agent has some discretion over how to finish the task, such as choosing which passages to retrieve. The Flow still decides where that step sits and what is done with its result.See also Agent node, Flow.
Analytics: Patterns across many runs: activity, errors, duration, model usage and what it costs. Where to look when something has changed over time rather than in one case.See also Run details, Token.Documentation: Analytics ↗
App: A Flow made available to people as a form: they fill in its inputs and see its outputs, without opening the Flow editor.See also Flow, Trigger.Documentation: Deploying a Flow as a form ↗
Audit logs: The platform’s own record of who did what, and when. Administrators set how long entries are kept and can export a period.See also Run details, Analytics.Documentation: Auditability ↗
Build section: The group of pages in the side navigation where builders create and manage their tools: Flows, Agents, Data (Knowledge Bases and Tables) and the App library. Earlier versions of the Platform called it the Workshop.See also Workspace.Documentation: The visual editor ↗
Case: One instance of a Process: one supplier being onboarded, one claim, one complaint. The case carries the data, documents, tasks, results and history of that piece of work, and the Process reads it to decide what happens next.See also Process, Task, Work Queue.
Conditional node: The node that sends the run down one of two paths depending on whether a condition is true. The simplest form of branching in a Flow.See also Switch node.Documentation: Conditionals and branching ↗
Connection: The configured account and credentials an integration uses to reach an external system. It decides what Noxus itself may do there, separately from what any person may do.See also Integration.Documentation: Integrations ↗
Context: The information available to a model for the task in front of it: the case data, the retrieved passages, the values a Flow has produced so far. The instructions say what to do; the context is what to do it with.See also Agent, Retrieval.
Evaluation suite: A set of test inputs with expected results, run against a Flow to show whether a change to a model, a prompt or the logic still produces the right answers before it reaches the operation.See also Version.Documentation: Tests and evaluators ↗
Extract from Structured node: The node that pulls named fields out of a structured value such as a JSON object, so later nodes can use each field on its own.See also JSON, Schema.Documentation: Data and file nodes ↗
Flow: A defined sequence of operations, built from nodes connected in order. A Flow has named inputs and outputs, so other components can use it without knowing the steps inside. It can mix exact logic with model steps, and can call or be called by an Agent.See also Node, Flow run, Subflow.Documentation: Flows (concept) ↗
Flow run: One execution of a Flow: its inputs, its outputs and a record of what every node did. The run is to a Flow what a case is to a Process. The Past runs tab lists them.See also Flow, Past runs.
Generate Text node: The node that sends a prompt and context to a language model and returns its answer. Used to read documents, extract values and draft text. It can return separate named fields instead of one block of text.See also Prompt, Language model, Extract from Structured node.Documentation: Text generation ↗
Guardrails: Limits placed around an agent so that it stays on its task: what it may read, what it may change, which systems it may call and what it must refuse. In Noxus, an Agent’s instructions and the tools it is given set these limits.See also Agent, Instructions.Documentation: Agent best practices ↗
Ingestion: The step that takes a file into a Knowledge Base: processing it, breaking it into passages and indexing them so they can be searched. A document that fails ingestion cannot be found later.See also Knowledge Base, Retrieval.Documentation: Supported files and sources ↗
Input node: The node where a Flow receives a value from outside: a file, a piece of text, a number. Each Input node is one named input of the Flow.See also Output node, Flow.Documentation: Inputs and outputs ↗
Insert Table Row node: The node that writes one record into a Table, binding each column to a value from the run. The register of submissions in the Associate course is filled this way.See also Table, Query Table.Documentation: Data Tables ↗
Instructions: The text that defines an Agent’s role, its task and its boundaries: what it is for, what it may do, and how it should use the evidence it is given.See also Agent, Prompt.Documentation: Prompts and instructions ↗
Integration: Access to an external application or service, such as the client’s ERP, so a Flow or Agent can read its records and write results back. A configured connection supplies the account and permissions used.See also Connection, API.Documentation: Integrations ↗
Knowledge Base: A collection of documents made available for retrieval by Agents and Flows: policies, procedures, manuals, contracts. Files are ingested and indexed, then relevant passages are retrieved in response to a question.See also Ingestion, Retrieval, Embedding model.Documentation: Knowledge Bases ↗
Make API Request node: The node that calls an external system over its API: a GET to read a record, a POST to write one. The response is mapped to named outputs the rest of the Flow can use.See also API, API endpoint, Integration.Documentation: Integration nodes ↗
Model Picker: The control on an Agent or a model node where the builder chooses a specific model or a preset.See also Preset, Provider.Documentation: Models and providers ↗
Node: One step in a Flow, with its own inputs and outputs. A node can receive an input, read a document, call a model, apply a rule, query a Table, invoke an Agent or call an external system. Connections between nodes set the order and pass values along.See also Flow.Documentation: Flows ↗
Organisation: The client’s whole Noxus installation, holding its users, its workspaces and its platform settings. The interface spells it Organization.See also Workspace, Organisation role.
Organisation role: A role that controls administration across the whole installation: users, identity, providers and settings. Separate from any workspace role the same person holds.See also Workspace role, Organisation.Documentation: Permissions and roles ↗
Output node: The node where a Flow hands a value back. Each Output node is one named output, and together they are what another Flow, an Agent or an App sees when it uses this Flow.See also Input node, Flow.Documentation: Inputs and outputs ↗
Partial run: Running a Flow only up to a chosen node, to check the values so far without executing everything after it.See also Flow run.
Past runs: The tab on a Flow or Agent that lists its previous runs, each with its inputs, outputs and the record of every node. Where you go to see what actually happened.See also Flow run.
Plugin: An installable extension that adds specialised nodes or integrations to the platform.See also Integration, Agent Sandbox.
Preset: A named, reusable set of model choices, such as Cost-Effective Models or High-Performance Models, that builders pick instead of a single model. Changing a shared preset changes every component that uses it.See also Provider, AI model.Documentation: Model presets ↗
Process: The reusable definition of how one kind of work gets done, from the event that starts it to the outcome the organisation needs. It names the activities, the decisions that choose a route, and who or what performs each step. Built in Process Builder; every time the work happens it produces a case.See also Case, Process Builder, Work Queue.
Process Builder: Where a Process is defined: its activities, how each one runs, who performs it, and what happens when work fails or needs a person. A task in the design can have an automation Flow attached.See also Process, Flow.
Prompt Improver: A platform feature that rewrites a draft prompt or set of instructions into a clearer, more complete version for the builder to review.See also Prompt, Instructions.
Provider: The company that trains a model and serves it over an API, such as OpenAI, Anthropic or Google. In Noxus, also the service models are reached through, such as Azure AI Foundry, Azure OpenAI or Google Vertex AI: the platform team connects a provider, and importing a model makes it selectable for Agents and Flows.See also AI model, Preset.Documentation: Models and providers ↗
Query Table: Asking a Table a question: which rows match a filter, in what order, how many. Available as a node in a Flow and as a tool for an Agent.See also Table, SQL.Documentation: SQL queries on Tables ↗
Rate limits: Caps on how many requests the platform’s public API accepts in a period, for operations such as starting runs or searching knowledge. Platform limits, separate from a model provider’s own quotas.See also API.Documentation: Rate limiting ↗
Retrieval: Finding the passages relevant to a question in a larger body of material, by meaning, so a passage matches when its words differ from the question. The passages then become context for a model, and embedding models and rerankers do the finding. In Noxus, retrieval runs over a Knowledge Base.See also Knowledge Base, Embedding model, Reranker.Documentation: Search and retrieval settings ↗
Run Code node: The node that runs a short piece of code written by the builder. Used for exact checks a model should not be trusted with, such as comparing two dates or validating an identifier.See also Deterministic, Conditional node.Documentation: Logic and control nodes ↗
Run details: The record of how one automated step executed: the inputs each node received, what it produced and how long it took. Where to look when a reading error is suspected.See also Flow run, Audit logs.
Self-hosted: A platform installation the client controls, in its own cloud account or on its own infrastructure. It describes who runs the platform and says nothing about where the models run: a self-hosted Noxus can still call an external model service.See also Worker, Model endpoint.Documentation: Deploying Noxus ↗
Subflow: A Flow used as a node inside another Flow. Its inputs and outputs become the interface the outer Flow sees, so a piece of work can be built once and reused.See also Flow.Documentation: Subflows ↗
Switch node: The node that sends the run down one of several named paths depending on a value, such as an outcome of Compliant, Not compliant or Cannot tell. Each path can end differently.See also Conditional node.Documentation: The Switch node ↗
Table: Structured records in rows with typed columns, for information a Flow or Agent needs to read, filter, query or update: reference values, supplier records, dates, results. Prose belongs in a Knowledge Base; records belong in a Table.See also Knowledge Base, Insert Table Row node, Query Table.Documentation: Data Tables ↗
Task: One piece of work that moves a case forward, with a purpose, its inputs, an expected result and someone or something responsible for it. A person, an Agent, a Flow or a connected system can hold a task. Finishing a task does not finish the case.See also Case.
Tools: The capabilities a model may invoke beyond producing text: an API, a database query, a document store, a calculation, an action in another system. In Noxus, what an Agent can reach beyond its own model: knowledge it can search, Tables it can query, Flows it can call and connected systems it can use, which the platform calls the Agent’s actions.See also Agent, Knowledge Base, Table, Flow.Documentation: Agent tools ↗
Trigger: An event that starts a Flow run without a person pressing a button, such as an email arriving in a watched mailbox.See also App, Flow run.Documentation: Triggers ↗
Version: A saved state of a Flow, Agent or Process that can be returned to. The live version is kept apart from drafts, and a case records which version it ran under.See also Evaluation suite.
Widget: An Agent embedded in another website or application as a chat window, so people can use it where they already work.See also Agent.Documentation: Chat and widget deployment ↗
Work Queue: The operational surface of one Process: the list of its cases in progress, their status and assignment, and the human work waiting to be picked up. The team runs the Process from here. Older screens label it Inbox.See also Process, Case.
Worker: One of the four parts of an installation: the services that actually perform Flow and Agent runs, as distinct from the application people use, the backend that coordinates work, and the storage that keeps records.See also Self-hosted.
Workspace: A bounded area of a Noxus installation holding one set of resources, the Flows, Agents, Knowledge Bases, Tables and Work Queues of one area of work, and the people who work with them.See also Organisation, Workspace role.Documentation: Workspaces ↗
Workspace role: A role that controls what a person can do inside the workspaces they belong to. The built-in roles are Case Worker, Runner, Editor and Admin, from working cases only up to full workspace access.See also Organisation role, Workspace.Documentation: Permissions and roles ↗
Workspace variables: Named values set once for a workspace and read by its Flows, such as an ERP address. Secrets are the same idea for values that must not be shown, such as an API key.See also Workspace.Documentation: Variables and secrets ↗

Other terms

The general vocabulary the courses lean on: AI, software, and the business words of the running example.

Agent loop: How an agent works: understand the objective, decide the next step, pick a tool, act, read the result, decide again, until the task is done or needs a person. A business process adds state, explicit logic, exact rules, permissions and human intervention around the loop.See also Agent, Tools.
AI model: A trained system that takes in text, and sometimes images or files, and produces an output: an answer, an extracted value, a classification, a choice. Noxus does not train models; it connects to models that providers serve.See also Language model, Provider.
API: Application programming interface: the way one piece of software asks another for data or tells it to do something, without a person in between. Noxus has one for starting work from outside, and calls those of the client’s systems.See also API endpoint, Make API Request node.Documentation: REST API reference ↗
API endpoint: One address an API exposes for one kind of request, such as reading a supplier record. A GET request asks for data; a POST request sends some.See also API, Status code.
BYOK: Bring your own key: the organisation supplies the credentials or the approved endpoint a platform uses to call a model, so the model relationship, its contract and its data terms stay with the organisation rather than the platform.See also Provider, Sovereignty.
Context window: The amount of text a language model can take into account for one request: instructions, the question, retrieved passages, earlier turns, tool results. It is finite, and a fact that never enters it is a fact the model cannot use, which is why retrieval exists.See also Retrieval, Retrieval-augmented generation, Token.Documentation: Model selection guide ↗
Data residency: Where data is stored and processed. The platform, the operational data and the model calls can each carry a separate requirement, and the terms depend on the provider, the service, the region and the contract.See also Sovereignty, Self-hosted.
Decision model: A model that reads language or images and answers only in typed shapes: a choice from a set, a score on given levels, or a yes or no, each with a probability. It writes no text. Used for the steps of a process that route, classify or gate, with a threshold deciding when a person looks. TypeSafe's Jev is the best-known example.See also AI model, Language model.
Deterministic: Producing the same output for the same input every time. A rule in code is deterministic; a model reading a document is not. The courses put exact checks in code and interpretation in models for this reason.See also Run Code node, Hallucination.
Embedding model: A model that turns text into numbers in such a way that related meanings land close together. It is what lets a Knowledge Base find the passage about accepted standards from a question that uses different words.See also Retrieval, Reranker.
ERP: Enterprise Resource Planning: the system a company runs its core operations in, holding its suppliers, materials, orders and records. In the running example the ERP is the system of record for which supplier and material an order concerns.See also System of record, Integration.
Frontier model: One of the most capable general-purpose models available at the time. Worth its cost on ambiguous evidence and complex reasoning; a smaller model does narrow, repeatable work for less.See also Reasoning model, AI model.
Hallucination: A fluent answer from a language model that is not supported by the evidence it was given. The reason a judgement should quote the passage behind it, and why a date comparison belongs in code rather than a model.See also Deterministic, Retrieval.
JSON: A plain-text format for structured data, written as named fields in braces. The common currency between Flows, APIs and models when they exchange more than one value.See also Schema, API.
Kubernetes: A system that runs software packaged as containers across several machines, restarting and scaling pieces independently. The hosting option for installations that need workers and services to grow separately.See also Virtual machine, Worker.Documentation: Kubernetes deployment ↗
Language model: A model that reads and writes language. It can classify an email, extract values from a document, draft an explanation or help an Agent choose a tool. Often abbreviated LLM, for large language model.See also AI model, Prompt.
Model endpoint: The address a model is served from, in a provider’s cloud or inside the client’s network. Importing a model into Noxus does not move it: the model keeps running at its endpoint, and document content sent to it is processed there.See also Provider, Self-hosted.
Model independence: Keeping model access separate from the business process, so that swapping the model for a step is a configuration change rather than a redesign. Providers release, retire, reprice and occasionally fail; the process should survive all four.See also Provider, Preset.
Multimodal model: A language model that can take inputs beyond text, such as an image of a scanned certificate.See also Language model.
Parameters: The adjustable numbers inside a model, millions or billions of them, that training sets from examples. After training they stop changing, and together they hold the patterns the model applies to new inputs. Nobody writes them by hand.See also Training, AI model.
Primary key: The column, or combination of columns, whose value identifies one row of a Table and no other, such as a submission number.See also Table, Schema.
Procurement policy: In the running example, the manufacturer’s written rules for which supplier certificates are acceptable for which materials. It lives in a Knowledge Base, and the judgement is made against it.See also Knowledge Base, ERP.
Prompt: The text sent to a language model to tell it what to do: the task, the format of the answer and any rules. In a Generate Text node the prompt is written by the builder; an Agent’s instructions are a prompt that applies to every conversation.See also Generate Text node, Instructions.
Reasoning model: A language model built to work through harder analysis step by step, such as weighing several policy requirements at once. Slower and dearer than a general model, so used where the task needs it.See also Language model, Frontier model.
Reranker: A model that takes the passages a search found and puts the most relevant first, so the language model sees the best evidence.See also Embedding model, Retrieval.
Retrieval-augmented generation: Fetching the passages that matter for the current request from a document collection and placing them in the model's context before it answers. An embedding model and a reranker usually do the fetching. In Noxus, a Knowledge Base is where this happens.See also Retrieval, Embedding model, Reranker, Knowledge Base.Documentation: Knowledge Bases ↗
Schema: The declared shape of some data: which fields or columns exist, what type each one has, and which are required. A Table has a schema; so does a structured output.See also Structured output, Table.
Single sign on: Signing in to Noxus with the identity a person already uses at work, through the company’s identity provider, instead of a separate password.See also Organisation role.Documentation: Authentication ↗
Sovereignty: An organisation's control over the environment a system runs in: where the runtime and the data sit, which providers and services it depends on, how those dependencies are permitted, how updates enter, and whether the organisation can keep operating the system on infrastructure it controls.See also Self-hosted, Data residency, Model independence.
SQL: The standard language for asking questions of tabular data: which rows match, sorted how, counted or summed. Querying a Table in Noxus follows the same ideas.See also Query Table, Table.
Status code: The three-digit number an API returns with every response to say how the request went: 200 for success, 404 for not found, 500 for a failure on the other side. A Flow reads it to decide whether to trust the response.See also API endpoint.
Structured output: A model answer returned as named fields in a fixed shape rather than free text, so the next step can use each value directly. Separate field outputs on a Generate Text node are this.See also Schema, JSON.
System of record: The one system that holds the authoritative copy of a piece of information. If the ERP owns supplier identifiers, a Flow establishes identity from its record, not from a name printed on a document.See also ERP.
Token: The unit a language model reads and writes in, roughly three quarters of a word. Models are priced per token, which is why a long prompt or a long document costs more to process.See also Analytics, Language model.
Training: The process that sets a model's parameters from examples: show the model inputs with the right answers attached, adjust the parameters a little each time it is wrong, repeat. It happens before anyone uses the model. Giving a model a document as context does not train it.See also Parameters, Context window.
Virtual machine: One rented machine in a cloud, running every Noxus service together. The simplest hosting option, with capacity and availability shaped by that single machine.See also Kubernetes, Self-hosted.Documentation: Virtual machine deployment ↗
VPN: Virtual private network: a company’s private network connection for its staff. An application reachable only through the VPN is invisible from the open internet but can still call approved cloud services.See also Self-hosted.