Glossary
archmax automation keeps one word per concept, shared with the archmax harness. Terms marked (SDK) mean exactly what the harness means; terms marked (platform) are concepts the harness does not define. The same words are used in the product, the API, the code and these pages, and the spellings in the last column are not used anywhere.
This table is rendered from the vocabulary in openspec/config.yaml when the site is built, so
it is the normative list itself, not a copy of it. Each row has an anchor: link to a term as
/reference/glossary/#session.
| Term | Meaning | Not called |
|---|---|---|
| archmax automation (platform) | The product this repository builds. "archmax" is its short form: always lowercase, and the one identifiers, prefixes and titles use (ARCHMAX_*, .archmax/, archmax.* events, X-Archmax-* headers); "archmax automation" names the product itself (the browser title of a deployment whose branding sets none, the README). | pangea in any spelling (pangea-sdk, pangea_*, .pangea/, PANGEA_*, Pangea), archmax pangea |
| Agent (platform) | Tenant-owned container: a git repository, its environments and settings. Distinct from the SDK's assembled runtime agent and from the design agent. | project, tenant, repo (as the noun for the container) |
| Agent icon (platform) | The agent's picture: a square PNG at icon.png in an environment's workspace root, beside AGENTS.md, chosen on the Agent page and always drawn as a circle. Authored like the system prompt, so it is published and promoted with it. | avatar, logo (for this) |
| Agent description (platform) | The sentences an agent is introduced with: the description key of the frontmatter AGENTS.md can open with, at most 500 characters, written in the Agent page's Description card and shown under the agent's name on the Chat page's start view. Authored like the system prompt, so it is published and promoted with it, and the model reads it with the rest of the file. | tagline, bio, blurb, subtitle (for this) |
| Start view (platform) | What the Chat page shows for a new chat before its first message: the agent icon, the agent's name and its agent description, the workflow's title when the published version offers more than one chat workflow, and the workflow's example prompts, over the start view's backdrop — archmax's brand gradient, or tints of the deployment's brand colour when its branding sets one, that drifts behind the selected chat and fades once the chat holds a message. Part of the Chat page, not a page of its own. | start page, welcome screen, splash screen, greeting |
| Boot screen (platform) | What the browser shows from its first paint until the first page is usable: the ax monogram stepping through the CI colours over a plain backdrop, then easing to ink and fading, archmax's whatever the deployment's branding. Painted from static files in apps/frontend/public/ ahead of the application bundle (the design asset that draws it keeps its own file names, archmax-splash-cycle.*); not a page, and distinct from the Chat page's start view. | start screen, loading screen, launch screen |
| Branding (platform) | How a deployment presents itself: the title it names itself by, the logo that leads the icon rail and the sign-in notices, and its brand colours, set in the config's branding section and read by the SPA from GET /api/branding before its first page. A deployment whose branding sets a title or a logo says powered by archmax where it names itself; the boot screen and the favicon stay archmax's. | white-label, skin, theme (for this) |
| Brand colour (platform) | One of the six colours the application draws every meaning in, each named by what it says, never by its hue: brand (the deployment's own colour — what a person has in hand, a notice addressed to them, and decoration), success, error, executing, attention and waiting. archmax's CI pigments are their defaults and a deployment's branding replaces them; a glyph or a line of text takes the colour's mark, a shade derived from it. | CI colour (for these), status colour, accent, primary (for these), a hue as a name (purple, sage, … for these) |
| Appearance palette (platform) | The seven hues an author gives a state or a transition (metadata.color): sage, rose, blue, purple, rust, amber and teal. The one place a colour is named by its hue: the names are fixed because every published version stores them, and a deployment's branding may retune each one's tone (branding.appearancePalette); in the application's own chrome it only tells arbitrary labels apart (a session's tags, a decision's approvers). | CI palette (for this), brand colours (for this) |
| Example prompt (platform) | A prompt a workflow's chat trigger offers a member before a chat's first message: listed under the declaration's examples (at most six), shown on the start view, and placed in the composer — not sent — when chosen. Inert to the session: the agent never reads them. | starter, conversation starter, suggestion, quick prompt, sample prompt |
| Environment (platform) | A named branch of an agent's authored tree with a draft plane, a published plane and its sessions. | worktree, branch (outside git internals), stage |
| Draft plane / Published plane / Data plane (platform, internal) | An environment's storage tiers: the two authored ones, and the data plane holding the folders a workflow mounts, outside versioning. Never a user-facing word; the owner sees Storage on the Files page. | draft store, authoring plane, governance plane |
| Version (platform) | A published snapshot of an environment (publish, promote, restore). The content revision is a freshness counter, not a version. | release, revision (for a version) |
| Publish / Promote (platform) | Publish: draft to published within one environment. Promote: a child's published tree into its parent. | deploy, release |
| Release (platform, operator-facing) | A tagged build of archmax automation itself: the vX.Y.Z tag on main, its GitHub release with generated notes, and the image ghcr.io/archmax-ai/automation tagged X.Y.Z, X.Y and latest, cut when a pull request labelled release, release:minor or release:major merges or by a dispatch. Its number is the image's APP_VERSION, which GET /api/health reports; a pull request's image (pr-<number>) and the unstable image of a commit on main that passed CI (unstable-<sha>, and unstable for the newest) are not releases. Never an agent's version or a publish, which keep their own words. | deploy, ship (for a release), build (for a release) |
| Schema version (platform, internal) | The version of one MongoDB collection's stored shape: declared by the collection's model, stamped on every document as schemaVersion, indexed, and raised by one with each data update. Per collection, never global. A collection's baseline is the oldest version a data update starts from; a document below it is reset or converted by hand. Never an agent's version or a release, which keep their own words. | data version, model version |
| Data update (platform, internal) | The code that brings one collection's stored documents from one schema version to the next (data-updates/updates/<collection>.v<n>.ts). Every API and dispatcher process applies pending data updates at boot, before it serves, and the data update sweep brings forward documents the previous release wrote while both were running. Forward only; a process refuses to start against documents newer than its models unless ARCHMAX_ALLOW_NEWER_DATA is set. | migration, migration script, backfill, conversion script, upgrade script |
| Workspace (SDK) | The authored file set an agent runs over (AGENTS.md, workflows/, skills/). The word in routes, types and identifiers (/workspace/files). Browsed and managed on the Files page's Agent view, beside the editor, the Skills page and the Agent page that author its documents. | tree, files |
| Mount (SDK) | A folder of the environment's storage or a remote mount routed into a session's agent workspace, granted per state by mounts.allow_always / mounts.allow and taken away by forbid. | — |
| Files page (platform) | The owner-facing explorer over an environment's files, in two views switched at its top: the Mounts view, the default, and the Agent view. Reached from the left rail as Files. | Mounts page, files view, data explorer |
| Mounts view / Agent view (platform) | The Files page's two views. Mounts is what a session can mount: the environment's storage and its remote mounts, one tree whose breadcrumb root is /, where a write reaches the next turn at once. Agent is the environment's workspace as its draft holds it, platform entries included, where every write is staged until Publish. The URL names the Agent view (?view=agent). | Draft view, Workspace page, Repository view, Agent page (for this; the Agent page is the system prompt's) |
| Platform entry (platform) | An entry of the workspace whose name begins with a dot: .archmax/ with the environment's connections, settings and remote mount definitions, and .gitignore. The Agent view lists, previews, downloads and copies it, and never writes it: the surface that owns it does. | hidden file, system file, dotfile (for this) |
| Storage (platform, owner-facing) | The data plane as the Files page names it (Local Storage in the Add mount picker, beside Remote Storage for the connections): the folders the owner uploads, written by the page and by a read_write grant. | S3 folder, bucket folder, local mount |
| Remote mount (platform) | A per-environment definition at .archmax/mounts/<slug>.yml naming a connection of a mountable collection and a folder of it, served live to every turn and to the Files page and never mirrored. | synced folder, mirrored folder, connector folder, drive mount |
| Mount source (platform) | Where a mount's files live: the environment's storage, or a mountable collection reached through a connection (SharePoint first). | mount provider, mount backend (owner-facing), storage provider |
| Zone / session zone (SDK, internal) | The kernel's classification of a path; the session zone is sessions/<id>/. | run zone, run store, run folder, area |
| SDK (SDK) | @archmax-ai/harness, the runtime that executes workflows: its machine spec, its runtime tools (archmax_advance, archmax_wait, archmax_run, archmax_workflow_<slug>, …) and its authoring skill archmax-harness. | — |
| Workflow / State / Transition (SDK) | One authored unit under workflows/<slug>/; a key under states:; a declared edge. | process, flow; node, step, phase; edge, route |
| Trigger / Firing / Delivery (SDK) | How a session starts or resumes; one occurrence of a trigger arriving; a firing handed into a parked session. | event (for a firing), listener |
| Deployment / Listen window / Tick (platform) | The host's active listener for one (workflow, trigger); the editor's test window for a trigger; one poll or schedule job. | listener (noun), subscription, binding |
| Retry / Retries exhausted (platform) | A deployment in error is retried automatically after a delay that doubles with each failure in a row; after five retries its retries are exhausted and only a publish, a credential change or a member's Retry now tries it again. | parked (for a deployment: parked is a session's), dead, abandoned |
| Webhook (platform) | HTTP ingress for a webhook trigger, reached at the endpoint of the webhook incoming connection it names (/api/webhooks/<token>). | hook (reserved for lifecycle hooks) |
| Callback trigger / Callback address (platform) | A collection's trigger its service calls back (strategy kind callback, the Activepieces WEBHOOK strategy): enabling its deployment registers the deployment's own callback address, /api/callbacks/<token>, with the service, each request arriving there is handed to the collection to turn into firings, and disabling it unregisters the address. The address is minted once per deployment and kept across re-activations; the platform registers it, so no owner configures it. Never a webhook trigger, which is the platform's own and reached through an incoming connection. | push trigger, piece webhook |
| Completion trigger (platform) | An event trigger, type: completion, naming another workflow of the environment under workflow: each turn of a production session of that workflow that ends succeeded, or failed once it had started, fires it once — never one a member stopped — with the finished session as its payload and how the turn ended as its status, so a workflow looks back at another's sessions — rating, classifying or following up on them. Deployed from the published version like every event trigger, with no scheduler or address; every firing opens a session of its own about its subject session. | workflow trigger, chained workflow, follow-up trigger, on-complete hook, post-run hook, introspection trigger |
| Endpoint (platform) | The address an incoming connection has in one environment — the AG-UI endpoint /api/agui/<token>, the MCP endpoint /api/mcp/<token>, the webhook ingress /api/webhooks/<token> — minted by the platform, shown with the connection, and serving the published triggers that name it. | ingress (for these; ingress is the token's), API endpoint (for these), MCP server (for the platform's side) |
| Session (SDK) | The durable conversation of one workflow: one checkpoint thread, one sessions/<id>/ folder, one machine position. | run (as the folder), thread, conversation, task |
| Session attribute (platform) | A key-value pair on a session, written by its agent or by the agent of a session it is the subject session of, with sessions__set_attributes: a key of a lowercase letter then lowercase letters, digits, _ or -, and a value that is text, an integer, a decimal or a boolean — its kind is the value's own, never declared. Never read by the harness and never a variable; the Sessions table shows a key as a column a member switches on. Tags stay the member's own labels. | metadata (for this), annotation, custom field, property (for this), label (for this) |
| Turn (SDK) | One invocation on a session: a prompt, a decision, a reply or a delivery. The unit a worker executes. | run, execution, job |
| Decide / Reply / Deliver (SDK) | The three resumes of a parked session. | resume (generic), respond |
| Parked / Pending decision / Pending input (SDK) | A session suspended at a human state or at archmax_wait, and the records it presents. | interrupt, wait state |
| Human state / Decision (SDK) | type: human; it parks the session for a person's decision. | HITL node, approval step |
| Hold (platform) | How a transition is taken in the decision dialog: the pointer, or Enter or Space, kept down on the transition's button for three seconds while a bar fills it from left to right. A shorter press, or a click, decides nothing, and the button's tooltip says how to take it. The UI kit's HoldButton draws it. | long press, long-press, hold-to-confirm |
| Child session (SDK: sub-workflow) | The session an archmax_workflow_<slug> call runs in, with a folder of its own; a dispatch is one such call. Its id is its caller's id, ~ and the dispatch's number among its caller's, counted from 1 (<session>~2, and <session>~1~1 inside ~1); a dispatch id is the child session's id after the root session's (2, 1~1). | sub-run, subrun, subagent, delegation node |
| Subject session (platform) | The finished session a completion trigger's firing is about, named by its payload's session. The session that firing opens records it as its subject, belongs to the member the subject belongs to, may read it (sessions__read_subject) and write its session attributes, and fires no completion trigger itself. | source session, target session, rated session, parent session (for this) |
| Hook / Rubric / Verdict (SDK) | before/after slot on a state (kinds script, rubric); the standard a rubric grades against; what a hook returns (ok, correct, veto). | gate, guard, judge |
| Variables (SDK) | The flat key-value store (${{name}}); a trigger's requires declares the ones a start needs. | context, inputs |
| Case / Suite / Verdict (SDK) | One workflows/<slug>/tests/*.test.yaml; all cases of a workflow; passed, failed, skipped. tests/ and .test.yaml stay only as the on-disk contract. | test, test case, scenario, eval, judge (use grade) |
| Evaluation (platform) | The record of running one or more cases in an environment. | test run |
| Tool (SDK) | A callable the agent may use; governed per state by tools.allow / tools.forbid. | capability, sub-tool, action (for a tool) |
| Connection / Credential / Collection (platform) | A configured tool-source instance referenced by slug from allow entries; the secret a connection uses; the catalog entry a connection is made from. | capability, piece (outside the Activepieces adapter), connector, provider (for a collection), integration |
| Packaged collection / Offered collection (platform) | An Activepieces collection is packaged when its piece ships with the release, as an @activepieces/piece-<id> or an @archmaxpieces/piece-<id> dependency of @archmax/core (never both); a packaged collection is offered when, and only when, the config's activepieces.collections names it, so a config without an activepieces section offers none. Only an offered collection is in the catalog, resolves into tools, takes a credential or deploys a trigger. | installed piece, enabled piece, available connector |
| archmaxpieces (platform, internal) | The Activepieces pieces archmax authors itself on the Activepieces framework: one workspace package per collection under packages/archmaxpieces/<id>/, named @archmaxpieces/piece-<id>, packaged and served like any Activepieces piece. A piece forked from an Activepieces piece keeps that piece's collection id, actions and triggers, and replaces its dependency; a lite piece serves part of one under an id of its own (a lite collection). Lowercase and one word, like "activepieces". | custom pieces, own pieces, archmax pieces, ArchmaxPieces |
| Lite collection (platform) | A collection archmax authors that serves part of a packaged Activepieces collection <id> under its own id, <id>-lite: upstream's own actions and triggers, unchanged, behind an OAuth2 declaration that asks for a narrower scope. It pins the upstream version the release packages, and is packaged beside the full collection, never instead of it, so the config offers either or both. gmail-lite, google-drive-lite, google-sheets-lite and google-docs-lite ask Google for no restricted scope, so a Google OAuth app serving only them and google-calendar needs no CASA assessment. | light collection, slim piece, reduced piece, sensitive-only piece, CASA-free piece |
| Incoming connection (platform) | A connection of type incoming: one endpoint of one protocol (agui, mcp, webhook) and who may call it — its authentication mode (public, bearer, oidc), browser origins and rate limits. Its credential is compared against rather than presented; the chat, mcp or webhook triggers that name it are what its endpoint serves. | access connection, agui connection, AG-UI access connection, auth connection, inbound connection, API key (for the connection) |
| Direction (platform) | Whether a connection is Incoming (callers reach the platform through it: an incoming connection) or Outgoing (the platform reaches a service through it: every other type). Derived from the type, never stored. | inbound, outbound |
| Model provider (platform) | An llm connection: where an agent's models are called, named with a model ID by the model selection in .archmax/settings.yml and priced by the rates it declares. Its provider says which kind: Generic Model Provider (generic, stored as no field — any OpenAI-compatible API at a base URL, called through the api it names), AWS Bedrock (bedrock — the Bedrock Converse API in one AWS region, signed with an AWS access key) or Azure OpenAI (azure — the Responses API of one Azure OpenAI resource, with its API key; its model ID is the name of a model deployment in that resource, always so qualified, never the platform's Deployment). The catalog offers one option per provider, llm-<provider>. | LLM Provider (as an option's title), model connection, inference provider |
| Endpoint token (platform) | The secret a bearer incoming connection admits callers by: issued by the platform, shown to the owner once, and stored only as its sealed SHA-256 digest in an ENDPOINT_TOKEN credential. Regenerating it replaces the digest. Not the <token> in an endpoint's address, which is the endpoint's address token. | API key (for this), access key, shared secret |
| Secret store (platform) | Where a deployment keeps its credentials' secret fields, which ARCHMAX_SECRET_STORE names: the database store (db, the default: sealed with AES-256-GCM under MASTER_KEY on the credential's record in MongoDB) or the AWS Secrets Manager store (aws-secrets-manager: one secret per credential, named <prefix><credential id> under ARCHMAX_AWS_SECRETS_MANAGER_PREFIX, archmax/credentials/ by default, the record keeping only its name and the version it wrote). One store per deployment, each a folder under credentials/secret-store/; tools/move-secrets.ts moves secrets from one to the other. | vault, secrets backend, secret provider, key store, KMS (for this) |
| OAuth app (platform) | A client the platform operator registered with an identity provider — an Entra app registration, a Google Cloud OAuth client — named in the config's oauthApps list with the collections it signs owners in for, so an owner connects one by signing in and supplies no client id or secret of their own. Delegated only: an OAuth app signs a person in and is never used for the client_credentials grant. It is also the only way to a delegated sign-in: the owner's own OAuth app carries app-only access and nothing else. | platform app, shared app, default app |
| Client registration (platform) | The client the platform signs an owner in to a Remote MCP Server as, which it registers itself with the server's authorization server for each sign-in rather than taking from the owner or the config: a client issued to it by dynamic client registration and kept, sealed, with the credential it signed in, or — where the authorization server offers no registration — its client ID metadata document (/api/oauth2/client-metadata). Never an OAuth app, and never the owner's own client, which carries app-only access only. | MCP app, dynamic app, auto app, owner app (for this) |
| Reach (platform) | What a connection signed in through an OAuth app can get at beyond the signed-in person's own access, decided by the identity provider rather than the platform: the accounts and repositories a GitHub App is installed on. An OAuth app's reach in the config describes it to owners (its note), names the provider's page that changes it (its url), and says whether that page also signs the person in (signsIn). | coverage, app access, installation scope |
| Config (platform) | The deployment's document of what the platform offers — the design agent, the services and the token each one checks, the skill registries, the OAuth apps — read at boot from config.yaml in the app directory or from the same document as one line of JSON, plain or base64-encoded, in ARCHMAX_CONFIG. Its string values may carry ${{VAR}} placeholders resolved from the process environment, so it holds no secret. Where the platform runs stays in environment variables. | configuration file, app config, env document, settings document |
| Sign-in settings (platform) | What the SPA signs in with, read from GET /api/sign-in-settings before it renders: the deployment's sign-in mode and that mode's public settings, which the API answers from its own environment — in OIDC sign-in the issuer, the SPA application's client id, the API audience and any sign-out address; in proxy sign-in only where signing out ends; nothing for the dev user. The image carries none of it. | client config, runtime config, auth config |
| Identity provider (platform) | The service people sign in at (Auth0, Amazon Cognito, Okta, Keycloak): the OIDC issuer the platform trusts, directly in OIDC sign-in or through the proxy in proxy sign-in. It decides who may sign in, verifies addresses and asserts the managed-domain claim; the platform never sees a password. | IdP (in prose), auth provider, Auth0 (for the role) |
| Sign-in mode (platform) | How a deployment signs people in, which ARCHMAX_SIGN_IN names: OIDC sign-in (oidc: the SPA signs in at the identity provider and sends its access token), proxy sign-in (a proxy in front of the platform signs people in and forwards an identity it signs; AWS ALB sign-in, aws-alb, is the one proxy today), or the dev user (dev-user, or unset; outside production only). Each mode reads only its own variables, and another mode's refuses the start. One folder per mode in the code (access/sign-in/, providers/sign-in/). | auth mode, auth strategy, login type, edge auth, header auth |
| Subject (platform) | The identity provider's stable id for a person (the sub of what it signs), stored on the user record as subject; how a returning person is recognised, whichever mode signed them in. | auth0Id, external id, provider id |
| Waitlist / Refused sign-in (platform) | The waitlist holds every account an operator has not activated yet, recorded at the identity provider (in Auth0, as the user's app_metadata.approved, which the tenant's post-login Action reads); the provider refuses each of its sign-ins with the reason on_waitlist, and the SPA tells the person they are on the waitlist. A refused sign-in is the identity provider returning to the SPA with an error instead of a code: the SPA names the reasons it knows (on_waitlist) and shows every other one with a single generic message, never with the provider's text. | approval (for this), allowlist, pending account, blocked (Auth0's own block is a different switch) |
| Invitation (platform) | An offer of membership in an organization to one email address, carried by an invite link: issued by an Organization Owner adding a member by email, which always issues one and never says whether the address has an account, or by a domain's auto-onboarding. It names the groups the invitee joins, built-in and custom, any number of each: User unless the inviter names others, and an Organization Owner changes them with Edit on its row. Nobody joins by it until the holder of that address, verified by the identity provider, accepts it with Join on its consent page, which the invite link opens and which each invited organization in the organization control's menu opens; Dismiss declines it, and signing in accepts nothing. | join request, pending member |
| Verified domain (platform) | A domain an organization proved it controls by publishing the TXT record _archmax-verification.<domain> the platform reads over DNS, managed in the Auto-onboarding section of Organization & Account settings. At most one organization holds a domain verified; a domain whose record is gone when it is read again lapses to pending. A deployment that turns the DNS check off (ARCHMAX_DNS_VERIFICATION=off, for single-tenant deployments whose Organization Owners are all trusted) verifies a domain as soon as an Organization Owner adds it. | claimed domain, domain claim |
| Auto-onboarding (platform) | A verified domain's switch: a person who signs in for the first time with a verified email at exactly that domain, through an account the domain's owner manages, as the identity provider asserts in the managed-domain claim (ARCHMAX_MANAGED_DOMAIN_CLAIM; with Auth0, its post-login Action asserts it for a Microsoft Entra account, or a Google Workspace account of that domain), is offered membership of the organization holding it — an invitation from the domain, into the domain's default group — which they join or dismiss on its consent page, and gets no personal organization unless they dismiss it. An offer, never a membership by itself, and never for a later sign-in. Off on each domain until an Organization Owner turns it on. | auto-join, domain capture |
| Service (platform) | A first-party deployable that serves a platform collection's actions over MCP from its own image, named in the config's services list — with the endpoint and the token that one service checks — and never in platform code. It answers the platform's two reserved tools, archmax_describe (its credential form) and archmax_verify (a credential test), which the platform calls itself and never offers to an agent. "Remote MCP Server" stays the owner-facing name of an mcp connection. | sidecar, microservice, plugin |
| Dispatcher (platform) | The long-running process that consumes the platform's queues (apps/dispatcher): it runs the platform's own jobs — provisioning, environment operations, schedules, sweeps and trigger work — and starts a worker for every turn and every call a job makes, serving it through its broker and settling its outcome. Every dispatcher process serves every queue, so adding one adds capacity. The API starts the workers its own requests need (a connection test, a property's options) the same way, and is then that worker's dispatching process. BullMQ's per-queue objects inside it are its consumers. | worker (for this), queue worker, orchestrator |
| Worker (platform) | The process the platform runs code it does not control in: one per turn (a workflow, design-agent or evaluation turn, its tools, scripts and child sessions) or one per call made through a connection outside a turn (a connection test, a property's options, a trigger lifecycle, a remote mount listing, the catalog). It holds none of the platform's own secrets and opens no connection to the data stores, reaching them only through its broker. Distinct from the Daytona sandbox (the machine a session's commands run in) and the SDK's QuickJS sandbox (where a script evaluates inside a worker). | compartment, sandbox (for this), isolate, jail, cell |
| Broker (platform) | The interface the process dispatching a worker serves it through: a fixed set of operations, each checked against the worker's token and bound to its turn or call, over the platform's own scoped services. Inside the worker the SDK's injected stores are broker clients. Credentials are shaped and refreshed here, and the design agent's model calls and service calls are made here, so no platform-owned secret crosses into a worker. | data gateway, data proxy, sidecar (for this) |
| Worker token (platform) | The unguessable value a dispatching process mints per worker, naming what it may reach — its organization, agent, environment, tree, session or deployment, the connections and mounts it may use, and an expiry — checked by the broker on every operation and revoked when the worker ends. Minted from the turn's own records, never the job payload. | compartment token, capability token, grant (for this; grant is the mounts' word) |
| Worker host (platform) | A deployable that runs only workers, for the API and dispatcher processes that dispatch to it, authenticating them and refusing to start with any data-store address, key, config or cloud credential in its environment — so a deployment can place workers where the stores are unreachable. In the all-in-one container, workers are processes of their own instead. | compartment host, sandbox host, runner pool |
| Skill (SDK) | A skill bundle skills/<slug>/ with SKILL.md. Qualify the others: the authoring skill is the SDK's bundled skills/archmax-harness; skill governance is skills.allow / skills.forbid. | capability |
| Registry (platform) | A configured source of skill bundles named in the config's skillRegistries list, cloned at startup into .archmax-skills/<id>/ and browsed from the Skills page. A registry holds skills/<slug>/SKILL.md and is never read at turn time. | marketplace, store, hub, source (for a registry), catalog (for a registry) |
| Install (platform) | Copying a registry skill into an environment's skills/<slug>/ as a draft change, with its origin in the bundle's own frontmatter (metadata.registry, metadata.skill, metadata.commit). | download, import, pull, add (in code identifiers) |
| Argument guard / Trigger guard (SDK / platform) | Glob patterns keyed by a dotted field name, matched one way: on a tool allow entry's args (the SDK's) they restrict what the agent may pass a tool; on an event trigger's guards (the platform's) they decide which firings reach a session. Every guarded field must match one of its patterns. | filter (for a trigger guard), condition, match rule, gate |
| Allow / Forbid (SDK) | The governance keys (allow, forbid, allow_always, forbid_always) and their verbs. | allowlist, denylist, blocklist, deny, permit |
| Design agent / Thread (platform) | The authoring assistant in the editor and its conversations. | chat, conversation (for its threads), assistant, copilot |
| Chat / Chat conversation (platform) | The end-user channel; a chat conversation is a session keyed chat:<id>. Members hold production chats with the published workflows on the Chat page, the rail entry after Sessions; an author tests a draft through testing chats in the editor's chat surface. | thread (for chat) |
| Belongs to a member / Personal (platform) | A session a member started from inside the product — a chat on the Chat page or in the editor's chat surface — belongs to that member, recorded as the session's startedBy (never owner, which is the agent's creator), and is personal: the Sessions page marks it with a lock. Listings show a member the sessions that belong to them and those that belong to no member — trigger firings, endpoint callers, manual starts, evaluation cases — and a member holding sessions:personal every member's. | private session, owned session |
| Allowance (platform) | The design agent's per-tool consent (deny, allow, always), asked of the member whose message started the turn. | decision (for this), approval, permission (for this) |
| Usage (platform) | What one call consumed: the token counts of a design-agent turn — input, output, cache-read, cache-write — and the daily ledger they accumulate in (design_agent_usage), or the count a service reports for one tool call (_meta["archmax/usage"], X-Archmax-Usage). Owners see a turn's counts; what the design agent's counts cost stays inside the platform, which pays for it. What an owner's own agent costs is Spend. | credits, consumption, tokens spent |
| Spend (platform) | What an agent's model calls cost, in USD, priced from the rates its llm connection declares and recorded per turn and per Period. Usage is the counts; Spend is the money they come to. An agent's calls are billed to the owner's own provider, so owners see the amount — unlike the design agent, which the platform pays for. | cost (as the noun for this), burn, billing |
| Spend cap (platform) | The ceiling an owner sets on a workflow's Spend within one environment over one Period, and the refusal raised once it is reached. A workflow holds at most one per Period in each environment, and whichever it reaches first refuses. Spend is also totalled for the agent and the environment, which hold no cap. | budget (for this; it names a state's authored execution bound and the design agent's daily ceiling), spending limit, cap (unqualified) |
| Period (platform) | The UTC calendar bucket a Spend cap accumulates in and resets on: a day, a week from Monday, or a month. | window, timeframe, cycle, billing period |
| Editor (platform) | The workflow authoring surface (graph canvas, inspector, settings). | builder, designer, canvas (as the surface name) |
| Sessions page (platform) | The board or table of an environment's sessions. | Tasks, activity board |
| Permission (platform) | One entry of the fixed catalog of what a member may do, named <area>:<action> — workflows:write, sessions:use, members:write — and checked by that string on the server and in the UI. Within one area write includes use and read, and use includes read. | privilege, right, capability, scope, access level |
| Built-in group: Organization Owner / Administrator / Maintainer / User (platform) | The four groups every organization has, created with it and fixed. Each gives its members that role on every agent of the organization, agents created later included — Organization Owner gives Administrator — and Organization Owner also every organization permission (organization:manage): the organization's name, domains, members and groups; Organization Owner, Administrator and Maintainer also let their members create agents. A member is in any number of them, the highest counting, and their members are changed like a custom group's — in the Groups section, or with Edit on a member's row of the Members list; the membership itself holds no role, only what every member holds (reading the members and groups). A built-in group cannot be renamed, deleted or given agents or permissions, its name is taken, and an organization keeps at least one Organization Owner. | organization role, system group, default group (a domain's word) |
| Agent role: Reader / User / Maintainer / Administrator (platform) | The role a member holds on one agent: the highest of the role their built-in group gives on every agent and the roles their custom groups give on it: Reader reads it; User also starts sessions, chats, decides and replies; Maintainer also builds and publishes, without connections, spend caps, session deletion or access; Administrator holds every agent permission. A member with no role on an agent holds None there, which is never stored or given. Reader is given only by a custom group. "User" the role and the built-in group is capitalized; a user is an account. | viewer (for Reader), operator (for User), editor, author, builder (for Maintainer) |
| Group (platform) | A named set of an organization's members: one of the four built-in groups, or a custom group, which names agents, each with one agent role that every member of the group holds, and can give two organization permissions: Manage organization (organization:manage, everything Organization Owner gives) and Create agents (agents:create). Creating an agent creates its own custom group, named after it, holding its creator as Administrator. Groups only add: a member's role on an agent is the highest their groups give, and a person is kept to some agents by keeping them out of the built-in groups. | team, role assignment, grant (the mounts' word) |
| Landing page (platform) | The agent sub-page — one of the icon rail's entries, Agent settings included — an agent or environment opens on when its URL names none: the one the person last had open, remembered per browser across agents and environments, and the Sessions page until they have had another open. Only the rail entry: what was open in it — a workflow, a conversation, a section — stays with the agent it was open on. | last view, remembered view |
| Documentation site (platform) | The Starlight site in apps/docs that documents archmax automation for operators and authors, published at docs.archmax.ai. Its glossary is this table, rendered when the site is built. | docs portal, wiki, handbook |