Open most playlist pitching platforms and somewhere on each curator's profile is a percentage: how often they add a track. It looks like exactly the information you want. We have that number for every curator here, each one can see their own, and it appears nowhere an artist can read it.
What publishing it would do
Suppose we showed it. You are deciding where to spend a credit, and one curator adds 4% of what they hear while another adds 30%. You pitch the second one. So does everybody else.
Now look at it from the curator's side. They have just watched their queue fill up because their number is high, and watched a more careful curator's queue empty out. They are paid per review. The incentive we have just built is say yes more, and it took about one month to build it.
Six months later the 30% curator is at 60%, their playlist is a dumping ground, their followers have stopped listening, and the add you paid for is worth nothing. We would have caused that by publishing one number that looked helpful.
What we show instead
Two things, and the difference between them is the whole argument.
How fast they answer. Measured from their own reviews once there are a few, not from what they claim. This is reliability, and wanting a reliable curator creates no bad incentive at all.
How often they answer. The share of pitches they actually respond to, counting a lapse against them. A curator who lets your 72 hours run out has cost you three days, and you deserve to know that before you choose them.
Answering is reliability. Adding is taste. One is safe to publish and the other quietly destroys the thing it measures.
The test
This is enforced in the code rather than in a policy document. There is an automated test that reads the artist-facing curator data and fails the build if it ever grows a field whose name looks like an add rate, and another that reads the published curator pages and checks the same thing. If somebody here ever decides to ship it, they will have to delete a test that explains why not.