How to use TutorGuard

How TutorGuard fits into your workflow

Step‑by‑step setup

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.

Running Demo 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.

Switching to live key

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.

- Verify the endpoint URL ends with a slash if your provider requires it. - Check that the model name matches exactly what the provider expects. - After saving the key, run a quick test with a neutral prompt to confirm connectivity.

Core safety checks performed

Unsafe content detection

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.

Factual consistency verification

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.

Policy compliance scan

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.”

What this is NOT

No absolute guarantee

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.

Not a replacement for human review

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.

Does not block all edge cases

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.

Configuring input fields

API key entry

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.

Model selection

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.

Threshold tuning

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.

- Unsafe content: default 0.6, range 0.0‑1.0 - Factual consistency: default 0.5, range 0.0‑1.0 - Policy compliance: default 0.7, range 0.0‑1.0

Interpreting the output report

Risk levels explained

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.

Action items list

Below the summary you find a checklist:

- Edit the highlighted segments to remove unsafe language. - Replace factual errors with correct information from your source. - Add any missing disclaimers required by your policy. - Re‑run the check after each change to confirm the score drops.

Export options

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.

Integrating with your tutoring platform

Webhook endpoint

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.

Batch processing

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.

Logging and audit

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.

- Rotate logs weekly to prevent disk overflow. - Review the audit trail monthly to spot trends in false positives or negatives. - Export the log to your SIEM if you need longer‑term retention.

Operator checklist for How to use TutorGuard

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.

Before you change production

- Freeze the branch or config revision you will measure against. - Record the current failure mode with one concrete input and one concrete output. - Confirm which identity the job runs as, and whether that identity can reach data it should not. - Open the primary references you will cite: https://owasp.org/www-project-top-10-for-large-language-model-applications, https://www.nist.gov/itl/ai-risk-management-framework.

While you run the check

- Prefer one reproducible path over ten anecdotal screenshots. - Write the expected safe outcome before you trigger the tool or query. - Capture the exact command, prompt, schema, or regex under test — not a paraphrase. - If the system can act (send, write, delete, transfer), require a confirmation boundary in the same pass.

After you finish

- File residual risk with an owner and a date, even when the scan is clean. - Do not convert a green check into sales language that claims completeness. - Re-run the same checklist when the model, tool schema, or validation rules change.

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.

How I explain limits to buyers

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.

References

- https://owasp.org/www-project-top-10-for-large-language-model-applications - https://www.nist.gov/itl/ai-risk-management-framework

Frequently asked questions

What is TutorGuard?

Keep every AI tutor reply safe before students see it.

Who should use TutorGuard?

Operators and builders who need a fast first draft or checklist from TutorGuard.

Does it work without an API key?

Yes in explicit Demo mode. Live AI requires a configured key.

Does it guarantee outcomes?

No. Outputs are decision-support; you still review before publishing or acting.

Does it include SSO, Slack, or bulk CSV?

Only if those features are implemented in this product build — do not assume them from marketing copy.

Where does data go?

Runs may be stored locally under the product's .data/ boundary; treat demos as ephemeral.