Our Methodology
A plain description of how assessments are built, scored, and validated on PsiQ — no marketing language, just what the platform actually does under the hood.
1. Evidence-status labeling
Every assessment on PsiQ carries one of four labels, set by whoever authored it and never defaulted to something more impressive: Standardized (built against a recognized normative framework), Validated (published psychometric validity/reliability evidence exists), Research Instrument (used in research contexts, not intended as a standalone clinical measure), or Educational (illustrative/self-reflection use only). We do not upgrade an assessment's label to make it sound more credible than its actual backing evidence.
2. Server-authoritative scoring
Your answers are submitted to our server, checked against the assessment's real scoring key, and computed there — raw score, subscale scores, and (where a norm set exists) percentile and stanine. None of this logic ships to your browser as JavaScript, so it can't be read out of page source or tampered with client-side. Question timers shown on-screen are cosmetic; expiry is checked server-side against the actual session start time.
3. Norm computation
When an assessment author enters a population mean and standard deviation for a subscale, we compute percentile and z-score using the Abramowitz & Stegun normal-CDF approximation — a standard, deterministic statistical formula, not something invented for this platform. Where an author hasn't entered norm data for a given subscale, that field is left genuinely blank on your report rather than showing an invented percentile.
4. Item lifecycle and validation
Every question in our item bank moves through a five-state lifecycle — draft, needs review, validated, invalid, or archived — and a real validation checklist (prompt present, response options configured, subscale assigned, item code set, no duplicate code) has to pass before an assessment can be published. An assessment builder shows a live readiness percentage computed from these same checks, not a separate, potentially-out-of-sync number.
5. Immutable published versions
Once an assessment version is published, it's locked. Editing it clones a new draft version rather than rewriting the one people have already taken — so a result from six months ago always reflects the exact instrument that produced it, and a longitudinal or research use case never silently changes underneath you.
6. Randomization, where enabled
An assessment author can optionally enable section- or question-level randomization. Where enabled, ordering is session-seeded: you see a consistent order across page reloads within one attempt, but different attempts (yours or someone else's) can get a different order — reducing simple order-effects without making a single attempt internally inconsistent.
7. What we deliberately don't do
We don't auto-generate an interpretive clinical label ("mild anxiety," "high risk") from a raw
score — that would fabricate clinical validity the platform has no normative basis for on most
assessments. We don't let an admin type an arbitrary scoring formula to be evaluated as code —
interpretation rules are pure threshold comparisons against an already-computed percentage,
configured explicitly by the assessment's author. And we don't apply a generic
MedicalTest structured-data schema to assessment pages, since that would imply
clinical validity most assessments here don't claim.