> ## Documentation Index > Fetch the complete documentation index at: https://docs.fabriqa.ai/llms.txt > Use this file to discover all available pages before exploring further. # Workflow glossary > Key terms used across Fabriqa workflow authoring and the built-in AI-DLC workflow. # Workflow glossary Use this page as a quick reference while reading the Workflow DSL and AI-DLC docs. ## Core terms ### Workflow A named, folder-based definition that tells Fabriqa how to structure planning, execution, artifact persistence, and workflow shell UI. ### Workflow file `workflow.yaml`, the orchestration envelope for a workflow. It defines phases, agents, artifact references, connector subscriptions, relations, and UI defaults. ### `ui.sidebar.allowed_group_by` The workflow-level sidebar grouping configuration. The workflow author selects a subset from Fabriqa's built-in grouping vocabulary, and Fabriqa uses `default` as the initial grouping shown in the sidebar. If `allowed_group_by` is omitted, Fabriqa shows all built-in grouping modes. ### Phase A broad lane of work such as planning, execution, or operations. Phases are coarse-grained. They are not meant to model every internal step inside an agent prompt. ### Artifact A first-class workflow object with identity, lifecycle, relationships, document semantics, and a validated payload. ### Artifact schema A YAML file that defines one artifact type, including: * artifact identity * parent requirement * lifecycle * schema block * document semantics ### Parent artifact The artifact that structurally owns another artifact. For example, a `walkthrough` may have a `run` or `bolt` parent depending on the workflow design. ### Built-in relation vocabulary Fabriqa's fixed set of graph relation labels: * `depends_on` * `implements` * `validates` * `supersedes` * `related_to` Workflows can use the full built-in set or declare an allowed subset in `workflow.yaml`. ### Lifecycle The state machine for a specific artifact type. Lifecycles describe artifact states such as draft, in review, approved, or verified. ## Document model terms ### Document-first artifact An artifact designed to read like a document instead of a form. The main body is built from markdown sections, while primitive metadata is inferred automatically. ### `document` The artifact schema block that defines document semantics for the artifact detail view. ### `document.sections` The main body of the artifact document. Sections usually point to one markdown field through `field`. ### Metadata field A field that is not claimed by `document.sections`, plus built-in system fields. Metadata fields support the main document body without becoming prose themselves. ### Tags A built-in string-array metadata field available on every artifact. Agents can attach tags for grouping, filtering, review, or later workflow behavior. ### Markdown section A section whose main field is a string rendered as markdown. This is the preferred pattern for artifact documents. ### Structured section A section that uses `fields` instead of a single `field` because it needs to display several primitive or list fields together. ## Agent and prompt terms ### SAF file A `.saf` JSON file that defines one workflow agent, its generic kind, its prompt file, and its tool access. SAF stays runtime-agnostic in V1. ### Prompt-driven flow The rule that agents decide sequencing through their prompts. The DSL describes contracts, but it does not auto-run planning or execution. ### Execution input An artifact that guides work to be done, such as a `bolt` or `work_item`. ### Execution output An artifact that records what was done, such as a `walkthrough` or `test_report`. ### Planning root The top-level planning artifact for a workflow tree, such as an `intent`. ### Root artifact viewer The product-defined deep-work surface that opens one root artifact context at a time and auto-selects the clicked child artifact inside that context. ### Context rail The slim right-side panel inside the root artifact viewer. It holds the artifact tree plus contextual lists such as relations, linked chats, and activity. ### Metadata row The compact row under the document title where Fabriqa shows small primitive metadata such as status, phase, targeting, or timestamps. ## Scope and targeting terms ### Workspace The top-level Fabriqa container that can include one or more attached projects. ### Workspace project An attached project or repo inside a workspace. Planning scope and execution tracking are often expressed in terms of workspace projects. ### `target_scope` A built-in Fabriqa planning target field. In the current DSL this should usually be either `workspace` or `workspace_project`. ### `target_workspace_project_ids` A built-in Fabriqa planning target field for the workspace projects an artifact is intended to affect when `target_scope` is `workspace_project`. Project names should be derived from workspace metadata rather than stored as duplicate artifact fields. ### `touched_workspace_project_ids` A built-in Fabriqa execution-tracking field for the workspace projects actually changed during execution. ## Connector and export terms ### Connector A product-defined integration kind that can project artifact content out of Fabriqa storage and into another surface, such as the filesystem or a future external platform. ### Connector config A workflow-owned file in `connectors/*.yaml` that maps workflow artifact types into a built-in Fabriqa connector kind. ### Workflow UI The optional `ui` block in `workflow.yaml` that controls workflow-level sidebar defaults. Dashboard and root artifact viewer behavior are product-defined in V1, and artifact schemas do not define their own UI block. ### File connector The built-in connector that writes artifacts into workspace-visible files using templates. ### Runtime connector settings Workspace-level connector settings managed by Fabriqa after a workflow is activated, such as enable or disable state, account selection, target workspace project selection, and sync behavior. ### Template A file usually used by the file connector to render an artifact into a markdown or text export. Templates are not the source of truth. ## AI-DLC terms ### Inception The AI-DLC planning phase that captures the overall intent and decomposes it into units, stories, and bolts. ### Construction The AI-DLC execution phase that works against a selected bolt and produces design and execution artifacts while implementing code. ### Operations The AI-DLC follow-up phase that records deployment state, verification, and incidents in operational artifacts. ### Intent The root artifact that captures the overall objective, constraints, and success criteria. ### Unit A meaningful, buildable decomposition of the intent. ### Story A user-facing requirement or behavior that belongs to a unit. ### Bolt A planned execution batch that groups related stories into one construction unit of work. ### Walkthrough An execution output artifact that explains what changed, why it changed, and what to review. ### Test report An execution output artifact that records verification results and evidence. ### Deployment unit An operations artifact that tracks deployment and rollout state after construction work. ## Related pages * [Workflow DSL](/workflows/workflow-dsl) * [Workflow file](/workflows/workflow-dsl-workflow-file) * [Artifact schemas](/workflows/workflow-dsl-artifact-schemas) * [AI-DLC workflow](/workflows/ai-dlc)