Enums

Version: 4.6.0

AdapterSharingMode

Whether and to whom an adapter lends its process as a leasable pool member (AB#4924). NotShared (default) keeps the adapter private to its own tenant — the behaviour of every adapter in the estate today. Descendants lends to any descendant of the owning tenant, direct or indirect, resolved by the same breadth-first tenant walk as GET {tenantId}/v1/tenants/descendants (AB#5151). DescendantsAndSiblings additionally lends to tenants that share the owning tenant's parent. In every mode the optional LendingAllowedTenantIds allow-list narrows the resolved set further; it never widens it, so a tenant outside the subtree can not be granted a lease by listing it.

ID	Values	Descriptions
0	NotShared
1	Descendants
2	DescendantsAndSiblings

CommunicationState

Indicates the current SignalR connection state of an adapter or pool operator.

ID	Values	Descriptions
0	Unregistered
1	Online
2	Offline

ConfigurationState

Indicates whether a deployable entity has been successfully configured with its pipeline definitions and settings.

ID	Values	Descriptions
0	Unconfigured
1	Pending
2	Configured
3	Error

DeploymentState

Tracks whether a deployable entity (adapter, application, pipeline, pool, or trigger) is currently deployed and active. Disabled means the entity cannot be deployed at all: Edge pools (no central operator CR), workloads missing Helm chart/version/repository, or pipelines/triggers whose adapter is Disabled. Deploy/Undeploy actions are rejected on Disabled entities.

ID	Values	Descriptions
0	Undeployed
1	Pending
2	Deployed
3	Error
4	Disabled

Environment

Where a pool's adapter workloads are hosted. Cloud pools are auto-deployed by the central Communication Operator into the OctoMesh cluster; Edge pools must be installed and run by an external operator outside the central cluster.

ID	Values	Descriptions
0	Edge
1	Cloud

HelmChannel

Distribution channel of a Helm chart repository. Used as a label so the UI can colour-code dev vs release sources; the operator does not derive behavior from this value.

ID	Values	Descriptions
0	Dev
1	Release

HelmRepositoryPurpose

Which kind of chart a Helm repository serves. Adapters covers adapter and platform charts, Applications covers tenant-app charts. Used by the Communication Controller to pick a repository for a workload that carries no explicit HelmRepository association; never a label only.

ID	Values	Descriptions
0	Adapters
1	Applications

LifecycleMode

Author-configured lifecycle policy of a deployable workload. AlwaysOn (default) keeps the workload running permanently. OnDemand lets the controller scale it to 0 replicas when idle and wake it on demand (AB#4914); only valid for workloads whose deployed pipelines use exclusively wake-capable triggers. Auto is reserved for a future controller-decided mode and is rejected by validation until implemented. Leased (AB#4924) means the workload has no process of its own at all: its pipelines execute on an AdapterPool lent by an ancestor or sibling tenant, one lease per work item — see the LentFrom association to a LentAdapterPool mirror (AB#5271) and docs/concepts/shared-adapter-leasing.md. Leased is the BORROWER's mode and only ever that; an AdapterPool is its own workload type with a replica range and is not itself Leased.

ID	Values	Descriptions
0	AlwaysOn
1	OnDemand
2	Auto
3	Leased

LifecycleState

Runtime lifecycle state of an OnDemand workload (AB#4914). Running: normal operation. Draining: idle timeout reached, scale-to-0 requested. Hibernated: scaled to 0 replicas on purpose — CommunicationState=Offline is expected and must not raise alarms. Waking: a demand signal triggered scale-to-1; consumers wait for ConfigurationState=Configured. AlwaysOn workloads stay Running permanently.

ID	Values	Descriptions
0	Running
1	Draining
2	Hibernated
3	Waking

PipelineExecutionClass

Scheduling class of a pipeline on a leased adapter pool (AB#4924), resolved from the pipeline's trigger node when the pipeline is SAVED and persisted here — not parsed from the YAML at dequeue time, so the scheduler reads a field and the Studio / octo-cli / MCP surfaces can show WHY a job sits where it does. Interactive is work a human is waiting for (HTTP request, manual run, Studio "execute now"). Batch is everything scheduled or event-driven. Within one tenant's turn in the round-robin rotation, Interactive is served before Batch; across tenants the class has no effect whatsoever. Mirrors OnDemandCapable: computed, persisted for display, and re-resolved whenever the pipeline is saved — so a pipeline edited to a different trigger changes class visibly, as a change, rather than as behaviour that quietly shifts.

ID	Values	Descriptions
0	Interactive
1	Batch

PipelineExecutionStatus

Status of a pipeline execution lifecycle, from queued or running through completion or failure. Queued (AB#4924) precedes Running on a Leased workload: the execution entity exists from the moment the work item is enqueued, so one execution stays one entity from enqueue to completion and the Studio renders a continuous history instead of joining a queue and an execution source.

ID	Values	Descriptions
0	Running
1	Completed
2	Failed
3	Interrupted
4	Cancelled
5	Queued

PipelineTriggerType

Indicates how a pipeline execution was initiated.

ID	Values	Descriptions
0	Manual
1	Scheduled
2	Event
3	Startup

PoolScaleUpPolicy

Which queue signal makes an adapter pool start another member (AB#4924). QueueDepth scales when the number of work items waiting for a lease crosses ScaleUpQueueDepthThreshold. QueueWaitSeconds scales when the oldest waiting item has waited longer than ScaleUpQueueWaitSeconds. QueueDepthOrWaitSeconds (default) scales on whichever fires first, which is the behaviour a pool wants in practice: depth catches a burst, wait time catches a slow trickle behind one long-running lease. CPU-based scaling is deliberately absent — a member waiting for a lease is idle by construction.

ID	Values	Descriptions
0	QueueDepthOrWaitSeconds
1	QueueDepth
2	QueueWaitSeconds

SignalRegistrationAction

Audited action of a Signal channel registration attempt (AB#5143). Every register/verify/delete attempt against the tenant's SignalChannel — including failed ones — appends one entry with this action to the channel's RegistrationHistory. Adopted means the bridge already held a working account for the number, so register/verify were skipped and the definition went straight to Registered. ProfileUpdated records a display-name profile push (PUT /v1/profiles/{number}) — its detail carries the pushed name, the failure text for a rejected push on the displayName endpoint, or the cleared note (clearing never touches the bridge profile). Deleted is part of the audit vocabulary but a persisted Deleted entry never survives: a successful DELETE erases the definition including its history (fresh definition = fresh history); the system event trail still records the deletion.

ID	Values	Descriptions
0	RegisterRequested
1	RegisterFailed
2	CodeVerified
3	VerifyFailed
4	Deleted
5	DeleteFailed
6	Adopted
7	ProfileUpdated

SignalRegistrationState

Registration state of a tenant's Signal phone number against the Signal bridge (AB#5143). Unregistered means a definition exists but no registration was started (or a rate-limited attempt is pending retry). CodePending means the bridge accepted the register call and Signal sent an SMS verification code. Registered means the verify call succeeded and the number can send/receive. Failed means the last register attempt was rejected by the bridge (see LastError); a new register attempt is allowed.

ID	Values	Descriptions
0	Unregistered
1	CodePending
2	Registered
3	Failed