It is not a probability
A personhood score reflects how many attestations of what kind a holder completed. A credential carrying 82 does not mean an 82% chance of being human, and treating it that way leads to arithmetic that looks rigorous and means nothing: averaging it with a fraud score, multiplying it by a confidence, feeding it into a model as a continuous feature.
It is closer to an ordinal signal with a known composition. Two holders on 60 may have got there by different routes, and whether those routes are equivalent for your purposes is your judgement rather than the number's. The useful question is never what the score is but which attestations are behind it.
The threshold comes from the cost of each error
There are two ways to be wrong and they are not symmetric. A false accept lets a sybil through. A false reject turns away somebody real, who in most systems does not come back and does not complain, which is what makes that error the easy one to under-count.
So the threshold is a business decision wearing technical clothes, and the way to set it is to name what sits behind the gate. A forum where a duplicate account is an annoyance can afford a low bar. A payout where a duplicate is theft cannot. Picking a round number first and justifying it afterwards is the common path and it is backwards.
One threshold is the wrong shape
The instinct is to gate at the door: check once at sign-up, admit or refuse. It maximises the false rejects, because the check happens when you know least about the user and before they have any reason to complete more attestations.
Stepping up works better. Let a weak credential in to read and to look around. Ask for more before the actions where a duplicate actually costs something. The user meets the friction at the point where it is obviously justified, rather than before they know whether your product is worth it.
read, browse no credential
post, comment any valid credential
vote, claim, payout score above your bar, checked freshIt is one signal, not the answer
A single credential check is a single point of failure, and the attack against it is not forgery but acquisition: getting hold of a legitimately issued credential. Account age, rate limits, and behaviour over time are cheap to keep and fail in different ways, which is the only reason to combine them.
This is also where the honest limit of the whole category sits. Nobody is accountable for a non-qualified attestation. There is no supervisory body and no legal presumption, as a separate post sets out, so the recourse when a check is fooled is whatever you built for yourself.
Freshness, revocation, and what to keep
Check status at the point of use, not once at enrolment. A credential issued a year ago and never re-checked is an assertion about a year ago, and every credential format in this space carries a status mechanism for exactly that reason.
On storage, the instinct to keep the credential is worth resisting. What you need is the fact that a check happened, when, and what it returned. Keeping the presentation itself gives you a liability and no capability, since you cannot re-verify it later against a fresh nonce anyway.
The harder decision is whether you need to recognise a returning holder. Answering “have I seen this person” requires a stable identifier per service, and the moment you have one you have something that can be correlated if it ever leaks or is shared. Sometimes that is the right trade. It should be a decision, not a side effect of how the integration happened to be written.
And where this does not apply
If what you actually need is an attribute rather than uniqueness, none of the above is your problem. Age, residence, a professional qualification: those come from an issuer who is authoritative for them, and in the EU that means the wallet and, where legal effect matters, a qualified attestation. The difference between the two questions is worth being sure about before building either, and it is laid out here.