Glossary¶

Plain-language definitions of GaugeWright's vocabulary. These are the user-facing summaries; the formal definitions live in the product specification.

Each term carries a status badge so you can tell at a glance what is usable today versus what is built-but-not-live or still planned. Status uses one vocabulary, and the single source of truth for it is the Roadmap & status table — if a badge here ever disagrees with that table, the table wins.

What the badges mean

Available — shipped in the product you can download today (the local desktop workbench). Built — implemented and tested in the code, but not yet operationally deployed. Planned — committed and designed, not yet built. Not implemented — absent today.

The one counterintuitive truth

Local orchestration is not local inference. The workbench runs on your machine, but the agent's reasoning is performed by the third-party LLM provider you configure — so your prompts and the in-scope context are sent to that provider over the network. There is no local model. Who can and cannot see plaintext is spelled out in How GaugeWright protects your work → Where your data goes.

Core vocabulary¶

Project¶

A trust and data boundary — a body of work plus the parties who may see it. It's the root unit: the home for everything one piece of work needs (its context, its placements, its people). Not a folder — a boundary. Available

Archetype¶

A named bundle of method resources + configuration — the reusable agent definition you build in the workbench (its instructions, skills, tools). On disk this is the agent's .pi/SYSTEM.md, AGENTS.md, and .agent-config.json that the edit chat authors. You can package an archetype into a shareable object. Available

Placement¶

An archetype installed onto a project — the durable deployment, and the thing you chat with to do work. Its identity always shows its lineage as archetype · project (e.g. price-leveling · Peach), so where a deployed agent came from is never hidden. Available

Chat¶

A durable line of conversation. Rooting — the object you open the conversation against — fixes the chat's kind and its write authority at creation, and is never toggled (per ADR 0035, rooting is the mechanism, not a mode):

an edit chat is rooted on an archetype — its subject is the method; its output is a published archetype version. It lives in the library, not in a project;
a work chat is rooted on a placement — it does the job, consumes the method read-only, and cannot change it. It lives inside that placement, inside a project.

That the write-gate falls out of what the chat is rooted on (rather than a runtime check) is what makes method protection structural.

There is one kind of chat

Beyond its root, a chat has no engagement-mode axis (no autonomous-vs-interactive picker) — that axis was retired by ADR 0045. A chat is a single agentic loop that runs to completion and stops at the end of a turn; how closely you watch and steer is a choice you make in the same chat, not a mode.

Available

Run¶

One unit of work the agent performs, inside the boundary. A run consumes only the work it was admitted to do; in the workbench it produces a diff you keep or discard. A run's reasoning is performed remotely — see the data-flow truth above. Available

Resource¶

A protected thing the system records, references, or transports — a method, a context, or a derived output. Method and context are both resources; neither is privileged. Available

Handle¶

The reference by which resources are addressed. Holding a handle is not holding the data — reading a resource's payload requires a separate, explicit access grant evaluated at the boundary. Available

Method¶

Method is the expert's agent definition (the "how"). Context is the client's data the agent works on (the "what"). Both are resources — neither is privileged; they are kept apart by the same boundary, not by being different kinds of thing. The core promise: the method doesn't leak to the client, and the context doesn't leak to the method-owner or the runtime. Available

Context¶

The client's data the agent works on — the "what." The in-scope context for a run is sent to your configured LLM provider for inference; see Where your data goes. Available

Boundary¶

The protected execution context where an agent runs and the single point where egress is enforced. It mediates what a run can read, call, and export — a run has no ambient authority beyond what it was admitted. On Linux and macOS the method-isolation part of the boundary is enforced by a kernel sandbox; the Windows sandbox is Planned. Available (Linux/macOS)

Output¶

What the agent produces. Generating an output is not releasing it: outputs are held until reviewed and explicitly released to authorized stakeholders. Available

Workstream¶

A named, shared line of work inside one placement that a set of chats greedily auto-sync into — the collaboration axis for working together. Available

Engagement¶

Not a standalone product term anymore. "Engagement" once named both a mode on a chat (autonomous vs interactive) and the chat container itself. ADR 0045 retired the mode axis — there is one chat, one agentic loop — and the container is now just the chat. What survives is one piece of vocabulary: taint is "engagement-scoped" = chat-scoped. An output's conservative taint is the owners of everything that chat read up to production, tracked at the boundary at chat granularity. So when the principles or older specs say engagement-scoped taint, read chat-scoped taint. For everything else, see Chat. Available (as chat-scoped taint)

Package¶

A shareable object: a durable manifest that makes an archetype transferable across parties without turning transfer into execution or payload release. The packaging machinery is implemented; live cross-party hand-off is not yet operational. Built live deploy Planned

Runtime¶

The execution adapter inside a boundary that runs admitted work. It is not an authority over truth; it consumes admitted work, resolves resources only through the boundary, and reports observations back. Available

Authority & scope¶

Every durable fact names the authority responsible for it and the scope it affects. No authority may write into a scope it isn't authorized over — this is how projects and parties stay isolated. Available

Account¶

The person behind one or more placements and devices — the "this is all me" identity. Its identity is a governance root keypair (one root = one person), and a person's devices act under it. The always-on blind directory (sealed account state available when your own machine is off) and the cross-device account sync are not built yet. This is Post-M3 work and has not started. Planned

Organization¶

The enterprise-deployment container: the people of one buying company, the identities they sign in as, and the admin roles (invite, configure, audit, pay). The home of the enterprise (SSO / SCIM / RBAC / audit) layer. This is the M3 enterprise-readiness layer; it is not in production — no SSO/SCIM/RBAC runs today. Planned

Federation¶

Moving things (resources, commands, events, outputs) between parties — across machines or authorities. Nothing crosses without the source permitting it to leave and the target admitting it; relays route encrypted bytes but never read payload. Available

Attestation¶

Cryptographic proof that an agent ran inside a sealed, verified environment (a confidential VM), so both parties can trust the method and context stayed sealed. verifier Built live hosting Planned

Embedding & hosting vocabulary¶

All Planned

The terms in this section describe the embed surface — embedding a consultant's agent in their own website for end-users. The whole surface is Planned (see Public hosting / embedded agents and Deployment modes). Nothing here is usable today; the definitions fix the vocabulary so the design and the docs agree. They are grounded in the embed-surface contract behind the embed guide.

Audience¶

The consultant's end-users — an identified-but-non-authority principal inside the consultant's authority, not a separate account. The audience never owns product truth; everything it sees is a projection scoped to its own session (and, when signed in, its own chats). An audience identity is provider-asserted, with provider-style recovery (email reset / re-auth) — it never mints a keypair. Planned

Publishable key¶

The client-safe key that a <gw-session> snippet carries to talk to a deployment. It grants only the verbs the deployment chose; anything else is rejected at admission (fail-closed). It is publishable precisely because it conveys no secret — a separate server-side secret key (for backend proxying) is itself Planned. Planned

Panel ceiling¶

The maximum set of panels a deployment exposes — chat, optionally +viewer, optionally +files. Deploy sets the ceiling; the embed picks within it. The panel set chosen is the redaction: a panel beyond the granted ceiling does not render at all (no broken pane), rather than rendering and failing. Composition is scope. Planned

Allowed origins¶

The origin allowlist a consultant sets on a deployment — the web origins permitted to load its embed. A request from an origin that isn't listed is refused; a claim token presented from the wrong origin is rejected (fail-closed). Paired with budget/quota caps, this bounds where and how much a deployment can be used. Planned

<gw-session>¶

The web-component provider element that wraps an embed. One <gw-session> holds the deployment target and publishable key; the panel elements inside it render scoped projections for this session. The consultant copies a generated <gw-session>…</gw-session> snippet from the desktop Embed / Preview surface. Planned

<gw-chat>¶

The chat panel web component — the conversation and streaming assistant turns for one session, placed inside a <gw-session>. In authenticated mode it can carry a my-chats drawer for switching between the end-user's own durable chats. Planned

<gw-chats>¶

The standalone history pane web component — the end-user's own durable chats as a conversation switcher in its own element, an alternative to the <gw-chat> drawer. Both ship from v1 (authenticated mode only; there is no history in anonymous mode). Planned

Powered-by / white-label¶

Powered-by is the subtle GaugeWright mark that rides the embed panels on the free/standard tier. White-label — removing the mark — is a paid upgrade, a fourth paid lever beside hosting, compute, and attestation. Planned

Claim token¶

A one-time token issued at the teardown of an anonymous conversation that lets an end-user claim that conversation by signing up — the sole sanctioned, fail-closed bridge from anonymous to authenticated. A spent, expired, or wrong-origin token is refused. Planned

Workbench¶

The local desktop application you download and run — where you build archetypes, open chats, run agents, and review diffs. "Workbench" is the product; the runtime is the execution adapter inside it. Available

Stakeholder¶

A party with a legitimate interest in a resource or output — typically the method owner and the context owner of a project. Protected payload is never released to a non-stakeholder without an explicit basis. Available

Taint¶

The conservative record of whose data an output was derived from — the owners of everything a chat read up to producing it, tracked at the boundary. Release checks taint against the stakeholder set, so an output cannot be released to someone its inputs did not belong to. (Tracked at chat granularity; see Engagement.) Available

Host¶

In federation, the authority whose machine holds a project's data and executes its runs after a handoff. The host admits what crosses to it. Built

Operator¶

In federation, an authority that can drive runs on a project it does not host (e.g. the consultant after handing a project's home to the client). The operator places work; the host admits it. Built

Relay¶

The transport role in federation: it queues, retries, and forwards encrypted bridge messages between machines, but is never a payload authority and gains no access from carrying a handle (machine-checked, INV-14). Built

Handoff¶

The federation operation that relocates a project's home authority from one party to another (e.g. a consultant creates a project, then hands its home to the client who will host the data). Each side keeps what it owns; either can drive, the host admits. Built