Launched, claimed and unmanaged work

Fleet Console distinguishes work the controller launched from work it merely knows about. A row in the registry is not sufficient evidence of signalling authority.

Three management classes

Class	How the record arises	Controller control
Controller-launched	A new process starts through fleetctl launch	Verified service-control actions and lease cleanup
Claimed	An existing process is recorded with fleetctl claim	Observation and attribution, not signalling
Unmanaged	Work was started outside controller supervision	No controller stop, restart, pause or kill

A claim adds an owner, purpose, lease and event timeline. It does not transform an already-running process into one the controller started. An expired claim is reported and left alone rather than reaped. Output from a claimed process still goes where it was originally launched; claiming cannot retroactively capture its stdout or stderr.

Inspect without changing ownership

With the bundled CLI on PATH, inspect the current inventory and its recorded grouping:

fleetctl list --json
fleetctl agents --json

Review output locally before sharing it: commands, paths, ports and agent names can identify private work. An agent label reports who requested or was assigned the work; it does not prove that the human owner approved a disruptive action.

Why PID identity matters

A PID can be recycled after a process exits. Before signalling controller-launched work, the controller verifies the PID, recorded start time and process group. A refusal is not an invitation to bypass the guard with a raw signal. Reinspect the current process and service record instead.

The CLI documentation explains why claiming buys visibility without authority. Use service logs to review what the controller actually recorded.