The hazard log is where every design decision gets checked against one question: what could this lead a child or parent to do that is unsafe, and what stops that? It’s a lightweight log in the spirit of a clinical safety case, borrowing the shape of DCB0129, the clinical safety standard for health IT. It isn’t a formal safety case.
I started it on 18 October 2026 with nine hazards, before there was any code. It has thirty now.
How it’s scored
Each hazard has a cause, an effect, and a rating before and after controls. Severity runs from 1 (minor) to 3 (injury on the road). Likelihood runs from 1 (unlikely) to 3 (likely). The rating is the two multiplied. Most hazards start at 6 and come down to 3 once the controls are in. I’ve left almost all of them marked Open, because approving a control isn’t the same as seeing it work. Several get checked at the playtest.
A gate can’t pass while a safety defect is open. At the playtest that means a wrong feedback tier, a timer anywhere, harm imagery, a banned word, or crossing tolerance outside its conditions. Everything else goes on a ranked fix list.
Where the hazards come from
- Wrong content. A rule that’s incorrect, outdated or borrowed from a country that drives on the right (H1, H6, H13, H14). Controls: a source on every rule, source versions pinned, and a check that every child phrase maps to a step of the Green Cross Code.
- Wrong incentives. Rewards for speed or for going outside (H2, H7).
- False confidence. A child, or a parent, concluding that playing the game means being ready (H3, H22, H25).
- Design drifting during the build. Timing pressure creeping in, or tolerance being applied where it shouldn’t be (H15, H20).
- The picture misleading. The screen showing something the geometry says isn’t true (H17, H29).
Four that changed the design
H18: the rehearsal displaces the walk. This is the only hazard that started at 9, the top of the scale. An engaging screen session is easier than a walk of 25 to 30 minutes, and the evidence says the walk is the part that changes behaviour. A family could do the rehearsal every week and never go outside. I found it by checking the design against the Education Endowment Foundation’s guidance on digital technology, which warns that a good tool can crowd out other practice. The controls: every rehearsal ends by handing over to the parent with that week’s walk; the parent view opens on the walk, not on rehearsal progress; the parent induction states the time commitment and that the walk matters most; and logged walks never unlock anything, because that would create a reason to go out alone. It now sits at 6.
H17 and H29: a look that sees nothing, and a picture that lies. H17 came from Kerbcraft. The game credits a look only from a spot with a real view down the road. H29 came out of the build. A build session found that the kerb view could show a car further down the road while the scene was telling the child that a van hid the road. The picture and the words disagreed. Three week 2 scenes failed the new check, and I moved each vehicle, from 35, 40 and 30 metres, to 20 metres so the van hides it. A build check now fails if a direction with no view shows any vehicle.
H15: tolerance drifting into gap judgement. At the older stages the game silently tolerates a crossing made while one distant vehicle approaches on a slow road. It never rewards it, never comments, and counts it the same as waiting. The margins are multiples of each scene’s crossing time T, where T is the road width divided by 1.0 m/s, plus a second. Stage B needs the vehicle at least 3T away and stage C at least 2T, and a build check rejects anything below 2T at any stage. Tolerance applies only on slow roads with exactly one vehicle, no bend in view and a valid look. On a typical 7 metre street at 20 mph, 3T is about 24 seconds, or around 215 metres. The evidence for these margins is moderate. One of the sources is a trial protocol, so its figure is a working definition and not a measured threshold, and I’ve said so in the log. Neither of my children uses tolerance at present, because both start at stage A.
H27: generated speech changes the meaning of a safety line. Every line a child hears is made by an offline text-to-speech tool. A mispronounced “Don’t step out” could be heard as “Do step out”. So every clip is listened to against its text before a release build is allowed, and the review is recorded against a hash of the text. Edit a line and its review stops counting until someone listens again. I listened to all 134 clips on the iPad.
It kept growing
The log wasn’t written once and left. H10 to H17 came from the source review on 19 October. H18 came from the EEF review the same day, and H19 to H26 from the programme design. H27 and H28 came from the build brief on 20 and 21 October (H28 is a cached old version of the app carrying on teaching a rule after it’s been corrected). H29 came from the third build session on 21 October. H30 came from my family testing on the same day: the arrow that moves on to the next screen could be tapped before Pip had finished speaking, so a child could skip the explanation. That one is proposed rather than accepted, and I’ll watch how often it happens at the playtest before deciding what to do.