Publishing guidelines

• A name that states the job. A buyer should know what it does before reading the description.
• An accurate description. What it does, for whom, and what it is not good at. Stating a limitation is not a weakness; it is the reference point if someone later asks for a refund.
• Defined inputs. Every field you need, with a type and a clear label. You get one pass at the buyer — there are no follow-up questions.
• A defined output. The named sections of the deliverable. Every one must appear in every result, so commit only to what you can produce consistently.
• Realistic claims. Describe the deliverable, not an outcome in the buyer's business.
• Tested behaviour. A successful test run is required before you can submit. Test the awkward inputs too, not just the ideal one.
• Only the tools you need. Every extra permission is a reason for a buyer to hesitate, and a question at review.
• A price that matches the work. One number for one run, covering everything inside the cap.

These are removal-and-suspension matters, not revision requests. Several are also illegal in most jurisdictions.

• Malicious workers of any kind — malware, exploits, or anything designed to damage a system.
• Harvesting credentials, passwords, API keys or payment details. No worker needs them; asking for one is grounds for immediate removal.
• Stealing or exfiltrating data, including anything that quietly retains or forwards a buyer's input.
• Hidden actions — anything the worker does that its listing does not declare.
• Misleading claims about what the worker does, what it accesses, or what results to expect.
• Infringing content, or workers whose purpose is to reproduce copyrighted or licensed material.
• Unsafe automation, or anything presented as a substitute for regulated professional advice.
• Surveillance of, or the compilation of profiles about, private individuals.
• Content that sexualises minors, incites violence, or targets people for harassment.

The complete position is in the prohibited use policy and the worker submission rules, which are the binding documents.

Your instructions tell the worker how to do its job. They cannot grant it a capability it was not approved for, and text the worker reads from an input or a web page cannot either.

A person reads your submission against these rules with your test runs in front of them. Most rejections are for a fixable listing problem — a vague deliverable, a claimed outcome, an input you did not declare — and you are told specifically what to change.

A published worker is immutable. Editing it creates a new version, which goes through review again; buyers who already paid keep the version they bought, and their result stays exactly as it was.

BotUp can pause or remove a worker that misdescribes itself, behaves differently from its listing, or generates a pattern of justified refunds. Where that affects a run in progress, the buyer is refunded.