Skip to the main content

How the AI works

Flock has four models, each with one job. We trained two of them ourselves. The other two are Google’s Gemini, with our own rules around it.

Tap a model to jump to it.

Starling forecasts how busy a place will be

Starling is 800 small decision trees, each one fixing what the trees before it got wrong. It reads the hour, the weather, events nearby and the venue’s usual week, and gives a busyness score from 0 to 100 for every hour.

We tested it on three cities it never trained on: Miami, Barcelona and Tokyo.

The live readings it learns from are estimates on that 0 to 100 scale, not head counts. On them, its learned layer adds little over a venue’s usual week, so where Flock knows that week, the number on the venue’s card starts from it and moves with the latest readings. The research page has the numbers.

Inputs such as the hour, the temperature, whether it is raining and events nearby run through 800 trees, each fixing what the ones before it got wrong. Out comes the venue’s usual week plus a correction: busyness for each hour, 0 to 100.
A schematic, not real readings.
A world map of the cities Starling learned from, with Miami, Barcelona and Tokyo circled.
Miami, Barcelona and Tokyo were held out of training.
Code from backend/scripts/ml/train/train_model.py: 800 estimators, minimum child weight 7, maximum depth 8, cross-validation grouped by city, and the forecast clipped to 0 to 100.
The training settings, from the repository.

A forecast is a guess, and it says so

Flock marks the forecast as an estimate. When a venue knows better on the night, its owner can set the live number from their dashboard. Groups see it credited to the place, like “the cafe says”, and it lasts 90 minutes.

A chart of one evening’s busyness from 6 PM to midnight, the forecast inside a shaded band marked as an estimate. At 9 the venue sets 86, 22 points above the forecast, and its number lasts 90 minutes.
An illustration of one evening, not real readings.

Owl counts people from heat

Owl is a small neural network, 718,550 weights, that runs on the Raspberry Pi inside Flux, the sensor we’re building. It reads a thermal frame and marks each person as a peak of warmth. The count leaves the sensor. The frame stays behind.

It was trained on generated frames and six public thermal datasets, then tested on footage it never saw. It hasn’t run in a venue yet.

Owl's path through a frame: a 160 by 120 thermal frame goes in, through the network's layers, and out comes a 40 by 30 map where each person is a peak. Here it finds 3 people.
This thermal frame is generated, not a picture of real people.
Code from flock-sensor/main.py: a peak is a cell at least as sure as all eight neighbours, the same rule training scored the model with.
How a peak becomes a person, in the sensor’s code.
The Flux sensor deletes the frame and sends only “count: 3” to the Flock server.
Only the number goes to Flock.

Roost’s advisor can’t write a number

Roost is the plan for venues, and its advisor answers an owner’s questions in plain sentences. The model writing them, Google’s Gemini, isn’t allowed to type a single digit. Every number is filled in afterwards from the venue’s measured data, and a draft with a digit in it is thrown away.

And Birdie

Birdie is the assistant inside the app, built on Google’s Gemini. It suggests places that fit the group and asks before it does anything for you.

A venue owner asks when they peak this week. The answer: Friday. The dinner rush builds and peaks near 7 PM, about 92 on our index. Friday, 7 PM and 92 are highlighted as filled in from measured data.
An example answer. The highlighted values come from measured data.
Rule 3a of the advisor’s instructions: “You may not write a digit. Not one, anywhere.” Beside it, the check in backend/services/advisorPhrasing.js that rejects any draft with a digit.
The rule, and the check that enforces it.

See how they did

The research page scores the forecast and Owl on data neither one trained on, including where they fell short.