Entering the realm

VERITAS QUEST

Safety and trust

Safety starts with clear roles and controlled surfaces.

The app separates learner, teacher, guardian, tenant, and administrator workflows so each surface exposes only the actions that role should take.

✦ Architecture

How does Veritas Quest separate what each role can see?

Every authenticated screen runs a role check and a tenant context check before it renders, so a learner, teacher, guardian, tenant administrator, or platform administrator only reaches the tools built for that role.

✦ Architecture

How is one school's data isolated from another's?

Row-level security policies are enforced across the database for every school-scoped table, so one school's learner records and content stay invisible to another school's staff or learners.

✦ Architecture

How are uploaded files checked for safety?

Media uploads are scanned by ClamAV before they are served, and any file flagged as infected is quarantined instead of reaching a learner.

✦ Architecture

What can't a guardian see about a learner's work?

A guardian dashboard deliberately excludes raw answers, attempt-level detail, and assessment evidence. It shows progress, not the exact content of a learner's attempts.

✦ Architecture

How are reports about other users handled?

Any user can report a discussion post, thread, peer review, or profile field. Reports go to a moderator queue that can hide content, warn, or ban an account.

✦ Architecture

Is there private messaging between users?

No. There is no direct or private messaging feature. Interaction happens through discussions and peer review, and both are reportable.

✦ Architecture

What is not claimed here?

This page describes the mechanisms above as they exist in the product today. It does not claim a third-party security audit or certification, because none has been completed.

✦ Architecture

Who do I contact with a safety concern?

Use the in-app support desk, the same channel as any other account question, or email support@veritas.quest.