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, where it is kept, what leaves the country, 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 change their own details, and there is no page here where they could. 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. A correction goes through the centre.
Where this runs
Jugglr runs on Amazon Web Services in Sydney, Australia — the ap-southeast-2 region. The database, the backups and the event log are all there. Storage is encrypted at rest, and backups are retained for thirty days.
One thing leaves the country, and it has its own section below.
The assistant, and the one thing that leaves Australia
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 OpenAI, in the United States.
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.
No child data is part of it. The assistant sees room occupancy as numbers — never a pseudonym, never a birth date, never an attendance record for an individual child.
Every question, every answer and every tool the assistant used is recorded, so a decision can be explained months later.
A machine decides these hours
Jugglr decides who works, when they start, and when they take their break. It is worth saying that in those words rather than calling it a suggestion. Those are decisions about somebody’s pay and somebody’s week, and they are made by software.
Two things constrain it. The first is that no roster reaches an educator until a person puts it into force: the engine produces a roster marked as awaiting review, and publishing it is a separate, deliberate act by the director. The second is that every placement records the rule that produced it, so the question why am I on at 06:45 has an answer that can be read back months later rather than a shrug.
An educator who disagrees with a roster raises it with their director, who can change it — and the change is recorded as theirs.
Signing in, and 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.
There is a sign-in, and nobody can create their own account. Accounts are made by an administrator, one at a time, and are stamped with the single centre that account can see. Every table that holds centre data enforces that stamp in the database itself, so a token for one centre reaches nothing belonging to another. Passwords are at least twelve characters and are never seen by this application.
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.
Asking what is held, and complaining
A centre can ask us for everything held about any of its educators, or about any child, and we will provide it. So can an educator, through their centre — the centre holds the employment relationship and can confirm who is asking, which this system cannot do for somebody it has never met.
Corrections go the same way. A name spelled wrong, a qualification recorded against the wrong date, contact details that have changed: the centre makes the change and the change is recorded.
Write to privacy@jugglr.com.au. We will acknowledge within five business days and answer within thirty. If the answer is not satisfactory, a complaint can be taken to the Office of the Australian Information Commissioner at oaic.gov.au.
What is not built yet
Jugglr is in trial with one centre. Rather than describe what is planned as though it were finished:
- 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 an educator to change their own details, or for a family to ask what is held about their child. Ask the centre; they can ask us.
- Sign-in accounts exist for directors. Educators do not have one yet.
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 privacy@jugglr.com.au.