Terminology

The vocabulary the rest of these pages use, from intent to running software. Each term names one thing; where the product shows a plainer word, both are given.

The chain

Project→Requirement→Tool / Endpoint→Workflow→Agent→Manifest→Runtime→Deployment package

Term	Meaning	Where it lives
Project	One governed unit of work: a configuration database with commit history, a paired engine fork, and the applications, agents, workflows, requirements and tests built for it. A project is also the unit of tenancy and of delivery.	One database per project in the versioned configuration store; one fork in the engine catalogue.
Requirement	One row of what the project must do, with a kind (functional, quality, constraint, design, non-goal), a verbatim citation of the source document that asked for it, a status and the implementation that satisfies it. Requirements are derived from uploaded documents and change requests, and re-derived from the live code.	The project's knowledge vault; shown on the Docs page.
Tool / Endpoint	An endpoint is a named flow graph on the engine fork: the unit of executable behaviour. It is the application's data operation, the test's target and the agent's tool at once. A tool is an endpoint seen from an agent, with a typed input contract, exposed over the Model Context Protocol (MCP).	The engine fork; every save is a version.
Workflow	A business process drawn as steps, decisions and ends assigned to roles, people, agent actors or endpoint steps, with triggers and live runs. A workflow is data, executed by the workflow engine.	Definitions and runs in the project's own relational target database.
Agent	A manifest that names a persona, a model, a list of tools and a set of safeguards. An agent has no code of its own. It runs per chat turn, per delegated task or per workflow step.	The manifest is an endpoint on the fork; the registry row is in the platform database.
Manifest	The endpoint that defines an agent. Edited as data on the Agents page, versioned like every endpoint.	The engine fork.
Runtime	The processes that execute the above at run time. There are three, and they are distinct: the engine runtime that executes endpoints, pipelines and workflows; the application services, one container per application, built from the project's own container definition and source tree; and the agent runtime, a headless agent process started per turn or task inside the assistant service, with one MCP server and no file, shell or network access of its own. The model and the agent runtime are chosen per environment from the platform catalogue; nothing in a project names a vendor.	The platform while it hosts the project; the customer's infrastructure after delivery.
Deployment package	What leaves the platform: a git export or a customer archive holding every application service as ordinary source with its container definition, a compose file, optional Kubernetes and Azure Container Apps definitions, a generated CI pipeline, a runbook and the tests.	The project's private repository, or a downloadable archive. See Deployment and runtime.

Other terms

Term	Meaning
Fork	The project's own copy of the engine, prototyped from a shared core. It holds the project's endpoints, services, application services and vault. Every configuration branch of a project has its own fork.
Application service (app service)	The default shape of every application the platform builds: an arbitrary application, its own container definition and source tree verbatim, built and run as its own container at its own hostname. A .NET web application, a browser application behind a small server, a Java service, a static site. The platform generates no server around it and injects nothing into it.
Function service	The engine's other, older shape: a handler the platform wraps in a small server it generates. Used for platform-owned helpers, not for customer applications.
Companion	A platform feature an application may carry in its side menu: chat, workflows, guides, models, pipeline, governance, docs. Companions are switched on per application and shipped to a customer only when the delivery says so.
Fleet	The pool of coding-agent worker sessions that claim Board cards (a new application, a change, a fix, a build from requirement sources) and do the engineering. Fleet sessions have a repository checkout, file and shell access, and a bearer minted on behalf of the person who filed the card. The coding agent they drive is an environment setting.
Card	One request on the Board. The fleet works cards; a person files and reviews them.
Customer archive	The deployment package a customer deploys themselves: self-contained, with per-archive secrets and nothing the applications do not use.
Structure	The set of rows that declare everything a project consists of (sources, elements, rules, requirements, roles, workflows, agents, screens, services, delivery) with a status of planned, implemented, verified or missing, and a check that names the gaps between the declared design and the running implementation.