How vetting works

Why vetting exists

The people who land on the peer directory are usually coming in at the worst day of their week. They are not in a state to evaluate a stranger — they are in a state to be re-traumatized by one. A vetting process is what stands between that moment and a peer volunteer who is genuinely prepared to hold it. Without it, anonymity becomes anonymity for everyone, including the unprepared.

That is also why every step of our vetting process is recorded. The applicant submits a written history, an operator reads it, the operator has a real conversation with them, and the decision — approve or deny, with a reason — is logged against the applicant's account. If a denial is wrong, the applicant can see exactly what they were told and why, and they can ask for it to be revisited. The system is built so a denial cannot silently disappear.

What we look for

The pipeline a peer volunteer walks is short on purpose. Three steps, in this order:

Submission. A written application with sector (military, first responder, both), branch or agency, role, a short motivation, a lived-experience note, and the topics a candidate will not cover. The candidate also attests to a small list of disqualifiers — items that, if true, end the application.

Interview. A live conversation with an operator. Not a clinical assessment — an honesty check. The operator reads the application back to the candidate and asks the candidate to explain what they wrote. The point is to confirm the candidate has actually lived what they wrote down, that they understand which topics are out of scope, and that they have the capacity to take a session without breaking themselves.

Decision. Recorded with a reviewer, a timestamp, and a short note. Approval is conditional on the disqualification flags all being false — that gate is enforced on the server, not just on the form. Denial requires a reason line the applicant can read; approval carries an optional note the rest of the team can read. Either way, the row is part of the audit trail.

What we won't accept

There are a few answers on the form that close the application on the spot, and we want them written down so nobody is surprised by them later. A peer volunteer who has any of the following is not someone we can put between another person and their worst Tuesday:

A prior felony conviction. The disclosure is the candidate's own — we take their word for it, and we do not run our own criminal-history check. If the form says yes, the pipeline stops there. Background verification, when it matters, is off-system and human; this gate is the trust baseline.

A dishonorable discharge. Not a value judgment on the person — a fit check with the room. A peer whose discharge-status story would surface in a session is a peer who cannot effectively hold a session with the cohort that hears it.

An unresolved active-duty conflict. A peer volunteer who is still inside the chain is a peer whose privacy is not their own. Anonymity fails the moment their command has standing access to their communications. We ask the candidate to wait until their situation is clear.

We'd rather turn down a good candidate here than put a session at risk. The cost of a stricter gate is a longer roster; the cost of a looser gate is the room. We pick the longer roster.

If you want to apply, the peer volunteer directory is the starting point. If you want to read more posts in this series, back to the blog.