What we will not automate
There is a version of this product that rejects candidates on its own. It would be easy to build, customers would ask for it, and we are not going to.
Every hiring tool eventually gets the same feature request: just let it decline the obvious no's. The pitch is always efficiency, and the arithmetic is always compelling. Four hundred applications, maybe sixty worth reading, why should a human open the other three hundred and forty.
We are not going to build it, and it is worth being specific about why, because the reason is not squeamishness.
Automation moves the error, it does not remove it
A model that declines candidates makes the same mistakes as a model that recommends them. The difference is that a recommendation lands in front of someone who can catch the mistake, and a rejection does not. The error rate is unchanged; what changes is whether anyone ever sees it.
Hiring errors are also asymmetric in a way that most automation decisions are not. Advancing a weak candidate costs an hour. Declining a strong one costs them a job and costs you someone you will never know you missed.
Where the line sits
YoHe will read everything, assess against your requirements, band applicants by evidence strength, and tell you exactly where to start. It will draft the decline message. It will not send it, and it will not close a candidate out on its own.
In practice this is not slow. Reading a banded pipeline with the evidence attached is a different activity from reading four hundred PDFs, and it takes a fraction of the time. What it preserves is the part of the process someone can stand behind.
The same logic, applied elsewhere
The list of things we will not do comes from the same reasoning. No facial analysis. No emotion recognition. No personality inference from writing style. No inferring protected characteristics in order to correct for them. These are not gaps in the roadmap — they are load-bearing.