Glossary

A one-paragraph definition of every term the Academy uses. Skim it once now; come back whenever a word is unfamiliar. Terms are grouped, not alphabetised, so related ideas sit together.

Some older links and screenshots still use previous names. The names in this glossary are the ones on screen today.

Where you are — the three scopes

Everything in the product sits at one of three levels, and knowing which one you are looking at answers most “why can’t I change this?” questions.

Platform — The whole install: every workspace, every project, every account. Platform settings open from the account menu (your avatar, top right) ▸ Administration ▸ Admin. Only someone with the Platform Admin role — or on the Super Admin list — sees that entry at all.
Workspace — The container that holds projects, people and licences. Its settings — General, Users & Access, Audit & Usage — open from the ⚙ on a workspace row in the Browse overlay (Browse everything on the Command Deck). If your organisation reaches the platform on its own web address, the same three open from the Workspace Settings gear on your project list.
Project — One solution inside a workspace, with its own collections, agents, experience, people and personas. Almost everything you build is scoped to one project.

The three levels form a ladder: the platform sets the ceiling, each workspace sets its own rules inside that ceiling, and each project reads what it inherited. Wherever a limit bites, the screen names who set it and who to ask.

The containers

Collection — The home for one type of record in a project — its schema, its processing, its lifecycle, and the screens people work it on. Set up under Studio ▸ Data ▸ Collections. See D1 · Collections & schema.
Document — One ingested record (a PDF, a crawled page, pasted text, a form submission). It appears in the list before extraction finishes (you see a “Processing…” chip), then fills in with extracted fields, sections and lifecycle history.
Record — A row in a structured collection: the same idea as a document, but typed columns rather than a file.

Collection flavours

Processing collection — Each document moves through review stages, an agent extracts and scores its fields, people confirm, a decision is recorded. The “decide on each document” case (invoices, claims, contracts).
Knowledge collection — Each document is turned into searchable knowledge so agents can read and cite it. The “answer questions over a corpus” case (handbooks, manuals, policies). It gets an extra Index Health tab showing whether its documents are ready to be searched.
Structured collection — Typed rows and columns instead of files. It gets an extra Schema tab where you define the columns.
Human collection — A work queue people run themselves, with no agent attached. It is not one of the purposes you pick when creating a collection; the project’s Inbox is one.

See D2 · Collection types.

The schema — what to pull out

Taxonomy — The extraction schema, shown as a tree on a collection’s Taxonomy tab.
Learner — The schema container at the top of that tree, attached to a collection.
Label — A single extractable field: a name plus a type (invoice_total / currency). The thing an agent fills in and a person can correct. Some screens call it a Field — same thing.
Schema — Not a separate object: a schema is a learner plus its labels. An agent’s output targets a schema.

The lifecycle — how a document moves

Lifecycle (also shown as workflow stages) — The ordered stages a document passes through in a processing collection, with gated transitions between them. Configured on a collection’s Lifecycle tab. This is not an XFlow. The default is the 8-stage Four-Eyes flow.
Four-Eyes flow — The lifecycle seeded on new processing collections: Intake → AI Processing → AI Recommendation → L1 Review → L2 Approval → Needs Info → Approved / Declined. “AI recommends, two people confirm, the platform remembers.”
Stage — One step in a lifecycle. It can require human review, be limited to particular personas, and trigger automations.
Decision — Not a stored object: a decision is read back from the document’s stage history — the audit trail is the record.

The workforce — things that run

Agent — A configured AI worker: instructions + model + tools + skills + MCP servers + guard rails + knowledge + (optional) sub-agents. See A1 · Agent anatomy.
Agent mode (Auto / Fast / Thinking) — How an agent executes, picked on the agent’s Model tab. Fast is a low-latency tool-use loop. Thinking is extended reasoning with human-in-the-loop support. Auto lets the platform choose per request; pick Fast or Thinking explicitly when you need predictable behaviour.
Multi-agent team — One leader agent delegating to member agents. Modes: coordinate (delegate and synthesise), route (pick one member), collaborate (all in parallel), sequential (pipe member to member).
Mesh — A durable pipeline that wires runnables (agents, XFlows, other meshes, services) together and survives restarts. For long, multi-step automations. A mesh member does one bounded step; work that runs for a long time — a slow external check — belongs in a Service, which parks until it reports back.
XFlow — A visual pipeline: a graph of operators (a step of code, an agent call, a query, an API call, an indexing step). The reusable “verb” that processes documents. Distinct from a lifecycle, which is the document’s stage machine. Flows live alongside agents on Studio ▸ Agents ▸ Agents. See A10 · XFlows & pipelines.

Capabilities — what a runnable can use

Tool — A callable an agent can invoke: either a built-in one (search, knowledge retrieval) or a custom tool you register under Studio ▸ Agents ▸ Tools with a URL and an input schema.
Skill — A reusable, parameterised capability an agent can pick up. Catalogued per project under Studio ▸ Agents ▸ Skills.
Skill pack — A bundle of skills that expands to its members when loaded.
MCP server — An external tool server you connect under Studio ▸ Agents ▸ MCP Servers, so its tools become available to your agents. See A7 · MCP servers.
Guard rail — A safety rule attached to an agent, blocking unwanted answers or actions. See A8 · Guard rails.
Language model — A model registered under Studio ▸ Agents ▸ Language Models with its endpoint and credentials. Agents pick one, with failover. Older screenshots call this page “LLMs”.
Managed Gateway — The platform’s own hosted model access, offered on the Language Models page. Choose it when you don’t want to bring your own model account.
AI model (trained extractor) — Not a language model: the platform’s own trainable extraction and classification models, managed under Studio ▸ Agents ▸ AI Models and scored in the Prediction Report.

Data & integration

Connector — A saved connection to an external source (SharePoint, email, a drive, a feed, blob storage), set up under Studio ▸ Data ▸ Ingestion. The connector is the identity — what you sign in as. See D4 · Ingestion & connectors.
Job — A scheduled pull from one connector, scoped to what it should fetch (“the /Legal folder”), with its own schedule and de-duplication. The connector is the identity, the job is the scope.
Input form — A form people fill in to add a record by hand, built under Studio ▸ Data ▸ Input Form and switched on for the collections that should offer it. The third way data arrives, alongside upload and a connector.
Event / webhook — A collection-level subscription that fires when a lifecycle stage or a label changes, calling out to an external address. Configured on a collection’s Events tab.
View — A saved, filtered slice of a collection’s documents — a named query that surfaces extracted labels as columns. Set up under Studio ▸ Data ▸ Views, not under Search.
Datasheet — A tabular data table the project reads and writes, under Studio ▸ Data ▸ Datasheets. Fill it by hand or sync it from a source. See D5 · Drive & datasheet.
Drive — The project’s file storage: a folder tree and file browser for raw files, under Studio ▸ Data ▸ Drive.
Service — A long-running external worker you register under Studio ▸ Agents ▸ Services (a slow model, a scanning engine, a partner API) so a mesh or flow can hand work to it and park until it reports back. An advanced surface — if you cannot see it, ask your administrator. See A2 · LLMs & services.
Library — Reusable building blocks — such as derivation and calculation libraries — that agents and collections reach for, under Studio ▸ Agents ▸ Library.
Bot — An automation worker that carries out repetitive steps and feeds structured data into the platform, under Studio ▸ Agents ▸ Bots.
Export — How finished documents and results leave the platform: on ingestion, on a workflow transition, or on demand. Set up under Studio ▸ Data ▸ Export.

The experience your users see

Page — A screen you design under Studio ▸ Experience ▸ Pages: pick a layout, drop in cards, configure each one, preview it. What your end users land on is a page you built.
Card — One block on a page — a list, a chart, a viewer, a chat panel. Browse the whole set under Studio ▸ Experience ▸ Cards.
Pack — A set of pages bundled into one journey, wired so a click on one page opens another, under Studio ▸ Experience ▸ Packs.
Search and Chat — The two conversational channels your users get, configured under Studio ▸ Experience ▸ Search and Studio ▸ Experience ▸ Chat.
Inbox — The work queue for people: items needing a person land here, and the review itself happens on the underlying document.

Distribution

Solution — A whole project packaged so it can be installed elsewhere: its collections, agents, flows and experience, without your documents.
Hub — The marketplace of ready-made solutions and agents, opened from the Hubs chip on the top bar while you are in Studio. Hubs ▸ Solutions carries whole solutions; Hubs ▸ Agents carries individual agents you can install into an existing project.
What ships and what does not — Configuration travels with a package; your documents, keys and connections stay behind. That is why an install asks you to point the package at your own model and your own collections before it runs. See V4 · Hubs & distribution.

People & access

One screen — Users & Access — appears at all three scopes with the same layout, the same role vocabulary and the same “About roles” explainer. What changes is the tabs and how much authority it has.

Users & Access — The people-and-permissions screen. At platform scope: Administration ▸ Admin ▸ Governance ▸ Users & Access (tabs: Users · Workspaces · Projects · Policies). At workspace scope: Workspace Settings ▸ Users & Access (Users · Projects · Policies). At project scope: Studio ▸ Governance ▸ Users & Access (People · Personas · Effective policy). See G1 · Access & roles.
Role — The platform’s own vocabulary for who administers what: Platform Admin (runs the install), Workspace Admin (runs one workspace), Builder (builds in Studio), Reviewer (annotates and reviews), Viewer (consumes search, chat and dashboards), plus the protected Project Admin.
Project Admin — The protected role that runs one project — its people, its personas, everything in Studio. It cannot be renamed or deleted, and a project must always keep at least one holder.
Super Admin — Botminds operations break-glass: a configured list of email addresses with cross-workspace access. It is not a role you can grant in the product; it is shown read-only.
Persona — Your solution’s own workflow role inside one project — Underwriter, L1-Reviewer, Claims Handler. Each persona bundles the pages, actions and data that role uses here. Managed on Studio ▸ Governance ▸ Users & Access ▸ Personas. Personas are separate from platform administration: the Personas tab keeps the two in visibly separate sections.
Policy — The rules that decide how people get in: how they join, who can invite, who can hand out passwords, the default join role, whether two-factor is required. A workspace sets its own on its Policies tab, inside the ceiling the platform set on its own Policies tab.
Effective policy — The read-only tab in a project showing which of those rules apply here and who set them. It exists so you can see why the Add-user dialog behaved the way it did without asking.
Company sign-in — Your organisation’s own identity provider. People who use it show an “SSO” badge on their row.
Email invite — An emailed secure link that lets the person set their own password. The default way to bring someone in — no passwords to share.
One-time password — A temporary password an admin generates and hands over. Shown once and never again; the person changes it after signing in.
View as / Return to your role — Preview the product as a lower level of access without signing out, from the account menu. Previews only go downward and are genuine: pages and data are limited to what the previewed role really gets, and your own admin powers are hidden while it is on. Return to your role is always one click away at the top of the same menu.
Audit & Usage — One page with a two-way switch: Audit shows who did what and when, Usage shows consumption and activity. It exists at all three scopes; the project one is Studio ▸ Governance ▸ Audit & Usage. See G5 · Audit & compliance.

Quality, releases and keys

Evaluation — A measured comparison of an agent, flow or mesh against a set of known-good answers: build the set, run the evaluation, compare against a baseline and watch for drift. Run from Studio ▸ Agents ▸ Evaluations; the known-good answers live in a collection created with the Dataset (Evaluation) purpose. See A12 · Crew & evaluations.
History — The project’s change record — what changed, when, and by whom — under Studio ▸ Governance ▸ History.
Snapshot — A saved copy of the project’s configuration you can restore from, under Studio ▸ Governance ▸ Snapshots.
Freeze — A switch that stops the project’s configuration being changed until you lift it again, under Studio ▸ Governance ▸ Freeze. Useful while an audit or a release is in flight.
API key — The credential another system uses to talk to this project. Create, rotate and revoke keys — and read the API reference — under Studio ▸ Governance ▸ APIs. See V1 · Runtime API.

Surfaces

Studio — The builder side of a project, opened from the Studio icon in the top bar. Four pillars run across the top of Studio — Agents, Data, Experience, Governance — and the Hubs chip and Exit Studio sit on the right of the top bar. Builders and project admins see the Studio icon; Viewers and Reviewers do not.
The four pillars — Agents (what does the work), Data (what it works on), Experience (what your users see), Governance (who may do what, how releases ship, what happened). Each pillar opens a list of pages on the left; small non-clickable headings such as Agent Toolkit or Designer break that list into sections.
The app your users see — Everything outside Studio: the pages you designed, document lists, the viewer, search, chat, the inbox. Exit Studio takes you there.
Switched off for a workspace — An administrator can hide some pages for a whole workspace. If you cannot see something this Academy describes, ask your administrator.

Next: S2 · Core concepts — the two heroes, which connects all of these into one picture you can hold in your head.