Occupancy reports from lighting sensors.

Challenge

Who reads the report, and what each reader needs

Universities and large corporates still make decisions about their buildings off manual space-utilisation analysis, and that analysis does not scale across a customer base this size. The people waiting on the answer also read very differently: a board member wants the one call to make, a facilities manager wants the whole category in front of them, and a department head wants their own footprint without translating physical zones into teams first. Underneath all of that sat harder questions about whether the platform could carry the reporting at all.

• Is the occupancy data actually good enough to write decisions on top of?
• Can a language model report on a building without inventing a number along the way?
• Can all of it run without customer occupancy data leaving UK jurisdiction?

Approach

Three reports from one occupancy dataset

Hand a board member a fifty-page facilities report and it will not be read, so the top tier stops at the spaces that need a decision and pushes everything performing normally down the stack. The middle tier runs deliberately wide, because an exception is only useful to the person acting on it when the ordinary spaces sit either side of it for comparison. The bottom tier is keyed to organisational units, so a department head reads their own footprint directly.

All three draw on the same query and the same pre-calculated metrics. Fixed thresholds set every action flag, so a space marked critical is critical by the same rule in every report, in every building, every month.

• The board. One page, and only the spaces that need a decision.
• Facilities managers. Every space in the category, so an exception has context either side of it.
• Department heads and finance. The long one, keyed to teams.

Architecture

Inside the reporting service

The model never sees raw data

Python computes every utilisation percentage, action flag and department aggregation first, and the prompt is a payload of numbers that have already been checked. The model writes narrative around arithmetic that is already verified, which is what makes the output auditable.

UK-hosted, with every model call traced

Customer occupancy data cannot cross jurisdiction, so the architecture targets a UK region with tracing on every model call, and prefers private models over public AI APIs. That ruled out most of the obvious options before the design conversation started.

Runs inside SmartScan itself

The reporting service pulls the occupancy data, works out the numbers, asks the model for the wording and writes the finished report, and SmartScan’s existing screens display and export it. Everything lives in the platform Thorlux’s team already runs and already knows how to support.

Sized for one site, parameterised for the rest

The design is keyed on site, so the same pattern holds for one building and for the whole installed base without a rewrite, and reports generate on a fixed schedule so operating cost stays predictable.

Result

The engineering team took the specification forward

The strategy report carries the tiered recommendation, the model comparison behind it, and the full risk register. The specification is written so an in-house team can build from it without a second round of discovery: the service design, the queries, the prompt schemas and the report structures. Three sample reports came with it, generated from real data, so nothing in the package rests on a claim about what the system would probably do.

Specified

• PostgreSQL with TimescaleDB
• Python AI reporting service
• AWS Bedrock (UK region)
• Langfuse observability
• PHP display layer in SmartScan

OpenKit certifications

• ISO 27001 and ISO 9001, UKAS-accredited
• Cyber Essentials

Controls on this project

• UK GDPR
• UK data residency
• Customer data sovereignty