What happens when something breaks

South African schools do not have reliable connectivity, and a queue of children at a gate does not pause while a phone waits for a server. So the gate is built on one rule: the phone decides, the school records.

A slow, flaky or entirely absent connection changes how long a check-in takes to reach the school’s records. It never changes how long the officer waits.

The phone does not ask permission

When a badge is tapped, the phone already has what it needs — who is on the roster, who is expected, what each badge means — and it answers from that. The answer is drawn on screen in about sixteen thousandths of a second, measured across a thousand-learner roster, and it stays there whether the connection is perfect or dead.

This is not an optimisation that kicks in when the signal drops. It is how every scan works, all the time. A system that is fast when the internet is good and slow when it is bad is a system that fails exactly when a queue is longest.

What the phone decides for itself

Three things happen without any help from the school’s servers.

An ordinary check-in or check-out is recorded and confirmed. That includes a learner the phone’s roster thinks is inactive. The phone’s copy of the roster can be hours old, and being wrong there means turning a real child away at a gate. The school’s records settle the question afterwards.

A double tap is absorbed. Scan the same badge twice in a few seconds and the phone tells the officer it has already been done, rather than sending a second record and waiting to be told off.

A lockdown the phone already knows about stops a release. Safety states are pushed out to gate phones and held there, so a lockdown the phone has been told about is enforced with no connection at all. This is the only thing that stops an officer.

Everything else — the checks that need the school’s live records — happens after the fact, not in front of the queue.

Recorded and sent are two different things

The phone is scrupulous about the difference, because it matters. A check-in the phone has recorded is not yet a check-in the school has.

A scan that has not yet been sent shows on the receipt as “Saved on this phone - not sent yet.” — and a visitor sign-in in the same state says the visitor is “saved on this phone — NOT sent yet. Sends automatically when you’re back online.”

There is a running count at the top of the gate screen, and a screen behind it called Scans waiting to send, which lists every check-in and check-out this phone is still holding. When it has all gone through, it reads “All scans sent”.

If the connection goes, the gate says so and says what it means: “You’re offline — you can still check learners in and out; they’ll send automatically when you’re back online.”

None of that requires the officer to do anything. It exists so that “recorded” never has to be taken on trust.

What the school sees meanwhile

This is the part a principal should understand clearly.

While a phone is holding scans, the school does not have them. They are not on the dashboard, not in attendance, and — importantly — guardians have not been notified. Notifications go out when the record reaches the school, not when the badge was tapped. A gate phone that has been offline for twenty minutes means twenty minutes of parents who have not yet had their message.

When the connection returns, the queue drains and everything lands. Parents are notified then, the dashboard fills in, and attendance updates.

The times stay honest through all of this. Each record keeps the moment the badge was tapped, not the moment it arrived. A check-out at 14:03 that reaches the school at 14:23 is recorded as 14:03 — and the message to the parent, the attendance mark, and the history all say 14:03. The arrival time is kept separately, so the two questions — when did this happen, and when did we hear about it — always have separate answers.

Nothing is thrown away

When the phone sends its queue, it sends up to a hundred records at a time and gets an answer for each one individually. One record the school refuses never stops the other fifty from landing — partial success is the normal case, not an error.

The school’s answer distinguishes two things that look the same and are not. A record the school has decided is invalid is final: the phone stops trying, corrects itself, and keeps the record for a human to look at. A record the school could not decide on — a timeout, a fault, a bad moment — stays queued and is tried again. Collapsing those two would mean either discarding real check-ins because of one bad second, or retrying a doomed record forever.

If the officer’s session has expired, the work is held and the officer is asked to sign in again. It is never discarded, and it never stops them scanning.

Retries slow down as they fail, with a small random spread so that every phone at a school does not retry in perfect unison the moment an outage ends. A phone that is backing off is still holding everything it has.

When the school disagrees afterwards

Because the phone records first, a record the school later refuses means the learner already walked through the gate. There is nothing to undo. What the system produces is a record for an administrator to reconcile, not a recall.

That is a deliberate trade, and it is the right way round for a school: a child who is at the gate gets through, and the paperwork catches up.

Limits worth knowing about

Some things genuinely cannot reach a phone that is not connected, and the honest answer is to name them rather than imply otherwise.

A lockdown declared while a phone is offline does not reach that phone until it reconnects. A push cannot arrive where there is no connection. The gate displays when safety was last confirmed rather than implying either answer, and it never blocks scanning simply because that information is old.

A collection restriction recorded this morning does not reach a phone that has been offline all day. Restrictions travel with the roster copy, which refreshes on its own schedule and whenever the phone syncs. Every connected gate enforces the restriction regardless of what any phone believes, so the exposure is a narrow one — an offline phone, a restriction recorded today, a release before the next sync — but it is real. A school recording an urgent restriction mid-morning should assume a phone that has been offline since breakfast is still working from yesterday’s answer, and should say so to the officer directly.

A badge reported lost has the same shape. Every connected gate refuses it immediately. A phone that has been offline since before the report still accepts it until it next syncs. Neither case is silent: the record lands in the school’s history like any other queued scan.

A roster copy ages, and the gate says so. Past its expiry the copy stays usable for a further grace period rather than vanishing overnight and leaving an officer with no roster at all at 06:45. The gate displays when the learner list was last updated and carries on scanning. A successful sync renews it.

What this means for the school

Two practical things.

Keep at least one gate phone that reaches the network during the day. Everything still works without one, but the school’s dashboard, attendance and — most visibly — the parents’ messages all wait on the phone that is holding the records.

And treat the waiting count as information rather than an error. A number sitting there at the end of the morning rush is the system telling you something true about your connection, at the moment you can still do something about it.