For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Submitting an Item

1

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.

2

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.

3

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.

4

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.

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".

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 summary and transcript, so a reviewer can see what was actually agreed

Scope of Work

A scoping estimate's content, so a reviewer can check the ask against what was scoped

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.

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.

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.

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.

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.

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.

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

See the reviewer's side of the same item

Collect the files produced by an approved item

Submit and track items by asking Darcy

Last updated

Was this helpful?