Privacy Policy

1. Who we are

AI Challenge Portal ("the Service") is a critical-thinking practice platform operated by [LEGAL ENTITY NAME], [REGISTERED ADDRESS], trading as cognificance.com ("we", "us", "our"). The Service consists of the public documentation site at cognificance.com, the student portal, the management (admin) portal, and the application programming interface behind them.

Questions about this policy or your information can be sent through our contact form (choose the "Privacy" category) or to [PRIVACY EMAIL ADDRESS]. [COUNSEL: if the operator is established outside the EU/UK and serves EU/UK users, name the Article 27 representative(s) here, or confirm none is required. State whether a data protection officer is appointed; if not, say so.]

2. Scope and our role

This policy covers everyone who uses the Service: students and independent learners in the student portal; teachers, institution administrators, and platform administrators in the admin portal; and visitors to the documentation site, including people who use the public contact form.

• Institutional accounts. When a school, district, or other institution ("Institution") provides the Service to its students and staff, the Institution decides why and how their information is used. For those accounts we act as the Institution's service provider (a "processor" under the EU and UK GDPR, and a "school official" with a legitimate educational interest under the US Family Educational Rights and Privacy Act where it applies) and process information only on the Institution's instructions and under our agreement with it. The Institution's own privacy notice also applies, and requests about those records should go to the Institution first.
• Independent learners, visitors, and inquiries. For people who use the Service without an Institution, for documentation-site visitors, and for contact-form and authenticated framework inquiries, we decide how information is used and are the "controller".

3. Information we collect

Information you or your Institution give us

• Account details: email address, display name, role (student, independent learner, teacher, institution administrator, or platform administrator), preferred language, and, where provided, date of birth. Students who sign up with a class code must give their date of birth.
• Institution and class details: Institution name and web domain, the Institutions and classes (rosters) you belong to, your enrollment dates, and the class join codes teachers create.
• Challenge work: the messages you write in a challenge conversation, the AI's replies, assignments and challenge templates, and the timing, progress, and turn counts of each session.
• Evaluations: scores, score dimensions, checkpoint progress, and written feedback produced for a session.
• Feedback you send us from inside the portals: category, optional rating, message, the page you sent it from, and the app version.
• Contact and framework inquiries: name, email address, optional organization, category, and message. Signed-in framework requests also carry your user identifier and institution identifier and name, plus the framework name, jurisdiction, optional link and note.
• Teacher-authored content: challenge templates and the requests teachers make to the teacher assistant. Teacher-assistant conversations are not stored; each request is processed and discarded, and only a usage record is kept.
• Framework documents: the standards or assessment text an administrator pastes or uploads to the framework assistant on the Catalog page, its conversation and the draft on show. They are sent to the AI model for that request and are not stored; only a usage record is kept. A framework the administrator then imports is kept as catalog data, as for any import.

Outside assessment results, when your Institution has them turned on

This is off by default. We turn it on for an Institution only on request, after recording that a data processing agreement with the school or district is on file (who recorded it, when, and the agreement's reference). An Institution's administrators can then record a student's state or district student identifier on the roster and upload a results file for one assessment and one test window. For each matched student we keep the overall level, an optional scale score and any category levels, and record those levels as evidence on the assessment's items. We also keep a record of each upload: who uploaded it, when, a fingerprint (SHA-256) and the size of the file, the row counts, and for rejected rows only the row number and the reason. The file itself is not kept. Rows are matched on the student identifier only; we never create an account from a results file. Results are never used to predict a score or to rank students.

LMS and partner integrations, when enabled

An LMS launch supplies a platform identifier, deployment, user subject, course and activity identifiers, roles, and optionally a name and email. We use the name for display and map supported roles; launch identity is the platform registration plus subject, not an email match. A link to the account records the source, subject, account, asserted age band where present, origin, activity and last seen. Newly provisioned external accounts have a synthetic email and no Microsoft sign-in identity.

When an administrator requests NRPS roster sync, we receive Learner membership records, including available names and emails, and queue an add-only roster import. With automatic provisioning enabled, learners are provisioned by source/subject; without it, unlinked learners can be enrolled using LMS email through the existing roster-import process. Bulk rows follow the retention below. An institution can set a default age band for newly provisioned LTI learners without another age record; partner learners carry the partner's asserted band.

A partner platform sends its opaque learner subject, age band, optional display name and language preference. We keep that learner record and its challenge work and evaluations. The partner API does not accept a learner email field. These integrations default off and require configuration and enablement.

Information created when you use the Service

• Identity records: the identifier our sign-in provider assigns to your account, whether your account is active or deactivated, and when you last signed in where recorded. We do not store your password. If we create your account, our sign-in provider issues a one-time temporary password that is shown once to the administrator who creates it and that you must change at first sign-in.
• Legal acceptance records: which version of this policy and the Terms of Use you accepted, and when.
• Safeguarding and integrity records: any safeguarding flag or integrity pause raised on a session (see section 6), its reason, and reviewers' notes and decisions.
• Inquiry handling notes our staff add while answering a contact or framework inquiry.
• In-app notifications sent to you and whether you have read them.
• Learning progress: a progress record calculated from your graded solo challenges: your XP and level, the badges you earned and when, your mastery per challenge type (the average step credit of your latest runs of that type), the runs counted toward it, and a suggested next challenge type and difficulty; and evidence toward the thinking skills and standards your runs measured (each observation's value and when it was made; your mastery and level per skill or standard are worked out from those observations each time they are shown, and are not stored separately). You see all of it. Your teachers and your Institution's administrators see only what your counted runs whose reports they can already open (for a teacher, your runs under assignments they created) add up to (XP, mastery per type, and the evidence from those runs), never your overall level, your badges, or work whose reports they cannot open. Results of outside assessments that your Institution imports for you (see below) are seen only by your Institution's administrators, never by your teachers or by you in your portal; they are included in your data export. Platform administrators can see all of it when they support the Service. It is never used to rank you against other learners. The suggested next challenge is worked out each time you open your dashboard; it is not stored and is not in your data export. The rest is included in your data export.
• Usage and audit records: for each AI request, the account and session it served, the model used, token counts, response time, and any error code (not the text of the conversation); and records of who opened a student's session report, safeguarding flag, or learning progress.
• Device and connection information: IP address, browser and device type, and request details, which our network and sign-in providers process to deliver pages, block attacks, and enforce rate limits. The Service also uses your account identifier, or your IP address before sign-in, to count requests against limits shared across the Service. These counters hold request timestamps in a shared memory store, with each request counted for one minute; a counter expires one minute after its last admitted request. No conversation text is included. For IPv6 addresses the counter uses the network prefix (/64). Counter keys and limit records use a code computed from the account identifier or address with a secret key shared by the servers, rather than storing the identifier or address. The code lets us connect records for the same caller until that key is rotated.
• Technical logs: server logs and request traces used to run and secure the Service. They are keyed to internal identifiers and generally do not contain conversation text.

Information from third parties

• Your Institution, when it creates or manages your account.
• Our sign-in provider (Microsoft Entra External ID), which confirms your email address and sign-in.
• Cloudflare Turnstile, which tells us whether a contact-form submission passed its automated abuse check.

We do not ask for, and ask you not to enter, sensitive information such as health details, government identifiers, or financial information in challenge conversations.

4. How we use information and our legal bases

We do not sell personal information, share it for cross-context behavioral advertising, show advertising in the Service, build marketing profiles of students, or use students' information for any purpose other than providing the educational Service and the purposes listed above. We do not make decisions that produce legal or similarly significant effects about anyone solely by automated means; AI evaluation scores are formative feedback that educators can review, together with the full conversation behind them.

Your right to object. Where we rely on legitimate interests, you can object at any time on grounds relating to your situation; see section 13.

Is the information required? An email address is needed to have an account, and a date of birth is needed to sign up with a class code, because we must confirm you are old enough to use the Service. Without them we cannot create the account. Other information is optional or created by your use of the Service.

5. AI processing

Challenges are conversations with AI models. When you take a turn, the challenge brief, its rules and criteria, and the conversation so far are sent to an AI model to produce the next reply, and to a separate evaluation model that tracks progress and scores the session. Your name and email address are not included in these requests, but whatever you type is sent as written, so please do not include personal details in your answers.

• Providers. AI requests are processed by Microsoft through Azure AI Foundry ("Models sold by Azure"). Under Microsoft's terms, prompts and responses are not used to train, retrain, or improve Microsoft's, OpenAI's, or any third party's models, and are not shared with the model's creator. An AI feature can instead be configured to use OpenRouter, Inc. (during the beta, the challenge conversation, the session's completion score and the review of a teacher's challenge template are); that feature's requests are then sent to OpenRouter, which passes them to the company that hosts the chosen model (the model provider). We configure OpenRouter to route those requests only to model providers that do not retain prompts for training, according to OpenRouter's record of each provider's data policy. Those requests are handled under OpenRouter's terms and the model provider's terms, not Microsoft's.
• Processing location. Our model deployments use Microsoft's "Global" deployment type, so a request may be processed in any Azure region where the model runs, including outside the European Economic Area. Data that Microsoft stores at rest stays in the Azure geography of our resource, [FOUNDRY RESOURCE GEOGRAPHY].
• Some providers store prompts. Not every AI provider discards a request once it has answered. Microsoft screens every request with automated content filters, and stores prompts and responses its systems flag as potentially abusive, in the Azure geography of our resource, where authorized Microsoft staff may review them under Microsoft's terms. Other model providers may keep prompts and responses for a limited period for abuse monitoring, safety, or troubleshooting under their own terms [OWNER: name any provider in section 8 that retains prompts, and its retention period]. A provider's copy is outside our control and is not removed when we erase your data (section 13); it is deleted on the provider's own schedule. This is another reason not to type personal details into a challenge.
• Conversation state at the provider. Our own database is the record of your conversations: each request carries the conversation so far, and on a provider interface that can store conversation state we ask the provider not to keep a copy of the request or the reply once it has answered. Some provider interfaces can store requests and replies on the provider's servers so a later request can refer back to them, by default for up to 30 days on Microsoft's service. If a provider stores them, whether because a feature needs it, its terms require it, or a setting does not take effect, those copies sit on the provider's servers under its terms for that period, in addition to the abuse-monitoring storage described above, and like that storage they are outside our control and are not removed when we erase your data. [OWNER: confirm the providers in section 8 and their storage settings before publication]
• No training by us. We do not use conversations, evaluations, teacher-assistant requests or framework-assistant documents to train or fine-tune AI models.
• Accuracy. AI output can be wrong. Evaluations are formative feedback for learning, not certified assessments, and educators can read the full conversation behind any score.

6. Safeguarding and integrity monitoring

To protect students, the AI is instructed to raise a safeguarding flag if a student discloses or suggests self-harm, abuse, or serious distress. When that happens:

• the session pauses and the student cannot continue it; a reviewer can release it, and a paused session that is not released is closed automatically about 24 hours after it started;
• for an assigned challenge, the teacher who created the assignment is notified in the app, with the reason, and the teacher and the Institution's administrators can review it;
• for a challenge an independent learner runs on their own, the flag goes to our platform administrators for review;
• reviewers record notes and a decision on the flag; the flag and its record remain after the session closes.

A safeguarding flag is also raised whenever the AI service's own content filter blocks a student's message, whatever the category the filter screens for (for example self-harm, violence, hate or sexual content). That flag is notified and reviewed in the same way, and the teacher and the Institution's administrators (or our platform administrators, for an independent learner) can see it together with the blocked message in the session transcript. The session is not held for it: the student can choose Resume and continue, and the blocked message is not sent to the AI again or used in grading.

The AI also watches for messages that try to make it ignore its role or the challenge rules (for example, prompt injection). When that happens, the AI's reply is replaced with a notice and the session pauses for review by the student's teachers or our platform administrators, on the same timing as above.

Flags are produced by an AI model and can be wrong in both directions. The Service is not an emergency or crisis service and does not contact emergency services, parents, or guardians. Institutions remain responsible for their own safeguarding procedures. If you or someone else is in danger, contact local emergency services or a crisis line right away.

7. Who can see your information

• You can see your own sessions, reports, and results.
• Teachers in your Institution and teachers of your classes can see the sessions you start after you join their Institution or class, including transcripts, evaluations, and safeguarding and integrity records, whether the session came from their assignment, another teacher's assignment, or the challenge library. A teacher can also see every session on assignments they created.
• Your Institution's administrators can see accounts, memberships, sessions, and safeguarding flags within that Institution, and, where the Institution has them turned on, the outside assessment results it imported. Teachers never see imported results, and students do not see them in their portal.
• Our platform administrators (a small number of our own personnel) can access all records to operate and support the Service, review independent-learner safeguarding flags, and respond to inquiries and feedback. Some access to student records, such as opening a session report or a safeguarding flag, is recorded in an access log.
• Your school's LMS, when enabled, receives grade passback: its linked learner subject, scaled overall/dimension score or completion credit, and an evaluation narrative comment where available (at most 500 characters).
• Your partner platform, when enabled, can read its linked learner's session and report, including conversation and evaluation data. Its webhook receives the opaque learner subject and session id for completion, overall score/completion/mastery fields and step credit percentage (stepCreditPercent) for evaluation, or the client turn identifier/status and fixed safe error text for turn completion. A safeguarding webhook adds only fixed category/severity codes and a session link, with no free-text reason or transcript. Deliveries are signed and may be retried.
• Service providers listed in section 8, only as needed to run the Service.
• Others when required: to comply with law, a court order, or a lawful request from authorities; to protect the safety of any person; to investigate fraud or security issues; or as part of a merger, acquisition, or sale of assets, in which case the recipient must honor this policy for information already collected [COUNSEL: confirm the change-of-control commitment, including any student-data restrictions under applicable state law].

8. Service providers and international transfers

For enabled integrations, the school's LMS and the partner platform are also data recipients as described in section 7. Their operators and hosting locations depend on the institution or partner. Their copies of records are managed by those recipients; our erasure does not recall grades, reports or webhook payloads already delivered.

We use the following providers to run the Service. Each processes personal information only on our instructions and under written terms.

Some of these providers process information outside the country where you live, including in the United States. Where EU or UK personal data is transferred to a country without an adequacy decision, we rely on the provider's certification under the EU-US Data Privacy Framework (and its UK Extension) where available, or on the European Commission's Standard Contractual Clauses (with the UK Addendum) incorporated in the provider's data processing terms. You can ask us for more information about these safeguards. [COUNSEL: verify each provider's current transfer mechanism.]

9. Cookies and browser storage

We use only storage needed to run the Service or to remember a setting you chose. We do not use advertising or cross-site tracking cookies.

You can clear cookies and browser storage in your browser settings; you will then need to sign in again and re-select preferences. [COUNSEL: confirm that no consent banner is required for the strictly necessary and preference storage listed, under the ePrivacy Directive and UK PECR.]

10. How long we keep information

Erased or deleted information may remain in database backups for up to 14 days and in technical logs for up to 30 days, until they expire.

11. Security

We protect information with measures appropriate to its sensitivity, including:

• encryption in transit between your browser and our network (TLS);
• servers that accept no direct inbound internet traffic, reached only through an encrypted tunnel behind a web application firewall;
• sign-in through Microsoft Entra External ID, so we never store your password;
• role-based permissions, separation of each Institution's data, and access logging for key student records;
• request rate limits, content security policies, and automated abuse checks;
• restricted administrative access and secrets kept out of source code.

No system is completely secure. If we learn of a breach affecting your personal information, we will notify you, your Institution, and regulators as required by law. [OWNER: before launch, consider encrypting the database disk and backups and storing backups off the server; this text deliberately does not claim encryption at rest.]

12. Children and students

• Not for children under 13. The Service is not designed for, directed to, or offered to children under 13, and we do not knowingly collect personal information from them. The Service refuses any sign-up or administrator-created account whose date of birth shows the person is under 13, and Institutions must not give access to children under 13. If we learn that an account belongs to a child under 13, we will deactivate it at once, erase its personal information as described in section 13, and tell the Institution where there is one. If you believe a child under 13 is using the Service, please contact us.
• Students in Institutions. Student information is used only to provide the educational Service to the Institution. We do not use it for advertising, sell it, or build profiles for non-educational purposes. Parents, guardians, and eligible students can ask the Institution to review, correct, or delete education records; we help the Institution respond.
• Teenagers. Users under 18, or under the age of majority where they live, should use the Service only with the permission of a parent, guardian, or their Institution. Some challenges carry age ratings and are shown only to users who meet them.
• EU and UK students. Where the Service is used by an Institution, the Institution determines the legal basis for processing students' data. We do not rely on a child's own consent for any processing. [COUNSEL: confirm GDPR Art. 8 and UK Age Appropriate Design Code position for independent learners aged 13-17.]

13. Your rights and choices

Depending on where you live, you may have the right to:

• know what personal information we hold about you and get a copy;
• correct inaccurate information;
• delete your information;
• receive your information in a portable format;
• object to, or ask us to restrict, certain processing;
• withdraw consent where we rely on it, without affecting earlier processing;
• not be treated differently for exercising these rights;
• complain to a data protection authority, such as your local EU supervisory authority or the UK Information Commissioner's Office.

What deletion does. When we act on a deletion request, we erase your personal data rather than only closing the account, and the erasure cannot be undone: the account cannot be restored, and to use the Service again you would sign up as a new user. We delete your sign-in account with our sign-in provider (Microsoft keeps a deleted sign-in account recoverable for 30 days, then removes it permanently). We replace your name, email address, and date of birth with placeholders. In challenges you ran on your own, we replace the conversation text, evaluation narratives and rationales, and checkpoint notes with "[erased]" and end any challenge still in progress. In team challenges, we erase the messages you wrote but keep your teammates' messages and the team's shared answers and scores, which are their work too; AI-written team summaries that may quote you are removed. We also erase your safeguarding reasons and reviewer notes, feedback, inquiries linked to your account or email address and any purchase contact details sent from your email address, delete your own notifications, your learning progress record (XP, level, badges and mastery per type), and any data exports that include you, replace locally kept LMS grade passback comments with "[erased]" and clear their last error, remove external identity links to an LMS or partner and delete matching partner webhook deliveries (including sent and abandoned records), and remove your name and quoted details from notifications sent to your teachers. What remains is de-identified: scores, dates, counts, and the anonymous placeholder account that records such as class enrollments, AI usage counts, and legal acceptances still point to, so that totals and other users' records stay accurate. AI call records, AI usage records and access audit records are deleted when their retention ends (section 10). Copies held by AI providers (section 5), backups, and logs (section 10) expire on their own schedules. [COUNSEL: confirm that the retained de-identified records are acceptable under Art. 17 and state student-privacy deletion duties, given that an Institution may still know which placeholder belonged to which student.]

Who can erase an account. If you are an independent learner, you can erase your own account at any time from Options > Delete your account in the student portal, confirming with your account email address. An Institution's administrators can erase the accounts of their own students and teachers when the Institution receives a deletion request; an account that also belongs to another Institution, and administrator accounts, are erased by us on request so that no Institution erases data another one controls. Every erasure is recorded in an access log.

How to ask. If your account belongs to an Institution, contact the Institution first; we will forward any request we receive to it and help it respond. Otherwise, use our contact form with the "Privacy" category or write to [PRIVACY EMAIL ADDRESS]. We will verify your identity, normally by confirming the request from the email address on the account, and respond within the time the law requires (generally one month in the EU and UK, 45 days in US states). You can change your preferred language in the student portal; ask us or your Institution to change other account details. An authorized agent may act for you with written permission that we can verify.

14. Additional notices for US residents

• Categories collected (last 12 months): identifiers (name, email, account identifiers); education information (challenge work and evaluations); internet activity limited to use of the Service; age (date of birth); and sensitive information limited to account sign-in, which is handled by our sign-in provider. Sources, purposes, and recipients are described in sections 3, 4, 7, and 8.
• No sale or sharing. We do not sell personal information or share it for cross-context behavioral advertising, and we never have, for any user of any age, including those under 16.
• Student privacy laws. We comply with applicable state student-privacy laws, such as California's Student Online Personal Information Protection Act, by using student information only for school purposes and not for targeted advertising or non-educational profiling.
• Do Not Track and Global Privacy Control. We do not track you across sites, so there is nothing for these signals to switch off.

[COUNSEL: confirm which state comprehensive privacy laws (e.g., CCPA/CPRA thresholds) actually apply to the operator, and whether a separate state-specific notice is needed.]

15. Changes to this policy

We will post any change on this page and update the version and date above. If a change is material, we will tell you in the Service and ask you to review and accept the new version the next time you sign in, and we will tell Institutions in advance where our agreement with them requires it.

16. Contact us

[LEGAL ENTITY NAME], [REGISTERED ADDRESS]. Privacy questions: contact cognificance.com or [PRIVACY EMAIL ADDRESS].