Privacy & notices

What the tower processes

Cameras built into the tower produce frames of the room. Every model runs on the tower itself — face detection, the numeric signature that groups a person to themselves, expression, head pose, age band and gender. On a default configuration no inference call leaves the device.

For each face found in a frame the tower writes one record: the timestamp, which camera saw it, the box it occupied, detector score and pixel size, the embedding, expression, an attending flag, age band, gender, head and gaze angles, and where it sat in the room. That is the complete list, not a summary of it.

There is no name, no ticket id, no badge scan, no device MAC address and no wifi probe anywhere in that record — and no identifier that outlives the event.

What reaches you is statistical: a unique attendance count, attention distributed across the zones of the room, and sentiment aggregated at the level of the audience.

The face embedding, named plainly

Counting one person once means recognising that two faces in two frames are the same face. The tower does that by computing a numeric template from every face it measures at identity range and grouping the ones that match. That template is a face embedding — a signature derived from a human face. We call it that rather than “just numbers”, because a reviewer assessing this system has to be able to weigh it as what it is.

Detections beyond identity range carry no embedding at all — they store an empty vector, so counting a far crowd produces no template of anybody.

The person an embedding is grouped under is an integer that starts at 1 in every session and means nothing outside it. There is no second number anywhere linking it to a person, a seat, a ticket, or another event.

What sits on the tower's disk while the event runs

At default settings the tower writes full-resolution frames, face crops and embeddings to its own encrypted storage for the duration of the event. It has to: grouping the same person across an hour of frames is what makes an unduplicated count possible, and that work happens at the end, over everything retained.

Storage is AES-256-GCM, with a key generated on first run and held at file permissions 0600.

The honest limit: that key sits on the same disk as the data it protects and is not yet wrapped by a secure element. It defends against a disk removed and read elsewhere. It does not defend against someone who obtains root on a running tower. We would rather say that than let the word “encrypted” carry more weight than it can hold.

The lifecycle, and the moment the footage dies

Capture → finalize → issue a signed report → purge the raw data. Every transition is appended to a hash-chained audit log, so a step deleted or altered afterwards is detectable — and the chain is anchored to a head written in a separate file, so hiding an entry takes a consistent edit of two files rather than truncating one.

By default the raw store is deleted the moment the report is exported. The delete removes the entire raw tree and sets a flag that refuses every later raw write, so a capture cycle still in flight cannot resurrect face data after a purge has completed.

Retention is opt-in, and the explicit opt-in wins over every other combination of settings — a control like this has exactly one safe direction to fail in. With retention on, the tower skips the purge, writes a `purge_skipped` entry with its reason into the signed chain, and the operator console changes the notice it displays. A tower that kept footage cannot quietly imply otherwise.

Four tests hold that behaviour in place, rather than a sentence like this one.

What never happens

• No identification. There is no watchlist, no enrolment gallery and no face database to compare anyone against — those concepts do not exist anywhere in the code.
• No per-person record reaches you. Neither the live dashboard nor the report contains a single row about an individual.
• No identity carried between events. Nobody recognised in this room is recognised in the next one; the session's ids are destroyed with the raw data.
• Nothing that identifies a person leaves the venue. Where two towers cover one room, each publishes a per-person centroid — the mean of that person's face embedding — to the other over the venue's own network, so somebody standing in both fields of view is counted once. A centroid is a template derived from a face; it travels on your network and it goes no further.
• No tracking across venues or across time. Each event is closed on itself.

What crosses a network, exactly

Between towers, on your own network: the centroids described above, and nothing else. That exchange is an allowlist of seven fields, built one field at a time, so an attribute added to a detection next year cannot ride along with it. A recursive gate refuses raw bytes, image-shaped field names, data URIs, base64 image magic, over-long strings and deep nesting — on the way out and on the way in, so a compromised tower cannot push frames sideways into a healthy one.

To us: nothing at all unless a relay address is configured, and the default is empty. A tower with no relay address never opens the connection.

When one is configured, what is pushed is aggregate numbers against a closed field list: unique attendees, peak concurrency, occupancy peak, mean attention, net sentiment, average dwell, and a demographics block that accepts only age bands and gender as label→share. The cross-tower block accepts counts, tower ids and a threshold — and refuses a list of numbers where tower ids belong, on grounds stated in the code itself: a list of numbers is what an embedding looks like, and this store never holds one. Anything else is refused with a 400 and never written.

That is the part worth understanding. Anonymity here is not a promise the server keeps by intention. It is a shape it refuses to store.

Separately from event data, a tower reports on itself: its id and public key at enrolment, signed vitals (version, CPU, disk, online), and signed counters for billing — sessions, frames and faces. Those describe the machine, not the audience. Frames and faces are counted; not one of them is transmitted.

The two cloud paths, stated exactly

The report narrative — real, and off unless you turn it on. The narrative paragraph in your report is written offline by default, by a deterministic writer that is always available. If an operator switches the provider to an external model, that paragraph is instead written by an API call carrying the event's name and the final aggregate metrics as JSON — counts, shares, timeline points. No images, no embeddings, no per-person rows. Any failure falls back to the offline writer.

Cloud vision enrichment — not built. There is a seam in the code for sending sampled face crops to a third-party vision service. It cannot send anything: the function that would construct such a client returns nothing on both branches, with a key configured and without one. The honest statement today is that raw imagery never leaves the tower and the feature that would send it does not exist. If it is ever built, a written zero-retention agreement with that provider becomes a prerequisite for shipping it — not a description of something already in place.

Visibility in the room

IRIS is built to be seen. It is a two-metre column standing at the front of the room with a lit seam, not something concealed in a ceiling. Coverage is set and reviewed before the event starts, so the operator knows precisely which part of the room is measured and which is not.

The product ships no attendee-facing signage. Nothing in it generates, displays or prints a notice to the people in the room, and no signage artwork exists in the product today. Signage at your venue is something we agree with you before the event rather than something the tower does on your behalf — and we would rather tell you that now than have you find it out on the day.

What has not been done

No penetration test, no external audit and no certification of any kind has been performed on this system. Nothing on this page should be read as one, and if you are ever handed a document that reads like one, it did not come from us. When that changes we will name the auditor and the date.