The workspace-you-own glossary: 27 terms, defined properly

The old way with vocabulary in this market is simple: bend each word until your product qualifies. “Sovereign” becomes a region setting, “agent” becomes a chatbot with a job title, “your data never leaves” becomes a sentence nobody is expected to parse. This glossary is the countermeasure: 27 terms defined strictly enough to evaluate claims against — including the claims on this website, which belongs to CloudTop — the AI workspace you own. Where CloudTop has a specific stance, it’s noted; where a term is still future-tense for us, that’s noted too.

Sovereign workspace

A working environment the organization owns across four tests: it holds the model keys, it controls what data leaves and to whom, it owns the workflows and memory, and it can leave — providers, models, and hosting — without rebuilding. The sovereignty describes the workspace, never the AI. Full argument: the definition piece.

Data sovereignty

The principle that data remains subject to the laws and control of the jurisdiction and organization it belongs to — a matter of who can access, compel, and move it, not merely where a disk sits.

Data residency

Where data is physically stored. Necessary information, insufficient sovereignty: residency answers “which country’s data center?” while saying nothing about custody, traffic paths, or exit.

Digital sovereignty

An organization’s (or region’s) ability to act independently in the digital domain — to choose, control, and replace its technology without a veto from any single foreign or commercial dependency.

Sovereignty-washing

Marketing a dependency as independence — typically a regional flag on an unchanged vendor relationship. Detection kit: the eight questions.

Model (AI model)

The AI engine itself — the thing that reads a request and writes the answer. Different providers make different models, and new ones leapfrog the old every few months. Everything an “assistant” does runs on some model underneath; which one, and on whose account, is the whole ownership question.

Bring your own model (BYOM)

Connecting the AI models of your choice to a workspace using your own provider accounts, swappable per task. In CloudTop, the standing posture: models are guests; the workspace is the host.

Bring your own key (BYOK)

Using your own API credentials with a model provider. Only meaningful if the key stays in your custody — a “BYOK” stored in a vendor’s server vault is their key with your name on it. In CloudTop the key sits in your own settings, on your own device.

Inference

A model producing output from input — the metered unit of AI usage. Who bills for it reveals the architecture: CloudTop never does; you pay your model provider directly.

Proxy (AI middleman)

An intermediary through which your AI traffic flows — able to log, retain, meter, and fail on your behalf. The box we argue shouldn’t exist: client-side access.

Client-side / edge execution

Running work on the user’s own device rather than a vendor’s server. In CloudTop, applications and the AI connection execute client-side — which is what makes the credential and traffic claims mechanically true rather than contractual promises.

MCP (Model Context Protocol)

An open, vendor-neutral protocol through which AI models discover and use tools that applications expose. The plumbing standard of AI-that-acts. Plain-language tour: MCP for business.

Tool

A function an application exposes for AI use — “create invoice,” “search folder” — carrying the application’s own validation. Tools are the app’s real operations, not descriptions of its buttons.

Toolbelt

The set of tools available to the AI at a given moment. In CloudTop it is assembled at runtime: workspace tools always present, plus whatever the currently open applications contribute — so every installed app extends the AI.

Connected services

The user’s own external accounts and systems made reachable to the AI on the user’s side of the line — the user’s services, on the user’s credentials, within granted scope.

Agent

Software with standing permission to act within limits: plain-language instructions, a trigger, separate read and write scopes, and an autonomy level. In CloudTop, literally a small readable file. Anything that can’t show those four fields is a vibe.

Trigger

The condition that runs an agent: manual, scheduled, on-change, or on-mention. The difference between software that acts and software that waits to be prompted.

Read scope / write scope

Separately granted boundaries on what an agent or assistant may see versus change. Everything outside the write scope is untouchable by it; everything outside the read scope is invisible to it.

Autonomy level

A per-agent setting for how much may happen without a human: ask first for everything; act on safe reads and small writes; or fully autonomous. Governance as a dial, not a debate.

Propose-and-commit

The pattern where AI fills an application’s real form as a proposal and a person commits it. Catches the errors that validation can’t — the balanced entry on the wrong side. Origin story: why the AI proposes.

Human oversight

Demonstrable human control over consequential AI action — the direction of EU law, and only inspectable when it’s architecture (a commit step, an audit stream) rather than a policy sentence.

Audit trail

The record of who did what, when. The standard worth demanding: one stream where AI actions — each with its tool trace — sit beside human actions, so incidents are readings, not correlation projects.

Data binding

Applications attaching to data such that changes propagate live in both directions, for every connected user and device. In CloudTop the binding layer also carries offline queuing, sync, and versioning — which is why every app is collaborative without sync code.

Offline-first

Designed to work without a connection and reconcile when one returns — queued changes, merged histories, versions kept. A platform property in CloudTop, not a per-app achievement.

Native install (marketplace apps)

An app downloaded from the workspace marketplace arrives as a native application on the device — sitting in the Dock or taskbar, opening and feeling like anything locally installed, while staying cloud-connected underneath. The same app installs natively on Windows, Mac, Linux, mobile, and car dashboards from one codebase; the platform handles every conversion, and the developer ships once. The test: no “available on” matrix, no per-platform version numbers quietly drifting apart.

Shared team memory

Working context held as governable files in a shared folder, readable and updatable by every team member’s connected model — so context survives model swaps and personnel changes alike. For CloudTop this is the design arriving with the public release, stated in the future tense on purpose: one memory, any model.

Lock-in

Any accumulation that makes leaving cost more than staying — keys held, memory hoarded, formats sealed, integrations fused. The quiet product behind many loud ones. Antidote by design: a workspace where the exit is priced at day one.

Terms will be added as the vocabulary shifts — and if a definition above wouldn’t survive being quoted back to us in a sales call, tell us and we’ll tighten it. A glossary you can’t be held to is just marketing with anchors.