by TutorGuard (LX AI)
Open TutorGuard, provide the required inputs, run Demo to preview the workflow, then switch off Demo when a live key is configured.
Keep every AI tutor reply safe before students see it.
Decision-support only — confirm before you publish or act.
When you first open the application you see a form with three fields: the AI provider endpoint, the model identifier, and the API key. Fill in the endpoint URL exactly as your provider documents show, for example https://api.example.com/v1. Choose the model you use for tutoring from the dropdown; if your model is not listed you can type the name manually. Leave the API key blank for now; you will add it later when you move from demo to live mode.
Demo mode uses a built‑in mock generator that returns sample tutor replies. Click the Run Demo button to see how TutorGuard processes a reply. The screen splits into two panes: the left shows the raw tutor output, the right shows the safety report. You can edit the raw text in the left pane to test different scenarios, such as inserting a prohibited phrase or a factual mistake. The report updates instantly, letting you see which checks fire.
When you are satisfied with the demo behavior, obtain a real API key from your AI provider. Paste the key into the API key field and toggle the Demo switch off. The application will now send actual requests to the provider and return real tutor replies for review. Remember to keep the key secret; treat it like any other credential and do not commit it to a public repository.
This scan looks for language that could harm a student, such as hate speech, harassment, or instructions for dangerous activities. The detector uses a classifier trained on public safety datasets and on the OWASP Top 10 for LLM applications (https://owasp.org/www-project-top-10-for-large-language-model-applications). If the score exceeds the threshold you set, the reply is flagged and the report shows the offending span highlighted in red.
The second check compares statements in the tutor reply against a trusted knowledge base that you can point to, such as a curriculum database or a vetted FAQ. It flags contradictions, outdated numbers, or missing citations. For example, if the tutor claims “the Earth is flat” the check will raise a warning because the knowledge base contains the correct spherical model.
Many tutoring platforms have internal rules about age‑appropriate content, copyrighted material, or data privacy. You can upload a plain‑text file that lists prohibited patterns or required disclaimers. The scan runs a simple regex match over the reply and reports any hits. This lets you enforce platform‑specific guidelines without writing custom code.
| Check type | What it looks for | Example trigger |
|---|---|---|
| Unsafe content | Hate, harassment, violence, illegal advice | “You should ignore the teacher’s advice and cheat on the test.” |
| Factual consistency | Contradiction with knowledge base, outdated info | “The mitochondria is the powerhouse of the cell, but it also makes coffee.” |
| Policy compliance | Custom regex patterns, disclaimer absence | Missing required statement: “This material is for educational use only.” |
I do not claim that TutorGuard catches every possible problem. The tool provides decision‑support; you must still read the flagged reply and decide whether to edit, reject, or approve it.
Even with the strongest settings, a cleverly worded edge case can slip through. Treat the output as a first line of defense, not the final authority.
Some novel attack vectors or highly domain‑specific nuances may not be covered by the current rule set. Keep the detection rules up to date and review the logs regularly.
Paste the key exactly as shown in your provider’s console. Do not add extra spaces before or after the string. The field masks the characters for privacy, but you can click the eye icon to verify the entry.
Choose the model that matches the version you use in production. If you run multiple models, you can create separate profiles in the settings menu and switch between them without re‑entering the key.
Each safety check has a slider that sets the sensitivity. Start with the middle position, run a few demo replies, and observe the false‑positive rate. If you see too many flags on harmless text, lower the slider; if risky text passes unnoticed, raise it. Record the chosen values in your internal documentation so the team can reproduce the setup.
The report assigns a level to each detected issue: Low, Medium, or High. Low indicates a minor style concern that may not affect safety. Medium suggests a potential problem that warrants a quick look. High means the reply likely violates a rule and should not be shown to a student without revision.
Below the summary you find a checklist:
You can download the report as JSON for integration with logging systems, or as a plain‑text summary for quick sharing. The JSON includes the original reply, the flagged spans, and the numeric scores for each check.
TutorGuard can POST a JSON payload to a URL you specify whenever a review finishes. The payload contains the decision (allow, edit, block) and the annotated reply. Set up a listener on your side that updates the tutoring interface in real time.
If you need to vet a large pool of generated replies, upload a CSV with two columns: prompt and tutor answer. The application will process each row and return a result file with the same structure plus a safety column. This is useful for nightly runs or for checking a backlog of content.
Every request and response is written to a local log file under the .data/ directory. The log includes a timestamp, the model used, the raw reply, and the final safety decision. Keep this folder backed up and restrict access to authorized operators only.
I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.
| Signal | What to record | Stop-ship? |
|---|---|---|
| Unexpected write or send | Tool name, args, identity | Yes until gated |
| Missing confirmation on destructive action | Call path and bypass | Yes |
| Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach |
| Scanner clean, judgment open | Deferred items + owner | Only if core path safe |
tutorguard helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.
When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.
If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.
Keep every AI tutor reply safe before students see it.
Operators and builders who need a fast first draft or checklist from TutorGuard.
Yes in explicit Demo mode. Live AI requires a configured key.
No. Outputs are decision-support; you still review before publishing or acting.
Only if those features are implemented in this product build — do not assume them from marketing copy.
Runs may be stored locally under the product's .data/ boundary; treat demos as ephemeral.