Changelog

Release notes.

This log is written from the release history — it summarises the user-visible changes that shipped, month by month. Entries are dated to the month they landed; where something is built but not yet switched on, the entry says so.

August 2026

8 release areas

LEDS asks what the enquiry is, not just why

The access gate on every LEDS record now captures a policing purpose and the operational reason for the enquiry alongside your written explanation — the same two-part record a real national police system keeps. You can also tie the check to the call it came from.

Pick the policing purpose the access falls under, and what you are doing — a stop, a collision, a custody check, an intelligence enquiry, and so on.
The purposes shown follow your service's jurisdiction.
An optional CAD reference ties the check to the job it came from, so an audit can answer what was looked up off the back of a call.
The written explanation stays, with the same minimum length, and now sits below the two questions — answering them first makes clear what the explanation is actually for.
Every gate now asks the same thing in the same way. Six screens had drifted apart, and one told officers ten characters was enough while rejecting anything under twenty.
Skipping the purpose is restricted to platform management, is separately recorded, and no longer available to support or administration staff.

A call now shows what came of it

A CAD incident can be linked to the records the job produced — a crime report, a search, a custody record, an intelligence submission — and the link works in both directions. Open the call and you see everything that came out of it; open the report and you see the call it arose from.

Link records to a call from the incident screen: pick the record type, type its reference number, and say what the relationship is.
Four relationships, because those are the ones that mean something operationally: the incident produced the record, resulted in it, it was recorded while the call was live, or the call merely refers to it.
The wording changes side with the reader. The call says it produced a crime report; the crime report says it arose from that incident.
Links use the same system every other record already uses, so a call sits alongside people, vehicles, addresses and every report family rather than in a list of its own.
Records link straight back to the call, and opening one takes you into the console with that call loaded.
A closed call keeps its links on screen but stops accepting new ones, matching how the rest of the incident screen behaves.

The Org Chart can be read three ways, and you choose the columns

The organisation chart is no longer only a diagram. A switcher inside the module moves between the chart, an indented establishment table and a command picture grouped by tier — and the establishment table shows the datapoints you pick. Your choice is remembered, and a community sets what everyone starts from.

Three views: the diagram, an establishment table showing the structure as an indented list, and a command picture grouped by tier that leads with unfilled posts.
The switcher sits in the Org Chart itself, not in a settings screen, because which view you want depends on what you are checking rather than on how you like the product to look.
On the establishment table you choose which datapoints sit beside the unit name — short code, level, lead, rank, strength, service and others. Unit name is always shown.
Your view and your columns are remembered. Changing your workspace appearance does not move them.
A community sets the opening view and the starting columns for everyone. That is a starting point only — it never overrides a member who has already chosen for themselves.
Vacant command posts are called out as vacant in every view, in words as well as colour.

Three workspace appearances, and where the navigation sits

OpsCentre can now be laid out three different ways, chosen by each member with a community default. These are genuinely different designs rather than colour schemes: they differ in density, in how records are grouped, and in how you move around a member's record.

Standard is the layout OpsCentre has always had. Operational is a dense records presentation — more columns, tighter rows, identifiers first. Briefing leads with figures and groups people by posting.
The dashboard, the Members directory and the member record all follow the appearance you choose.
On a member's record the three appearances differ in how you navigate it: a tab strip across the top, an index down the left, or panels you open in a column.
Navigation can sit down the left-hand side or across the top of the page. Both show exactly the same links.
Every appearance works in light and dark, and alongside the accessibility settings — colour-vision adjustment, dyslexia-friendly type, increased contrast and reduced motion.
Changing appearance never changes what you can see or do. The same records, the same controls, arranged differently.

Last on duty on the Members directory, if your community wants it

The Members directory can show when each member was last on duty, taken from Duties. It is off or on per community, and when it is off the information is not sent to the browser at all rather than merely hidden.

A Last on duty column on the Members directory and on the member record, sourced from duty sessions.
Someone currently booked on reads as On duty now rather than as a timestamp, and a member who has never booked on reads as Never rather than a dash.
Voided duty sessions are excluded — a retracted record does not make somebody look recently active.
Switched off in Community settings, the column is not shown and the underlying dates are never sent to the browser.
Only members who can already see the roster ever see it. It is not included in the colleague picker.

Comment types restricted by desk, rank and qualification

A community can now decide who may use each remark type, not just where it may be used from. A type can be limited to several control-room desks at once, to officers at or above a given rank, or to holders of a named qualification — and the console only offers what the server will accept, so a control that appears is a control that works.

A remark type can be restricted to any number of desks rather than a single one, so a type shared by two control-room positions no longer needs duplicating.
A type can carry a rank floor. The floor is read in the rank the officer holds in the service the remark belongs to, so a rank held in another service does not unlock it — and an acting or temporary rank counts only in the service it was granted in.
A type can require a qualification, matched against what the member actually holds and ignoring anything expired.
Restrictions apply to canned templates as well as to types, and are enforced on the officer's mobile terminal as well as in the control room.
Where a type is unavailable the console says why — naming the desk or the rank required — rather than quietly leaving it out.

Protected nominals are protected against changes, not just reads

Records marked as protected — a protected witness, an officer working under cover, a high-risk subject — could already only be READ by officers holding the protected-nominal entitlement. That restriction now covers every change to the record as well.

Editing, adding to, or deleting a protected record requires the same entitlement that reading it does. Previously the read was restricted and the write was not, so a record could be altered by somebody who could not see it.
This covers the whole record: identity details, aliases, associates, addresses, markers, circulations, court orders, custody, DNA and photographs.
Directors and LEDS administrators keep access to their own protected records. The rule was previously stricter on reads than the platform intends, which could lock out the two most senior roles.

Ops Messages say who may work them

The controls for issuing, closing and logging on an Ops Message are now shown only to the control-room desk that actually holds them, and the screen says plainly when no desk has been given the role.

Issuing, closing and writing in the running log are offered to the controlling desk and nobody else. The buttons previously appeared for anyone holding the permission and were refused on use, while the controller who genuinely held the desk could be shown no composer at all.
Holding a public-order command role no longer offers the log composer. Command issues the instruction; the control-room desk writes it into the log and broadcasts it — which is how it already worked on the server.
Where no desk has been given the Ops Message role, the screen says so and points to the setting instead of showing an empty panel.

July 2026

16 release areas

Pursuit and firearms command on the live console

Controllers can now run a vehicle pursuit or a declared firearms incident from the dispatch console, using the command structure and tactical authorities police forces actually use. A pursuit runs from a vehicle failing to stop, through an initial phase, into tactical options; a firearms incident stands up its command roles, authorises arming, and works through the recognised tactical options. Officers see the whole command picture, read-only, on their mobile terminal.

A pursuit is marked from the moment a vehicle fails to stop, then authorised through its phases and tactics — rolling roadblock, box, tactical contact and stinger — with car counts and pre-planned intercepts where they apply. Any controller can mark the fail-to-stop; only a pursuit authoriser can authorise the tactical phase.
A declared firearms incident stands up its command roles — operational, initial and cadre tactical, and strategic — authorises arming and its mode, and works through the recognised tactical options grouped by where the subject is: on foot, in vehicles, in buildings, location unknown, or a contaminated environment. The most serious options require strategic authority.
The response is set to form up at a rendezvous point or go straight to scene, and the whole command picture — who holds each role, arming state, tactics authorised — is mirrored read-only on the officer's mobile terminal.
Both run entirely on the console with the flat control-room look, and are recorded — a pursuit feeds the involved officers' driving records afterwards.

Typed remarks and firearms markers for officers and controllers

Officers can now add typed remarks — use of force, medical, and the other categories a community configures — from their mobile terminal, not just plain text. Controllers see at a glance which live calls are firearms or pursuit incidents, and any action taken from a control-room desk is now attributed to that desk rather than the person's substantive rank.

Units add typed remarks from the terminal; the types on offer are the ones a community allows officers to use, and controller-only types stay out of reach.
The call list marks firearms and pursuit incidents so other controllers can see them without opening the call.
Actions taken while signed into a control-room desk are recorded against that desk, matching how a real control room attributes work.

Faster, steadier live screens

The live console and officer terminals refresh more efficiently, and the checks behind every request do less repeated work, so busy control rooms stay responsive. A database-level safety net was added so a single stuck query can no longer tie up the platform.

When something changes, connected screens refresh once, in a coordinated way, rather than every screen reloading everything in the same instant; a backgrounded tab holds off until you return to it.
Permission and access checks repeat less work per request, cutting the load a single action places on the database.
A query time limit now frees a stuck database connection automatically, reducing the chance of a busy period backing up.

Consistent in light and dark mode

The platform now reads correctly whichever theme you use. A set of panels and status messages that had fixed pale backgrounds were showing near-invisible text in dark mode; these now follow the theme, and a check is in place to keep new screens honest.

Success, warning and information callouts adapt to the theme instead of staying pale, so their text stays legible in dark mode.
The onboarding screens, the case-file review and countersign pages, the review queue and several forms were corrected.
The deliberate fixed-colour control-room skins — the dispatch console and officer terminal — are unchanged.

Service status page — every system, live

The status page now shows the current state of each part of the platform, grouped the way the app is, and keeps a running timeline for any incident from first report to resolution. The browser self-check stays, clearly labelled as a check of the web frontend rather than an independent monitor. We still publish no uptime percentages — only what we can stand behind.

Each module and platform system has its own status line, so it is clear exactly what is affected during an incident.
Incidents carry a running update timeline — investigating, identified, monitoring, resolved — with each update timestamped.
The in-browser self-check remains, and the page is honest when live status cannot be read rather than claiming all is well.

Duties and resourcing — book on and off, rosters, operations, and sign-off

A full duties and resourcing module. Officers book on and off, take breaks, and crew up with colleagues; supervisors see a live resource board, plan rosters and operations, and sign off recorded time. Times come from the actual book-on and book-off, and a correction never overwrites the original — the first record is always kept alongside who changed it and why. The whole module is presented as a control-room terminal, CARMS, with a tabbed board, colour-coded roster grid and function-key actions.

Book on with your service, callsign, unit type, equipment and command markers; take refs and resume, or invite a colleague onto your callsign — nobody is ever booked on by someone else's action.
Rosters run in published periods with planned duties, personal availability that never asks for a reason, and coverage that warns rather than blocks; a planned duty is an expectation, so booking on stays the member's own action.
Operations bring together workstreams and role slots with invitations and self check-in; the resource board and everything on it reads from one attendance source, so it can never disagree with itself.
Activity sign-off runs a review, return, decision and appeal flow with Sergeant and Inspector thresholds; approval decides what counts, never the recorded time itself, and self-approval stays off.
Your duty history separates recorded, break and counted time, shows corrections and voids in full, and can be exported; planned time never enters your recorded totals.

Computer Aided Dispatch — the control-room console

A full dispatch console for the control room. Calls come in on 999 or 101, a dispatcher grades and dispatches units drawn straight from who is booked on, and the whole board updates live. Desks, callsigns, gradings, codes, comment types and reference formats are all configurable per service, and each service sees only its own units and calls.

Grade and dispatch from the live duty board, with a one-live-assignment-per-callsign rule enforced so two dispatchers can never double-book a unit; unit status moves through a proper sequence and Call Comms clears everything down in one action.
Desks (Force Control, EOC, supervisor, firearms and more) carry their own colours, restriction rights and sign-in clearances; ambulance services grade on the real response categories rather than the police set.
Sensitive incidents can be restricted to permitted desks or officers and never leak to anyone else, on screen or over the live feed; dispatcher-only secret notes are gated separately.
Observations and BOLOs push to booked-on units in a chosen scope, ops messages broadcast planned-event information, and desk pagers run specialist call-outs that book an officer onto the paged callsign and back again when they stand down.
Operator messaging, an ANPR watchlist that lights up on genuine checks against nominated plates, and cross-service pass to hand a call to another service round out the console. Point to Point and a live map are coming soon.

Mobile Data Terminal for officers

An in-vehicle terminal that shows an officer only their own state and their current job. It reads from the same dispatch and duty sources as the control room, so there is no separate copy of the truth to drift out of date.

See your current incident and its remarks, set your unit status, take refs and book off, and raise urgent assistance as a priority the control room can acknowledge.
Alerts bring you the observations, pages and ops messages actually aimed at your unit — including lookouts for your posting type and messages addressed to you by name.
Person and vehicle lookups run through the Law Enforcement Data Service, and a prisoner-transport status and a request-callback action are built in.

The whole platform works on a phone

A platform-wide responsive pass. Every screen now adapts to a phone — the sidebar collapses to a menu, wide tables and record grids scroll instead of breaking, forms stack, and the dispatch and terminal screens pan cleanly rather than crushing.

The public website's navigation, pricing comparison and feature pages all read correctly on a phone, with the sign-in and get-started actions reachable at every width.
Records, custody, prosecution, training and administration tables scroll horizontally on small screens rather than clipping their right-hand columns.

Security and reliability hardening across dispatch and resourcing

A dedicated security review and quality pass over the dispatch and resourcing work, following an independent implementation review. Access controls were tightened so that a permission scoped to one service can only ever be used against that service, sensitive records stay sensitive on every surface including the live feed, and a range of correctness issues were fixed.

Every action on dispatch and duty records now confirms the actor's standing in the relevant service, closing gaps where a service-scoped role could act beyond its service.
Restricted incidents and protected records are consistently withheld from anyone without the right to see them, across screens, exports and real-time updates.
Reference numbering, unit state, break and resume, and the resource board were made robust against races and edge cases, and duty times stay accurate through every correction.

Authorisations: staged occurrence-log pathways and register fixes

Dispersal (s.34/35) and s.60/60AA authorisations gain the real staged pathway: a Sergeant logs the occurrence, a selected Inspector reviews and authorises or refuses with reasons, and a selected Superintendent records the oversight review — each hand-off routed as a task with notifications.

Occurrence logs route to a chosen Inspector, then a chosen Superintendent, with the pathway state shown plainly on the record.
Rank pickers only offer members who genuinely meet the required rank, counting acting and temporary ranks.
Authoriser titles now show the officer's actual rank — a Commissioner is no longer displayed using the statutory floor label.
Register links open correctly for references containing slashes, and senior authorisers keep the existing direct-grant path.

Custody welfare questions and specialist-crime closure safeguards

Custody book-in now asks the seven welfare questions — illness or injury, self-harm thoughts, suicidal thoughts, neurodiversity, medication, mental-health history, and whether the detainee wants a healthcare professional — and hate or specialist crimes can no longer be closed without a named Inspector's authorisation.

Welfare answers cross-populate the risk assessment: disclosed self-harm or suicidal thoughts set the matching risk flags, and mental-health history triggers the appropriate-adult requirement.
A healthcare-professional request is surfaced on the record so a healthcare event gets logged.
Closing a hate-crime or specialist-category report requires selecting an authorising Inspector or above; who authorised, and when, is recorded on the report and audited.
Profile-visibility settings on officer records now load back correctly when re-opened for editing.

Community-controlled support access

Platform staff can now only open a community-requested support session against a request the community itself raised. Community admins raise, track and cancel these requests from a new Configuration page, and every session records exactly who asked, who approved and who acted.

Support-access requests carry the requester, their authority at the time, the scope authorised and an expiry — staff cannot manufacture community consent.
A view-only authorisation can never be consumed by a full-access session, and the requester can neither approve nor receive their own session.
The website gained a Legal section in the navigation, and signed-in visitors get an Open OpsCentre button instead of a sign-in prompt.

Billing groundwork and data lifecycle

The subscription billing spine is now built — checkout, consent capture, webhooks and subscription lifecycle handling. It ships behind a launch gate: billing is not yet open, and the checkout surface says so honestly rather than pretending otherwise.

Checkout flow with explicit consent capture — the exact versions of the Terms, Acceptable Use Policy, Privacy Policy and Data Processing Addendum you agree to are recorded.
Subscription lifecycle handling for activation, renewal and cancellation.
Data-lifecycle controls: community data export, a retention schedule on cancellation, and suspension handling.
Billing remains switched off until subscriptions launch — no payment is taken anywhere on the platform today.

Platform-wide review and fix waves

A full-platform investigation examined every module and logged 57 findings. All of the serious ones are fixed and shipped, worked through in priority order — security first, then broken user-facing flows, then quality-of-life.

Three security holes closed before anything else.
Six broken user-facing flows repaired, plus navigation dead-ends and decision races.
Rate limiting added to every previously-unprotected mutation endpoint.
All remaining hand-rolled dialogs replaced with the shared in-app dialog — no native browser pop-ups anywhere.
Automated test and type-check gates now block every merge, so regressions are caught before they reach you.

Identity and age assurance

Account identity is now captured and verifiable, in line with the platform's 13+ policy and UK regulatory posture. Security hardening shipped alongside it.

One-time real-name and display-name capture at onboarding, with staff-managed corrections.
A re-check gate lets platform staff require re-verification of name and date of birth where misrepresentation is suspected.
An under-13 date of birth blocks the account from the product immediately; the account is then erased under a governed data-protection process, with re-registration prevented.
Sign-in protections: connection metadata capture and anonymiser flagging, restricted to senior platform staff.
Content-Security-Policy rollout and a sweep that tightened what error messages reveal.
ICO registration details published in-product.

June 2026

10 release areas

Public website

The public marketing site launched — nine pages covering the product, modules, pricing, roadmap, vision, trust and safety, FAQ and contact, with its own light and dark theme.

Every feature claim carries an honest status label: Live, In Development, or Planned.
Legal documents are readable without an account.
The whole site is reachable without signing in.

Legal documents managed in-platform

The Terms of Service, Acceptable Use Policy, Privacy Policy and Data Processing Addendum are now managed through an in-platform editor with version history and a publish lifecycle — and the public legal pages always render the live version.

Full version history for every legal document.
Draft, review and publish lifecycle with archival.
A Legitimate Interests Assessment register alongside the existing DPIA.

Court applications: statute-faithful forms

Every court application family now has bespoke, statute-faithful forms — no more generic one-size-fits-all fields. The catalogue's 104 application types were verified against published legislation across England & Wales, Scotland, Northern Ireland and the Republic of Ireland.

Bespoke forms for all seven application purpose families.
Citation corrections where the catalogue and the legislation disagreed.
Orders-in-force tracking, so granted applications carry through to live records.

Compliance foundation

The legal and safety backbone shipped ahead of the feature set: public legal pages, the independence disclaimer, dedicated contact routes, and age gating.

13+ age gating on every account, with 18+ checks where required.
One-time date-of-birth capture at onboarding, enforced platform-wide.
Dedicated contact routes for support, trust and safety, and data protection.
Transactional email delivery for account and safety notices, built and ready — it switches on once our sending domain is verified. Notices are delivered in-app today.

Granular permissions overhaul

The permission model was rebuilt for maximum granularity — communities decide exactly who can do exactly what, and where. Blanket access keys were split into per-action verbs across the whole platform.

Grants now compose three axes: the action, the record sub-type it applies to, and the organisational scope it covers (community-wide, service-wide, or a single org unit and its subtree).
Community-defined note types with their own access rules.
An approval queue for sensitive grants, requiring senior sign-off.
Absolute self-protection rules — nobody can be locked out of their own account controls by a grant.

Multi-service organisations and ranks

Communities that run more than one service — police, fire, ambulance — now get first-class support across the org structure and rank model.

Service-aware org units and command offices, with per-service and overall org charts.
A cross-service authority matrix and a community governance tier above service ranks.
Multi-service memberships: one member, multiple services, with a rank in each.
Acting and temporary rank support.

Admin permissions surface rebuilt

The community admin area was reorganised around a clearer information architecture, and the permissions tooling grew up with it.

Bundle editor — create, edit, fork and archive permission bundles.
Rank and role bridges that grant bundles automatically.
Per-member bundle apply with revoke-by-source.
Native browser dialogs removed platform-wide in the same pass.

LEDS terminal: PNC-style skin, tabbed workspace and hardening

The LEDS lookup terminal gained a selectable PNC-style skin alongside the default terminal look, a multi-record tab workspace, and a full security and QA audit whose 30 findings were all resolved.

Selectable terminal skins, with jurisdiction-aware presentation.
Tabbed workspace — keep several person, vehicle, property or firearm records open at once.
Reference data completed: the full proscribed-organisations list and Scotland and Northern Ireland court orders.
Audit fixes across server-side redaction, authorisation guards, theming and input validation.
A redesigned three-pane login terminal with conditions of use and data-protection guidance.

Member profiles expansion

Member profiles grew from a directory into a proper personnel record.

Service record timeline with rank-tenure history.
Record of Service print and PDF export.
Performance, appraisal, notes and absence sections surfaced on the profile.
A theming sweep so every profile section reads correctly in light and dark modes.

Safeguarding and missing persons completion

The safeguarding and missing-persons module reached completion, with the workflows tightened end to end.

Mandatory actions and checks on every missing-person episode.
Structured Herbert Protocol and Philomena Protocol forms.
Write authorisation tightened across every safeguarding record type.
A dedicated quality pass across the whole module.

What's next lives on the roadmap.

This page looks backwards; the roadmap looks forwards — what we're actively building, and what's further out.

View the Roadmap →