Documentation Core concepts

Glossary

Every Cella component and product term, with definitions, examples, aliases, and links to its feature contract.

Product guide · implementation in progress

On this page

Status: explanatory vocabulary for the intended product, reviewed against the complete feature requirements and canonical component model on 2026-10-12. Definitions describe the contract, not availability in a released build. The feature milestones own implementation status.

Look up a name from the landing page or feature guide. Each entry explains what it means, gives an example, and links to its detailed guide and feature scope. Search in the documentation sidebar also finds individual terms and aliases.

Start with the work cycle

An independent agent works in an Agent Cell, producing a Candidate. A Service Cell runs an approved Service Revision, independently of that worker. An authorized Channel lets the worker test a named Service through Relay. cellad coordinates their identities, policy, and lifecycle. Wall contains execution; Gateway mediates external Effects using Connections. Workstreams, Checkpoints, and the Work Journal preserve declared work state across Runs. Evidence ties the work to its authority, checks, and consequences.

These are different responsibilities, not a separate daemon for every name. Long-lived work includes pauses, approvals, recovery, and replacement Runs; it does not require one immortal agent process.

Names that are easy to confuse

Names Difference
Channel / Connection / Link Channel permits service traffic; Connection references external provider authority; Link carries remote operator intent.
Wall / Gateway / Relay Wall contains execution; Gateway executes credentialed external Effects; Relay carries authorized Channels.
Cell / Generation / Run / Workstream Cell is logical runtime identity; Generation is the admitted boundary; Run is one attempt; Workstream retains the task's lineage.
Run / Run Target Run records an attempt; Run Target is an approved launch definition.
Candidate / Service Revision Candidate is editable work awaiting selection; Service Revision is sealed admitted application input.
Project Secrets / provider credentials Project Secrets belong to authorized application runtimes; provider credentials remain behind Gateway. Neither belongs in an Agent Cell.
Data Volume / Data Snapshot / Artifact Volume is mutable application state; Snapshot is an immutable data view; Artifact is an immutable bounded result.
Approval / policy / Lease Approval binds an exact decision; policy bounds authority; Lease limits the duration and revocability of a grant.
Receipt / Attestation / Evidence Event Receipt records a terminal operation result; Attestation signs a defined claim; Event records an attributable fact or gap.
Managed / Connected Service Managed runtime is owned by Cella; a Connected Service is only an enrolled external endpoint.

Execution and identity

Cell

A Cella-managed isolated environment with a stable logical identity, a role, explicit authority, resource limits, and a lifecycle.

A user may reuse an existing Cell or create another for narrower task inputs, context, tools, or permissions. Scope and lifetime are independent.

Example: A worker and the backend it tests occupy different Cells.

Read more: Cells. Related guides: Agent isolation, Tasks and execution history.

Agent Cell

Aliases: Cell Agent.

The Cell role for an untrusted coding agent and its private writable candidate. Provider credentials and Project Secret values stay outside it.

A general-purpose environment that can retain its workspace, scripts, permitted workspace-local tools/dependencies, agent context, and task state across explicitly selected Runs. The agent may create and execute scripts within its admitted limits. General and focused Agent Cells share this role; completing a Run does not by itself destroy a retained Cell.

Example: Codex returns to a retained project Cell, uses its existing context, and runs a script; the user creates a separate read-only Cell for review.

Read more: Cells. Related guides: Agent isolation, Private repository workflow, Agents and handoff.

Service Cell

Aliases: Cell Service.

The Cell role for an approved application or task running from a sealed revision. It has its own lifecycle and may receive exact runtime secret and data bindings.

Example: The test backend keeps running while the coding agent is paused.

Read more: Services. Related guides: Run and test applications, Limits, recovery, and cleanup.

Analysis Job Cell

The Cell role for an approved, bounded analysis task with explicit data or artifact inputs. Outputs cross into an Agent Cell only under a separate grant.

Example: An approved job summarizes a database snapshot before the agent reads the result.

Read more: Services. Related guides: Run and test applications.

Cell Record

The durable record of a logical Cell's identity, role, ownership, desired configuration, and generation lineage. A record may exist before any runtime starts.

Example: Creating a Cell does not by itself start an agent.

Read more: Cells. Related guides: Tasks and execution history.

Cell Generation

Aliases: Generation.

One admitted execution boundary with fixed inputs and authority. Replacement, changed admitted inputs, or a resumed attempt requires explicit generation handling and fresh grants.

Example: An old service Channel does not automatically authorize a replacement agent generation.

Read more: Cells. Related guides: Agent isolation, Tasks and execution history, Limits, recovery, and cleanup.

Cell Generation Manifest

Aliases: Generation Manifest.

The immutable description of the exact inputs, runtime, policy, identity, and restrictions admitted for a generation.

Example: A reviewer can identify which source and policy a Run actually used.

Read more: Cells. Related guides: Agent isolation, Tasks and execution history.

Cell Observed Status

Aliases: Observed Status.

Trusted changing observations about a generation, such as running, stopped, or quarantined. Observed state is separate from desired configuration and admission identity.

Example: The record may request running while observation reports quarantined.

Read more: Cells. Related guides: Agent isolation, Limits, recovery, and cleanup.

Admission

The governed checks that must succeed before an exact generation may execute. Configuration intent alone does not establish protection.

Example: Missing runtime enforcement makes admission fail rather than select a weaker mode.

Read more: Wall. Related guides: Agent isolation, Tasks and execution history.

Cella CLI

Aliases: cella, CLI.

The user-facing command interface. It captures intent, presents previews and approvals, and reads status; it does not own privileged enforcement.

Example: The CLI asks cellad to create a logical Cell.

Read more: Cli. Related guides: Supervise agent work, Operations and integrations.

cellad

The independent, constrained controller that coordinates policy, lifecycle, Workstreams, approvals, Channels, Effects, evidence, and recovery. Only enrolled cellad controls the authority components.

Example: An agent can stop while cellad retains the task's state.

Read more: Controller. Related guides: Agent isolation, Tasks and execution history, Limits, recovery, and cleanup.

Cella Wall

Aliases: Wall, cella-wall.

The privileged execution boundary that creates, contains, inspects, stops, and destroys admitted Cells. It owns runtime enforcement, not provider credentials or business approvals.

Example: Wall enforces the workspace and resource boundaries.

Read more: Wall. Related guides: Agent isolation.

Wall Profile

An installed low-level enforcement definition for containment, storage, network, resources, images, and inspection under the Security Floor.

Example: An admitted profile supplies bounded runtime settings instead of arbitrary caller mounts.

Read more: Wall. Related guides: Agent isolation.

Runtime Manifest

A signed release object pinning compatible platforms, components, artifacts, runtime inputs, configuration, and identities.

Example: Setup verifies the pinned artifact digests and compatibility.

Read more: Operations and integrations. Related guides: Run Cella yourself, Operations and integrations.

Protected Cell

Aliases: protected.

A generation-specific qualification claim requiring the mandatory isolation, authority, and evidence contract. A container, authenticated session, or passing unit test alone does not establish it.

Example: An unqualified runtime remains explicitly non-production.

Read more: Wall. Related guides: Agent isolation, Run Cella yourself.

Authority and policy

Cella Policy

Aliases: Policy, Policy as Code.

Trusted, versioned declarative rules governing runtime, work, operations, data, approvals, budgets, and evidence independently of the model.

Example: Changing from Codex to Claude does not widen permissions.

Read more: Policy. Related guides: Permissions and policy.

Policy Engine

The proposed subsystem inside cellad that parses trusted sources, composes policy, evaluates exact requests, and explains decisions. It does not execute the operation or hold provider credentials.

Example: Simulation and runtime evaluation use the same decision semantics.

Read more: Policy. Related guides: Permissions and policy.

Effective Policy

The canonical result of intersecting the Security Floor with all applicable organization, Project, Workstream, Cell, and operation restrictions. It carries exact identity and provenance.

Example: A permissive Project rule cannot override an organization denial.

Read more: Policy. Related guides: Permissions and policy, Organization controls.

Cella Security Floor

Aliases: Security Floor, Cella Floor.

Installed minimum invariants and evidence requirements that no lower policy layer, approval, prompt, or exception may weaken.

Example: An approval cannot permit an Agent Cell to read host credentials.

Read more: Policy. Related guides: Agent isolation, Permissions and policy, Organization controls.

Policy Exception

An accountable, narrowly scoped governance record for a rule that explicitly permits exceptions, with actor, reason, expiry, and review. It cannot weaken the Security Floor.

Example: An authorized exception applies to its exact scope, not every later request.

Read more: Policy. Related guides: Permissions and policy, Organization controls.

Policy Template

An inspectable versioned starting configuration that compiles through ordinary policy layers. Templates grant no privileged exemption.

Example: A repository-review template can narrow access without weakening inherited rules.

Read more: Permissions and policy. Related guides: Permissions and policy.

Operation Contract

A trusted, namespaced and versioned definition of an operation's typed parameters, bounds, mediation, redaction, idempotency, and evidence behavior. Registration defines meaning; policy still determines authorization.

Example: A connector registers a bounded operation before policy can allow an exact request.

Read more: Permissions and policy. Related guides: Permissions and policy, Operations and integrations.

Operation Catalog

The trusted installed set of operation definitions bound into the Effective Policy digest. A repository cannot install its own mediator or trust class through a policy file.

Example: A custom operation refers to an installed connector and exact schema.

Read more: Permissions and policy. Related guides: Permissions and policy, Operations and integrations.

Decision Record

Aliases: Policy Decision.

The attributable outcome of evaluating an exact request: allow, deny, or approval-required, with rule, source, scope, explanation, expiry, and evidence requirements.

Example: A denied service request identifies the rule that rejected its destination.

Read more: Policy. Related guides: Permissions and policy, Activity and evidence.

Capability

Exact scoped authority to request a defined operation, bound to identity, resource, parameters, policy, budget, approval, and expiry. It is not a raw secret or unrestricted authenticated shell.

Example: Permission to propose one candidate does not authorize arbitrary GitHub writes.

Read more: Gateway. Related guides: External access and credentials, Approvals and external actions.

Approval

An authenticated decision bound to an exact request, actor, role, parameters, policy, candidate, scope, and expiry. It cannot override policy denial.

Example: Approving one patch does not approve a later changed patch.

Read more: Policy. Related guides: Approvals and external actions, Supervise agent work, Organization controls.

Budget

Enforced limits for resources, elapsed time, cost, output, or consequences in an exact scope, with attributable consumption.

Example: A Run stops or throttles when its admitted limit is reached.

Read more: Limits, recovery, and cleanup. Related guides: Agent isolation, Limits, recovery, and cleanup, Operations and integrations.

Lease

Revocable, time-bounded authority for a Channel, capability, attachment, input, secret, or data grant. It cannot widen immutable generation policy.

Example: A disconnected controller loses its expired terminal-input lease.

Read more: Channels. Related guides: Run and test applications, Limits, recovery, and cleanup, Remote control with Cella Link.

External operations

Cella Gateway

Aliases: Gateway, cella-gateway.

The credential-use boundary that executes approved typed external Effects through Connections, returns bounded redacted results, and records receipts. It is separate from Relay and Wall.

Example: Gateway proposes a repository change without handing the agent a GitHub token.

Read more: Gateway. Related guides: External access and credentials, Approvals and external actions.

Cella Connection

Aliases: Connection.

A stable logical reference to an external provider identity, allowed operations, resources, version, status, and credential source. Credential material is resolved outside the Agent Cell.

Example: org/github-production can rotate its backing credential without changing the agent.

Read more: Gateway. Related guides: External access and credentials, Organization controls.

Connection Catalog

The governed inventory of logical Connections and their owners, scopes, versions, and states.

Example: An organization disables a Connection and blocks new and queued uses.

Read more: Gateway. Related guides: External access and credentials, Cella Cloud, Organization controls.

Credential Resolver

The Gateway-side responsibility for acquiring authorized credentials from an OS keychain, encrypted store, external secret manager, workload identity, or provider.

Example: A short-lived token is obtained outside the worker and revoked after use.

Read more: Gateway. Related guides: External access and credentials.

Effect

Aliases: Cella Effect.

One exact typed external operation with bound identity, target, parameters, Connection version, policy, approval, and reconciliation state.

Example: A pull-request proposal is an Effect; an arbitrary credential-bearing shell is not.

Read more: Gateway. Related guides: External access and credentials, Approvals and external actions.

Connector

An installed provider adapter that defines and performs bounded typed operations with validated parameters, redacted responses, and evidence.

Example: A GitHub connector proposes a digest-bound change.

Read more: Gateway. Related guides: External access and credentials, Permissions and policy, Operations and integrations.

Model Gateway

The provider-authentication path that adds authorized model-service authentication only after a request leaves the Agent Cell.

Example: The agent uses a model endpoint without holding the provider API key.

Read more: Gateway. Related guides: External access and credentials.

Idempotency

Aliases: Idempotency Key.

The request identity and state handling used to avoid duplicate consequences during retries. Unknown outcomes require reconciliation, not blind re-execution.

Example: A lost acknowledgement must not create a second pull request.

Read more: Approvals and external actions. Related guides: Tasks and execution history, Approvals and external actions, Operations and integrations.

Reconciliation

Comparing intended state with observed runtime or provider state after interruption before choosing a safe next action.

Example: The controller checks whether a timed-out Effect completed before retrying it.

Read more: Limits, recovery, and cleanup. Related guides: Approvals and external actions, Limits, recovery, and cleanup.

Redaction

Policy-controlled removal or filtering of secret and restricted values from bounded results, artifacts, observations, and evidence.

Example: A connector returns operation status without including the token used.

Read more: Gateway. Related guides: External access and credentials, Run and test applications, Activity and evidence.

Services, Channels, and data

Cella Channel

Aliases: Channel.

Directional, scoped permission for an exact caller generation to communicate with a named Service endpoint, with protocol, limits, and lifetime.

Example: An Agent Cell may call backend-test GET /health without reaching every port or reading service secrets.

Read more: Channels. Related guides: Run and test applications, Remote control with Cella Link.

Cella Relay

Aliases: Relay, cella-relay, Cella Relayer, Relayer.

The network-sensitive data boundary that carries authorized Channel traffic, enforces route bounds and revocation, and holds no provider credential authority. Relay is the canonical name.

Example: Relay carries an approved health request; it is not a general internet proxy.

Read more: Channels. Related guides: Run and test applications.

Cella Service

Aliases: Service.

A named protocol endpoint that can resolve to a Cella-managed runtime or an explicitly enrolled external service. A Channel targets the named identity, not an arbitrary address.

Example: backend-test names the exact endpoint permitted for testing.

Read more: Services. Related guides: Run and test applications.

Managed Service

A Cella Service backed by a current Service Cell generation under Cella runtime and lifecycle ownership.

Example: Cella can govern the backend's admitted revision and runtime boundaries.

Read more: Services. Related guides: Run and test applications, Bring existing services into Cella.

Connected Service

An enrolled endpoint outside Cella runtime ownership. Cella governs its Channel access but cannot claim that the external service runs in a protected Service Cell.

Example: An existing local database exposes one explicitly permitted endpoint.

Read more: Services. Related guides: Run and test applications, Bring existing services into Cella.

Service Revision

Immutable code or artifact inputs sealed for a Service Cell generation. Editing an agent candidate does not mutate an admitted revision.

Example: New backend code passes the required checks and approval before replacement.

Read more: Services. Related guides: Run and test applications, Checks and build outputs.

Run Target

An approved exact launch definition binding command, arguments, working directory, runtime, inputs, secrets, network, resources, and approval rules. It is a definition, not an execution attempt.

Example: The agent requests an approved test-backend target ID, not its own secret-bearing command.

Read more: Services. Related guides: Run and test applications, Checks and build outputs.

Project Secret Set

Aliases: Secret Set, Project Secrets.

Explicitly imported application runtime values held outside repository ingress and every Agent Cell. They are separate from Gateway provider credentials.

Example: A backend's database configuration stays out of the coding workspace.

Read more: Services. Related guides: Run and test applications.

Project Secret Boundary

Aliases: Secret Boundary.

The sensitive storage and projection boundary for Project Secret Sets and exact authorized runtime bindings.

Example: It projects approved values into a Service Cell generation without returning them to the agent.

Read more: Services. Related guides: Run and test applications.

Secret Runtime Binding

Authorization connecting an exact Secret Set, eligible runtime generation, Run Target, revision, projection, scope, approval, and lifetime.

Example: Replacing the service requires a fresh valid binding.

Read more: Services. Related guides: Run and test applications, Limits, recovery, and cleanup.

Cella Data Volume

Aliases: Data Volume.

Cella-managed persistent mutable service storage with its own identity and lifecycle, independent of source revisions and agent workspaces.

Example: Replacing backend code does not silently replace its database volume.

Read more: Data. Related guides: Run and test applications, Limits, recovery, and cleanup, Bring existing services into Cella.

Data Snapshot

An immutable point-in-time data object with identity and integrity metadata, created using an appropriate consistent snapshot or export procedure.

Example: A database-native snapshot becomes input to bounded analysis.

Read more: Data. Related guides: Run and test applications, Bring existing services into Cella.

Data Grant

Exact read-only authorization for a specified data snapshot, recipient Cell, scope, limits, and expiry. It is not general mount authority.

Example: An Analysis Job Cell reads the approved snapshot instead of the live database file.

Read more: Data. Related guides: Run and test applications.

Object Transfer

Digest-verified ingress and export of repositories, snapshot descriptors, and bounded results. Callers do not select arbitrary host paths.

Example: An artifact crosses a boundary by object identity and verified digest.

Read more: Data. Related guides: Run and test applications, Private repository workflow, Checks and build outputs.

Cella Service Adoption

Aliases: Service Adoption, Cella Adopt, Adopt.

The planned migration transaction that discovers, approves, quiesces, imports, starts, and verifies an existing service under Cella. It claims no retroactive containment.

Example: A systemd service moves to a sealed Service Cell after an approved plan.

Read more: Bring existing services into Cella. Related guides: Bring existing services into Cella.

Adoption Plan

The exact reviewed migration object binding source facts, runtime, data, secrets, downtime, validation, cutover, and rollback limits.

Example: Inferred routes and mounts are proposals until the plan is authorized.

Read more: Bring existing services into Cella. Related guides: Bring existing services into Cella.

Quiescing

Stopping or coordinating writes so a service can produce a consistent migration snapshot. Databases may need their own flush or backup procedure.

Example: The source database stops writes before its state is copied.

Read more: Bring existing services into Cella. Related guides: Bring existing services into Cella.

Cutover

The explicit transition to the new managed service after required verification. Once it accepts writes, rollback may require data reconciliation.

Example: Cella does not promise automatic lossless rollback after new database writes.

Read more: Bring existing services into Cella. Related guides: Bring existing services into Cella.

Work and continuity

Workstream

The durable identity and envelope for intended repository work, including Runs, candidates, checkpoints, decisions, approvals, budgets, and final disposition.

Example: A backend repair survives an agent pause and a later handoff.

Read more: Workflow. Related guides: Tasks and execution history, Save and resume work.

Run

Aliases: Execution Attempt.

One immutable bounded attempt under exact generation, adapter or job definition, inputs, policy, budget, and result lineage. A Run is not a Workstream, shell command, CLI invocation, or Run Target.

Example: Resuming from a checkpoint creates a child Run instead of rewriting the parent.

Read more: Workflow. Related guides: Tasks and execution history, Save and resume work, Agents and handoff.

Checkpoint

An immutable continuity object sealing eligible workspace state, declared task state, environment references, lineage, and evidence at an explicit boundary.

Example: A later Run restores files and task notes without claiming hidden reasoning was captured.

Read more: Workflow. Related guides: Save and resume work, Limits, recovery, and cleanup.

Work Journal

The declared task record: goals, constraints, decisions, outcomes, failures, remaining work, evidence links, and handoff notes. Agent-authored claims retain their source attribution.

Example: The next agent sees which tests failed and what remains.

Read more: Workflow. Related guides: Save and resume work, Agents and handoff.

Agent Adapter

A pinned lifecycle contract for a supported coding agent: start, input, output, interrupt, exit, metadata, and supported session or checkpoint behavior. It grants no enforcement authority.

Example: A Claude adapter and a Codex adapter share Cella policy while retaining explicit differences.

Read more: Agents and handoff. Related guides: Agents and handoff.

Handoff

Starting a new Run with explicit checkpoint and Work Journal context while preserving policy, lineage, and prior evidence.

Example: Claude continues Codex's candidate using files and declared notes, not transferred chain-of-thought.

Read more: Agents and handoff. Related guides: Save and resume work, Agents and handoff.

Fork

Creating a child candidate at an explicit divergence point with independent workspace, budget, and result lineage.

Example: Two alternatives start from one pinned base without sharing writable state.

Read more: Compare candidate changes. Related guides: Save and resume work, Compare candidate changes.

Ephemeral Workstream

Aliases: ephemeral.

A one-Run lifecycle using the full authority contract, with runtime and workspace destruction at the configured boundary unless explicitly retained.

Example: A short review is disposable without bypassing policy or evidence.

Read more: Tasks and execution history. Related guides: Tasks and execution history, Limits, recovery, and cleanup.

Retained Continuity

Aliases: retained.

Explicit preservation of eligible checkpoints and declared task state for later work. Workspace, continuity, and evidence retention remain separate decisions.

Example: A task checkpoint can be retained while other runtime artifacts are deleted.

Read more: Limits, recovery, and cleanup. Related guides: Tasks and execution history, Save and resume work, Limits, recovery, and cleanup.

Provider Session Reference

An encrypted opaque native-session reference when an adapter supports it. It is a same-provider optimization, not portable hidden model state.

Example: A supported native resume can coexist with a cross-provider Work Journal.

Read more: Save and resume work. Related guides: Save and resume work, Agents and handoff.

Repository Continuity Index

A derived governed index of provenance-linked accepted setup facts, recurring failures, corrections, policy decisions, and reviews. Stale, conflicting, revoked, or deleted history is excluded.

Example: A later task uses accepted setup context without pooling private customer code.

Read more: Repository knowledge. Related guides: Repository knowledge.

Repository results and human control

Repository Ingress

Aliases: Repository Transaction Service.

Reviewing and importing a pinned local or remote repository view into private Cella storage, rejecting secrets and unsafe filesystem objects before execution.

Example: A dirty local overlay enters only after an explicit provenance-bearing preview.

Read more: Private repository workflow. Related guides: Private repository workflow.

Repository Object

An immutable named source with repository identity, pinned base, reviewed overlay, ingress manifest, policy, and delivery scope.

Example: Two imported repositories retain separate identities and authority scopes.

Read more: Private repository workflow. Related guides: Private repository workflow.

Candidate

An agent-produced repository result for checking, review, comparison, selection, or rejection before deliberate delivery.

Example: A candidate patch does not silently overwrite the host checkout.

Read more: Compare candidate changes. Related guides: Private repository workflow, Compare candidate changes.

Check Definition

Aliases: Check Profile.

A versioned exact check contract binding commands, runtime, inputs, environment, services, budgets, expected outputs, and required status.

Example: Compared candidates use the same declared test profile.

Read more: Checks and build outputs. Related guides: Checks and build outputs.

Check Result

Aliases: Check Receipt.

An immutable check outcome bound to definition, candidate, Run, environment, artifacts, and evidence. Reruns preserve earlier failures.

Example: Missing required test receipts block sealing or proposal.

Read more: Checks and build outputs. Related guides: Checks and build outputs, Review and verify changes.

Repository Delivery

The governed workflow for selected output: previewed local apply or exact external commit, push, issue, or pull-request Effects.

Example: Only the selected candidate digest proceeds to a proposal.

Read more: Private repository workflow. Related guides: Private repository workflow, Approvals and external actions, Review and verify changes.

Artifact

An immutable bounded classified output with provenance, such as a report, binary, check result, or analysis summary.

Example: An analysis report identifies the input snapshot and producing Run.

Read more: Data. Related guides: Run and test applications, Checks and build outputs.

Artifact Grant

Exact permission for a recipient to read a named artifact within scope and expiry, without gaining access to the producer's storage.

Example: The agent reads the approved summary rather than browsing service data.

Read more: Data. Related guides: Run and test applications, Checks and build outputs.

Intervention

An accountable operator input, attachment, interruption, decision, or responsibility handoff bound to identity and exact state.

Example: A human terminal takeover appears in evidence.

Read more: Supervise agent work. Related guides: Supervise agent work, Remote control with Cella Link.

Input Lease

The renewable authority to send interactive input. Other enrolled observers do not silently acquire terminal control.

Example: An observer waits for an explicit policy-governed transfer of input.

Read more: Remote control with Cella Link. Related guides: Supervise agent work, Remote control with Cella Link.

Change Capsule

Aliases: Capsule.

A signed proposal binding selected patch and base, checks, policy, approvals, evidence, protected Effects, provenance, and explicit gaps.

Example: The approval and test result must refer to the same patch being delivered.

Read more: Evidence. Related guides: Review and verify changes.

Capsule Verifier

Aliases: Merge Verifier.

The open verifier for Capsule identity, signatures, checks, policy, lineage, approvals, and current merge conditions. It rejects stale, altered, incomplete, or unauthorized proposals.

Example: A required merge check can verify a Capsule without a Cloud account.

Read more: Evidence. Related guides: Review and verify changes, Run Cella yourself.

Evidence and lifecycle

Cella Evidence

Aliases: Evidence.

Attributable records of admitted inputs, authority, observations, decisions, checks, lifecycle, interventions, Effects, and consequences, with explicit coverage limits.

Example: A denial identifies what was refused without inventing hidden reasoning.

Read more: Evidence. Related guides: Activity and evidence.

Evidence Event

One immutable attributable fact or explicit gap bound to actor, producer, Run, Cell generation, sequence, policy, and relevant digests.

Example: A Channel request records its exact caller and destination.

Read more: Evidence. Related guides: Activity and evidence.

Evidence Stream

An ordered hash-linked history under an exact stream identity and producer role.

Example: A verifier checks ordering and continuity instead of treating isolated lines as complete proof.

Read more: Evidence. Related guides: Activity and evidence.

Evidence Ledger

The durable store preserving ordered events and integrity continuity under retention rules.

Example: An incident review follows the task's recorded boundary events.

Read more: Evidence. Related guides: Activity and evidence.

Evidence Signer

A role-scoped integrity boundary authenticating records for its defined producer responsibility. Signing does not make unobserved claims true.

Example: A runtime signer cannot attest to an external business fact it did not observe.

Read more: Evidence. Related guides: Activity and evidence.

Evidence Verifier

The verifier for required signatures, schemas, hashes, identity, ordering, policy, completeness, expiry, and revocation for a stated claim.

Example: A missing observation remains a gap even when available signatures are valid.

Read more: Evidence. Related guides: Activity and evidence, Review and verify changes.

Receipt

An attributable terminal result of one bounded operation, linking request identity, outcome, result digest, and evidence references.

Example: An Effect receipt reports provider outcome and redactions.

Read more: Evidence. Related guides: External access and credentials, Activity and evidence, Approvals and external actions.

Attestation

A signed defined claim about an exact subject, contract, evidence references, producer role, and explicit gaps.

Example: An attestation states which generation and controls were checked.

Read more: Evidence. Related guides: Agent isolation, Activity and evidence.

Evidence Coverage

Aliases: Evidence Gap.

The distinction between mediated, observed, provider-reported, user-asserted, and unavailable signals. Attribution does not imply complete internal shell visibility.

Example: An agent's completion claim is provider-reported until required checks substantiate it.

Read more: Activity and evidence. Related guides: Activity and evidence.

Provenance

The recorded origin and lineage of inputs, results, decisions, state, and evidence.

Example: A synthesis candidate identifies its contributing candidates and checks.

Read more: Evidence. Related guides: Private repository workflow, Compare candidate changes, Activity and evidence, Repository knowledge.

Digest

A cryptographic identity for exact content or canonical semantics, used to bind requests, candidates, policy, results, and approvals.

Example: A changed candidate digest invalidates approval of the prior candidate.

Read more: Evidence. Related guides: Permissions and policy, Approvals and external actions, Review and verify changes.

Quarantine

A refusal or restricted state used when the required boundary cannot be established or runtime state is uncertain. It is not a successful protected admission.

Example: An unverifiable runtime is reported explicitly instead of silently downgraded.

Read more: Wall. Related guides: Agent isolation, Limits, recovery, and cleanup, Organization controls.

Revocation

Removing scoped authority so disabled Connections, expired Channels, stale leases, or stopped generations cannot keep acting.

Example: Stopping a Cell revokes its grants before teardown.

Read more: Limits, recovery, and cleanup. Related guides: Agent isolation, External access and credentials, Run and test applications, Limits, recovery, and cleanup, Organization controls.

Verified Deletion

Policy-governed removal of private retained artifacts with attributable evidence of the defined deletion boundary.

Example: Deleting a candidate does not corrupt shared immutable repository objects.

Read more: Limits, recovery, and cleanup. Related guides: Private repository workflow, Limits, recovery, and cleanup.

Installation and organization

Cella Installation

Aliases: Installation.

One locally authoritative deployment and trust domain, binding enrolled components, identities, runtime ownership, trust epoch, and evidence roots.

Example: A remote device selects one installation but cannot substitute its local authority components.

Read more: Link. Related guides: Run Cella yourself, Organization controls, Operations and integrations, Remote control with Cella Link.

Cella Context

Aliases: Context.

Saved safe CLI addressing and display configuration selecting a local or remote installation. Selection itself grants no authority.

Example: A context points to Virtus while Link enrollment authorizes the operator.

Read more: Link. Related guides: Remote control with Cella Link.

Controller Device Identity

Aliases: Device Identity.

A distinct revocable identity binding remote intent to an enrolled accountable device.

Example: Revoking a laptop's device identity blocks its later remote requests.

Read more: Link. Related guides: Remote control with Cella Link.

Aliases: Link.

The authenticated relationship and typed intent path from an enrolled controller to a target installation's authoritative cellad. It works over an explicitly provided private route without requiring Cloud.

Example: An enrolled Mac supervises a Virtus Workstream without direct Wall access.

Read more: Link. Related guides: Remote control with Cella Link.

Cella Organization

Aliases: Organization.

The governance scope for principals, Projects, baselines, Connections, approvals, retention, evidence, billing, and emergency controls.

Example: An organization-wide Connection disable applies across enrolled workers.

Read more: Organization controls. Related guides: Cella Cloud, Organization controls.

Cella Project

Aliases: Project.

The resource and governance scope grouping repository identity, policy, targets, Workstreams, Services, Connections, retention, and authorized principals.

Example: A Project owns the approved backend test target.

Read more: Run and test applications. Related guides: Run and test applications, Permissions and policy, Organization controls.

Enrollment

Explicitly authorized binding of a component, installation, repository, operator, or device identity to its governed trust scope. Reachability alone is not authorization.

Example: A process with network access cannot call Wall unless it is the enrolled controller.

Read more: Link. Related guides: Agent isolation, Organization controls, Remote control with Cella Link.

Cella Engine

Aliases: Engine, Local Engine.

The intended open-source account-free local trust loop, including the same security-critical contracts, open formats, and verification as Cloud.

Example: Local policy and verification do not depend on purchasing hosted governance.

Read more: Run Cella yourself. Related guides: Run Cella yourself.

Cella Cloud

Aliases: Cloud.

The planned organization authority plane over enrolled Cells wherever they run, for policy, Connections, exact approvals, fleet control, continuity, and durable evidence. Local enforcement remains authoritative.

Example: Cells may run on-premises while the organization governs their allowed Effects.

Read more: Cella Cloud. Related guides: Cella Cloud, Organization controls.

Dedicated Worker

Optional customer-scoped managed execution placement using the same Engine and authority contracts. Managed compute is a placement option, not the definition of Cloud.

Example: An organization places work on a dedicated worker rather than a developer machine.

Read more: Cella Cloud. Related guides: Cella Cloud.

Release Trust Root

The installation's trusted release-verification material defining which signed runtime manifests and release artifacts it accepts.

Example: A downloaded binary digest alone does not establish signed release authorization.

Read more: Operations and integrations. Related guides: Run Cella yourself, Operations and integrations.

Trust Epoch

The versioned trust context used to reject stale or rolled-back authority material across changes such as rotation and revocation.

Example: Old policy or credentials do not remain valid merely because their original signature verifies.

Read more: Organization controls. Related guides: Organization controls, Operations and integrations.

Drift Detection

Comparing admitted or desired configuration with observed fleet or runtime facts and reporting mismatches for governed remediation.

Example: An organization detects an installation diverging from its policy baseline.

Read more: Organization controls. Related guides: Organization controls, Operations and integrations.

OIDC and SSO

Aliases: OIDC, SSO.

Organization authentication mechanisms for accountable principals. Authentication does not replace Cella's exact policy and approval checks.

Example: A signed-in operator still needs the role and scope required for an approval.

Read more: Organization controls. Related guides: Organization controls.

Supporting modules and stores

These describe internal responsibilities rather than separate required daemons.

CLI Control API

Carries authenticated user intent between the CLI and cellad. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Receives intent from an enrolled remote controller. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Workstream Manager

Maintains the task's identity, candidates, and lifecycle. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Cell Registry

Retains Cell Records, immutable generation manifests, and sanitized status references. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Continuity Store

Retains checkpoints, declared task state, lineage, and recovery information. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Agent Adapter Registry

Maps supported agents to pinned runtime inputs and lifecycle definitions. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Approval Coordinator

Binds an approval to an exact request, actor, scope, and expiry. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

State Reconciler

Compares desired state with observed runtime and Effect state after interruptions. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Wall Control API

Carries a closed, authenticated vocabulary from cellad to Wall. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Wall Profile Store

Holds installed immutable enforcement profiles and allowed runtime inputs. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Wall Runtime Adapter

Converts admitted profiles into fixed runtime operations. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Wall Storage Adapter

Creates private storage, enforces quotas, and manages snapshots and verified deletion. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Wall Network Adapter

Applies and inspects the admitted network topology. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Wall Resource Adapter

Enforces CPU, memory, process, time, and related limits. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Generation Inspector

Checks the actual execution boundary against the admitted controls. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Runtime Interval Recorder

Measures verified running intervals and lifecycle timestamps. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Lifecycle Receipt Emitter

Records ordered facts about privileged operations and failures. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Run Target Registry

Stores approved commands, runtime inputs, bindings, and launch limits. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Workspace Object Store

Holds repository objects, private workspaces, checkpoints, and candidate outputs. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Checkpoint Manager

Seals declared state and verified object references at an explicit boundary. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Change Capsule Builder

Binds the selected patch to its checks, policy, approval, and evidence. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Evidence Execution Recorder

Records observable execution facts, results, resource events, and explicit gaps. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Setup and Upgrade Controller

Plans explicit installation, verification, activation, rollback, and removal transactions. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Image and Profile Store

Retains verified immutable installation inputs. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Conformance Harness

Tests a runtime combination against required isolation, failure, cleanup, and drift behavior. This is a responsibility within Cella’s component model.

Read more: Supporting modules and stores.

Runtime and transport terminology

Sandbox

An isolated execution environment with admitted workspace, tools, resources, and access. In Cella, the managed Cell carries identity, policy, lifecycle, and evidence around that execution boundary; the sandbox backend is replaceable.

Read more: Wall and isolation. Related guides: Agent isolation.

gVisor

Aliases: runsc.

The initial Linux isolation backend target. Its user-space kernel and runsc runtime are infrastructure beneath Wall, not the identity of Cella. An exact runtime profile still needs qualification before a protected claim.

Read more: Wall and isolation and runtime substrate.

containerd

A container runtime service in the initial pinned Linux substrate. Agents do not receive its privileged socket; Wall mediates the installed runtime interface.

Read more: Runtime substrate.

Control Plane

The authenticated paths that coordinate intent, policy, lifecycle, and authority. Only enrolled cellad invokes the authority-component control methods; Cell traffic does not become control-plane access.

Read more: Component architecture.

Data Plane

The provisioned paths that carry permitted workload data, such as Channel traffic. Data-plane identity and access are distinct from permission to administer Relay or another authority component.

Read more: Channels and Relay.

mTLS

Mutual TLS: both peers authenticate with certificates. Cella binds authentication to enrolled identities and exact component roles; an authenticated peer still needs authorization for each method.

Read more: Component transport authentication. Related guides: Agent isolation, Remote control with Cella Link.

ALPN

Application-Layer Protocol Negotiation in TLS. The control contract checks the exact service protocol so a valid credential cannot silently cross into another component's service.

Read more: Component transport authentication.

SO_PEERCRED

The Linux Unix-socket peer-credential check used to inspect the connecting process's operating-system identity. It is one part of admission alongside fixed socket ownership, enrolled mTLS identity, protocol, and controller lease.

Read more: Component transport authentication. Related guides: Agent isolation.

cgroup

Linux resource accounting and enforcement used in the runtime contract for bounded CPU, memory, processes, and I/O. Limits and their enforcement results must be inspectable for the admitted generation.

Read more: Cell Wall requirements.

UID

The operating-system user identifier. The intended Agent Cell runs under a non-root identity; that restriction is one part of the broader containment contract.

Read more: Cell Wall requirements.

Read-only rootfs

A runtime root filesystem that the workload cannot modify. The private admitted workspace and bounded temporary storage are separate from this read-only system input.

Read more: Cell Wall requirements.

no-new-privileges

A Linux process restriction preventing execution from gaining additional privileges. It complements dropped process capabilities and the other mandatory Cell controls.

Read more: Cell Wall requirements.

SLO

A service-level objective: a stated operational reliability or performance target. Targets require measurement and failure reporting; they are not claims that the incomplete product already meets them.

Read more: Operations and economics.

Key Rotation

Governed replacement of signing, device, component, or provider key material, with identity, version, trust, and revocation handling. Different key roles remain in their owning boundaries.

Read more: Operations and economics and evidence signing.

Supply-chain Controls

Verification of release provenance, pinned artifacts, signatures, digests, and compatible runtime inputs through the installation lifecycle. A matching hash identifies bytes but does not alone establish trusted release authorization.

Read more: Operations and economics.

Retention

Policy defining which workspace, continuity, evidence, or service data remains and for how long. These dimensions are independent; stopping execution is not equivalent to deleting every retained record.

Read more: Lifecycle and retention.

Portable Export

A versioned, attributable export of permitted work and evidence objects using open formats and verified identities. It does not grant raw access to installation state, secrets, or private storage.

Read more: Operations and portability.

Source contracts

Source: docs/concepts/glossary.md · Current feature milestones