Task Marketplace Rules
Task Marketplace Rules
The Task Marketplace is where a requester describes a real-world outcome they need, and a local executor accepts responsibility for delivering it. This page sets out how Tasks are meant to be published, accepted, executed, and completed — the practical rules that keep a Task clear, fair, and traceable for both sides. It is not a restatement of Prohibited Activities or the Terms of Service; for what conduct is not allowed anywhere on ONETO, see Prohibited Activities.
What Makes a Valid Task
A Task must describe a concrete, lawful, and independently reviewable outcome — not a vague intention. It needs enough context for a suitable executor to understand what's being asked: the country or city (or other execution locus, for remote or route-based work), the deadline, the budget or reward, and what evidence would show the work was actually done. A Task must not require an executor to misrepresent their identity, authority, or qualifications to complete it, and the requester must have the authority to request the work and access to anything it depends on — premises, accounts, documents, or people.
If a request actually contains several outcomes that could be executed and reviewed independently, it should be published as separate Tasks rather than combined into one. The current system does not split a single Task across multiple executors, allocate partial responsibility, or settle a Task in parts.
Publishing a Task
Titles and descriptions must be accurate, specific, and consistent with what's actually being requested. The requester must disclose material hazards, permissions, equipment, timing dependencies, and known legal or professional requirements up front — essential requirements should not surface only after an executor has already accepted. Deadlines and rewards must be realistic and not misleading. AI can assist in turning a description into a structured plan, but the requester reviews and approves that plan before publication; AI does not decide whether a request is lawful, accurate, or likely to succeed. Once the plan is approved, the Task completes its funding stage and is published to the Task Marketplace, where executors can find and apply to it — see Funding and Settlement below for what that funding stage actually means today.
Accepting a Task
Executors browse or search the Marketplace and apply to a Task through an execution request. Before applying, an executor should independently assess their own suitability — authority, capability, time, travel, safety, and professional restrictions — rather than relying only on the Task description. The requester selects one executor, who then becomes the single responsible executor for that Task; ONETO's model is single-executor, and responsibility is not shared or silently subcontracted. Profile information, including any reviewed professional qualification, supports the requester's decision, but the requester still exercises their own judgment — platform review is not a guarantee of an executor's competence or performance.
The Work Order
Once an executor is selected, the approved plan becomes the Task's Work Order — the current, agreed record of scope and steps that execution actually follows. Both the requester and the executor should treat the Work Order, not an informal message or conversation, as the shared reference point for what was agreed.
A later material change to scope, timing, or budget goes through a Change Order rather than an informal request; an accepted Change Order produces a new Work Order version. A genuinely new, independently executable outcome should become a new Task, not a change bolted onto an existing one.
Execution Responsibilities
The executor works through the Task's steps and records progress as they go, communicating proactively about progress, blockers, or delays instead of going quiet. ONETO provides the workspace and structure for this; it does not supervise the work in the field, and the executor remains responsible for working lawfully, safely, and within their own competence. Execution responsibility stays with the selected executor — it may not be secretly transferred or subcontracted to an unauthorized third party.
Evidence
The executor submits evidence against the Task's requirements — photos, video, files, or written observations, tied to the relevant step — because evidence is what makes a Task reviewable. Evidence must be genuine: fabricated, staged, altered, or recycled evidence, or unrelated material presented as current proof of work, is not permitted.
Evidence supports review; it is not by itself proof of objective truth. A timestamp, a location field, or a successful upload does not independently verify that evidence is authentic, complete, or accurate.
A requester who needs evidence for a legal, financial, or technical purpose beyond the Task should verify it independently.
Changes, Delays and Blockers
Delays and blockers should be communicated as they happen, not discovered at the deadline. A material change to scope, timing, or budget goes through a Change Order that both parties agree to before it takes effect — not an informal message, and not a unilateral decision by either side. Scope should not shift quietly once a Work Order has been agreed, and it should not be reopened or redefined after the requester has already accepted the outcome; a genuinely new need belongs in a Change Order or a new Task.
Review and Acceptance
The requester reviews submitted evidence against the Task's agreed outcome and Work Order, step by step where applicable, and does so in good faith. If something is missing or doesn't meet the agreed scope, the requester can request a revision tied to that specific gap; the executor addresses it or explains why it cannot be completed as asked. Revision exists to close a stated, scope-bound gap — not to add new requirements or extract additional unpaid work. Rejection must be based on a genuine, material failure within the agreed scope, not a fresh preference. When satisfied, the requester accepts the submitted work; acceptance records that decision inside the platform workflow — it is not ONETO certifying the outcome, and does not by itself resolve a legal or factual dispute between the parties.
Responsibility for the Task
A Task has one responsible executor and one requester responsible for what they ask for. Neither party may misrepresent identity, authority, or qualifications to get a Task published, accepted, or accepted-as-complete, and execution responsibility may not be secretly transferred to someone else. ONETO structures the process; it does not stand behind either party's judgment, competence, or the eventual outcome.
Requester
Responsible for the legality, accuracy, and completeness of what they ask for.
Executor
Responsible for carrying it out lawfully, safely, and within their own competence.
Funding and Settlement
Task architecture includes a funding stage and a settlement stage as part of every Task's lifecycle. Today, that runs entirely through ONETO's own internal financial workflow: funding, commission, and payout or refund states are tracked as internal platform records. Acceptance, or a resolved cancellation, can create payout or refund eligibility inside this internal workflow — that eligibility is a recorded state, not a completed transfer. Real-money capability opens only once a payment phase and provider integration are formally approved and connected — not something available in the product today.
Current boundary
- No real, regulated payment provider connected
- Not legal escrow
- No real external payout or real-money refund
- "Funded," "settled," or "paid" reflects an internal record, not a confirmed bank transaction
- FinancialReview dispute process is approved in design but not yet deployed
Before an executor is selected, a requester can generally cancel a Task and enter the internal refund workflow, subject to the Task's current state. After an executor is selected, cancellation is more limited, and both parties are expected to use messaging, revision, and review first to resolve a performance problem. For a material payment-related dispute, ONETO's governance framework describes an internal review process — approved in design, and limited to directing the funded amount fully to one party or the other, with no partial split — but that workflow is not yet deployed in the product; it is not something either party can invoke today.
Records and Traceability
Every Task produces a platform record: the Work Order and its versions, evidence submissions, review and revision exchanges, and the final acceptance decision. These records exist to make the process traceable — what was agreed, what was delivered, and what was decided, and by whom. They are platform records of what happened inside the workflow, not an independent guarantee that the underlying claims, evidence, or outcome are true, legal, or of a particular quality.
Problems and Reporting
Most Task problems — a missed deadline, evidence that doesn't meet scope, a disagreement about quality — are best resolved directly through revision, review, and messaging, using the Work Order as the shared reference. Tasks do not currently have an in-product reporting entry point the way Signal content and Signal comments do; where a concern can't be resolved directly, use available account or contact channels — see Reports & Appeals for what is currently supported. A real-world emergency should always go to local emergency services, not ONETO.
These rules describe how a Task is meant to move from a clear request to a completed, accepted outcome — one responsible executor, one independently verifiable result, and a traceable record at every step. They work alongside Community Rules and Prohibited Activities, which set out broader conduct expectations and boundaries across ONETO.
Executing Tasks? Read the Executor Guide