Every marketplace for small paid work runs on the same question: how does the buyer know it was done? Get the answer wrong and the whole thing collapses into disputes.
The answer here is that proof is defined per campaign, before work starts, by the person who will check it. This page covers what to ask for, how to write it so review is fast, and what happens to the files.
The wider model this sits inside is described in what a task marketplace is for, and the sampling case in crowdsourcing. Proof is one stage of a longer sequence; the full mechanism from brief to payout sets out where it sits. The case against the alternatives — scores, identity checks, reviews — is made in why proof beats reputation.
The five proof formats
A written note. The worker describes what they did or found. Fastest to produce and to read, weakest as evidence. Right for opinion, observation and structured feedback where the content is the deliverable.
An HTTPS link. A posted URL, a public profile, a published item. Strong evidence when the thing being verified exists at a stable address, and worthless when it does not.
A screenshot. Verifies something appeared on a screen at a moment. The standard proof for anything happening inside an app or a site.
An image. Captures a visual result that is not best represented by a live URL: a creator frame, a rendered design, an app state or another digital artefact requested by the brief.
A video file. Verifies a process rather than a state. Necessary for content briefs where the file is the deliverable, and for anything where the sequence of events matters.
Most briefs need one or two. Almost none need all five, and asking for everything is the most common way a brief becomes slow to complete and slow to review.
Matching proof to the task
| Task | Proof that verifies it |
|---|---|
| Short-form video for a brand | The video file, in the specified format and length |
| Posting something publicly | The live link, plus a screenshot in case it is removed |
| Testing a signup flow | Screen recording, plus a written note per step |
| Comparing regional website offers | Screenshots, plus the displayed price as digits |
| Structured feedback on a design | Written responses to each numbered question |
| Reviewing a creator profile | Profile link, screenshot and numbered observations |
| Confirming a listing renders correctly | Screenshot, plus stated device and browser |
The pattern: ask for the artefact that would convince a sceptical colleague, plus the one field that makes forty submissions comparable to each other.
That second part is where most briefs fail. A screenshot proves a page rendered. A screenshot plus the displayed price as digits produces comparable results. The extra requirement costs the worker seconds and changes what you can do with the submissions.
Writing the requirement
State the format explicitly
"A screenshot" and "a screenshot showing the full checkout with the displayed total legible" produce very different submissions.
Say how many
"Screenshots" is ambiguous. "Three screenshots: the product page, the cart, and the confirmation" is not.
Give the field format where you want data
"The price" returns "about twelve euros", "€11.99" and "cheaper than usual". "The displayed price in digits and local currency" returns comparable numbers.
Cover the failure case
What should somebody submit if the page will not load, the product is absent, the code never arrives? Without an instruction, forty people improvise forty different things and none of them are comparable.
Ask for the context fields you will need
Device and OS version for anything technical. City for anything regional. Time of day where it matters. Workers forget unless asked, and a submission you cannot attribute is a submission you cannot use.
Stop there
Every additional requirement is another way for good work to fail on a technicality, and another minute in your own review.
Why the proof requirement is fixed
Once a worker reserves a spot, the proof requirement cannot change. A poster can request one correction against the requirements as written, and cannot introduce a new one afterwards.
What it protects the worker from
The alternative is unbounded. A buyer who can add requirements after seeing the work can extract additional work indefinitely, and the fixed fee stops meaning anything. Capping it at what was stated is what makes a reward a reward rather than an opening offer.
What it does for the buyer
It forces the thinking to happen before launch, which is when it is cheap. A requirement written under time pressure after forty submissions have arrived is a requirement nobody can apply consistently.
How proof is handled
On arrival. Files are signature-checked — the format is verified against the actual bytes rather than the extension — and placed in quarantine.
During quarantine. An administrator reviews for safety before a poster can see it. The poster's 48-hour review clock does not start until this completes, so a worker is never timed against media nobody has looked at.
In storage. Private object storage, never addressable from a public URL. Object keys are not returned through public or ordinary dashboard APIs. Media streams through an authorised endpoint with no-store and nosniff, so proof cannot be forwarded as a shareable link.
Limits. Alongside any note or link:
On release. A worker releasing an unused reservation has unattached uploads removed rather than left orphaned.
Review, and what a rejection means
Review is a check against the requirement list, in order. Anything meeting the stated requirements should be approved even where the poster would have made a different choice — a submission is judged against the brief, not against a preference formed afterwards.
Three outcomes:
Approve. The reward credits the worker's balance and debits the campaign reserve in one balanced ledger entry.
Request one correction. This pauses automatic approval and gives the worker 24 hours. One per submission. The request should name exactly what to change, because vague notes produce a second draft with the same problem.
Reject. Opens a 72-hour appeal decided by an administrator rather than by the poster who rejected it. Overturned rejections settle through the same retry-safe path as ordinary approvals.
If nobody reviews, the submission approves automatically after 48 hours.
Setting a rejection standard before you start
Deciding case by case across forty submissions produces inconsistency that workers experience as arbitrary, and arbitrary rejection is what loses a pool. Buyers underestimate how quickly this travels: a campaign that rejected unpredictably last month fills slowly this month, and nobody explains why.
Proof that does not work
Some requirements sound rigorous and verify nothing. Worth knowing before you write them into a brief.
For workers
Read the proof requirement before reserving, not after completing the task. Most rejections trace to a stated requirement that was missed rather than to work being poor.
Submit exactly what was asked, in the order asked. Extra material is fine after the requirements are met and no substitute for them.
Include the context fields. Device, city, time — whatever the brief listed. A submission missing them may be technically complete and practically unusable.
Keep your own copy until payment confirms. Uploads occasionally fail and being able to resend immediately is the difference between an annoyance and an unpaid afternoon.
If you cannot complete it, release the reservation rather than letting it expire. Capacity returns to the campaign and your record stays clean.
Proof and privacy
Proof necessarily involves a worker sending something about themselves or their surroundings, and a few rules keep that from becoming a problem.
Ask for the minimum that verifies the task. A shelf check needs the shelf, not the person. A screen recording needs the screen, not a webcam feed. Every extra field is data somebody has to store and protect.
Do not require identity documents as proof of work. Identity verification is a platform function that happens once, not something a poster collects per task. A brief asking a worker to photograph an ID is not a brief we will run.
Expect faces only where the deliverable is a face. A creator brief asking for on-camera presence is buying that. A price check is not, and requiring it there is collecting something you have no use for.
Remember what a photograph carries. Images may contain location metadata and background detail the worker did not consider. Ask for what you need in frame, and treat what arrives around it as incidental rather than as material to keep.
Posters see the proof they asked for and the approval state. They do not receive worker account data, contact details or payout information, and no part of a submission route exposes those.
The principle underneath
Proof exists so that neither side has to trust the other's account of what happened.
A buyer does not have to believe a worker; they can look. A worker does not depend on a buyer's goodwill; the requirement was written down before they started and cannot move.
That is the whole design, and every specific rule above follows from it. Where a marketplace lets the requirement change after the fact, or lets a rejection stand without explanation, the mechanism stops working and what is left is trust — which is exactly what nobody has when the two parties have never met.
The same requirement shapes review work at volume, where an assertion that something was checked is worth nothing without an artifact attached. How moderation queues are bought and which ones distribute covers that case in detail.