Terminology
The review call spent time on the word "harness", and different people on our side explained it differently. This sheet fixes the vocabulary we will use with Allvue from now on. The word harness is retired: where it was used, one of the precise terms below is meant.
The chain, from intent to running software
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. | The platform. One database per project in the versioned configuration store (Dolt), 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 fork 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 app services, one container per application, built from the project's own Dockerfile and source tree; and the agent runtime, a headless coding-agent process (Claude Code) started per turn or task inside the assistant service, with one MCP server and no file, shell or network access of its own. | The platform while cortex hosts the project; the customer's infrastructure after delivery. |
| Deployment package | What leaves the platform: a git export or a customer archive holding every app service as ordinary source with its Dockerfile, 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 architecture. |
Other words that came up
| Term | Meaning |
|---|---|
| Fork | The project's own copy of the engine, prototyped from a shared core. It holds the project's endpoints, services, app services and vault. Every configuration branch of a project has its own fork. |
| App service | The default shape of every application cortex builds since September 2026: an arbitrary application, its own Dockerfile and source tree verbatim, built and run as its own container at its own hostname. A .NET web application, a Node server, a Java service, a static site. Cortex generates no server around it and injects nothing into it. |
| Companion | A cortex 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. |
| 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. |
What "harness" used to mean
In the call the word stood for three different things at different moments: the agent runtime (the process an agent runs in, with its tools pinned server-side), a fleet worker session (the coding-agent session that builds a card), and the whole platform around an agent (safeguards, tools, tests, deployment). Each has its own row above. We will not use the word again in Allvue material.