IQnition

Context & problem

By late 2022 every edtech deck had a chat tutor in it. Study Sense was ours: a conversational AI that answered questions and explained concepts for grade 3–12 students. It worked. Students used it. And it had a problem that showed up the moment we tried to charge money: the student isn’t the buyer.

Parents of a 10-year-old do not want their child alone with an open-ended chatbot. They want to know what their kid is studying, whether it’s working, and that the thing is safe — in the specific, legally-defined sense of COPPA, and in the everyday sense of “will it say something I’d be horrified by.” A general chat product can’t answer any of those questions, however good the answers are.

Insight

The product we were selling and the product people would pay for were different products. Demand testing across positioning variants made it unambiguous: the oversight-first framing converted parents; the smart-tutor framing converted students, who have no credit card.

The second insight followed from the first. If parental oversight is the value proposition, then trust and safety is not a compliance layer on top of the product — it is the product. The architecture had to make it impossible for the app to behave in a way a parent couldn’t see and control. That reframing turned a feature backlog (“add parental controls”) into a system design.

Mini PRD

Strategy & bets

• Pivot the product, keep the engine. Study Sense’s content-generation core was sound; what changed was the surface, the buyer and the control model. Pivoting on positioning rather than rebuilding saved most of a year.
• Parents buy, students use. Every flow has two users. Onboarding targets the parent; the daily experience targets the student; the plan is the contract between them.
• Build the gateway before scaling usage. A consumer AI product for kids with inconsistent output quality is a churn machine and a liability. The LLM gateway — model abstraction, eval models, guardrails, cost telemetry — came before growth spend.
• Give the parent an agent, not just a dashboard. The parent inbox agent reads the school and household email the parent already receives and turns it into a digest and plan updates. It makes the parent the daily user of the product, not just the monthly payer — and it’s the feature that pulls the whole family’s school life into one place.
• Own the curriculum map. A school database (type, curriculum, grade range, district) lets plans align to what the student is actually being taught, which is the difference between a study app and a trivia app.

Explicitly out of scope: open chat, homework grading, and anything that positions the app as a replacement for a teacher. Each would have pulled the product back toward the version parents wouldn’t buy.

System design

The gateway turned out to be the product’s biggest feature. It sits between the app and every model, and nothing reaches a model except through it. In order of what it does to each request:

• PII stripping. Children’s data never reaches a third-party model unredacted. Names, school, location and any identifier are removed or tokenised before the call and restored after; the model works on a de-identified request. This is the single control that makes using external models in a children’s product defensible.
• Compliance and input guardrails. What may be asked, by which role, in what context — enforced from the token’s role and consent claims, so a child-scoped request can’t reach a parent-only capability and nothing runs for a profile without consent on file.
• Model selection. Provider abstraction and routing per task and budget; models have been swapped more than once with zero app change, which matters when the best model changes quarterly.
• Eval models. Generated quizzes and plans are scored for quality and difficulty against the knowledge graph; below threshold is regenerated, never surfaced.
• Cost and latency telemetry per call — where a consumer app’s unit economics are actually decided.

One chokepoint, five controls. Everything that would otherwise be scattered across features — privacy, safety, quality, cost — lives in one place where it can be tested and audited.

Family Circle is the account model: a parent-rooted graph where under-13 profiles can only be created by a parent who explicitly acknowledges the data terms. It is distinct from platform family-sharing features because it carries product semantics — approval, visibility, limits — not just billing.

The knowledge graph and school database anchor generation to real curricula. The US school database is complete; the Canadian one (public, private, Catholic, French-immersion, special-needs and other types, by province and district) is being built to the same schema.

Engineering notes: the gateway

For technical readers. The gateway is the component the whole product rests on.

Why one chokepoint. In a children’s product every model call is a privacy event, a safety event and a cost event at once. Handling those per feature means every new feature re-implements them and one of them gets it wrong. The gateway makes it impossible to call a model any other way, so the controls are written once, tested once and audited once.

The controls, in request order.

1. Authorize from the token’s role, consent and acting-profile claims. A child-scoped request can’t reach a parent capability; nothing runs for a profile without consent on file.
2. Strip PII. Names, school, location and any identifier are tokenised before the call and restored after. The model works on a de-identified request. This is the one control that makes external models defensible in a children’s product.
3. Route. Provider abstraction and per-task routing on a cost/quality/latency budget, with fallbacks. Models have been swapped more than once with no app change.
4. Evaluate. Output is scored against the knowledge-graph node and difficulty band; below threshold regenerates and is never surfaced.
5. Measure. Cost and latency per call, fallback reasons per model — the data the routing table is tuned on.

What it bought. Privacy, safety, quality and cost live in one audited place. New features inherit all five controls by construction. Model churn is an operations task, not a product rewrite.

What it cost. Latency — every request pays for PII handling and evaluation — and the discipline of never letting a feature call a model directly, even for a prototype.

Engineering notes: the knowledge graph

For technical readers. The graph is the reason generated quizzes and plans stay consistent across models and prompts.

What it holds. Curriculum as a graph: subject → grade → unit → concept → skill, with prerequisite edges between concepts and a difficulty band on each node. The school database links a student’s school and curriculum (US complete, Canada in progress on the same schema) to the right subgraph, so a 7th grader in one district and one in another get plans anchored to what each is actually being taught.

How it’s used.

• Quiz generation is constrained, not free. The model is handed a concept node and a difficulty band and asked to produce questions for that node. It doesn’t choose the topic or the level; the graph does. That is what keeps difficulty consistent across thousands of generated quizzes and across model swaps.
• Study plans are prerequisite traversals. A plan is a walk through the graph from where the student is to where the curriculum says they should be, ordered by prerequisite edges and paced by the schedule. Replanning after a weak quiz result is a re-traversal, not a new prompt.
• Evals score against the graph. The eval models check generated output against the node’s concept and difficulty band, so a question that drifted off-topic or off-level is rejected before a student sees it.
• Progress is graph state. Mastery is recorded per node, which is what the parent dashboard reads and what the plan re-sequences on.

Why a graph and not a prompt. The alternative — asking a model to “make a 7th-grade algebra quiz” — produces different topics and levels every run and every model. Putting the structure in data and keeping the model to the fill-in step is the same decision as the deterministic templates in Studio 3Sixty5’s media engine: move the variance out of the model and into something you control.

Engineering notes: parent and child authentication

For technical readers. This was one of the hardest design decisions in the product, and it’s a product decision as much as a security one.

The constraint that reshaped the design: a child account can’t be authenticated. Not “shouldn’t” — can’t. An under-13 user has no email, no credentials, no capacity to consent, and no identity provider will issue a token with them as the subject. Every standard auth pattern assumes a principal with credentials, and the product’s daily user doesn’t have one. That implication took a while to fully accept: the child isn’t a user of the auth system at all. They’re a profile the parent operates, on a shared tablet, switching with a sibling, and they must never reach parent surfaces. The parent, meanwhile, has to act on behalf of a child without logging in as them. Standard auth gives you one identity per token; this needs a family with one principal.

Where it hurt most: row-level security. RLS policies key on the authenticated identity — “a row is visible if its owner is the current user.” The child’s rows — quizzes, progress, mastery — have no authenticated owner, and the parent’s identity is the one the database sees on every child request. The naive policy either exposes every child in the family to every other child’s session or blocks the child entirely. The fix was to stop keying RLS on who is authenticated and key it on which profile is acting: policies read the family and acting-profile claims from the token, so a child-scoped token sees exactly one profile’s rows and a parent-scoped token sees the family. Getting the token claims and the RLS policies to agree on that model, and keeping them in agreement as surfaces were added, was the slow part.

The decision. One principal, two roles, scoped tokens. The parent is the only authenticated identity. Child profiles are objects owned by the parent’s family, not accounts. A JWT carries the family, the acting profile, the role (parent or child) and the consent state for that profile; a child-scoped token is minted by the parent session and can only reach child surfaces, with a short lifetime so a shared device doesn’t leave a long-lived child session behind. Profile switching re-mints a token rather than re-authenticating — a nine-year-old can’t do a password flow, and shouldn’t need to.

What it bought. COPPA compliance by construction — there is no path by which an under-13 profile exists without a parent having created and consented to it, and the claim set proves it on every request. Parent-on-behalf-of-child is a role claim, not a shared password. Authorization is enforced twice from the same claims — at the gateway and in RLS — so a bug in one layer is caught by the other.

What it cost. The painful part was the time spent trying to make child accounts behave inside a conventional auth-plus-RLS model before accepting that they can’t exist there. Token design is also harder to change than a schema; getting the claim set and the policies to agree took longer than building the login screen. And every new surface has to declare which role may reach it, which is extra discipline for a small team — the right kind.

Metrics & experimentation

• Positioning was tested before the pivot was committed: oversight-first vs. smart-tutor framing, measured on parent sign-up intent. That test is the reason the product is called IQnition.
• Activation is the first parent-approved study plan — not the first quiz taken — because a plan without parental buy-in is the Study Sense failure mode again.
• Retention is measured per family (weekly active student sessions), since the family is the paying unit.
• Eval-model pass rates are tracked per model and per prompt version, so a model swap or a prompt regression shows up before users feel it.

Growth & GTM

Parents buy, so every channel targets the parent at the moment they’re thinking about their child’s schoolwork.

• Referral. Family-to-family: a parent who sees the plan working tells another parent at the same school. Built into the product as a referral loop with a family-level reward, because the natural unit of word-of-mouth here is the school community, not the individual.
• Peachjar. Digital flyer distribution direct to parents through school districts — the one channel that reaches the buyer through a trusted institution rather than an ad. Pairs with the school database: the curriculum alignment is the pitch.
• AI SEO / GEO. Parents increasingly ask an AI assistant “how do I help my 7th grader study for…” before they search. Content is structured to be cited by those answers as well as ranked by search.
• Blog. Long-form, grade- and subject-specific study guides for parents — the content asset that AI SEO and search both depend on, and the thing a parent forwards to another parent.
• Search ads. Bottom-of-funnel capture on high-intent queries (study planner, parental controls for AI, subject + grade), tuned on the activation event rather than sign-ups.

The sequence is referral and Peachjar first — low cost, high trust — with paid search as the lever once activation economics are known.

Outcomes

• Repositioned from Study Sense (AI chat) to IQnition (oversight-first study planning) on the strength of demand testing; web, iOS and Android.
• LLM gateway in production as the central control point — PII stripping, compliance, model selection, evals, cost telemetry; model provider swapped without app changes.
• COPPA-aware child-account architecture (Family Circle) shipped; under-13 profiles gated on parental acknowledgement.
• US school database complete; Canadian database in progress on the same schema.
• Go-to-market defined — segmentation, positioning, onboarding, activation/retention KPIs — and now the prioritisation input for the roadmap. Raising seed.

What it turned out to be

IQnition started as a tutoring platform. What it became is an exercise in building an AI that people — parents, specifically — can trust with their children. Almost none of the hardest work was tutoring: it was the gateway that strips PII and enforces compliance, the account model that makes a child a protected profile rather than a user, the row-level security that keeps siblings apart, and the knowledge graph that keeps a generated quiz honest. The product is the trust; the study plan is how it’s delivered.

Retro — what I’d do differently

• Run the buyer/user test on day one. The Study Sense year was not wasted — the engine survived — but the “who pays?” question could have been answered with a landing page before a line of code.
• Build the eval layer with the first prompt, not the hundredth. Quality regressions from prompt and model changes are invisible without evals; we added them after feeling the pain, not before.
• Start the school database earlier. Curriculum alignment turned out to be the single biggest differentiator from generic AI study tools, and it is slow, unglamorous data work that should have started in month one.