Last updated: July 2026 · For pre-health departments, advising offices, and academic integrity reviewers.
Every admissions office is now asking who actually wrote the application. These are the four things we enforce in code rather than promise in a policy document — and, for each one, where the promise stops.
01
Our personal-statement tool cannot hand a student a sentence to paste into their application. It reads the draft they wrote and coaches it — what is working, what is weak, and the questions whose answers would make it specific. The same is true of activity and experience descriptions.
Two layers. The model is instructed in absolute terms never to produce prose in the student’s voice — not a hook, not a closing line, not an example. Because an instruction is not an enforcement, every response is then inspected before it reaches the student: if it contains drafted first-person prose, it is discarded and regenerated, and if it fails twice the student gets an explanation instead of an essay.
The output check is deliberately tuned to avoid blocking legitimate coaching, so it prefers to miss a borderline case rather than break the feature. It governs our tool only — a student can still paste text in from anywhere, and no product can prevent that.
02
Self-reported hours are the weakest number in any application file. A student can ask the supervisor who actually oversaw them to confirm the total — one click, no account needed on the supervisor’s side — and your department sees those hours reported separately from the ones nobody checked.
The supervisor gets a single-use link that expires in 30 days and shows them only what they need to judge: the student’s name, the role, the organisation, the dates, and the hour count. They can confirm or dispute. Editing any of those fields afterwards automatically voids the confirmation, so a badge always describes the exact numbers the supervisor saw.
This verifies that whoever controls the supervisor’s email address confirmed the figure. It is not identity verification of the supervisor, and it is opt-in per experience — so a cohort will contain both verified and unverified hours, which is exactly why we never merge the two numbers.
03
When we tell a student a school is a Safety, Target, or Reach, that verdict is computed in code from published admissions data — not guessed by a chatbot. So is the readiness score and the four-year cost of attendance. The AI only writes the explanation around an answer that was already decided.
The tier is calculated from GPA and test-score gaps with program-specific thresholds, then adjusted by six named, ordered rules — academic momentum, residency, mission fit, re-applicant status, and a low-GPA guardrail — each of which records a human-readable reason. The model runs at temperature zero and is given the verdict as locked input; if what it returns disagrees, the server overrules it. A professor asking “how did you get that number?” gets an answer, every time, and the same student gets the same words on every run.
The thresholds are reasoned from published national medians, not backtested against admissions outcomes. It is a transparent rules engine, not a prediction of whether a student will get in — and we do not claim otherwise anywhere in the product.
04
A student’s draft, their grades, and their experiences are theirs. We do not use student data to fine-tune or train models, we never sell data, and we run no advertising.
Before any student text reaches the model, identifying fields are stripped and grades are rounded so a record cannot be fingerprinted, the passage is capped at 3,000 characters, and known prompt-injection phrases are redacted. Institutions can be pinned to a specific AI provider, and if that provider is not configured the request fails rather than quietly falling back to a vendor the school excluded.
We use Google Gemini as a processor under their terms; this promise describes what we do with student data, not a warranty about a third party’s internal practices. Sub-processors are listed in full on the Security page.
We do not, and nobody can. We control what our own tool produces, not what a student pastes in from elsewhere. What we can tell you is that nothing a student takes from White Coat World is application prose, because our tool does not produce any — and that is one fewer source to worry about, not a solution to the whole problem.
No. We do not scan student work to judge whether a human wrote it, and we would be sceptical of any vendor claiming to. Our writing analysis flags weak writing — clichés, vague claims, telling instead of showing — regardless of who or what wrote it.
That the person controlling the supervisor email address the student gave us confirmed a specific hour count, role, organisation, and date range. It is a real check and it is far stronger than self-reporting, but it is not identity verification of the supervisor. We report verified and self-reported hours as separate figures so you always know which you are looking at.
They can edit them, and doing so automatically voids the confirmation. If a student changes the hour count, the dates, the organisation, the role, or the supervisor, the verified badge clears and has to be requested again. A badge always refers to the exact numbers the supervisor actually saw.
No. We do not use student data to fine-tune or train models. Before any text reaches the model, identifying details are stripped and the passage is length-capped. We use Google Gemini as a processor under their terms; our commitment is about what we do with student data.
Yes. The Security page covers our architecture, FERPA posture, and sub-processors, and we can provide a Data Processing Agreement and a completed HECVAT. Email security@whitecoatworld.com.
The Security page covers architecture, FERPA posture, and every sub-processor by name. The AI Use Agreement is what every student accepts before the writing tools unlock. For a Data Processing Agreement or a completed HECVAT, email security@whitecoatworld.com.