Glossary

A one-paragraph definition of every term in the Academy, plus the old “wire” name where the UI was renamed. Skim it once now; come back whenever a word is unfamiliar. Terms are grouped, not alphabetised, so related ideas sit together.

Naming drift — read this first. The platform has been renamed in place several times. The UI and this Academy use the new names; the API/URLs/database still carry the old ones. They are the same thing. The big three:

The Academy says	The code/URL says
Project	finon (FinonId, api/finon/*)
Collection	Entity (RelationalEntity, EntityId)
XFlow	Workflow (bm.workflows) — but a “Lifecycle/Stateflow” is a different thing; see below

---

The containers

• Subscription — The tenant / billing boundary; a workspace owner. Holds Projects, users, roles, and payment. The outer scoping ring on every request.
• Project (code: finon) — The workspace you build inside. Owns Collections, Agents, XFlows, Connectors, taxonomy, dashboards, roles. Almost everything is scoped to one Project.
• Collection (formerly: Entity) — The operational home for one type of record in a Project — its schema, pipelines, lifecycle, and surfaces. Has two independent axes: Category (Processing vs Knowledge — why it exists) and Kind (Agent vs Human — who works it). See D1 · Collections & schema.
• Document — One ingested record (PDF, crawled page, pasted text, form submission). Exists in the list before extraction finishes (you see a “Processing…” chip), then fills in with extracted fields, sections, and lifecycle history.

Collection flavours

• Processing collection — Each document moves through review stages, an agent extracts and scores its fields, humans confirm, a decision is recorded. The “decide on each document” case (invoices, claims, contracts).
• Knowledge collection — Each document is turned into searchable knowledge (chunked, embedded, indexed) so agents can read and cite it. The “answer questions over a corpus” case (handbooks, manuals, FAQs). Partly forward-looking in the current build — see D2 · Collection types.

The schema (what to pull out)

• Taxonomy — The extraction schema as a tree: Learner → Collection → Label.
• Learner — A trainable extractor / schema container attached to a Collection; the top of the schema tree.
• Label (UI: Field) — A single extractable field (a name + a type, e.g. invoice_total / currency). The thing an agent fills in and a human can correct. “Field” is the UI word; “Label” is the storage word — same thing.
• Schema — Not a separate object: a schema is a Learner plus its set of Labels. An agent’s output targets a schema.

The lifecycle (how a document moves)

• Lifecycle / Stateflow (also: Workflow stages) — The ordered stages a document passes through in a Processing collection, with role-gated transitions between them. This is NOT an XFlow. The default is the 8-stage Four-Eyes flow.
• Four-Eyes flow — The default lifecycle seeded on new Processing collections: Intake → AI Processing → AI Recommendation → L1 Review → L2 Approval → Needs Info → Approved / Declined. “AI recommends, two humans confirm, the platform remembers.”
• Stage — One step in a lifecycle. Can require human review, be gated to specific roles, and trigger automations.
• Decision — Not a stored object: a decision is inferred from the document’s stage history (the audit trail).

The workforce (runnables — things that execute)

• Agent — A configured LLM-backed worker: instructions + model + tools + skills + MCP + guard rails + knowledge + (optional) sub-agents. Built from a config row at runtime. See A1 · Agent anatomy.
• Agent mode (Auto / Fast / Thinking) — How an agent executes, picked on the agent’s Model tab. Fast = a low-latency tool-use loop. Thinking = extended reasoning with human-in-the-loop support. Auto (the default option in the picker) lets the platform route between Fast and Thinking per request; the routing behaviour is still maturing, so pick Fast or Thinking explicitly when you need predictable behaviour.
• Multi-agent Team — One leader agent delegating to member agents in-process. Modes: coordinate (delegate + synthesise), route (pick one member), collaborate (all in parallel), sequential (pipe member-to-member).
• Mesh — A durable, restart-surviving pipeline wiring runnables (agents, XFlows, other meshes, Services) together by queues/topics over a database-backed bus. For long, multi-step, fault-tolerant automations. A mesh member has a 240-second ceiling; longer work must be a Service.
• XFlow (code: Workflow) — A visual pipeline: a graph of operators (a Python step, an agent call, a SQL query, an API call, a vector-ingestion step…). The reusable “verb” that processes documents. Distinct from a Lifecycle/Stateflow, which is the document’s stage machine. See A10 · XFlows & pipelines.

Capabilities (what a runnable can use)

• Tool / Function — A callable an agent can invoke: either a built-in toolkit (SQL search, knowledge retriever) or a custom API tool you register with a URL + input schema.
• Skill — A reusable, parameterised capability (a named prompt/tool bundle) an agent can call. Catalogued per-Project.
• Skill Pack — A bundle of Skills that expands to its members when loaded.
• MCP Server — A Model-Context-Protocol server that exposes a set of external tools to an agent over a transport (HTTP/stdio), with its own auth. See A7 · MCP servers.
• Guard Rail — An input/output validation or safety filter attached to an agent. See A8 · Guard rails.
• LLM / Model — A concrete provider model instance (Azure OpenAI, Gemini, …) configured with an endpoint + credentials. Agents pick one (with failover).
• AI Model (trainable extractor) — Distinct from an LLM: the platform’s own trainable extraction model that a Learner trains against labelled examples and scores with accuracy reports.

Data & integration

• Connector — An identity binding to an external data source (SharePoint, Drive, a public feed). Connector = identity. See D4 · Ingestion & connectors.
• Source / Job — A scoped instance of a Connector (“the /Legal folder of Drive connector X”) that owns scheduling, drip, and dedup. Job = scope.
• Event / Webhook — A Collection-level subscription that fires on lifecycle/label changes, calling out to an external URL.
• View — A saved, filtered projection over a Collection’s documents — a named query that surfaces extracted labels as columns. End-users pick Views to slice the document list.
• Datasheet — A flat SQL table (the platform’s structured-data layer), sourced from databases/spreadsheets/APIs or materialised from a document View. Agents query it by SQL. See D5 · Drive & datasheet.
• Drive — Project file storage: a folder tree + file browser for raw files.
• Service (async) — A registered external long-running worker (GPU model, OCR, slow partner API) that exceeds the mesh’s 240-second limit. It pulls jobs from the platform over a small HTTP gateway. Flag-gated.
• Library / Derivation Library — Studio-authored sandboxed Python callables reused inside XFlow/mesh nodes. Not a public package — a private snippet store.
• Bot (RPA) — A robotic-process-automation worker that feeds structured data into the platform (e.g. an Excel-from-bot path into a datasheet).

Distribution

• Solution — A bundled, exportable Project recipe (collections + pipelines + skills + dashboards) shipped as a package that creates a new project elsewhere.
• Object Package — A newer, finer-grained package: publish a single agent / team / mesh into an existing project. Partly forward-looking — see V4 · Hubs & distribution.
• Hub — The registries that Solutions and Object Packages publish to and install from: the per-object tabs and Solutions catalog in Studio ▸ Hubs, plus the external, signed Solution Hub.
• EMBED / DECLARE / REBIND — How a package handles each dependency on install: EMBED = ship the config by value; DECLARE = require an environment capability, never ship it (e.g. a model class); REBIND = a project-local data dependency wired up at install (e.g. which Knowledge collection to attach). The rule: structure travels, data doesn’t.

Surfaces & roles

• Studio — The no-code builder: a left rail of sections (Agent Builder, Data Model, Connector, AI/Asset Builder, Search, Chat, Intelligence, Security, Hubs).
• Consumer App — What end-users see: document lists, the viewer, chat, search, dashboards, the inbox.
• Agent OS — A newer agent-first consumer landing (Home / Agents / Work / Live), partly flag-gated. See S2 · Core concepts.
• Inbox — The human-in-the-loop work queue: items needing a person land here; the actual review happens on the underlying document.
• Role — A named set of permissions in a Project (e.g. L1-Reviewer, L2-Approver, Admin). Lifecycle stages are gated to roles. See G1 · Access & roles.
• Lab flag / Feature flag — A toggle (mostly in an admin “lab” menu) that turns on in-progress surfaces. Pages name the flag whenever a feature is gated.

Three apps

• Backend (BE, .NET) — System of record + control plane: auth, CRUD, uploads, lifecycle, audit, RBAC. Postgres is canonical.
• Agent-Orchestrator (AO, Python) — Execution plane: runs XFlows (as Prefect flows), agents (Fast/Thinking), teams, meshes, vector ingestion, chat streaming.
• Frontend (FE, Angular) — Studio + consumer surfaces. Pure client.

---

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