Executor Guide
Executor Guide
You've found a Task worth doing, or you're about to. This guide walks through the practical steps of applying, executing, and completing a Task on ONETO — in the order you'll actually hit them. It's not a new set of rules — see Task Marketplace Rules for that.
1. Before You Apply
Before you submit an execution request, check the Task against the basics:
Outcome
Is the described outcome clear enough that you understand what "done" looks like?
Location
Is it somewhere you can actually reach, and where you're allowed to operate?
Deadline
Is it realistic given the outcome, the location, and your other commitments?
Reward
Does the budget make sense for what's being asked?
Work requirements
Read whatever scope and requirements are already published; don't assume you can negotiate them away after acceptance.
Required evidence
Can you actually produce what's being asked for (photos, video, files, written observations)?
Your own capability
Do you have the skills, tools, and time this Task actually needs?
Professional authority
If the Task requires a specific credential or license, do you genuinely hold it? Never apply to a Task you'd need to misrepresent your authority to complete.
Time, travel, and safety
Factor in real travel time and any safety considerations before you commit.
If something doesn't fit, don't apply. It is better not to apply than to accept a Task you cannot realistically deliver; an accepted Task you can't actually deliver costs both sides time and trust.
Before You Start
Once you're selected, before you do any work, confirm you actually understand the Work Order:
- The expected outcome, in your own words
- The Work Order's steps and requirements
- What evidence each step needs
- Access and contact details for the location, if applicable
- Any special instructions
- The deadline
Treat the Work Order — not a chat message, not a verbal aside — as the shared reference point. If a requester mentions something in conversation that isn't in the Work Order, that's not yet part of the agreed scope; if it's material, it needs to go through a Change Order before you act on it.
Follow the Work Order
Execute against the Work Order as agreed. That means:
- Don't quietly change scope because you think it's a better approach — raise it instead
- Don't skip a required step because it seems unnecessary
- Don't add your own interpretation of an ambiguous requirement and treat it as if the requester agreed to it
- Don't hand off execution to someone else. You're the one responsible executor for this Task — responsibility isn't transferable, secretly or otherwise
If the Work Order is genuinely unclear, ask before you act, and keep the answer in writing where the platform supports it.
Evidence
Evidence is what makes your work reviewable — treat it that way:
- Capture evidence that actually shows the specific step was done, not just that you were present
- Use clear photos, video, files, or notes — if a reviewer can't tell what they're looking at, it doesn't help you
- Give enough context that someone unfamiliar with the situation can understand what happened
- Leave out material that isn't relevant to the step
- Never fabricate, stage, alter, or recycle evidence from something else — this is a serious violation, not a shortcut
- Be clear about what you directly observed versus what you're inferring or assuming
- Don't include private or confidential information beyond what the step genuinely requires — an exact address, a person's private details, or similar shouldn't appear in evidence unless the Task actually needs it there
Evidence supports the requester's review — it is not automatically certified truth, and submitting it doesn't by itself prove the work meets every requirement. That judgment still belongs to the requester, working from what you submitted.
Changes, Delays and Blockers
Real work runs into real problems: access falls through, a person or item isn't available, the location changes, timing slips, conditions turn out different than expected, or the requester asks for something new mid-execution. When that happens:
- Record what happened as it happens, not after the fact
- Communicate it to the requester promptly — don't let a blocker sit quietly while the deadline approaches
- Don't privately agree to a new scope, timeline, or budget over chat and treat it as settled
A material change to scope, timing, or budget should go through a Change Order where the product supports it — not an informal message. An accepted Change Order produces a new Work Order version, which becomes your new reference point. Until a change is actually accepted, the existing Work Order still governs.
6. Safety
Your safety comes first — ahead of finishing on time, ahead of the reward, ahead of anything else:
- Never enter a property, system, or space you don't have clear authority to access
- Never impersonate someone else to get access or complete a step
- Never conduct unauthorized surveillance, covert recording, or unlawful data collection as "evidence"
- Don't take on work outside your actual competence or, where relevant, outside your professional authority
- If conditions become unsafe, stop. A Task is not worth an injury or a legal problem
ONETO is not an emergency service. If you're in a real-world emergency, contact local emergency services directly — not ONETO.
Communicating During Execution
Good communication is most of what makes execution go smoothly:
- Report meaningful progress, not just a final "done"
- Raise blockers early, while there's still time to address them
- Stay factual — describe what's actually happening, not a more polished version of it
- Don't hide a material problem hoping it resolves itself before review
- Keep communication professional, even when a requester is being difficult — see Community Rules for the baseline everyone is expected to meet
Before Submission
Before you submit, run through this:
- Is every required step actually completed?
- Is evidence attached for each one?
- Does each piece of evidence match the correct step — not just dropped in generally?
- Are your notes accurate and specific, not vague?
- Have you left out private or confidential information the Task didn't actually require?
- Have you disclosed any blocker or deviation, rather than quietly working around it?
- Does the outcome you're submitting actually match the Work Order — not a version of it you found more convenient?
If you can't answer yes to all of these, it's worth fixing before you submit rather than after a revision request.
After Submission
Once you submit, the requester reviews your evidence against the Work Order:
- A revision request should point to a specific, scope-bound gap — something the Work Order actually required that's missing or incomplete
- A revision should not be used to add new, unrelated requirements or extra work outside the agreed scope; those changes should be handled separately through the appropriate Task workflow
- Keep the relevant communication and evidence available — you may need to refer back to it
- Respond clearly and specifically to a genuine revision request, addressing the actual gap identified
When You Should Stop
Some situations mean you stop rather than push through. Stop, and don't proceed, if:
- What's being asked is unlawful
- The situation has become unsafe
- You'd need authorization you don't actually have
- Completing the Task would require you to misrepresent who you are or what authority you hold
- The Task has drifted into something requiring professional authority you don't hold
- The requester materially changes the Task without an agreed Change Order and expects you to just go along with it
- A request for evidence would require you to violate someone's privacy or the law to produce it
If you stop, record why, and raise it through the available contact channels — see Reports & Appeals for what's currently supported. Don't quietly abandon a Task without documenting the reason; that record protects you.
Protect Yourself as an Executor
A few habits keep you in a defensible position if something goes wrong later:
- Rely on the Work Order as the record of what was actually agreed — not memory, not a side conversation
- Keep communication on the platform where possible, so there's a record
- Report blockers promptly rather than staying quiet and hoping they resolve
- Don't accept a scope expansion that wasn't actually agreed through a Change Order
- Don't make claims — about your qualifications, your findings, or the outcome — that go beyond what you actually know or can support
- Don't take responsibility, in your evidence or notes, for facts you didn't personally observe
- Don't manufacture a result just to get through review. A Task that genuinely can't be completed as scoped is better flagged honestly than faked
12. Quick Execution Checklist
A short version for the field:
Outcome, location, deadline, and reward all make sense before I apply
I've confirmed the Work Order before starting
I'm following the Work Order, not my own interpretation of it
Evidence is clear, relevant, and matched to the right step
No fabricated, staged, or unrelated evidence
No unnecessary private or confidential information in evidence
Blockers and delays reported as they happen, not hidden
Material changes go through a Change Order — not a side agreement
I stop if something becomes unsafe, unlawful, or outside my authority
Before submitting, my evidence actually matches the Work Order