Glossary

Quick definitions for the terminology used throughout these docs.

Term	Definition
Adaptkit	The official CLI tool (@mochabug/adaptkit) for developing, testing, and publishing mochabug Adapt applications. Provides commands to scaffold new applications, add vertices, emulate locally against the mochabug Adapt sandbox, and publish to the platform.
Application	A complete piece of software hosted on mochabug Adapt clusters. Applications can have a frontend, backend, handle input/output, and manage streams. You connect applications rather than individual endpoints. Applications can be organizational (private) or installed from the public marketplace.
Barrier	A native node that collects one or more parallel forks and controls graph behaviour before execution continues. Required any time forked branches need to be merged.
Configurator	An optional UI component within an application vertex that lets users customise executor behaviour directly on the mochabug Adapt platform canvas.
Constant	A named, project-wide value that can be bound to receivers just like a signal. Constants are useful for reusable data such as IDs and folder paths. They can be created inline when binding signals or managed from project settings.
Delegate	A native node that transfers a session to a different client mid-execution. All nodes downstream of a delegate run on the new client. Inside a fork, delegation is scoped to the lifetime of that fork.
Deployment	A published, versioned snapshot of a project that is ready to go live. Publishing a project creates a deployment with a new version number. Existing live sessions continue on the previous version while new sessions start on the latest one.
Deployment group	A folder-like container that every deployment is stored within. Currently it only serves to organize deployments in a way that makes sense to you and has no functional effect on the deployments themselves.
Edge	A connection between two vertices, drawn from a transmitter on one vertex to a receiver on another. An edge without a fork icon belongs to the main fork; an edge marked with the fork icon starts a parallel fork.
Exchange	A mechanism that lets an active application trigger a sub-graph (a fork of the main graph) and receive a response back. The calling application can only see the defined input (start node) and output (exchange node) of the exchange, not its internal graph.
Executor	The core logic component of a vertex inside an application. Available executor types are Action, Cron Trigger, External Trigger, and Browser, each suited to different integration patterns.
Fork	A parallel branch in a project graph. Forks are created by connecting multiple vertices from the same source vertex. Forks run concurrently and must be merged with a Barrier node if subsequent steps depend on all branches completing.
JTD	JSON Type Definition — the schema format used for all signals on the mochabug Adapt platform. JTD schemas enable static validation and automatic filtering so only compatible signals can be connected.
Marketplace	The public catalogue where applications built by mochabug, partners, customers, or the community can be discovered and installed into your organization. The search matches against both application titles and descriptions.
Native node	A platform-provided node that cannot be implemented as an application. Native nodes — Start, Output, Delegate, Barrier, and Exchange — handle flow control and the boundaries of a graph. Application developers can still build their own non-native flow controls.
Organization	The top-level account (also called a tenant) that owns workspaces, projects, deployments, and installed applications. Every user starts in a personal organization that can't be deleted or invited into; other organizations can have multiple members. Self-developed applications are private to the organization that uploads them.
Output node	A native node that explicitly defines which signals to return to the client when the deployment completes. Only signals bound to an output node are sent back.
Project	The canvas on which you build and configure an integration. A project is a directed graph of connected vertices (applications). Projects can be test-run locally and published as deployments when ready for production.
Proof of work	An optional, privacy-focused access-control check for deployments embedded on public websites. When enabled it gatekeeps resources against bots without tracking users; typically left off for internal tools.
Public ID	A unique, persistent identifier assigned to every deployment, used to call or embed it. The public ID does not change over time, even when you publish a new project that overwrites the current deployment.
Receiver	An input port on a vertex that accepts signals whose JTD schema matches the receiver's required schema. Only signals transmitted by upstream vertices are available for binding. Optional signals cannot be bound to required receivers.
Sandbox	A local Docker image (mochabug/adaptsandbox) that emulates the mochabug Adapt platform so applications can be tested locally via `adaptkit emulate`. It exposes ports simulating the different vertex types, the graphical interface, and the adaptkit publish endpoint.
Services	Credential and configuration settings for applications (such as API keys or environment variables). Services can be defined at workspace, project, or vertex level and are inherited downward, with lower-level settings overriding higher-level ones.
Session	A single runtime instance of a deployment. Sessions can be started and stopped from the deployment settings and can be subject to limits defined by the stop policy and session limits.
Signal	The unit of data flowing between vertices. Every signal conforms to a JTD (JSON Type Definition) schema, which lets the platform statically validate compatibility between transmitters and receivers before runtime.
Start node	The mandatory native node present in every project. It defines any required or optional input data the deployment expects when a session is started and controls how many initial transmitter edges the graph has.
Stop policy	A deployment setting controlling whether and how a live session may be stopped through the API: Not allowed, Allowed, or UI Node Only. A live session can always be stopped from the mochabug Adapt UI regardless of this policy.
Transmitter	An output port on a vertex that emits data as a signal with a defined JTD schema. Downstream vertices can bind to a transmitter's signal if their receiver schema is compatible.
Vertex	A single node on the project canvas, representing one instance of an application. Each vertex has optional config, service settings, receivers, and transmitters. Vertices are connected by edges to form the project graph.
Workspace	A container for grouping related projects and sharing application configurations across them. Workspace-level service settings are inherited by all projects and vertices inside it, but can be overridden at lower levels.