Write an article about
Key points:
When I shipped Gramms AI to the App Store, I ran straight into a question that every developer building for kids will eventually face: What does “age-appropriate” actually mean in practice? And how do you build systems that enforce it reliably?
Gramms is a bedtime story app. It generates personalized tales narrated in a grandparent’s cloned voice. Sounds simple enough. But the safety architecture behind it was anything but.
This is a practitioner’s account of the decisions behind Gramms, written to be useful to anyone building AI-powered products for children ages 3–10. None of this is legal advice, but all of it is hard-won.
1. Age bands: Not all children are the same audience
The most important design decision you’ll make is abandoning the idea of a single “kid-safe” content level. A story that works for a 9-year-old (mild conflict, narrative tension, multi-step moral reasoning) may genuinely frighten a 3-year-old. And a 9-year-old will check out in about 30 seconds if the content feels like it was made for a 4-year-old.
Gramms uses three developmental age bands, each with its own prompt engineering layer:
- Ages 3–5: Simple vocabulary, 200–400 word stories, single-protagonist narratives, repetitive structure, no conflict that requires resolution. Themes like friendship, animals, magical helpers. Language complexity targets a kindergarten Lexile range.
- Ages 6–8: Richer vocabulary, light challenge and resolution, two- to three-character dynamics, mild suspense that resolves happily. Stories run 400–600 words. Introduces simple cause-and-effect morality.
- Ages 9–10: Near-chapter-book structure, multi-step plots, humor that requires inference, protagonist agency and consequence. Stories can reach 600–800 words. Begins to introduce ambiguous situations with nuanced resolution.
These bands are encoded directly into the system prompt sent to the language model. The child’s age isn’t just metadata. It’s a hard constraint that shapes every element of generation: word choice, sentence structure, thematic scope, and narrative stakes.
2. Parental consent architecture for COPPA compliance
COPPA (the Children’s Online Privacy Protection Act) requires verifiable parental consent before collecting personal information from children under 13. In an AI app, “personal information” is broadly interpreted. A child’s name, age, and interests all qualify.
Apple reinforces this with its own App Store Review Guidelines (Section 5.1.4), which require explicit disclosure of which third-party AI services process user data. Gramms surfaces this at the point of parental consent. Before any profile is saved, the parent sees a screen naming OpenAI and Cartesia as our AI vendors, explaining what data each receives, and requiring active acknowledgment. This isn’t a terms-of-service checkbox. It’s a blocking action gate.
Two practical notes for developers building something similar:
First, design consent as a parent-first flow. The child’s profile creation should be gated behind an account that an adult controls. Not a frictionless onboarding flow that a seven-year-old could complete alone.
Second, store consent timestamps and vendor lists server-side. If your AI vendor changes (we migrated our text-to-speech provider mid-development), you need an audit trail and a mechanism to re-surface consent disclosures to existing users.
3. Automated content moderation: Defense-in-depth
Prompt engineering reduces risk, but doesn’t eliminate it. Language models are probabilistic systems. A carefully constructed prompt can still produce output that slips through. For a children’s product, “mostly safe” is not an acceptable quality bar.
Gramms implements a two-pass system. The first pass is prompt-level: the system prompt for each age band explicitly prohibits violence, fear-inducing antagonists, romantic content, and real-world geographic or political references. The second pass is post-generation moderation. Before a story is delivered to the parent or child, the full text is evaluated by a content moderation API against a children’s content policy.
When a story fails moderation, the user sees a simple “generating a new story” message. No error state, no explanation. The regeneration is silent. A parent should never encounter a moment where the app exposes them to content that required filtering.
One pattern worth calling out: moderating the narration script separately from the story text matters. The narration script (which adds dramatic pacing cues and emotional directions for the voice synthesis) can introduce tonal elements not present in the raw story. If your pipeline separates generation from narration formatting like ours does, apply moderation to both outputs independently.
4. Apple App Store review: Lessons for AI child data apps
Apple’s review process for apps in the Kids category is meaningfully stricter than for general apps, and AI features invite extra scrutiny.
Name every AI vendor explicitly. Apple will ask. Your privacy policy, your App Store description, and your in-app disclosures should all reference the specific companies whose APIs process user data. Not just the category of technology. “We use AI” is insufficient. “We use OpenAI’s GPT-4o-mini for story generation and Cartesia Sonic for voice synthesis” is what reviewers need to see.
Keep child data out of training. Confirm (in writing to reviewers if asked) that your AI provider contracts include data processing agreements that prohibit using child-associated data for model training. Both major providers offer this. You may need to select the appropriate API tier.
Separate child profiles from adult accounts at the data layer. The parent’s account owns the child profiles. Child data should never be independently addressable. It should only be accessible in the context of an authenticated parent session. This architecture is both a COPPA best practice and a common App Review inquiry.
Test with real children before submission. Not because App Review requires it, but because age-appropriateness is easier to calibrate empirically than theoretically. A 4-year-old’s reaction to a story you thought was gentle is a better signal than any content audit rubric.
The bigger picture
Building AI products for children isn’t harder than building them for adults. It’s differently hard. The technical constraints are manageable. The design empathy required is substantial. Every age-band decision, every consent flow, and every moderation threshold represents a judgment about what’s appropriate for a specific child at a specific developmental stage.
Here’s the good news, though: Families are ready for well-built AI children’s products. The anxiety isn’t about AI itself. It’s about carelessness. Demonstrating that you’ve thought carefully about safety architecture, named your vendors, built real moderation, and designed consent for parents rather than for frictionless sign-ups is how you earn that trust.
Robin Singhvi, Gramms AI
Robin Singhvi is the solo founder of Gramms AI (gramms.ai), an iOS app that generates personalized bedtime stories narrated in a grandparent’s cloned voice. Gramms is available on the Apple App Store. He can be reached at robin@gramms.ai.
Latest posts by eSchool Media Contributors (see all)
.Organize the content with appropriate headings and subheadings ( h2, h3, h4, h5, h6). Include conclusion section and FAQs section with Proper questions and answers at the end. do not include the title. it must return only article i dont want any extra information or introductory text with article e.g: ” Here is rewritten article:” or “Here is the rewritten content:”
