> 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/submitting-items.md). # Submitting & Revising Items Submit work to a pipeline, follow its review, and work through the required changes when a stage sends it back An **item** is one submission to a pipeline: a title, a summary, and the files a reviewer needs. It moves through the stages one at a time and comes back to you if any stage denies it. {% hint style="success" %} **Submit once, fix once**: You submit a renewal with the LOE attached. Legal returns it with two required changes — the liability cap and a missing signature page. You attach the signed page, tick both items off with a note on each, and send it back. Legal's agent is told what was previously asked for and checks specifically whether you did it. {% endhint %} ## Submitting an Item {% stepper %} {% step %} **Open the pipeline and click Submit item** You can also submit from the card on the **Pipelines** home page, which lets you pick the pipeline first. Only **active** pipelines accept submissions — a draft or archived pipeline says so on the form. {% endstep %} {% step %} **Read what you'll be judged on** The form shows the pipeline's intake instructions, then every stage in order with its owner and its requirements. This is the bar before you submit, not after. {% endstep %} {% step %} **Fill in the submission** A **Title** (required) — how the item appears on the board, e.g. "Acme Corp renewal — 3 year term" — a **Summary** giving each reviewer the context they need to make a call, and **Attachments** of up to 10 files at 25 MB each. {% endstep %} {% step %} **Submit** The first stage's review starts immediately. The item opens so you can watch it — a review is an agent call, so it takes a moment rather than answering instantly. {% endstep %} {% endstepper %} {% hint style="info" %} **Write the summary for the agents, not for the file list.** Each stage's agent reads your summary alongside that stage's requirements. "Three-year renewal at 12% uplift, existing paper, no scope change" tells every reviewer more than "renewal attached". {% endhint %} ## What You Can Attach A submission can carry three kinds of context, and every stage's agent is given all of them under their own headings — attached files, attached meetings, attached scope of work — alongside the prior stages' verdicts. | Attachment | What the reviewer gets | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | **Files** | Up to 10 files at 25 MB each. Documents are read in full on the agent's cloud computer, not just excerpted | | **Images** | Screenshots and photos are read for their content where possible, and stay available to the agent either way — useful as evidence of a problem | | **Meetings** | A [meeting's](/core-features/meeting-recording-and-transcription.md) summary and transcript, so a reviewer can see what was actually agreed | | **Scope of Work** | A [scoping estimate's](/grow/scoping-estimates.md) content, so a reviewer can check the ask against what was scoped | {% hint style="info" %} **Meetings and scopes are attached through Darcy or the API**, not the submission form, which covers the title, summary, and files. Ask Darcy to submit with a meeting or a scope attached — see [Pipelines with Darcy](/build/pipelines/pipelines-with-darcy.md). {% endhint %} ### Attached Context Stays Current A scope of work doesn't stop moving just because it's in review. So before each stage's agent runs, DarcyIQ re-reads the attached meetings and scopes from their source — the agent reviews the estimate **as it stands now**, not as it stood the day you submitted. * Every run re-checks, including a retried review, so you don't have to resubmit just to pick up an edit at the source * When the source has changed, the attachment is labelled **updated at the source since it was attached**, and the item's activity records that it moved * Each attachment also carries the revision it arrived in, so a reviewer can tell new context from context they've already seen The re-read is deliberately narrow: | Rule | Why it works this way | | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | It runs as the **person who attached it** | Refreshing can never show a reviewer something the submitter couldn't see themselves | | A deleted source, or one the submitter has lost access to, **keeps the version from submission** | Context never disappears mid-review; the attachment is labelled as showing what was submitted | | Reviewers still don't need their own access | The stored copy is what the review reads, whether it was captured at submission or refreshed since | | **Pricing is still left out** | Rates, totals, and custom fields are excluded on every re-read, so attaching a scope for review never circulates its commercials | ## Following Your Item Open any item to get three tabs: | Tab | What's in it | | ------------ | ---------------------------------------------------------------------------------------------------------------------- | | **Review** | Where the item stands: the current stage, the agent's verdict and reasons, and the required changes if it was returned | | **Files** | What you attached, per revision, plus any files the stages produced | | **Activity** | The event timeline — submitted, reviewed, decided, returned, resubmitted | The **Pipelines** home page keeps a **Returned to you** section, so you don't have to go looking for items that need your attention. ## When a Stage Returns Your Item A denial is not the end of the item. It comes back to you as **Returned**, carrying the reviewer's reason and a numbered list of **required changes** — the findings the agent raised and the owner stood behind. ```mermaid stateDiagram-v2 [*] --> InReview: Submit InReview --> AwaitingOwner: Agent answers AwaitingOwner --> InReview: Approved, next stage AwaitingOwner --> Returned: Returned with changes Returned --> InReview: Resubmit AwaitingOwner --> Approved: Last stage approves Returned --> Cancelled: Withdraw Approved --> [*] Cancelled --> [*] ``` ### The Findings Checklist Each required change is a row you can work: * **Tick it off** when it's handled — the count of what's still open is visible to the reviewer too, so progress shows before you resubmit * **Add a note** explaining what you did * **Attach evidence** — a file, up to 25 MB, that settles that specific point * **Doesn't apply** — strike a change you judge shouldn't have been asked for, with a reason Resolving a finding is your judgement, not an automated check. **Clearing the list moves the item.** Once nothing is left open, the item moves on without a resubmit and without the stage's agent looking again. What happens next depends on how you cleared it: * **Every change ticked off** — the item goes straight to the next stage. * **Any change dismissed** — on most stages, the item waits for the **stage owner** to accept the dismissals first. They either approve it, which moves it on, or return it, which reopens the changes you dismissed and leaves the ones you finished ticked. A stage owner can switch this off for their stage, and then dismissed changes count the same as finished ones. {% hint style="warning" %} **Dismissing is on the record.** A dismissed change stays on the list, struck through, showing your name and your reason, and the stage owner sees exactly that. It's the one thing standing in for the review you just skipped — so dismissing four changes and watching the item advance is visible for what it is. Use a note to say why; "dismissed with no reason given" is what shows otherwise. {% endhint %} A change you dismiss is off the table for good. If you resubmit with others still open, the stage is shown what you declined and why, but it can't re-open it or hold the item back over it — it can only raise it with the stage owner. ### Letting Darcy Do It Most of what a reviewer asks for is editing, and **Apply changes** hands that editing to Darcy. It reads the asks, makes the changes, ticks off what it handled with a note saying what it did, and resubmits — all without you watching. What it actually does: * **Edits the source, not just the wording.** If an ask is about the scope of work, Darcy edits the scope of work. Because the review re-reads attached scopes from their source, that edit is what genuinely answers the ask. * **Rewrites the summary** when an ask is about the summary, or when its other edits made the summary inaccurate. * **Stops short when an ask needs you.** Anything that needs a signature, an approval, a payment, or a document only you hold is left alone, and the item stays **Returned** with a note on each one saying what you have to do. Darcy does not resubmit an item it knows is still short of what was asked. {% hint style="info" %} **It runs with your access, not the reviewer's.** The agent acts as the person who submitted the item, so it can never reach a scope of work or a record that the submitter couldn't open themselves. A pipeline owner can press the button on someone else's item, and it still runs as the submitter. {% endhint %} Available to the same people who can resubmit — the **submitter** and the **pipeline owner** — while the item is **Returned** and has open asks. One run at a time per item, and everything it did shows up on the Activity tab. ### Resubmitting Write what changed, attach anything new, and choose **Send it back**. The item re-enters at **the stage that returned it** — the stages that already approved don't review again. A resubmission is judged against the list you were given, and nothing else. The stage goes through its changes one at a time and says whether each was made: * **All of them were** → the item passes that stage. It can't be held back over something the reviewer thought of this round but hadn't asked for. * **Some weren't** → it comes back for exactly those, in the words they were first asked in. The list never grows. Each change is then shown with a tick or a cross and the reviewer's note, so you can see what was accepted. {% hint style="warning" %} **Say what you changed.** Your note on each change is what the reviewer checks against. A resubmission with no explanation makes it harder to confirm the work was done, and is more likely to come back. {% endhint %} Only the **submitter** or the **pipeline owner** can resubmit, and only from **Returned** — the pipeline owner can unstick an item whose submitter is away. If a stage sends the same item back three times, the next round goes to the **stage owner** instead of to you. A disagreement that's survived three attempts needs a person, not a fourth revision. ## Cancelling The **submitter** or the **pipeline owner** can cancel an item at any point before it closes. Cancelling withdraws it from review; the history stays. There's no delete for an item — a cancelled item is the record that it was withdrawn. ## What Reviewers See, and What They Don't | You submitted | Reviewers see | You see | | -------------------------------------- | ------------- | ----------------------- | | Title, summary, attachments | Yes | Yes | | The stage's requirements | Yes | Yes — before you submit | | The stage's extra agent guidance | Yes | **No** | | The agent's verdict and reasons | Yes | Yes | | The agent's private notes to the owner | Yes | **No** | | The agent's full transcript | Yes | **No** | | Files a stage produced | Yes | Yes | This is deliberate: reviewers need somewhere to be blunt with their agent, and you need the decision and the reasons behind it. Everything you're shown is something you can act on. ## Next Steps | Goal | Documentation | | ---------------------------------------------- | ---------------------------------------------------------------------------- | | Understand the pipeline you're submitting to | [Pipelines](/build/pipelines.md) | | See the reviewer's side of the same item | [Reviewing & Deciding](/build/pipelines/reviewing-and-deciding.md) | | Collect the files produced by an approved item | [Deliverables & Completion](/build/pipelines/deliverables-and-completion.md) | | Submit and track items by asking Darcy | [Pipelines with Darcy](/build/pipelines/pipelines-with-darcy.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/submitting-items.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.