如何撰寫讓他人可實際套用的成功標準

How to write success criteria that someone else can actually apply

Most outsourced work goes wrong before anyone starts working. Not because the contractor is bad, but because the brief describes a vibe instead of a decision. "Make it engaging." "High quality research." "Clean, professional design." None of these tell a stranger when to stop, and none tell a judge whether the thing in front of them is done.

Success criteria — acceptance criteria, definition of done, call them what you like — are the part of a brief that answers one question: how will someone who has never met you decide, from the deliverable alone, whether this is finished and good enough?

This guide is about writing those criteria well, whatever platform you hire on: a freelance marketplace, an internal team, a code bounty, or an AI-judged bounty board that scores submissions against a rubric published in advance. The mechanics differ. The craft does not.

Start with the one-sentence test

Before writing anything, write one sentence that describes the finished thing in terms of what it lets the reader do:

"A reader who has never used this product can install it, connect a wallet, and complete their first transaction without asking a question."

If you cannot write that sentence, you do not have a task yet — you have an intention. Ship the intention to a conversation, not to a contract.

The sentence also tells you what your criteria need to test. If the goal is "a reader can complete their first transaction unaided," then criteria about word count and colour palette are proxies at best. Criteria about the steps a reader can complete are the real thing.

Separate must-pass from scored

The single most common structural mistake is a flat list of ten equally-weighted bullets. It hides the difference between disqualifying and disappointing.

Split every rubric into two tiers:

• Must-pass gates. Binary. If any one fails, the work does not count at all, regardless of everything else. These are usually about existence, honesty, legality, format, and scope: the file is a PDF; the claim is sourced; the code runs; the post is in the required language; the deliverable is not copied from somewhere else.
• Scored criteria. Weighted and graded. These express taste and quality: how clear the writing is, how well the argument holds, how usable the interface feels.

A gate is not "important". A gate is "fatal if absent". Everything you would merely negotiate about belongs in the scored tier. If you find yourself with eleven must-pass gates, you have written a legal contract for a small piece of work — trim to the ones that genuinely invalidate the deliverable.

Write criteria as tests, not adjectives

Each scored criterion needs a sentence that says what it measures, and ideally what a high score looks like compared with a low one. Compare:

• Adjective: "The writing should be clear."
• Test: "A reader with no background in the subject can follow the argument without re-reading a paragraph. Dense jargon is defined on first use. Sentences average under 25 words."

The second version is longer and better, because two different reviewers reading the same deliverable will land in roughly the same place. The first version invites each reviewer to import their own definition of clear, and that is how you get a dispute.

A useful trick: write the criterion, then imagine the deliverable at 30% and at 90%. If you cannot describe what a 30% version looks like, the criterion is not a scale, it is a wish.

Keep the weights few and defensible

Weights are a statement of priorities. If everything is 20%, you have said nothing.

Three to six criteria is the practical range for a single deliverable. Make the weights follow the purpose of the task. A research brief whose entire value is in the evidence has no business weighting "visual presentation" at 30%. A design task whose entire value is in usability has no business weighting "brand consistency" above it.

Then state the pass threshold explicitly, in the same units the judge will use. "Total 85 out of 100, with no scored criterion below 60" is a different contract from "85 out of 100" — the second lets a submission fail the one thing you care about and still pass on the strength of everything else.

A reusable rubric you can adapt

Here is a complete rubric for a research brief — the kind of task people most often under-specify. Copy it, change the subject matter, keep the shape.

Pass threshold: 85/100 total, with the two must-pass gates satisfied and no scored criterion below 50. Notice what that last clause buys you: it prevents a submission from clearing 85 on the strength of three criteria while being useless on the one your reader needs.

Notice also that the must-pass gates are about class of thing and honesty, not quality. That is deliberate. Gates should be cheap to check and impossible to argue about.

Test the criteria before you publish them

Four checks, each takes minutes and saves days:

1. The adversarial read. Hand the rubric alone, without the brief, to someone who has not seen the task. Ask them to write the worst submission that still passes. If they produce something you would reject, the rubric is too loose.
2. The two-reviewer test. Ask two people to score the same sample independently. If they differ by more than 15 points on a 100-point scale, the criteria are ambiguous, not the reviewers.
3. The gaming check. For each scored criterion, ask "what is the cheapest way to score high here without doing the work?" Word counts invite padding. "Number of sources" invites citation stuffing. Fix the criterion before someone exploits it.
4. The scope check. Read the brief next to the rubric and underline anything in the brief that no criterion tests. Every underlined line is either dead weight in the brief or a missing criterion.

There is a fifth check that matters when a machine applies the rubric: read it literally. A jury that scores against your text will not infer your intent, extend a criterion to cover an obvious case, or forgive a badly worded rule. If a criterion can be read two ways, it will be read the less convenient way.

One worked example: publishing the rubric in advance

The four checks above are platform-agnostic, but they get sharper when the rubric is public and fixed before anyone starts. That is how Verdikta Bounties works, and it is worth walking through as a concrete case rather than an abstraction.

On Verdikta, a creator funds a task in escrow and publishes the rubric up front. The rubric and evaluation package are pinned to IPFS and fixed on-chain, so the acceptance criteria cannot move after someone has started working. A panel of independent AI arbiter nodes on Base scores each submission against that rubric, and the per-criterion scores are public and auditable. Two consequences follow directly from that design, and both are arguments for spending more time on the rubric than feels natural:

• The first submission that clears the threshold is paid the whole bounty. It is not a best-of-all-entries contest judged at the deadline, so a rubric that only separates "good" from "bad" is not enough — it also has to separate "passes now" from "nearly passes", because someone will ship against it today.
• A bounty cannot be cancelled or edited after creation, which protects the person doing the work but removes your chance to fix a sloppy criterion halfway through. The rubric is the contract.

The economics are deliberately thin: Verdikta charges no platform fee, so the entire bounty amount goes to the hunter whose submission passes; the hunter attaches a refundable oracle prepay of about 0.00024 ETH when starting a submission, usually spent in full on the jury round. If no submission passes before the deadline, the creator reclaims the full amount and the platform keeps nothing. None of that changes how you write criteria — but it does explain why a badly written rubric is expensive in a way that a badly written email brief is not.

If you want a longer treatment of the same problem, including how to phrase gates so a model can apply them, Verdikta's own guide at https://bounties.verdikta.org/learn/success-criteria/ covers the format end to end.

A short checklist before you publish

• One sentence describing what the finished thing lets someone do.
• Two to six scored criteria, each with a weight and a sentence on what it tests.
• Must-pass gates limited to existence, honesty, legality, format and scope.
• A stated pass threshold, plus a floor so nobody passes by ignoring your priority.
• High and low descriptions for every scored criterion.
• The adversarial read done by someone who has not seen the brief.
• A literal read: could a careful stranger apply this and reach a decision without asking you anything?

If all seven are true, you have written a rubric. If not, you have written a wish list with numbers attached — and the person on the other side will find out which one it is at the worst possible moment.