Platform · Ejections management

Ejection and refusal records

Recorded where they happen, on a form you configure per event, with a welfare assessment that cannot be skipped.

Status

In build

Ejections is in build. Records, welfare gates, the field device app and the registers are working; appeals workflow and banning-order distribution are still being finished.

The problem

  • An ejection is written on a carbon pad an hour later, by someone who has since dealt with four other things.
  • Welfare is the part that gets missed, and the part a coroner asks about.
  • Photographs end up on a personal phone with no policy governing them.

What it does

  • Warnings, refusals and ejections as one record type with a defined process and a status.
  • A welfare assessment is required before an ejection or refusal can be completed — vulnerability, intoxication, age, lone status, weather and where the person was released to.
  • Force used or a safeguarding flag holds the record for supervisor review automatically.
  • Photographs and descriptions under an explicit policy, with a written justification and retention set per event.
  • Per-event form builder, so a stadium and a town-centre venue do not share one compromise form.
  • Scoped device links: a tablet at the tent can create records and read nothing, time-limited, rate-limited and revocable.
  • Officers identify themselves with a PIN or SIA number, so attribution survives a device four people use in a night.

How it joins up

  • Control shows each intervention as a referenced line in the log with the priority applied.
  • Reports counts interventions per thousand attendees and by zone, ejection reason and time of night.
  • Staffing supplies the officer identities that the field device matches against.

Who it is for

  • Head of security and supervisors running an ejections point.
  • Venues that have to produce a defensible record after an incident.

The rest of the platform