> For the complete documentation index, see [llms.txt](https://docs.darcyiq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.darcyiq.com/build/pipelines/deliverables-and-completion.md). # Deliverables & Completion Have a stage's agent write files as well as decide, then collect every document an approved item produced in one place Some review stages don't just say yes or no — their value *is* a document. A risk memo, a redline, a filled-in compliance checklist. With **Produces deliverables** switched on, the stage's agent writes files alongside its verdict, and an approved item gathers them all into one set. {% hint style="success" %} **A review chain that leaves a paper trail**: Finance's stage produces `margin-check.md`, Legal's produces `risk-memo.md`, and Security's produces a filled-in questionnaire. When the item is approved, the submitter gets all three in one list with a **Download all** — plus a written account of what each stage checked. {% endhint %} ## Turning On Deliverables Deliverables are a per-stage setting. In the stage editor, under **What this stage passes on**, switch on **Produces deliverables**. The switch says *that* the agent should write files — not *what* to write. Describe the artifact in the stage's **Requirements** or **Extra agent guidance**, which the agent already reads: | Instead of | Write | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------ | | "Produce a memo" | "Write a one-page risk memo as `risk-memo.md`, listing every exception you found and the clause it came from" | | "Fill in the checklist" | "Return the security questionnaire as `questionnaire.md`, answering every item and marking anything you couldn't verify" | {% hint style="info" %} **Name the file and say what goes in it.** There's deliberately no separate "what to produce" field — a third box would just be a second place to say the same thing, and the agent reads your requirements either way. {% endhint %} ## Where Deliverables Land | Where | What you get | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **On the review** | The files are attached to that stage's review, readable by anyone who can see the item — **the submitter included** | | **Even on a denial** | Files are collected whether the review approved or denied, so a half-finished draft or a memo explaining the denial isn't lost | | **Forwarded, if you choose** | With **Pass findings to later stages** on, later stages' agents get this stage's files too — quoted inline where they're text | | **In the Files tab** | Alongside the submitter's own attachments, per revision | Each file has a preview so you can read it in place, with download one click away. {% hint style="warning" %} **Deliverables is the wrong switch for a stage that only says yes or no.** An agent asked to produce a file when there's nothing to produce will produce something anyway. Use it where the document is the point. {% endhint %} ## The Completion View Once the last stage approves, the item becomes **Approved** and its Review tab turns into a record of the whole run: * **What happened across *****n***** stages** — a written summary of the run: what each stage checked, what had to be fixed along the way, and what was produced * **Every stage's deliverables in one list** — gathered across all stages, not buried in the review history, with **Download all** for the set as a zip * **The stages themselves** — still open-able for the individual verdicts and reasons So designing several stages to each produce one document is a reasonable thing to do: the submitter ends up with the set rather than a hunt. ### The Completion Summary The summary is generated **once**, when the item is approved, and stored on the item — so it reads the same for everyone and doesn't get re-narrated differently each time it's opened. It's built only from what the **submitter** can already see: the decision reasons, the stage owners' own words, the findings raised, and the files produced. The agent's private notes, its raw output, and its transcript are never part of it. {% hint style="info" %} **If the summary isn't there**, the completion view falls back to the last stage's own words, and each stage's review is still on the item. The summary is a convenience over the record, not a replacement for it. {% endhint %} ## Evidence Files Deliverables aren't the only files a review can accumulate. When a submitter works a findings checklist, they can attach **evidence** to a specific required change — the signed page, the corrected sheet. Evidence sits with the finding it settles, so a reviewer checking whether a change was made doesn't have to guess which file was for which point. See [Submitting & Revising Items](/build/pipelines/submitting-items.md). ## File Limits | Constraint | Limit | | -------------------------- | ----------------------------------------------------------- | | **Files per submission** | 10 | | **Size per file** | 25 MB | | **Evidence file size** | 25 MB | | **Deliverables per stage** | Written by the agent; described in the stage's requirements | Submitted files are placed on the reviewing agent's cloud computer rather than only quoted into its prompt, so a stage can genuinely open a document in full — including formats that text extraction can't handle, like a scanned PDF or a spreadsheet. ## Next Steps | Goal | Documentation | | --------------------------------------------- | ------------------------------------------------------------------- | | Configure the stage that produces the file | [Building a Pipeline](/build/pipelines/building-a-pipeline.md) | | Attach files to a submission | [Submitting & Revising Items](/build/pipelines/submitting-items.md) | | Read a review as the stage owner | [Reviewing & Deciding](/build/pipelines/reviewing-and-deciding.md) | | Pull an item's files through chat or an agent | [Pipelines with Darcy](/build/pipelines/pipelines-with-darcy.md) | | Store finished documents for the long term | [Artifact Vault](/organize/artifact-vault.md) | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.darcyiq.com/build/pipelines/deliverables-and-completion.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.