> ## 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. # AI-DLC artifacts > Learn what each AI-DLC artifact means, how targeting works, and what Construction produces while executing a bolt. # AI-DLC artifacts AI-DLC works because every meaningful step becomes an explicit artifact. ## Artifact reference | Artifact | Phase | Parent | Role | What you read it for | | --------------------- | ------------ | -------- | ----------------------- | ---------------------------------------------------------- | | `intent` | inception | none | planning root | The overall objective and success criteria | | `unit` | inception | `intent` | planning decomposition | A buildable slice of the intent | | `story` | inception | `unit` | planning requirement | A user-facing requirement or behavior | | `bolt` | construction | `unit` | planned execution batch | A grouped set of related stories to implement together | | `domain_design` | construction | `bolt` | design output | Domain model and business concepts | | `logical_design` | construction | `bolt` | design output | Architecture, interfaces, ADRs, and technical design | | `system_context` | construction | `bolt` | design output | System boundaries, dependencies, and environmental context | | `implementation_plan` | construction | `bolt` | execution prep | The concrete implementation strategy for the bolt | | `test_report` | construction | `bolt` | execution output | What was verified and whether it passed | | `walkthrough` | construction | `bolt` | execution output | What changed, why it changed, and what to review | | `deployment_unit` | operations | `bolt` | operations handoff | Deployment state, rollout evidence, and incidents | ## How targeting works AI-DLC separates planning scope from execution tracking. ### Planning artifacts Planning artifacts can use Fabriqa's built-in targeting fields: * `target_scope` * `target_workspace_project_ids` Workflow-authored schemas do not need to redefine those fields. Use them to say whether the plan applies to the whole workspace or to specific workspace projects. Typical pattern: * `intent` may stay workspace-level when it spans several projects. * `unit`, `story`, and especially `bolt` usually become project-targeted so Construction runs against an explicit build context. Recommended semantics: * `target_scope: workspace` * the artifact applies to the workspace as a whole * do not populate `target_workspace_project_ids` * `target_scope: workspace_project` * the artifact applies to one or more workspace projects * populate `target_workspace_project_ids` Use IDs as the canonical stored value. Project names should be resolved from workspace metadata instead of duplicated into artifact payloads. AI-DLC keeps workspace-wide targeting on purpose. Why: * Inception can start from a cross-project objective before planning narrows into project-specific units, stories, and bolts. * Some artifacts are genuinely workspace-wide, especially root intent, migration planning, and shared platform direction. ### Execution artifacts Execution artifacts can record: * `touched_workspace_project_ids` This is also a built-in Fabriqa field, so workflow-authored schemas do not need to redefine it. Typical pattern: * `bolt` says where the work is intended to happen. * `walkthrough` and `test_report` say what was actually touched. ### Why this split matters It gives you: * honest execution reporting * better multi-project visibility * safer handoff to linked worktrees or project-specific execution sessions ## What Construction creates while running a bolt Construction is the execution agent for AI-DLC. Its prompt decides when these artifacts are needed, but the DSL makes the contracts explicit. ### Design outputs These are bolt-scoped artifacts that help Construction think and help you review: * `domain_design` * `logical_design` * `system_context` * `implementation_plan` These should read like documents. Good examples: * markdown summaries * architectural rationale * implementation strategy * tradeoff notes Bad examples: * giant nested object arrays used as the main reading experience ### Execution outputs These are the primary execution-output artifacts for completed work: * `walkthrough` * `test_report` These are the artifacts you should expect to read before you trust the result. ## What to review before trusting Construction output Before you approve a bolt outcome, read: 1. the bolt itself for scope and grouped stories 2. `domain_design` and `logical_design` if the bolt changed the model or architecture 3. `walkthrough` for the implementation narrative 4. `test_report` for verification results 5. `deployment_unit` if the bolt changed deployable behavior ## Continue reading Go back to the user journey across planning, execution, and handoff. Continue into the target built-in definition shape. Compare AI-DLC artifacts with the general artifact schema reference. Review the terms used for lifecycle, document semantics, targeting, and execution tracking.