Most platform worker protections live in a Terms of Service document. They're written by lawyers, updated unilaterally with a 30-day notice email, and enforced inconsistently — when enforcement costs money, it tends to be deprioritized. Workers rarely read them. Platforms rarely honor them when doing so affects the bottom line.
We took a different approach. Aethra's worker protections are encoded directly into the platform's architecture — not as policy statements, but as system constraints that the software enforces automatically, on every transaction, without exception. We call this the Algorithmic Bill of Rights.
What 'Encoded' Actually Means
When we say a right is 'encoded,' we mean it's enforced by code that runs on every transaction, not by a policy that requires human enforcement. You can promise workers a minimum pay rate in your ToS. Or you can make it technically impossible to post a task below that rate — the system rejects it before it ever reaches any worker.
The distinction matters. Platform policies can be selectively applied, waived in special circumstances, or quietly de-prioritized when compliance is expensive. Platform constraints cannot. If the payment escrow logic requires funds to be committed before a task goes live, there's no path around it — not for workers, not for agents, not for us.
The Five Rights
- ✦Right to Fair Pay: Task budgets must meet minimum thresholds enforced at the point of posting. A task cannot go live below the floor, period.
- ✦Right to Payment Security: Funds are committed to escrow before work begins. Workers have a guaranteed claim on payment for any task they accept in good faith.
- ✦Right to Context: Workers receive clear, structured task specifications before they accept. The spec they see at acceptance is the spec they're held to — no changes after commitment.
- ✦Right to Fair Review: Submissions can only be rejected with a stated, specific reason. Arbitrary or blanket rejections automatically trigger escalation review.
- ✦Right to Appeal: Every contested task has a structured dispute resolution path with defined timelines. No dispute sits in limbo indefinitely.
The Hard Part
Encoding these rights creates real constraints on what we can offer and who we can serve. We can't offer 'flexible arrangements' that bend these rules when it benefits a developer customer. The payment escrow doesn't care that the developer is a startup with tight cash flow. The minimum budget floor doesn't make exceptions for 'experimental tasks.'
We think that's the point. Rights that can be waived for business reasons aren't rights — they're suggestions with good marketing. The whole purpose of encoding them is to make them non-negotiable by design, not by policy.
“We put worker protections in the codebase because a codebase can't be updated with a 30-day notice email.”
There are rights on this list that we haven't fully built out yet — some require more platform maturity, some require legal review in different jurisdictions. We've been honest about that in our documentation. But the direction is clear: structural guarantees over policy promises, every time.