How the data path works

Written for engineers and reviewers. The plain-language version for parents is Privacy by design.

Status: reference implementation. On-device inference measured on the bench; mesh and hub prototyped with off-the-shelf parts. Not a certified product.

Only the meaning leaves the room. Devices form a local mesh and talk to each other and to a classroom hub with no router in between. Raw audio dies on the toy. Only labels reach the hub. Only signed, encrypted labels reach the cloud. One rail runs from the toy in a child's hand to the record a teacher reads, and it runs one way.

Two tiers, one rule

Two tiers. The chip hears and forgets; the hub receives notes only and is the single connected device.

Do not make the small chip do the hub's job, and do not let the hub hear what the chip heard. That separation is the whole design.

The rail, step by step

From the toy in a child's hand to the record a teacher reads. One direction only.

1. Capture on the device. A child presses the button and speaks. The audio exists only in the chip's working memory.
2. Infer on the device. The bounded model classifies the interaction against a named early-learning construct and a zone position, then answers the child.
3. Destroy the audio. The recording is discarded on-chip. There is no path to store it or send it.
4. Emit one event. The device sends a small structured record over the local mesh. Shape: {child, construct, zone, timestamp}. Encrypted even though it carries no biometric content.
5. Aggregate on the hub. The classroom hub collects events from every device in the room. One room's mesh never sees another's.
6. Sign and push. The hub signs each event with its device identity (did:key, how device identity works) and pushes it, encrypted, outbound only, to the teacher and parent record. The signature is verified in a trusted execution environment before the record is stored (attestation flow). No inbound ports. Nothing can reach back down the rail.

This is a data diode in the plain security sense (NIST glossary): a path that carries information in one direction and cannot carry it back.

The one claim we make

The raw audio of a child never leaves the device. Inference runs on the chip, the audio is destroyed immediately, and only small structured events with no biometric content ever sync out.

We do not say "no antenna" or "cannot connect to anything." The classroom devices do carry a low-power local radio for the mesh. The claim above is the one that survives a teardown.

What the rail is built on

Layer	What	Why
Edge chips	ESP32-S3 class microcontrollers	Cheap enough to put in a plush, capable enough to run a small bounded model
Local mesh	ESP-NOW peer-to-peer	Espressif's own protocol. Devices talk directly to each other and the hub with no Wi-Fi router, at very low power
Classroom hub	Raspberry Pi 5 class single-board computer	Hosts heavier local models, aggregates events, the single hardened internet path
Signing and audit	Locale Network attestation layer (what it is · how it works · architecture)	Every event carries a device identity signature and timestamp, verified in a trusted execution environment. Records cannot be backdated or altered after the fact
Hub hardening	Standard host hardening	No default credentials, encrypted disk, minimal services, no inbound ports, outbound-only sync

The attestation layer is the open-source IoT attestation stack from our sister company, Locale Network. It gives each device a decentralized identity (did:key), verifies signatures in a trusted execution environment (two-service architecture), stores the result deterministically so it can be queried but not rewritten, and settles proofs on an EVM chain (high-level architecture). Data is encrypted twice on the way: once so only the verifier can read what a device reported even though the proof is public, and once so only an authorised reader gets a query answer (encryption architecture). Sensitive values can be bucketed before storage (privacy bucketing), which is how a room's noise level becomes "loud" rather than a decibel trace. Full documentation: what the attestation stack is · glossary · Locale Network on GitHub. Nothing on this page requires understanding that stack; it is the signing primitive, not the product.

Why it is built this way

• Every promise the software makes, the hardware enforces. "We do not sell your child's data or train on it" is a policy in most products. On this rail it is physics: there is no upload path for the audio. "No open AI chat with the child" is a design rule elsewhere; here the edge model can only run bounded local tasks.
• Signed events make the record defensible. Attendance, ratio state, and milestone events carry a cryptographic signature and timestamp. An inspector, a coach, or a parent can trust that the record they see was written when it says it was.
• Dialect fairness runs on the hub. A speech model that hears African American English or Southern English as "errors" would systematically mis-score those children's development. Fair dialect coverage is an equity requirement, and it runs on the hub, never the toy.
• The youngest children, without recording them. For infants and toddlers who cannot yet speak, on-device acoustic classification of babble complexity, consonant-vowel transitions, and turn-taking can emit milestone events into the parent feed without ever recording the baby. The alternative on the market is a microphone in a nursery streaming to a server.

Two product lines, two privacy architectures

	Commercial line (books and toys sold to families)	Classroom line (devices inside a programme)
Radio	None required. The toy has no dashboard to feed	Local mesh to the classroom hub
Privacy claim	Nothing leaves the toy, ever	Voice destroyed on-device; only labels leave
Purpose	A product that works forever with no servers	Developmental data for teachers and parents

A home toy that answers questions about a picture book does not need to transmit anything. Classroom devices are the only ones feeding dashboards, and those live behind the programme's walls with the honest claim above.

Security threat model

Threat	Exposure	Control
Eavesdropping on the mesh	Structured events only, no biometric content	Encrypted anyway; per-room isolation
Compromise of a toy	One device's future events	No stored audio to exfiltrate; no credentials to the hub beyond its own key
Compromise of the hub	Aggregate events for one room	Encrypted disk, no inbound ports, minimal services, outbound-only; the attack surface that gets the full hardening treatment
Cloud breach	Signed events only	Signatures make tampering detectable (attestation flow); proofs are encrypted before they are stored on a public ledger (input encryption); audio was never there to lose
Company shutdown	Commercial toys keep working	No server dependency by design

Where the evidence stops

The attestation layer today verifies device data by attesting cloud-platform API responses (what Locale calls Tier 3, IoT provider patterns). The design on this page, where the classroom hub signs on behalf of constrained devices, is what Locale's own documentation lists as Tier 2, gateway-attested, under future work (Tier 2). So the signing primitive exists and is documented; the hub-as-gateway integration is design, not shipped code. We link the source rather than round it up.

On-device inference at this chip class has been measured on our own bench (a 28.9M-parameter bounded model at roughly 9.5 tokens per second on an ESP32-S3 reference board). The mesh and hub have been prototyped with off-the-shelf parts. Independent security review, COPPA compliance sign-off, and any state-specific student-data requirements are open gates. This page describes a design and a reference implementation, not a certified product.

Sources

1. Espressif, ESP-NOW. https://www.espressif.com/en/solutions/low-power-solutions/esp-now
2. NIST CSRC glossary, data diode. https://csrc.nist.gov/glossary/term/data_diode
3. Locale Network on GitHub. https://github.com/locale-network
4. Locale Network, What is the attestation stack. https://docs.locale.cash/lcore-sdk/introduction/what-is-lcore
5. Locale Network, How it works (architecture, device identity, attestation flow, privacy bucketing). https://docs.locale.cash/lcore-sdk/introduction/how-it-works
6. Locale Network, Encryption architecture. https://docs.locale.cash/lcore-sdk/data/encryption-architecture
7. Locale Network, IoT provider patterns and future work (Tier 1/2/3). https://docs.locale.cash/lcore-sdk/guides/iot-providers
8. Locale Network, Architecture overview. https://docs.locale.cash/lcore-sdk/architecture/overview
9. UNICEF 2021, Policy guidance on AI for children. https://www.unicef.org/innocenti/reports/policy-guidance-ai-children