How to document a disputed AI platform work session
Build a clear dispute record from your own task history and platform reports, without preserving confidential task content.
No platform-specific rate or payout change is confirmed in the information available for this edition; contractors should track rates, task volume and payment timing separately.
For AI contractors, “pay changed” can describe several different things: a lower task rate, fewer available tasks, a longer wait before payment, or a revised rule for which work qualifies. Those are not interchangeable. This edition has no verified platform-specific announcement to report on current rates or payout terms at TELUS, Mercor, DataAnnotation, micro1 or other platforms. Naming a new rate or payment date without a confirmed source would give workers a false benchmark.
The useful signal this month is a reporting one: keep rate, volume and payout timing as separate lines in your own records. A single weekly earnings total can hide whether the work itself paid less, the queue supplied fewer tasks, or money is simply arriving on a different schedule.
A stated rate is not the same as an effective hourly return. For task-based work, a rough personal comparison is accepted earnings divided by the active time spent completing those tasks. That figure is an estimate, not a platform rate. It can move even when the nominal task rate does not: task duration may vary, work may be rejected, or available volume may change.
Record the basis for each number. Note the platform’s stated rate when it is visible, the task count, active work time, and the earnings shown in the platform report. If a platform changes a rate, preserve the date and the applicable project or task type. Do not combine a new rate with older work and call the result a current baseline.
Queue supply deserves its own line. If weekly earnings fall while the rate and task duration look stable, fewer available tasks may explain the change. That is different from a rate cut, and the distinction matters when deciding whether to keep a work block open or shift attention elsewhere.
Payment terms determine when earned money becomes available, not how much each task is worth. For each platform, check the current terms shown to you for the payment threshold, schedule, processing time, and any review or adjustment period. Record the date work was completed, the date the platform marked it payable, and the date funds arrived. Those dates can reveal a delay without implying that the rate changed.
Do not assume that another contractor’s calendar applies to your account or project. A reported payment delay can be useful as a prompt to check your own status, but it is not proof of a platform-wide policy change. When dates or totals do not match, compare the platform’s report with your own records before drawing a conclusion. A practical guide to building a dispute record from task history and platform reports covers that comparison without retaining confidential task content.
For a genuine change notice, look for a dated statement that identifies what changed, which workers or projects it covers, and when it takes effect. A revised rate should specify the unit of work. A payout update should identify the affected payment stage or schedule. If one of those details is missing, treat the claim as unconfirmed until the platform clarifies it.
Workers can make their own monthly comparison more useful with a compact ledger: platform and project, work dates, task count, active time, stated or estimated earnings, and payment status. Keep platform totals distinguishable from personal estimates. This avoids turning an estimate into a claim about what the platform owes.
A cross-platform record can help show whether a slow week is isolated or shared across a worker’s projects, but it does not replace the platforms’ own reports. RaterSidekick, for example, tracks sessions, task counts and estimated earnings across sites the user designates; its Pay Checker compares user records against platform reports. It does not capture screenshots, keystrokes or task content. As with any personal log, its figures should be checked against the relevant platform record before being used to challenge a payment.
Until a dated, platform-specific notice is confirmed, do not treat chatter about a “pay change” as evidence of a new rate or billing cycle. Track the work performed, the rate basis, and the payment dates separately. That gives contractors a clearer view of their effective return and gives builders a better way to distinguish policy shifts from changes in task supply or payment timing.
Build a clear dispute record from your own task history and platform reports, without preserving confidential task content.
A simple setup can reduce window switching and repetitive typing while keeping task records separate from platform reporting.
Queue gaps on DataAnnotation, Mercor and micro1 are hard to interpret; a careful cross-platform work log can separate a local lull from a broader pattern.