Your five star rating is not yours

A driver with five years, twelve thousand trips and a 4.97 average opens an account on a competing app and starts at zero. Reputation is the most valuable asset a platform worker holds, and it is the one asset they cannot take with them. That is not an oversight. It is the product.

Picture a courier who has been doing this for five years. Twelve thousand deliveries. A rating that has sat between 4.96 and 4.98 for three of those years, which anyone who has done the work will tell you is not luck. It is knowing which buildings have a service entrance, which restaurants lie about pickup times, and how to phrase the message that stops a customer from marking an order late when the traffic was not your fault.

A competitor launches in the city with better rates. Our courier signs up, and on day one is a stranger. No rating. No completion history. Placed at the back of the queue behind someone who started yesterday, because the new platform has no way to know the difference between the two of them. For the first several weeks, the good jobs go elsewhere, and the earnings are worse than the platform they left. Many people, at this point, go back.

That experience is usually described as a cold start problem, which makes it sound like a technical inconvenience with an obvious fix. It is not a bug. Ask what would happen to the incumbent if the courier could carry five years of proven reliability across the street in thirty seconds, and you understand immediately why no incumbent has ever built that button.

Why can't you take your ratings with you?

There are two answers. One is commercial and rarely said out loud. The other is technical and genuinely difficult. Both are true, and confusing them is why this conversation goes nowhere.

The commercial answer

Non portable reputation is one of the most effective lock in mechanisms ever built into a consumer product, and it is close to free to operate.

Consider what a platform normally has to do to retain supply. It can pay more, which costs margin. It can offer better conditions, which costs margin. Or it can arrange things so that leaving imposes a cost on the worker that the platform does not have to pay for. Reputation lock in is the third option. The switching cost is denominated in the worker's foregone earnings during their cold start, and the platform captures the benefit without spending anything.

It is also elegant, from the platform's point of view, because it strengthens over time. Every additional month a worker stays makes their accumulated history more valuable and therefore makes leaving more expensive. Lock in that compounds is the sort of thing product strategists draw on whiteboards and put in board decks.

So we should be honest about the starting position. Incumbents will not ship reputation portability because someone writes a persuasive blog post about worker autonomy. The pressure will come from regulators, from challengers who need supply, or from workers organising, and probably from all three at once. Anyone designing in this space should assume a hostile incumbent rather than a merely inattentive one.

The technical answer, which is the more interesting one

Suppose an incumbent woke up tomorrow feeling generous and wanted to let workers export their reputation. What exactly would it export?

The obvious answer, the number, is close to meaningless outside the system that produced it. Here is why, and this is the part worth slowing down for.

A rating is not a measurement. It is a summary statistic over a distribution, and that distribution is shaped by a long list of decisions the platform made:

• Who is allowed to rate. Everyone, or only completed jobs, or only customers who have themselves been rated.
• What the default is. On many platforms, most customers rate five or do not rate at all, which turns the scale into a binary with decoration.
• How many ratings count. A rolling window of the last hundred jobs behaves entirely differently from a lifetime average, especially after one bad month.
• What happens to disputes. Whether a rating removed after an appeal is deleted from the average or merely hidden.
• How ratings decay. Whether a poor rating from three years ago still weighs on the number.
• What the algorithm actually rewards. Some platforms are known among workers for penalising rejections more than the visible score suggests, which means the visible number is not even the full internal picture.

A 4.97 on one platform and a 4.97 on another are not the same claim about the world. They are two numbers produced by two different measuring instruments with different calibrations, and moving the digits between them is not portability. It is a category error wearing a data export button.

Here is the analogy that makes this stick. A grade of A in a class of thirty, marked by one teacher on one syllabus, does not transfer to another school as an A, and everyone understands why. Universities do not import grade point averages as raw numbers and treat them as equivalent. They look at the transcript: which courses, how many hours, over what period, from which institution. The transcript travels because it is a record of discrete, dated, describable events. The single number does not travel because it was only ever a compression of those events under one institution's rules.

Reputation portability has the same shape. The score cannot travel. The transcript can.

The third problem: proving the account was ever yours

There is a quieter obstacle that undermines every workaround people currently use. Suppose the courier takes screenshots of the rating, the trip count, and a few glowing customer comments. What does the receiving platform actually learn?

Almost nothing. A screenshot is an image of a claim. It can be edited in a browser's developer tools in under a minute, and there are people who sell exactly this service. Even a genuine, unedited screenshot proves only that someone had access to that account at some point, which is not the same as being the person who earned the record. Accounts on these platforms are rented and sold, a market we looked at in the piece on gig account renting, which means account access is a genuinely weak proxy for identity.

So the honest current state is this: the only trustworthy channel for reputation between platforms is no channel, and the only available workaround is an artifact nobody can verify. Which brings us to the useful reframing.

What can actually travel between platforms?

Not the score. The events underneath it.

A platform holds a large number of discrete, dated facts that it is uniquely positioned to attest, and which are meaningful outside its own rules. It knows that a specific worker completed a specific job of a specific type on a specific date. It knows whether that job was cancelled, disputed, or refunded. It knows the period over which the worker was active. It knows whether a substantiated complaint was ever upheld against them. Those are not summaries. They are facts, and unlike the rating, they mean the same thing in any system.

Now make each of those facts into a signed object issued to the worker at the moment it happens. The platform signs, the worker keeps it, and anyone can verify it later without asking the platform's permission. That is the whole idea, and the shift it represents is worth stating plainly:

Reputation portability is a receipt problem, not a score problem. Every attempt to move the number fails, because the number is not a fact. Moving the receipts works, because receipts are facts, and the receiving platform can compute whatever score its own rules call for from the underlying events.

This also resolves the calibration objection cleanly. The new platform does not import a 4.97. It receives a verified transcript of eleven thousand completed deliveries over five years with no upheld complaints, and it applies its own model to that. Its model may weigh things differently. That is fine, and correct. The worker is not asking to import a score. They are asking not to be treated as though the last five years did not happen.

What does a work receipt look like?

Small, boring, and specific. Here is a single completion receipt as a platform might issue it:

{
  "type": "work.completion",
  "issuer": "platform.example",
  "subject_key": "mnv:key:8f2c...41d9",
  "job_class": "food_delivery",
  "completed_at": "2026-08-30T19:42:11Z",
  "duration_minutes": 26,
  "outcome": "completed",
  "disputed": false,
  "customer_rating_present": true,
  "issuer_sig": "ed25519:9d0b...7ae4"
}

Read what is in it, and more importantly what is not. There is no customer name. No pickup or drop off address. No route. No rating value. No earnings. The receipt asserts that a job of a known class was completed by the holder of a specific key at a specific time and was not disputed. That is the fact a future counterparty needs, and it is the smallest object that carries it.

The subject_key is the load bearing field. It binds the receipt to a key the worker controls rather than to an account name or an email address, which is what makes presentation meaningful. When the courier later shows these receipts to a new platform, they also demonstrate control of that key, so the new platform learns that the person in front of them is the person the receipts were issued to. Without that binding you are back to screenshots.

Verification is deliberately dull:

from manav import verify_receipt, verify_holder

def evaluate_history(receipts, presenter_key):
    valid = [r for r in receipts
             if verify_receipt(r, issuer_key = published_key(r["issuer"]))
             and r["subject_key"] == presenter_key]
    verify_holder(presenter_key)          # proves control, not just possession
    completed = [r for r in valid if r["outcome"] == "completed"]
    disputed  = [r for r in valid if r["disputed"]]
    return {
        "jobs": len(completed),
        "disputes": len(disputed),
        "first_seen": min(r["completed_at"] for r in valid),
        "issuers": sorted({r["issuer"] for r in valid}),
    }

Notice that nothing in that function contacts the issuing platform. The signature checks against a published key. This matters more than it might appear, because the situation where a worker most needs their history is exactly the situation where the old platform is least inclined to help: after a deactivation, after an account dispute, or after the platform has exited the market. A verification model that requires the incumbent's cooperation at the moment of presentation is not portability, it is a permission slip. We wrote about that distinction in general terms in the piece on verifying credentials without phoning the issuer.

How the worker holds them

The receipts sit in a wallet the worker controls, alongside any other receipts they have accumulated. They choose what to present. A direct client hiring for one job might see a count and a date range. A competing platform onboarding them for regular work might see the full set for that job class. A background check provider might see nothing at all, because it is asking a different question.

Manav ships this part today: signed receipts the issuer cannot retroactively edit, held in a worker owned wallet with selective export, verifiable offline against a published key. What is not shipped, and should not be described as though it were, is disclosing an aggregate without revealing the underlying receipts, for example proving that a worker has completed more than five thousand jobs with no upheld disputes while showing none of them individually. That requires selective disclosure work such as SD-JWT or predicate proofs, and it is roadmap rather than reality. Today the worker discloses receipts, not derived claims about them.

What does regulation actually require?

Less than the headlines suggest, and it is worth being precise because a lot of writing on this topic overstates it.

The established right in Europe is data portability under the General Data Protection Regulation, which entitles a person to receive personal data they provided to a controller in a structured, commonly used, machine readable format. That is genuinely useful and it is also not what is needed here. It gives the worker a file. It does not give the receiving platform any reason to believe the file. An exported spreadsheet of trips is exactly as verifiable as a screenshot, which is to say not at all.

More recent European instruments have moved further in the direction of worker data rights. The Platform Work Directive, adopted in 2024 with a transposition deadline in December 2026, is primarily concerned with the presumption of employment status and with algorithmic management, including transparency about automated systems that affect workers and human review of significant automated decisions. Estimates of the population it touches run to tens of millions of platform workers across the European Union. The Data Act likewise strengthens access and switching rights in its own domain. What matters for our purposes is the direction of travel rather than any specific article: regulators have decided that workers should have meaningful access to and understanding of the data platforms hold about them, and that lock in is a legitimate policy concern.

None of these instruments, as far as we can determine, defines a verifiable, portable reputation object. They create rights to access and to explanation. They do not create a format a second platform can check. That gap is the specific thing this post is about, and it is the reason regulation alone will not produce portability: you can mandate export and still end up with a folder of unverifiable spreadsheets.

Does portable reputation enable fraud?

This is the standard objection from platforms, and it deserves a direct answer, because the answer is that the reverse is true.

The argument goes: if reputation can move, then reputation can be bought, sold, laundered, or fabricated, and a bad actor will arrive at your platform waving an impressive history they did not earn.

Now compare that hypothetical to the actual current state. Today, a worker's history moves between platforms as screenshots, PDFs, and claims typed into a form. Every single one of those is trivially forgeable, and the receiving platform's only real defence is to ignore all of it, which is precisely what they do. The status quo is not a world without reputation fraud. It is a world where reputation evidence is so weak that nobody even tries to use it.

A signed receipt bound to a key the presenter must demonstrate control of is strictly harder to fake than a screenshot, by a very wide margin. Forging one requires the issuer's private key. Presenting someone else's requires their key as well. Compared to opening an image editor, this is a meaningful barrier.

There is a real version of the concern, and it is about laundering rather than forgery: a worker with a genuinely poor record on one platform simply does not present those receipts, and shows only the good ones from elsewhere. That is true, and it is worth sitting with rather than waving away. Selective disclosure means selective, and a system where the holder chooses what to show will always permit favourable omission.

Two things reduce it. First, receipts carry dates, so a continuous history has no gaps and a curated one does, and a gap is informative even when the missing receipts are not shown. Second, the useful signal in these systems has always been volume and consistency over time rather than the absence of any negative event. A verified five year continuous record of completed work is a strong claim even if the worker has omitted a bad month, and it is a far better basis for a decision than the nothing a platform has today.

It is still worth saying plainly: this makes reputation portable and verifiable, not complete. A holder controlled system cannot guarantee you are seeing everything.

What travels today, and what could

Who issues the first receipt?

This is the hard part, and pretending otherwise would be dishonest.

The design has a two sided network problem. Receipts are valuable to a worker only if some receiving platform accepts them, and accepting them is only worth building if workers hold them. Meanwhile the parties with the most receipts to issue, the incumbents, have the clearest reason not to. Left alone, this equilibrium does not move.

There are three realistic entry points, and none of them is an incumbent having a change of heart.

Challenger platforms. A new entrant's binding constraint is supply. It has demand it cannot serve because it has no workers, and it cannot attract workers because they would start at zero. A challenger that accepts verified receipts from anywhere, and issues its own from day one, converts its weakness into a recruiting argument. It is the only party in the market with an unambiguous incentive.

Regulators and labour authorities. If portability is going to be mandated in some form, the difference between mandating a data export and mandating a verifiable attestation is enormous, and it is a distinction regulators have not yet drawn. It is a small technical amendment with a large effect, and it is the single most useful thing anyone drafting in this area could do.

Worker organisations and cooperatives. Where drivers or couriers organise, the collective has a direct interest in members carrying provable history, and cooperative platforms can issue receipts from the start.

There is also a fourth actor arriving that changes the calculus, and it is worth flagging because it is early. As agents begin to book, hire, and contract on behalf of people and businesses, the buyer stops being a human reading a profile page and becomes software that needs a machine readable, verifiable claim. Marketing copy on a profile is worth nothing to it. A signed receipt is exactly the input it can use. The demand for verifiable work history may end up arriving from the buyer side rather than the worker side, which would be an unexpected route to the same place.

Honest limits

• Incumbents have no reason to issue. Everything here depends on someone signing the receipts. The worker cannot self certify, because the entire value comes from the issuer being the party that observed the work. This design does not route around an unwilling platform.
• Selective presentation permits omission. A holder controlled wallet lets the holder leave things out. Dates and gaps limit this, they do not eliminate it.
• Reputation is partly context specific. Being an excellent courier does not make someone an excellent home cleaner, and a receiving platform importing history across job classes should discount accordingly. The receipt carries a job class field for exactly this reason, and the interpretation is the receiver's job.
• Issuer key compromise is a real risk. If a platform's signing key leaks, forged receipts become possible until rotation. This is the same operational problem every signing system has, and it needs the same treatment: short lived keys, published rotation, and a status mechanism.
• Aggregate disclosure is roadmap. Proving a summary claim without revealing the underlying receipts needs selective disclosure machinery we have not shipped. Today, disclosure means showing receipts.
• This does not fix deactivation. A worker removed from a platform still loses their income and their access. What they keep is the evidence of the work they did, which helps them start again and helps them contest an unfair removal. It is a meaningful improvement and it is not a remedy.

What to do this week

1. If you run a challenger platform, issue receipts from day one. Sign a completion object to the worker's key at every job. It costs almost nothing while you are small, and it is impossible to retrofit convincingly later.
2. Accept verified history at onboarding. Even a crude version, where verified receipts move someone up your queue faster, is a recruiting advantage no incumbent will match.
3. Separate your score from your events. If your rating logic reads directly from raw tables with no event log underneath, you cannot issue receipts at all. Build the event record first; portability is a consequence of it.
4. Publish a signing key. A well known endpoint with your public key is a few lines of configuration and it is the prerequisite for anyone verifying anything you sign.
5. If you are drafting policy, say verifiable. A right to export data produces spreadsheets. A right to a verifiable attestation produces portability. One word, entirely different outcome.
6. If you are a worker, start keeping receipts now. Where a platform will not issue them, keep dated records anyway. They are weaker, and they are better than reconstructing five years from memory after a deactivation.
7. If you are building an agent that hires people, demand signed evidence. Profile text is not evidence. Ask for something you can verify, and refuse to weight anything you cannot.

If you want to see the underlying mechanics, the worker side of this is the same wallet and receipt model demonstrated in the employee verification demo, and the receipt and verification formats are described in the developer documentation.

Frequently asked questions

Can I take my ratings and reviews with me to another platform? Not today. Ratings are unsigned internal records, and the receiving platform has no way to verify a screenshot or an exported file. What can move is a set of signed receipts for discrete jobs, issued by the platform to a key you control, which any future platform can verify offline without the original platform's cooperation.

Why do platforms not allow reputation portability? Because non portable reputation is a switching cost they benefit from and do not have to pay for. The longer a worker stays, the more expensive leaving becomes. There is also a genuine technical difficulty, which is that a rating only means something inside the rules that produced it, but the commercial incentive is the larger obstacle.

Does the EU Platform Work Directive make reputation portable? Not directly. The directive, adopted in 2024 with a transposition deadline in December 2026, focuses on employment status presumption and algorithmic management, including transparency and human review of automated decisions. Along with GDPR portability rights, it grants access to data. As far as we can tell, none of these instruments defines a verifiable, portable reputation object, which is the actual gap.

Is a screenshot of my reviews trustworthy? No. It can be edited in a browser in under a minute, and even a genuine one only proves someone had account access, not that they earned the record. Since platform accounts are rented and sold, account access is a weak proxy for identity. This is why receiving platforms ignore screenshots entirely.

Would portable reputation make fraud easier? The opposite. Today reputation travels as screenshots and typed claims, all trivially forgeable, which is why nobody trusts them. A signed receipt bound to a key the presenter must prove control of is far harder to fake, since forging one requires the issuer's private key. The real residual risk is omission rather than forgery.

How do new platforms verify a worker's history? At present, mostly they do not. They re-verify identity from scratch, ignore claimed history, and put experienced workers through the same cold start as beginners. With signed receipts they can verify completion counts, tenure, job classes and dispute records offline, and then apply their own scoring rules to those underlying events.

What stops someone presenting receipts that are not theirs? The receipts are issued to a key rather than to an account or a name, and presentation requires demonstrating control of that key. Holding a copy of someone else's receipt file is not enough, which is the specific weakness that makes screenshots and exported spreadsheets useless as evidence.

Sources

1. Directive (EU) 2024/2831 on improving working conditions in platform work, official text: eur-lex.europa.eu, Directive 2024/2831
2. European Commission, platform work policy overview and background on the directive: employment-social-affairs.ec.europa.eu
3. General Data Protection Regulation, Article 20, right to data portability: eur-lex.europa.eu, Regulation 2016/679
4. Regulation (EU) 2023/2854, the Data Act, on access to and switching of data: eur-lex.europa.eu, Regulation 2023/2854
5. W3C Verifiable Credentials Data Model, the standards work most relevant to portable attestations: w3.org, VC Data Model 2.0
6. IETF, Selective Disclosure for JWTs (SD-JWT), the mechanism relevant to disclosing aggregates: datatracker.ietf.org, SD-JWT

The score cannot travel, because it was never a fact. The receipts can, because they always were.