VETTING: Keeping Classroom AI Open to Questions, Accountable to Rules

The assignment was about AI in education. Some of the conversations became a test of the AI itself.

During a middle school writing activity, students could ask a chatbot for help with an essay about the advantages and disadvantages of AI. But alongside the writing support, some exchanges moved into relationship advice, mature themes, and roleplay. When a response ran into a boundary, students sometimes changed the wording and tried again.

For anyone building classroom AI, that creates a dilemma. Open-ended conversation is part of what makes these tools useful. Yet the freedom to ask almost anything cannot mean the system should answer anything. How do you keep the conversation open while keeping the AI accountable to classroom rules?

That is the problem behind VETTING, the Verification and Evaluation Tool for Targeting Invalid Narrative Generation. Developed by the University of Florida's VIABLE Lab, it separates the AI that writes a response from the AI that checks whether that response should reach a student. A new study involving 151 middle school chatbot users reports an estimated 91.2% reduction in inappropriate-content exposure under the tested configuration, with a 19.6% increase in token usage.

The open-access paper, by Hongming (Chip) Li, Shan Zhang, and Dr. Anthony F. Botelho, is published in Computers and Education: Artificial Intelligence. The full study and Python implementation are available for readers who want to examine the evidence or try the approach.

The answer is not just another instruction

Telling a chatbot to stay on task or avoid giving away an answer establishes an expectation. It does not, by itself, provide a separate check that the expectation was met. VETTING makes that check an explicit step between generating a response and showing it to a student.

Think of it as a writer working with an editor. The first model drafts an answer. The second evaluates it against safety and instructional criteria. A failed draft goes back for revision; if it still cannot pass within the allowed attempts, the system returns a fallback message.

The key is not simply adding another model. It is keeping the checking policy outside the student-facing conversation. The student can rephrase a request, but the policy is held in a separate verification layer rather than exposed as part of the exchange. The paper calls this policy isolation.

How VETTING works: a response is checked before release. Failed drafts return for revision within a fixed attempt limit; the checking policy remains separate from the student-facing conversation.

What happens when students choose the questions?

A design like this needs more than a few carefully chosen test prompts. The study examined a 45-minute writing activity in grades 6-8, where students decided when and how to use the chatbot. The researchers analyzed conversation logs and verification decisions, audited outputs by hand, and measured the additional computation.

The logs showed why checking throughout a conversation matters. Verification events were concentrated in a subset of conversations and often recurred. Requests could be indirect, culturally specific, or framed as fiction. A safeguard therefore had to consider the meaning of a response in its classroom context, not just whether it contained a particular word.

What the checks encountered: the left panel groups flagged responses by theme; the right shows how themes overlap across conversations. These are patterns in flagged interactions, not rates among all participating students. Those observations turn boundary-testing into something developers can study. The categories provide a starting point for asking which classroom rules need clarification, where a checker struggles, and what future evaluations should include.

A second AI still needs to be checked

Human review confirmed that 50 of the 53 flagged cases were policy violations; three were safe responses flagged incorrectly. The study reported precision of 0.943, estimated recall of 0.913, and an F1 score of 0.928. In plain language, the audit examined both whether the checker raised the right alarms and how many violations it might have missed.

Checking the checker: human review confirmed 50 of 53 flagged cases as policy violations. Missed violations were estimated from a sample of passed interactions, so recall and F1 are reported with uncertainty intervals.

The headline exposure-reduction estimate came with a practical trade-off: 19.6% more tokens, not twice as many, in this deployment. Tokens measure text processed and generated by the models, not a fixed dollar cost. That gives developers evidence to weigh additional checking against the risks of an unchecked response.

The result is a reference point, not a safety guarantee. Missed violations were estimated from a limited audit sample, and performance may change with the models, policies, or classroom setting. The study did not establish improved learning outcomes or universal superiority over other safeguards.

Its broader contribution is making classroom AI behavior inspectable: a rule can become a check, a failed check can trigger revision, and the resulting record can inform the next design decision. The same architecture can also support instructional boundaries, such as helping a student reason without supplying the final answer, an application illustrated by earlier undergraduate work discussed in the paper.

Bring VETTING into your work

Reading the paper is one way to explore VETTING. Trying it in your own setting is another. The best starting point depends on whether you want to run the framework yourself, connect it to an application, or use a student-facing tool.

Run and customize it yourself: the Python package

If you want control over the implementation and your deployment, start with the VETTING Python package. The repository includes installation instructions, configuration and integration examples, and a link to a Colab demo. It is a starting point for researchers comparing approaches and developers who want to adapt and run the framework in their own environment.

Build with a hosted implementation: the Developer Platform

If you want VETTING in your application without deploying the framework yourself, the VIABLE Lab Developer Platform provides integrated VETTING APIs. You can connect your product or research prototype to the hosted implementation and focus on the experience you are building. The quickstart guide explains how to get started.

VETTING sits alongside chat, agent workflows, and multimodal tools on the platform, giving developers a shared place to build and experiment with educational AI. This route is for API integration; your team still builds its own application.

Looking for a tool students can use? Meet VETTING Chat

For educators and researchers looking for a student-facing experience, we are also building VETTING Chat. It is not yet publicly open, but you can join the waitlist. If you would like to use it in a classroom or research study, contact our team directly to discuss your setting and what you need. You do not need to arrive with a technical implementation plan.

We would love to hear what you are working on, whether that is a classroom activity, a new learning tool, or a study of how students interact with AI. Questions, feedback, and ideas for collaboration are welcome. For technical issues with the Python package, you can also open a GitHub issue.

Li, H., Zhang, S., & Botelho, A. F. (2026). VETTING: A dual-LLM framework for in-loop safety verification via policy isolation in educational AI. Computers and Education: Artificial Intelligence, 11, 100646. doi:10.1016/j.caeai.2026.100646.