Building a Child-Safe AI Tutor
A worked example showing how Pepiko's four core APIs fit together inside a real homework-help chatbot for kids, end to end.
A note before you read this: this is a worked example we built ourselves to show how the pieces fit together โ it isn't a paid endorsement or a named customer's measured results. If you're already building with Pepiko and would like your own story featured here instead, get in touch.The scenario
A four-person team is building an AI homework-help chatbot aimed at 10-13 year-olds. Kids type questions about schoolwork, but also, inevitably, everything else going on in their lives. The team's first instinct was to drop in a general-purpose moderation API โ but those are built to catch toxicity and NSFW content, not the specific, quieter signals that matter for a product used by children: a kid describing being bullied, asking about something age-inappropriate, or testing how the bot responds to a risky question. None of that looks like "toxic content" to a generic classifier. Here's how the same product looks once it's wired through Pepiko's Prompt Classifier, Child Safety Classification, Policy Route, and PII Detection APIs instead.Wiring the safety pipeline together
Every incoming message goes through the same four-step pipeline before the model ever sees it, and again before the response goes back to the child.1. Classify intent before it reaches the model
The Prompt Classifier looks at the raw message first and buckets it by intent and safety category, so the product knows what kind of request it's dealing with before spending a model call on it.POST /v1/prompt/classify
{
"text": "can you help me with my math homework, its fractions",
"user_age": "10-12",
"context": { "platform": "kids_ai_tutor" }
}
Response
{
"intent": "academic_help",
"safety_category": "none",
"policy_bucket": "standard_response",
"confidence": 0.97
}
2. Screen for age-sensitive risk signals
This is where a generic moderation API would miss the point entirely. Child Safety Classification is trained on signals that matter specifically for kids โ not just "is this toxic," but "does this indicate a child may be at risk."POST /v1/child-safety/classify
{
"text": "everyone at school keeps saying I should just disappear and I don't want to go tomorrow",
"user_age": "10-12",
"context": { "platform": "kids_ai_tutor" }
}
Response
{
"risk_category": "possible_bullying_distress",
"risk_level": "elevated",
"recommended_action": "escalate_supportive_response",
"confidence": 0.91
}
A generic content filter would very likely pass this straight through โ there's no profanity, no NSFW content, nothing that trips a standard toxicity model. Pepiko's classifier is built to catch exactly this kind of quieter distress signal instead.
3. Decide how the product responds
Policy Route takes the outputs from the first two calls and turns them into an actual decision: answer normally, redirect gently, or escalate to a human-reviewed, supportive response path.POST /v1/policy/route
{
"risk_category": "possible_bullying_distress",
"risk_level": "elevated",
"user_age": "10-12"
}
Response
{
"action": "escalate_supportive_response",
"response_template": "supportive_checkin_v2",
"notify_human_review": true
}
4. Scrub identifying details before logging
Whatever gets stored for review or analytics goes through PII Detection first, so school names, real names, and other identifying details never end up sitting in a log file.POST /v1/pii/detect
{
"text": "everyone at Lincoln Middle keeps saying I should just disappear"
}
Response
{
"entities": [
{ "type": "org", "value": "Lincoln Middle", "action": "redact" }
],
"redacted_text": "everyone at [ORG] keeps saying I should just disappear"
}
