Technology and architecture

More than one chatbot.
A controlled learning system.

KIDNOVA is conceived as a group of specialised components working together. One part manages consent. Another checks safety. Another chooses the teaching approach. Human beings remain responsible for consequential decisions.

Explore the system layers ↓Review Safety and Privacy
Specialised componentsVerified calculationsHuman authority
A clear overview of the KIDNOVA system showing children and trusted adults flowing into identity, safety, learning orchestration, the educational digital twin, specialist models and governance layers.
The child experiences one calm learning companion. Behind that simplicity, separate controlled layers manage trust, safety, teaching and accountability.

The governing principle

The child sees simplicity. The system carries the complexity.

A child should not have to understand artificial intelligence, model selection or security controls. Those systems must work quietly behind a clear, age-appropriate learning experience.

What the child experiences

One calm learning companion

Short instructions, appropriate language, patient support and one useful next step at a time.

What the platform must manage

Many controlled responsibilities

Consent, permissions, safety, curriculum, adaptation, verification, privacy, audit and human review.

Six understandable layers

Each part has a different job.

The architecture is easier to trust when every major responsibility has a clear home and no single model is allowed to control everything.

A six-layer infographic for KIDNOVA showing the experience layer, identity and trust, safety, teaching, learning intelligence and governance.
Each major responsibility has a distinct home, so no one unrestricted component is expected to manage everything.

Experience layer

Different people need different views.

A child should see only what helps them learn. A parent should see controls and useful progress. A teacher should see classroom patterns. A specialist should see only authorised information relevant to their role.

Four interface concepts showing the different views needed for a child, parent, teacher and specialist.
A child, a parent, a teacher and a specialist each need a different interface, a different depth of information and different permissions.

Identity, consent and permissions

Access cannot be informal.

Before a child-facing system stores information or allows another person to view it, the platform must know who is authorised and what that person is permitted to do.

  • Verified parent or authorised school consent
  • Age-aware access and regional requirements
  • Role-specific permissions
  • Controlled specialist access
  • Visible privacy and deletion controls
A permissions diagram showing a protected child profile connected separately to parent control, teacher teaching access and authorised specialist support.
Access is limited by role, authorisation and purpose. Seeing one part of the system must never grant access to everything.

Learning orchestrator

The system must decide how to teach—not merely what to say.

The learning orchestrator brings together the lesson goal, the child’s present response, curriculum requirements, safety constraints and previous learning evidence.

An orchestrator infographic showing several learning inputs passing into a central learning orchestrator and several teaching outputs flowing out.
The orchestrator chooses the next responsible teaching move by balancing the lesson goal, present evidence, accessibility needs, curriculum requirements and safety constraints.

Educational digital twin

A learning model—not a copy of the child.

The twin is intended to remember only what helps the platform support learning. It may track skill mastery, accessibility needs, curriculum progress and which forms of explanation have helped.

Non-negotiable boundary

It must not become a broad psychological profile, intelligence label, location tracker, advertising record or prediction of the child’s future potential.

May includeMastery graph

Which specific skills are emerging, developing, secure or ready for transfer.

May includeInstructional preferences

Whether pictures, spoken guidance, examples or models have supported understanding.

Must excludeInvasive profiling

Information that is not necessary for the child’s learning should not belong in the twin.

Specialised model stack

Different tasks need different controls.

A friendly conversation, a curriculum decision, a mathematical calculation and a safety judgement are not the same kind of task. KIDNOVA should not ask one unrestricted model to perform all of them.

A specialised model stack infographic showing six different controlled components: child conversation, curriculum reasoning, mathematical verification, safety, localization and the digital twin.
Different tasks need different controls. KIDNOVA should not ask one unrestricted model to do every job.

Deterministic verification

A plausible answer is not enough.

Generated language can sound confident while being wrong. Arithmetic, scoring and other high-stakes calculations should therefore use dependable checking tools rather than rely on generated wording alone.

A three-step verification flow showing proposed explanation, verified calculation or rule, and a final child-safe response.
A plausible answer is not enough. High-stakes outputs should pass through dependable checking before anything reaches the child.

Audit and governance

Important changes should leave an understandable record.

When KIDNOVA materially changes a teaching path, the system should be able to explain what changed, why it changed, what evidence informed the decision and whether a human reviewed it.

Illustrative adaptation recordAR-0247
What changed?
Written explanation changed to a visual tens-and-ones model.
Why?
The child added the ones correctly but confused the tens.
Evidence used
Current answer, help request and prior visual-support preference.
Result
The child explained that three tens and seven ones make 37.
Human review
Available to the authorised parent or teacher summary.

Current status

A defined architecture is not the same as a finished platform.

The KIDNOVA concept is developed enough to support product discovery, prototype planning, partner discussions and pilot design. It still requires engineering, testing and independent validation.

Defined

Concept and governing boundaries

Audiences, learning model, safeguards, system roles and development direction.

To prototype

Working product experience

Child interface, parent controls, teacher tools, model orchestration and data flows.

To test

Safety and reliability

Security, red-team testing, bias, accessibility, consent, retention and escalation.

To validate

Educational effectiveness

Independent evidence that children genuinely learn, retain and transfer skills.

Continue the journey

Architecture becomes meaningful when it can be tested responsibly.

See how KIDNOVA could move from a carefully structured concept to a focused pilot and credible development path.

See the Pilot and Vision →