How ScholarThread's chat assistant stays on the right side of academic integrity

Every institution that has looked seriously at AI and assessment arrives at the same question: not "should students use AI," but "what, specifically, stops a chat assistant from writing the thing a student is supposed to write themselves?" Most tools answer with a sentence in their terms of service. We built the answer into the product.

ScholarThread's chat assistant is meant to help with research — summarising, finding gaps in the literature, explaining a method, checking whether your draft's claims are actually supported by your sources. It is explicitly not meant to produce text a student could submit as their own coursework. Those are different jobs, and conflating them is exactly how "AI assistant" tools end up quietly enabling the thing every academic-integrity policy exists to prevent. So rather than rely on a system prompt asking the model nicely, we built six separate, mostly deterministic safeguards around the assistant, each catching a different way the line could be crossed.

Here's what each one actually does.

1. The input gate — catching the obvious cases before any model runs

The first check happens before the assistant generates anything at all. A deterministic, regex-based gate looks at what's being asked: a direct "write my essay on X" or "answer this exam question" is recognised and hard-blocked immediately — zero model calls, zero credits spent, a fixed redirect response instead. This is the cheapest and most reliable layer precisely because it doesn't rely on a language model's judgment call; it's pattern matching against known-bad request shapes, and it fails closed.

Anything that isn't an obvious match passes through — including every legitimate use (summaries, explanations, critiques, comparisons, gap analyses) completely untouched.

2. The intent classifier — judgment for the ambiguous cases

Not every integrity-relevant request looks like "write my essay." "Can you help me structure an introduction?" is legitimate scaffolding help. "Can you write an introduction for my essay on X?" is not. The first layer's pattern matching can't reliably tell those apart — so the ambiguous cases get a second, smarter pass: a lightweight classification model reads the request and labels the underlying intent (analysing the library, getting feedback on your own text, requesting structural help, or attempting to produce submittable text outright).

Anything flagged as an attempt to get submittable coursework written for you gets redirected — but constructively: the assistant offers an outline, a critique of what you already have, an explanation of the underlying concept, or pointers to sources, instead of simply refusing. Everything else proceeds, tagged internally with the intent that was detected, which matters for the next layer.

3. Output checks — catching what slipped through generation

Even with the first two gates, a model can drift mid-generation into producing something closer to submittable prose than intended, especially on longer, more open-ended requests. So every response is checked after it's generated and before it reaches you: citation integrity (does every factual claim actually trace back to a real passage in your library, rather than an invented one), prose-shape (does the output look like an essay with a thesis and structure, versus an analytical answer), and two attachment-aware checks described next.

This is also why every chat turn is fully generated before any of it is sent to you, rather than streamed token-by-token while the feature is active — you can't run a check on text that hasn't been produced yet.

4. The attachment classifier — the same discipline for what you upload

A request's intent isn't only in the words you type — it's also in what you attach. Upload a published paper and ask for a summary, and that's squarely legitimate library analysis. Upload what looks like your own unsubmitted draft or an assignment brief and the calculus changes: the assistant should critique and explain, not complete. A classifier looks at anything attached to a message and labels it — an academic paper, something that looks like your own notes or draft, or something that looks like an assignment brief or exam paper — and that label tightens what the output checks allow for that turn. Ask it to "finish" a draft you've attached, or to directly answer an exam question you've uploaded as a PDF, and the attachment-aware checks catch it even if the surrounding text looked innocuous.

5. The AI-assistance disclosure log — because trust needs a paper trail

Guardrails that work invisibly are good for preventing problems. They're not, on their own, good for proving to a supervisor, an integrity panel, or an examiner that a student's use of the assistant was legitimate. So every assisted turn — when the assistant was invoked, what mode it ran in, whether a redirect fired — is recorded and available to the student on demand, under Settings → AI assistance log. Nothing about it is hidden from the person it concerns, and nothing leaves the browser until they choose to export it.

Two export formats serve two different purposes. A Markdown export is the quick, working copy — paste it into your own notes, review it yourself, hand it to a supervisor informally. The PDF export is built for the moment that actually matters: when a student needs to demonstrate their AI use was within policy. It's rendered entirely server-side, watermarked with the student's name and verified identity, cryptographically hashed, and recorded against a verification record the institution can check independently — deliberately not just a client-side "print to PDF," which anyone could edit before saving. We're explicit that this is a ScholarThread-issued attestation, not a substitute for independent forensic proof, but it's a meaningfully stronger evidentiary artifact than "trust me."

6. A red-team test suite, because guardrails that aren't adversarially tested aren't guardrails

Every one of the five layers above is backed by an automated test suite that includes genuinely adversarial cases — not just "does the obvious essay request get blocked," but boundary cases designed to probe where a classifier or a pattern-match might be fooled: paraphrased requests, legitimate-sounding phrasing wrapped around an illegitimate ask, attachments that straddle the line between "my notes" and "a paper." A fast tier runs on every change to the assistant, checking the deterministic layers with no live model calls. A nightly tier runs the full adversarial and legitimate-use fixture sets against the real classification models, tracking precision and recall over time — so a change that quietly makes the assistant more permissive, or one that starts over-blocking legitimate research questions, shows up before it reaches anyone's chat window, not after.

Why build all six instead of one strict filter

A single blunt filter either lets too much through (because natural language is flexible enough to route around any one pattern) or blocks too much (frustrating the legitimate research use that's the entire point of the product). Six layers, each doing a narrower job it's actually good at — deterministic pattern-matching for the obvious cases, a classifier for the ambiguous ones, post-hoc checks for what slips through generation, attachment awareness for context a text-only check can't see, a disclosure trail for accountability, and continuous adversarial testing so the whole system doesn't quietly rot — is how you get both properties at once: an assistant that's genuinely useful for research, and one that institutions can trust not to be a shortcut around the work students are supposed to be doing themselves.

If you're reviewing ScholarThread for use at your institution and want more detail on any of these — the exact classification taxonomy, how the disclosure log's PDF verification works, what the red-team fixture set actually covers — reach out via support. We'd rather have that conversation in detail than have it summarised in a single reassuring sentence.