Glossary

Coelevate has a small vocabulary and uses it precisely. Several of these words are ordinary English that mean something narrower here, and a few pairs look interchangeable and are not — outcome and response, cluster and batch, verification and evaluation. Where that is the case, this page says so rather than leaving you to infer it.

Terms are grouped by the part of the platform they belong to. Within a group they read in dependency order, so reading a group top to bottom works; jumping straight to one term also works, and anything it depends on is linked.

The context plane

Where curated material lives: the instructions, content and tools an agent works from. It is authored and versioned, and the running agent never writes to it.

Tool

An implementation an agent can call — an action against an external system, or a lookup.

A tool has two identities and they are not the same thing. Its reference is the durable one: the catalogued description of what the tool is and does, which survives the implementation being replaced. Its registry entry is the executable one: the thing that actually runs when an agent calls it. Curating a tool means writing the reference; deploying one means providing the registry entry.

Knowledge

Content an agent can consult — the facts, policies and reference material of your business, rather than instructions about what to do with them.

Knowledge lives in exactly one place and is referenced from wherever it is needed. It is never copied into a Skill or a Context Kit: a second copy is a second thing to keep true.

Skill

A self-contained unit of know-how: one standard operating procedure, plus everything it needs to be carried out.

A Skill carries its own instruction body, the Tool references it may call, and any scripts, reference material and assets it depends on. "Self-contained" is the operative word — a Skill can be read, reviewed and moved as one object, and it does not acquire meaning from where it happens to sit.

Pointer

A context asset that says where some external data lives, how to reach it and what to watch for — "the client list is in ClickUp, filter by name, the Tier column is a dropdown".

A Pointer names its places as up to fifty external references, says in one sentence when an agent should look there, and carries free-form instructions. It never holds the data it points at and never holds a credential. If an agent should fetch the data with a particular Tool, that is a link from the Pointer to the tool, and publishing is refused unless that tool is read-only. A Context Kit can contain a Pointer, and any asset can link to one.

Rule

A context asset that holds standing guidance an agent follows, written the way an agent's own rule files are: a unique name (the filename), a title, optional path globs it applies to, and a markdown body.

A Rule is something a person with authority decided, which is what separates it from a learned habit. It is versioned, reviewed and released like any other asset, and a Context Kit can contain it. Which skill or Tool a rule is scoped to is a link from the Rule, not a field of it. Whether a rule is interpreted by the model or checked by deterministic code, whether it is enforced or surfaced for review only, and the regulatory articles it contributes to are recorded on the rule as free-form metadata and tags; a rule may only claim to be enforced if it can name what enforces it.

ExternalRef

A stable name for one object that lives outside the platform: the system it lives in, an identifier or address for it, and optionally where inside that system to look.

It says which object and nothing about why it is named, so the same shape serves a Pointer's targets and the origin recorded for a piece of evidence.

SKILL.md

The rendering of a Skill as a single Markdown file — what you get when you export one, and what is served when something asks for a Skill in file form.

It is a view of the Skill, not the Skill itself. Editing the exported file changes a document; editing the Skill changes the platform's behaviour.

Context Kit

A versioned, ordered selection of a Project's assets that an agent is given for one kind of work.

A kit is not an asset. It holds references rather than copies — so updating a Skill updates it everywhere the Skill is used — and it can hold only assets that already exist. It is written directly through its own routes, never through a changeset, so a release never changes a kit: a member a release retires is skipped when serving (through its recorded successor when there is one) until the kit is repaired. A kit's own version changes when its members change and also when its title, description, tags, metadata or upkeep setting change, and each change is journalled.

The Context Repository is self-contained: nothing depends on Continual Learning keeping kits right. A client that uses only the API creates its kits after its assets are published and repairs them after every later release (see Keep your kits right after a release).

Revision

One entry in a context object's history. Every change to a Skill, a Knowledge page, a Tool reference or a kit appends a revision, and nothing is edited in place.

A version advances only on the object's own change, never transitively. Editing a Skill creates a new Skill revision; it does not create a new revision of every kit that references that Skill. This is the property that makes history readable — a version number tells you what changed, not what happened to be nearby.

Version

An immutable, numbered snapshot of one context object's content. Skills, Knowledge pages, Tool references and kits each version independently, following the rule in Revision.

Release

One published state of the whole repository of context — every object, at the version it held at the moment of publication.

The distinction that matters: a kit version identifies the selection; a release identifies content. A kit version tells you which Skills are in the kit. A release tells you what those Skills actually said. To reproduce what an agent did last Tuesday, you need the release.

Tag

A short label. Two different things carry this name, and they never overlap.

A release tag names a published release (stable, launch); at most one release holds a given tag, and tag on a release or asset listing resolves the release that holds it.

An asset's tags are the free-form labels every asset and every kit carries beside its metadata, a dictionary of text keys to text values. You choose what they hold (an owner, a last-verified date, a confidence, a review cadence) and Coelevate does not interpret them. To list the assets that carry a tag, use asset_tag.

Context

Three related things, and which one is meant comes from what is being discussed:

• the authoring surface — the place where Skills, Knowledge and Tools are curated;
• the assembled package — the specific material selected and handed to an agent for one request;
• the session identifier — see context_id.

The first two are the common ones and are related as recipe to meal.

Context plane

Where curated material lives — Skills, Knowledge, Tools, kits. Authored deliberately, read by everything else, written by nothing else. See also the Runtime plane and the Learning plane; the three of them are the whole architecture in three sentences, and every rule about what may not cross is a statement about them.

Agents

Agent

The customer-facing unit that delivers an outcome. An agent is what you point at a job: "handle new booking enquiries", "chase unpaid invoices".

One deployment can serve many agents. An agent is a logical thing — its contract, its context, its identity — and not a separate running process, so adding one is a configuration act rather than an infrastructure act.

Agents

The product switch for everything to do with agents: authoring them, running them and observing their runs. It is optional. An environment can leave it out, and an organization can be without it, in which case a project and the rest of the workspace work as before and simply show no agent sections.

Agent Registry

Where agents are authored: their definitions, versions and deployments, personas, MCP integrations, rules and automations. It holds configuration for projects, never the fact that a project exists; that belongs to the platform.

Agent Execution

The runtime that runs a deployed version of an agent when a client calls it over A2A, and records the session, its events and its tool calls. The workspace's sessions, runs and metrics views read that record.

Agent Contract

What an Agent promises, in three groups: the outcome it delivers, the request it accepts, and the response it returns.

An agent and its contract are one to one. There is no agent without a contract and no contract shared by two agents — which is what makes "what does this agent do" a question with exactly one answer.

Example

A whole request — a message together with its parameters — used to show an Agent what a real call looks like.

An example is deliberately a complete request rather than a phrase or a sample sentence. A phrase demonstrates wording; a request demonstrates shape, and shape is the part that is easy to get wrong.

Persona

The end-user role a caller asks an agent to act as — "a guest", "a supplier", "a new enquiry".

A persona is not identity and is never authenticated. It never keys a Session, never names the subject of an audit record, and grants nothing. It tells the agent whom it is talking to for the purpose of tone and expectations, and that is all. For who someone actually is, see Principal and Acting user.

ProcedureType

Which phase of the work a Skill belongs to: task execution — doing the work — or outcome verification — checking that the work met the contract.

The distinction exists because the two are separately authored and separately improved. A Skill that does a job well and a Skill that judges whether the job was done are different documents even when they concern the same job.

Runtime plane

Where agents execute against curated material. The runtime plane never writes to the Context plane — a running agent cannot edit its own instructions. All change to context goes through authoring, or through the review of a proposal produced by the Learning plane.

Provider

The organization offering the agents. The provider is the organization; the Project is the scope within it.

Service

A separately deployed process — the pieces the platform is built from. Some own a database and some are stateless.

This is the deployable sense of the word and the only one still in use. "Service" as a name for a unit of customer-facing work is retired; that is now an Agent.

A request, and what comes back

The vocabulary here is the most easily confused on this page, because five different words answer five different questions about the same piece of work. The summary is:

the contract promises an outcome; the session produces a response; the response contains the report on that outcome, the verification of it, and how the session ended.

Session

One request's whole lifecycle, and its durable state — everything from arrival to final answer, including anything remembered along the way.

session_id is the identifier. It is the term to use in conversation and in your own code.

context_id

The wire spelling of the Session identifier in the A2A protocol. If you are calling Coelevate over A2A, this is the field name you will see.

It is the same thing as session_id under a different name at the protocol boundary, not a second concept. Boundaries are allowed their own spellings; what matters is that the mapping is written down, and this is it.

Task

In the A2A protocol, a Task is the whole request, from submission to a terminal state — not one piece of work inside it. For a piece of work inside a request, see Step.

Its state is fixed by the protocol and has nine values: submitted, working, input-required, completed, canceled, failed, rejected, auth-required and unknown. This is a protocol vocabulary and does not describe background jobs — for those see Job lifecycle.

Step

One unit of work inside a plan.

Deliberately not called a "task": in A2A a Task is the entire request, so using the same word for a fraction of one would collide with the protocol at exactly the point where precision is needed.

Workflow

The ordered state machine one request runs through: idle → submitted → approved → interpreting → planning → executing → verifying → responding → resolved → closed.

resolved is reachable only through responding. Recording the response is what moves the work into a resolved state — so a request cannot be resolved without a response having been written.

Outcome

What the agent produces as an effect of its actions — the real change in the world. The booking that now exists, the message that was sent, the invoice that was chased.

This is the word's only meaning. It is not the status of the request, not the text returned to the caller, and not a verdict. An Agent Contract promises an outcome; everything below reports on whether one arrived.

Request

The input: a message, plus the structured params the Agent Contract describes.

Response

The message back to the requester. It carries a status — success, partial or failed, following from the Verification — the Output, the deliveries that were counted, any open issues, and the message itself.

partial is a real and common answer, not a rounding error: nothing was shown to fail, but not every promise could be confirmed, so the output should be reviewed before it is used.

Response and outcome are not synonyms and the difference is load-bearing: the outcome is the change in the world, the response is the message describing it.

Output / deliverable

An artifact the agent produces — a readout, a document, a structured result — shaped by the contract's output schema. The output is what a run makes; the Outcome is the effect it is supposed to cause.

Outcome report

A retired name for the Response. The step that writes it is the responder.

Verification

The check on whether a delivery met its Agent Contract. Its verdict is COMPLETE or FAIL, and the individual checks underneath it each pass or fail on their own.

Not to be confused with Evaluation, which is a different thing that shares much of the word.

Resolution

How the Session ended: success or failure. Not the billable "resolution" of outcome-based pricing — that is an Outcome, an effect in the world.

Delivery

What the requester got — the axis reported by the Response: success, partial or failed.

Listed separately from Resolution because the two overlap in spelling and not in meaning. Both use the word success, and they answer different questions: delivery asks what did the requester get, resolution asks how did the session end. A bare "success" means nothing without saying which axis produced it.

Job lifecycle

Whether a background job ran at all: queued, running, succeeded, failed, cancelled.

This describes the job, never the work's quality — a job can succeed at producing a failed Delivery. It is also not the A2A Task state, which describes a request rather than a job.

Evaluation

A scored assessment of a piece of work, taken in as Evidence for the learning loop.

Distinct from Verification, which is the phase that asks whether a delivery met its contract. The two words are related in English and unrelated here, and the platform keeps both because each names something the other does not.

Learning

How the platform improves the Context plane from what actually happened. The shape is a map and a reduce: many observations become many small proposed edits, and those edits are then grouped and resolved into concrete changes.

Learning plane

Where evidence becomes proposed edits. Personal data never enters it — see PII redaction.

Evidence

Anything a pipeline takes in, under one envelope: a recorded session, an Evaluation, a rating, an expert judgment, a specification. The envelope's kind says what the payload is evidence of.

Import

Bringing your files, notes and past sessions into Coelevate as Evidence. An import is accepted at once and then processed item by item: the Import history shows where each item is — queued, processing, imported, failed with its reason, or expired and waiting to be uploaded again — and each one appears among your evidence once it has been processed.

"Import" is the word the product uses on screen.

Ingestion

The same act as an Import, named from the platform's side: the service that takes evidence in, redacts personal data at that boundary (see PII redaction) and hands it to the Learning plane. You will meet the word in API paths and service names; in the product itself it is always called an import.

Signal

One typed observation the learning loop can weigh — a self-reflection, a user rating or verdict, an expert judgment, an evaluation.

PII redaction

Removing personal identifiers at the point evidence is taken in.

This is a compliance control and it is absolute: it happens at the boundary, before anything is stored, and it is not a judgement call. Distinct from Generalization, with which it is routinely conflated and must not be.

Generalization

Removing confidential specifics so that what is learned from one case applies to the next.

This is about usefulness, and it is a judgement: how much detail to strip is a question with better and worse answers rather than a right one. It happens later than PII redaction and for a different reason — redaction protects a person, generalization makes a lesson reusable.

Patch

A plain-language, minimal, generalizable edit instruction targeting any piece of context — or an explicit no-op saying that nothing needs to change.

One piece of Evidence yields zero, one or many patches across the things it touches. That the count can be zero, and can be more than one, is why the stage that follows exists.

Gap

The third possible finding beside a patch and a no-op: something worth changing that editing context cannot fix — a missing tool, an absent integration, a policy question.

Recording gaps rather than discarding them is deliberate. A learning loop that could only emit edits would silently convert every structural problem into a wording change.

Consolidation

The whole second half of the learning loop: grouping outstanding Patches into Clusters, subdividing a cluster into Batches where it is too large to handle in one pass, and Merging each into concrete changes.

Learning process

A background process of the learning loop that you can switch on or off for a Project. There are three, run in order: Evidence-based patch generation, Patch clustering and Cluster merging. Switched off, a process runs nothing for that project — neither on its own nor when you start it by hand — while everything stays readable. Switching it back on does not go back over what arrived meanwhile.

Evidence-based patch generation

The first learning process: it generates Patches from newly ingested evidence.

Patch clustering

The second learning process: it groups outstanding patches into Clusters.

Cluster merging

The third learning process: it turns one cluster into concrete changes, and it is the only process that does.

Cluster

The group of related patches that one consolidation takes. Scoped to a Project, formed once, never revised afterwards.

A cluster makes a semantic claim: its members belong together.

Batch

A mechanical subdivision of a Cluster that is too large to consolidate in one pass.

A batch carries no claim about its members beyond "these fit". Cluster and batch are not rivals and not synonyms: a cluster asserts relatedness, a batch asserts size.

Merge

The step inside Consolidation that turns one Cluster into concrete create, update and delete operations, resolving conflicts between the patches it contains.

Merge is a sub-step of consolidation and never a synonym for it. It is also not a version-control merge: nothing divergent is being reconciled.

Changeset

A Project's staging area for context changes — one per project, which anyone may stage into, and which is published as a unit or discarded as a unit.

Publishing a changeset is what makes staged edits live.

Staged change

Any change in the project's open Changeset, whatever produced it: a learning run, a direct edit in the workspace or through the API, or seeded content. Every change to your context is a staged change first, and reaches agents only once the changeset is merged with it approved.

While the request is reviewed, a staged change is Approved, Rejected, or still Staged (not decided yet). Stage returns a decided change to Staged. Staged changes still undecided when the request merges carry over to the next change request.

Review item

What a reviewer decides: every staged change to one asset, or to one link between two assets. All the changes in one review item are approved or rejected together, so a merge never ships half of an asset's edits.

Draft

An early version produced by the platform for a person to edit — the sense in "draft me an agent". A draft is a starting point offered to you, and is never stored as a distinct state of anything.

The word does not mean staged changes awaiting publication. That is a Changeset.

Approve / Reject

The pair used when adjudicating someone else's request — a petition has been submitted to you and you rule on it.

Save / Discard

The pair used for an object you hold and curate — keeping it or throwing it away.

The discriminator between the two pairs is whether something was submitted to you for a decision or is an object you already hold. It is not whether a record survives, and not who authored the thing. Patches, Clusters and Changesets are all objects a curator holds, so the whole learning loop is save/discard end to end — even though a person judges each one.

Governance

A Rule is a context asset like any other and is defined with the context terms above; this section holds the governance terms that are not assets.

Guardrail

A project-wide instruction applied before every agent invocation, defined in code rather than authored as an asset: a fixed set of instruction texts plus two programmatic checks. It has no scope, which is why it needs no field saying to what. It is the project-wide floor; a Rule is the authored, versioned guidance a person adds on top, which a Context Kit holds and which can be scoped to a skill or a Tool.

Organizations, projects and identity

Five different notions of "who" appear here and they are not interchangeable.

Organization

The tenant. An organization is a tenant — it owns projects, scopes data, and holds memberships. It is the technical boundary.

Account

The commercial record about an Organization: plan, contacts, billing, capability overrides. One account per organization.

Organization and account describe the same customer from two directions — the organization is the technical boundary, the account is the commercial relationship with it.

Project

The scope every piece of data and every authorization decision is keyed by. A project sits inside an Organization, and nothing crosses between projects.

Archived

A Project that is read-only. It still opens, and its context, agents and history can be browsed, but nothing can change it: no agent runs, no edits, no learning, no imports — for anyone. A write to it is refused with 409 project_archived. Restoring it makes it writable again. A project is either active or archived.

User

The person who signs in. The platform's global login identity.

Principal

The subject of an access token — a user today, and a service account or API key in future. This is the identity that holds membership and against which access is decided.

Acting user

The end user an Agent is acting on behalf of — a guest, a customer, a supplier.

Not the same as a Principal, and the difference matters. A principal is an authenticated subject with membership. An acting user arrives with the request, may be absent, and describes somebody who may never have signed in to Coelevate at all — agents are distributed, and the people they serve are not the people who administer the platform. See also Persona, which is the role a caller asks to be treated as and is weaker still: it is never authenticated at all.

The term is used in two senses across our own documents, so it is worth being explicit: some of them use "acting user" for the authenticated caller instead. Where the distinction matters, we call the caller the Principal and the person being served the End user.

End user

The person a run is being carried out for — the concrete, implemented form of Acting user above.

An agent authenticates as a member of a Coelevate organization, but the task it is performing usually belongs to somebody else: a guest, a customer, a supplier. Those are two different questions, and a tool call carries both answers separately — who is calling, proven by the request's signature, and who the call is for, named by the caller and signed alongside it so that nothing in between can change it and the agent itself cannot invent one.

Absent means nobody, never everybody. A run that names no end user gives a user-scoped tool nothing to read, rather than access to everyone's records.

Subject

Whom a call is for, as a connected system knows them. Each system you connect decides whether it needs one; when it does, a request names the person as that system knows them, because one person can have a different id in every system. It sits in the subject slot of the credential that system receives, and it is trusted only because the caller that named it is one the system trusts — who made the call is stated separately, in the same signed credential, and the two are never confused.

There is no separate Coelevate id for the person: the identity a request runs under on Coelevate is always the signed-in caller who sent it.

Identity claim

A fact about whom a request is for, such as the organisation a cardholder belongs to. Each connected system states the claims it needs when you register it, and an agent that uses that system asks for them — named after the system, so two systems' "user id" never get mixed up. The caller sends them with the request that starts a session, apart from the rest of the request, and a request missing a required one is refused before the agent runs.

The agent never sees or types these values, so it cannot point a tool at somebody else's data. They reach a connected system only inside the request's signed credential, and each system receives only its own.

Delegated token

The signed credential a connected system receives when the platform acts on an end user's behalf. It names the agent performing the call — by the client identity that system itself issued your project — and, when there is one, the end user the call is for, plus the identity claims that system is allowed to see, and nothing about Coelevate's own internal organization of the data. The agent has no authority of its own: it acts within what the system granted your project.

Client grant

What a connected system has granted the client identity it issued your project: which account it may reach, and, for each identity claim, which values it may carry — or any. A system that trusts you with only some of its organisations says so here, and refuses a call for any other one.

Audit trail

The record of who did what, and there are four of them — "the audit log" on its own names none:

• Request audit — one row per endpoint call on every backend service: the verified user, the service that carried the request, the route, when, the status, and whether the call was granted or rejected. This is the one a project's Audit log settings tab lists. It records that a call happened and how it ended, never what was said in it.
• Access record — the same verdict, written as a log line at the moment of the decision and kept in a tamper-evident log store. The trail of record; the request audit is the copy an operator can page through.
• Configuration audit — what changed in a configuration record, field by field, before and after.
• Tool-call audit — every tool an Agent ran, shown in the workspace's Activity tab.

Environment

What a deployment is configured as: dev, staging or demo.

Environment is independent of where something runs. A staging environment on a laptop and a staging environment in the cloud are the same environment configured the same way, in two places.

Words that are no longer current

If you meet one of these in older material, the right-hand column is what to say now.