> ## Documentation Index > Fetch the complete documentation index at: https://docs.kentron.ai/llms.txt > Use this file to discover all available pages before exploring further. # Factory concepts and configuration > The objective, task, candidate, job and check vocabulary, the promotion gate, the single execution path, and every key the Factory config loader actually reads. Factory is the engine behind Receipt's [background runs](/co-worker/background-runs). Give it a written goal and it breaks the goal into tasks, runs each one inside a disposable sandbox computer, integrates the results on an integration branch, and records the run as receipts you can replay afterwards. This page defines the vocabulary you see in the CLI's output and the configuration file that shapes a run. [The command reference](/cli/from-source/factory-reference) covers how to drive it. **Factory is reachable only from the in-repo developer CLI.** `receipt factory` requires a Receipt checkout, Bun and Postgres, and is absent from the released `receipt` binary. See [The developer CLI](/cli/from-source/overview) for the difference between the two programs named `receipt`. ## Objective An objective is the top unit of Factory work: a durable, receipt-backed goal. Its receipts live on the stream `factory/objectives/`, and its id starts with `objective_`. Commands accept either the bare id or the full stream name. An objective carries twelve statuses: `planning`, `waiting_for_slot`, `collecting_evidence`, `evidence_ready`, `synthesizing`, `executing`, `integrating`, `promoting`, `completed`, `blocked`, `failed`, `canceled` `completed`, `failed` and `canceled` are terminal. `blocked` also stops an objective, but it is deliberately kept out of the terminal set because an operator receipt can unblock or redirect it during replay. These are the transitions the objective reducer actually performs: ```mermaid theme={null} stateDiagram-v2 [*] --> planning planning --> waiting_for_slot: queued for the repo slot waiting_for_slot --> executing: a task run starts executing --> synthesizing: synthesis is dispatched synthesizing --> completed: investigation objectives end here synthesizing --> integrating: a task is integrated integrating --> promoting: integration reports ready_to_promote promoting --> completed: the promoted result is published executing --> blocked executing --> failed executing --> canceled completed --> [*] blocked --> [*] failed --> [*] canceled --> [*] ``` `blocked`, `failed` and `canceled` are reachable from any running status, not only from `executing`. Two of the twelve declared statuses — `collecting_evidence` and `evidence_ready` — are accepted everywhere an objective status is read but are never assigned to an objective by the reducer in this release; they surface as the task execution phase and as the objective's phase detail instead. Alongside the status the CLI surfaces two further vocabularies. **Display state**, the coarse label: `Draft`, `Queued`, `Running`, `Awaiting Review`, `Stalled`, `Blocked`, `Completed`, `Archived`, `Failed`, `Canceled` **Phase detail**, the finer one: `draft`, `waiting_for_slot`, `waiting_for_computer_lease`, `waiting_for_control`, `waiting_for_synthesis`, `waiting_for_promotion`, `collecting_evidence`, `evidence_ready`, `synthesizing`, `integrating`, `promoting`, `cleaning_up`, `awaiting_review`, `stalled`, `completed`, `blocked`, `failed`, `canceled`, `archived` The display state and the phase detail appear together in the header the CLI prints for an objective, alongside the status authority and the slot state: ``` state= · · authority: slot=[ q=] ``` Each phase also carries a fixed label and a fixed one-line summary, which the CLI prints as `status=