SmartScan space-utilisation reporting. FW Thorpe (Thorlux) · AI discovery and pilot specification
A working proof-of-concept on Thorlux’s own occupancy data, three reports shaped to three different readers, and a specification the in-house engineering team could build from.
7 models benchmarked ~6.5M records validated UK region only
Reports built from SmartScan’s own occupancy data.
FW Thorpe’s Thorlux business runs SmartScan, a connected lighting platform covering roughly a million luminaires across 661 buildings, every fitting carrying an occupancy sensor and feeding a time-series database. The platform was mature and the data was there. What nobody had was a way to put an answer in front of a facilities director making a capital decision without asking them to interpret a dashboard first.
They engaged OpenKit to find out whether that sensor data could become automated, executive-readable space-utilisation reporting, and to say so with evidence rather than a recommendation deck. The engagement produced a strategy report, a technical specification, three sample reports, and a proof-of-concept that generated them from real data.
- 01
Five tables mapped inside SmartScan’s own database, and a query whose numbers reconciled with the live dashboard for the same site.
- 02
Seven candidate models priced and scored against the four kinds of report they would have to write.
- 03
The proof-of-concept generated real reports from live Thorlux data, so the recommendation arrived with working output attached.
Who reads the report, and what each reader needs.
Universities and large corporates still make estate decisions 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.
- 01
Is the occupancy data actually good enough to write decisions on top of?
- 02
Can a language model report on a building without inventing a number along the way?
- 03
Can all of it run without customer occupancy data leaving UK jurisdiction?
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 not much use to the person who has to act on it unless the ordinary spaces sit either side of it for comparison. The bottom tier is keyed to organisational units instead of physical zones, so a department head reads their own footprint directly.
All three draw on the same query and the same pre-calculated metrics. Action flags are set on fixed thresholds rather than by a model’s judgement, so a space marked critical is critical by the same rule in every report, in every building, every month.
One dataset · three reports
- 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 rather than physical zones.
Inside the reporting service.
- 01
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 verified arithmetic instead of doing the arithmetic, which is what makes the output auditable.
- 02
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.
- 03
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.
- 04
Sized for one site, parameterised for the estate
The design is keyed on site, so the pilot proves the pattern on one building and widens across the estate without a rewrite, and reports generate on a schedule rather than on demand so operating cost stays predictable.
What the discovery measured.
occupancy records queried during discovery, reconciled against the live dashboard for the same site before anything was recommended.
models benchmarked on cost and output quality across the report types, so the choice is documented and switchable rather than a vendor preference.
reports off one dataset and one set of pre-calculated metrics. The prompt, the language and the presentation change with the reader.
of data required before a report will generate, so a thin dataset cannot produce a confident-sounding wrong answer.
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, sized to one site and parameterised for the estate. 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
More of the work.
Find your first workflow.
We start with a conversation, audit where AI actually pays back, and build the first automation into how your team already works. We reply within one working day.
Start the conversation AI Audit