JugglrJugglr

Privacy

Jugglr builds staff rosters for childcare centres. To do that it holds information about the educators who work there and about when children attend. This page says what it holds, how it is protected, and what happens when somebody leaves.

Children are never named

Jugglr does not store a child’s name, and has nowhere to put one. What it holds about a child is a date of birth, the times they were signed in and out, and which room they were in. Each child is identified by a pseudonym.

The pseudonym is a keyed hash — an HMAC-SHA-256 — of the reference your attendance provider uses, with a secret held per centre. It is deliberately not a plain hash. Provider references are short numbers, so an unkeyed hash of one can be reversed by working through every possible value in seconds; over a known enrolment list that is not a pseudonym at all, it is a lookup table nobody has built yet.

The only record that connects a pseudonym back to a real child is a single encrypted column in a single table. Deleting that one row erases the child: the attendance history stays, so the forecast keeps its shape, and it becomes permanently impossible to say whose it was. Where a centre hands us data that was already pseudonymised, there is no such row at all and never was.

A date of birth rather than an age band, because the ratio a room must meet changes on a birthday and a band written down at import time quietly goes stale. The date is used to work out which band a child is in on a given day; it is not displayed anywhere, and the row it sits on carries no name.

Educators

About each person who works at the centre, Jugglr holds what a roster needs: their name, their role, whether they are permanent or casual, their contracted hours, their qualifications and when those expire, their availability, their leave, and contact details the centre already keeps.

It also holds the centre’s own rules about people — she cannot open on a Tuesday, he should not be rostered to heavy lifting. Some of those concern somebody’s health or wellbeing. Those are marked as personal, and a reader who is not the centre’s director can be given the roster with their wording withheld.

An educator cannot yet sign in and change their own details. Until they can, every change is made by the director and is recorded as having been made by the director — which is the honest record, and is why the self-service page is not built rather than being built under the wrong name.

The assistant, and what leaves this system

A director can ask the roster questions in plain English and ask for changes. Those questions are answered by a large language model, which today means a request to an external provider.

What is sent includes real staff names, hours, and the wording of the centre’s rules about people — including the personal ones. That is a deliberate trade and it is worth stating plainly: with those rules withheld, the assistant twice refused to explain why it could not move somebody, because a rule it could see the existence of but not read stood in the way. Only the director talks to it.

Every question, every answer and every tool the assistant used is recorded, so a decision can be explained months later. Children are never part of any of it: the assistant sees room occupancy as numbers.

Nothing has a password in code

No credential, key or connection string is written into this system’s source. Database access is by role; secrets come from a managed secret store and are read at run time.

The link in a roster email is a signed token that opens one fortnight of one centre, lasts seven days, and can be revoked. Changing the roster identifier in the address gets you nothing. It is deliberately not a way in to anything else, and the pages that hand over contact details and contracts refuse it.

History is kept, and that is the point

A roster must be able to explain itself six months later, to a director and to a regulator. So every decision is recorded as an event and events are never rewritten — what changed, when, and why.

That is in tension with deleting somebody, and the answer is not to quietly keep them: a departing educator’s personal details are removed while the structural record stays, so a shift that happened is still recorded as having happened and is no longer attributable to a person.

What is not built yet

Jugglr is in trial with one centre and does not yet run on the internet. Rather than describe what is planned as though it were finished:

  • There is no sign-in. The only way in is the emailed link, and only a director has one.
  • Removing a departed educator’s personal details is designed and is not implemented. Their name is currently stored as ordinary text.
  • There is no page here for a family or an educator to ask what is held about them. Ask the centre; they can ask us.

This page will be updated as each of those changes, and it is versioned with the software it describes.

Questions about a specific child or educator go to the centre, which holds the relationship and the consent. Questions about the system itself can come to us.