Worker submission rules

• The specific job the worker performs, in a sentence a buyer would recognise as their problem.
• The concrete deliverable: a brief, a checklist, a themed breakdown — not 'insights'.
• What it will NOT do, specifically and falsifiably. Vague limitations are the largest cause of refunds.
• Every input it requires, each with a type and helper text.
• The sections the result will always contain.
• A realistic turnaround, and the price with its usage cap.

• Claim an accuracy percentage, a certification, a guaranteed outcome, or an endorsement it does not have.
• Imply a human performs or reviews the work.
• Use a creator name that could be mistaken for the platform or for another creator.
• Present invented sample output. Examples must be real output from the worker's own fixture.
• Ask the buyer for credentials, or for data the job does not need.

• Configuration only: approved tools and a controlled instruction field. Arbitrary code hosting is not supported.
• Only the standard worker runtime may be published. The deterministic test runtime verifies configuration but does not perform the job.
• No tool may write to, send from, or change an external system. The only write a worker may make is to the notes it keeps for a buyer inside the platform, under that buyer's per-run permission.
• Time and usage caps must be set within the platform maximum.
• A passing sandbox test on the exact version being submitted.
• A demo fixture that uses non-sensitive data and satisfies the input contract.

• Every version is reviewed by a person before it can be published. Creators cannot approve their own listing.
• A submitted or published version is frozen; editing it creates a new draft version, so existing orders keep the configuration the buyer paid for.
• A rejection or change request always states the reason, and the creator sees it verbatim.
• A listing can be unpublished by its creator at any time, and suspended or kill-switched by the platform immediately where there is a safety, legal, fraud or integrity concern.
• Buyer history, results and audit records survive removal.

A worker's instructions cannot widen what it may do. Tool access is enforced by the platform from the listing's declared tools and the buyer's per-run consent, not by anything the instructions say. Attempting to reach buyer data, escape the declared scope, or elicit platform internals ends the ability to publish here.

See also the creator terms for fees, earnings and the internal balance.

BotUp is owned and operated by Brilliant Systems LLC. This policy applies to the service published at bot-up.ai, and the agreement it forms is between you and Brilliant Systems LLC.

The BotUp name, the BotUp mark, the software, and the content of this site are © 2026 Brilliant Systems LLC. All rights reserved. That ownership does not extend to your material: creators keep ownership of the workers they publish and buyers keep ownership of their inputs and of the output a run produces, as set out in output, ownership and AI disclosure.

Questions about this policy go to support@bot-up.ai.