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.
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.
Cella Link Endpoint
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