brief bar/rules
A good brief gives a product the right start. We made the standard open.
→ score a brief in the live consoleThe rule texts below stay in their canonical English on purpose: the criteria are the exact files the judge reads, and the sample report above shows the judge's real output. Translating this page changes nothing about the bar itself.
Each rule is one contestable file. criteria and the examples are all the model reads; weight steers the score in code; ★ marks a rule that is also a gate requirement. The examples are also the rule's regression tests. Numbers (R01–R14) are for easy reference in discussion — link any rule directly, e.g. rules.html#anonymised; the id is the canonical name in PRs and API verdicts.
A product's outcome is mostly the team. The brief is the 20% that decides whether that team starts on solid ground — or spends its first month untangling what was meant. That untangling normally happens in workshops: expensive, slow, dependent on us being in the room. So we wrote the check down instead — grip on reality, doability, scale — and published all of it, so the bar isn't ours to gatekeep.
this page is the standard · the console scores against it · the rules live on GitHub and anyone can change them
Not a grade — a progress bar toward publication, and the to-do list that closes the distance.
The score says how good a brief is. A separate gate says whether it may publish at all. They are different axes, so read them as a matrix — no average papers over a leaked client name.
Four hard requirements, all of which must hold:
clear-titlemust not failproblem-definedmust not failbudget-floormust not failcontext: directoryanonymisedmust passcontext: directoryMiss one and the brief is blocked, with the unmet ones named — even at 92/100. The line is fair because the arithmetic is reproducible from the returned verdicts — every verdict names its model and carries verbatim evidence — the breakdown shows exactly which rule flips you, and you can revise and resubmit freely. The two directory-scoped requirements exist for the blind noticeboard only: a caller scoring a generic brief deactivates that context (gate_contexts: []) and both drop out entirely — no gate, no weight, the average renormalised over the twelve rules that apply anywhere.
Fluency is free now — a brief can read beautifully and say nothing. Every rule is anchored to a source, typed by authority, pinned and human-verified in the PR:
ISO/IEEE, W3C, OWASP, EN, AgID, GDPR. Authoritative and stable — preferred.
INVEST, SMART, OKR, scope management, Designers Italia. Recognised professional practice.
Wikipedia. A friendly way in to a concept — never the only anchor for a normative claim.
We run the directory and the bar, and welance also pitches as a team on that directory — same fees, same anonymity, same bar. That's a conflict of interest, and open-sourcing the bar is what defuses it. Three gestures, kept separate:
Open a PR on GitHub. Zero gatekeeping on contribution — this is the part that says we're not the bouncer.
A change ships when it passes the public fixture corpus in CI. Not because a curator likes it. Maintainership is earned by good PRs, not appointed.
It's OSS. If the bar is ever unfair, fork it and run your own. That exit right keeps the maintainers honest better than any promise.
the fixtures are the immune system — a corpus of labelled briefs with expected scores. quietly lower the bar to slip a weak brief through and CI rejects you; to get around it you'd have to delete fixtures, and that's a visible, suspicious diff. every verdict carries its ruleset_version, so anyone can check nobody got a different bar — and the Operator Covenant is what binds the operator itself.
decision-owner — does the brief name a single accountable decision-maker? It's pure “80% team”: a brief with no owner stalls. We left it out on purpose. Add it.