Trust pack

Verifi lets a learner explain their own coursework, spoken, typed or in a faculty-led conversation, and gives the instructor an organised, sourced summary of that explanation to read before the instructor decides what happens next. Its purpose is to make a human conversation about understanding practical at scale.

• No software output is a mark, a verdict or a judgement about a learner. Every decision of record is a named member of faculty's, recorded with their reason, and it cannot be edited after it is recorded.
• There is no AI-content detection, no proctoring, no biometrics and no behaviour analysis. The system does not try to work out whether a learner used AI, and records no risk of any kind.
• Learners never see an AI signal. What a learner sees is what their instructor chose to publish.
• The AI's suggestions to faculty are recorded with what the person did with them: accepted, edited or rejected. That record is the human-oversight record an EU AI Act deployer needs.

We treat Verifi as a high-risk use in education under the EU AI Act and design for Article 14 human oversight and Article 26 deployer duties accordingly. The instructions for use and the technical file are listed under Documents.

Three states only. In place means a DPO could verify it today. In progress means work exists and is not finished. Planned means nothing exists yet. Certification and conformance are words for an auditor to write, not for this page.

These are the third parties that may process personal data on an institution's behalf. If a party is not on this list, it does not receive personal data from the product. The list is maintained with the deployment runbook and reviewed on the date shown above.

Which provider is active is a deployment decision made through configuration, and the deployment's DPA annex records the choice. Every call is written to an AI-call ledger with its purpose, provider, model and prompt version, and the per-session oversight record exports it.

• The institution's LMS (Canvas, Blackboard) is the institution's own system. Verifi is a tool the institution connects to it through LTI 1.3; nothing is read from the LMS beyond the assignment being verified and the roster the institution chooses to share.
• Eklipse Technologies staff may access the production host for operations under named operator roles. They are the processor, not a subprocessor, and their access is logged.

• In transit: TLS everywhere, terminated at the edge and carried to the host over a private tunnel.
• Object storage: server-side encryption is requested on every recording and backup written, and is expected to be the bucket default.
• Database and local media on the host: the runbook does not yet record an encrypted volume.

Until an operator has verified an encrypted volume under the database, the honest state for encryption at rest is In progress, and every questionnaire answer we give says so. We would rather a reviewer read that here than discover it later.

Single-region hosting today, in Germany, with recording storage in the bucket region recorded for the deployment. Customer-selectable residency is not offered yet. Transfers to model providers are covered by the provider's standard contractual terms and are listed in the DPA annex; an institution that requires no transfer outside its region can run the deployment on the built-in stand-in providers at the cost of question quality, and we will say so plainly rather than pretend otherwise.

• Faculty sign-in is closed by default: an access code and a participant allowlist, both supplied out of band, and no self-service accounts. Institutional SSO is planned and not built; the sign-in page says the same.
• No passwords are collected anywhere in the product. Learners reach a verification from the LMS or a secure link, never an account.
• Failed sign-in attempts are throttled and locked out. Only a hash of a coarse requester hint is kept; no raw address or user agent is stored.
• The audit log is append-only at the database level: triggers refuse updates and deletes. Faculty decisions cannot be edited after they are recorded.
• Recordings are played back only through 90-second signed links issued to authenticated faculty, and every access is logged.
• Nightly backups are taken consistently, kept for 14 days on the host and copied off-host to private object storage.
• The incident response procedure names an incident lead, a data-protection contact and the institution's contact, and commits to notifying an affected institution within 24 hours of an incident being confirmed, with what is not yet known stated as such.

No third-party penetration test has been commissioned yet and no SOC 2 report exists. Both are planned. A reviewer who needs either before a pilot should say so; we will not describe internal testing as if it were an external one.

A new subprocessor is added to this page, the DPA annex and the privacy notice in the same change, before it receives any data. Institutions on a signed DPA are notified in advance under the notice period the DPA sets. The review date at the top of this page moves whenever any row changes.

Security, privacy and procurement questions go to [email protected], the one mailbox in use today, read by a person. Put Security, Privacy or Procurement in the subject line. A responsible disclosure of a vulnerability is answered within two working days, and we will not act against anyone who reports one in good faith.