Build-to-rent.

§ FOR BTR OPERATORS

One concierge. Three buildings. No screens to watch.

UK build-to-rent is the first vertical. The concierge-desk economics are the worst in the sector, the ICO posture has to be embedding-only or the residents' association vetoes it, and the operators we've spoken to — L&Q, Get Living, Quintain Living, Greystar UK — all confirm the same three pains below. Underneath those pains, this page names the five concierge scenarios that ReID actually changes.

§ NAMED PAINS

Three things the duty manager says on every call.

01

The concierge desk is the worst seat in the building

L&Q, Get Living, Quintain Living, Greystar UK — every BTR operator on our calls says the same thing. Concierge cost is 60-70% of the building's run-rate after rates. Cameras are watched by one human reading screens for 8-hour shifts.
02

Following a tailgater takes 20 minutes of footage review

Resident in 7F reports a stranger followed her through the front door. Today: 20 minutes scrubbing through three cameras to find the moment, another 30 to follow them to a lift, another hour to confirm whether they left. With ReID, that timeline collapses to a single thumbnail strip.
03

Resident privacy is the political constraint

Every BTR operator we've spoken to is one resident complaint away from a 'they're spying on us' headline. Facial recognition is a non-starter. Embedding-only ReID is the only posture that survives a residents' association vote.

§ FIVE BTR SCENARIOS

What ReID actually changes on the concierge desk.

Five named scenarios, each rendered as a chapter the DPO and the Head of Operations can read top-to-bottom. The ICO posture, the data retention and the concierge action repeat on every chapter — not as marketing, as the discipline the ICO will read for, the residents' association will read for, and the responsible governor will sign on.

Chapter 01

Move-in / move-out detection

A new face appears across the lobby, lift and corridor cameras for the first time, then keeps appearing across a seven-day window. The system surfaces it to the concierge as a candidate move-in — not as a decision, as a row in their morning brief.

What it solves: UK BTR turnover sits around 25% per annum; mid-sized buildings see one to three move-in or move-out events every week, and the concierge log routinely misses them because nobody asked the desk and the courier arrived at 19:40. The cost is downstream: the new resident isn't onboarded, the leaver still has a fob, the cleaning team isn't told. Cross-camera novelty detection over a seven-day window gives the concierge a single brief item — 'new face, 6 sightings, lobby + lift 4 + corridor 3' — and they pick up the phone.
ICO posture: ReID via embeddings, not facial recognition. The system never has a name, never has a face, never has a date of birth. The 'new face' is a vector that has not been seen in the rolling 30-day embedding store; the concierge attaches the human identity off-system through the lease record. Lawful basis: UK GDPR Art 6(1)(f), legitimate interests — building safety and lease compliance, balanced against resident expectation that move-in events are tracked by the operator.
Data retention: Raw frames: 72-hour ring buffer on the edge node, never written to durable storage. Embedding vectors: 30-day rolling window, UK region only, deleted on rolling expiry.
What the concierge does: Human-in-loop, always. The system raises a flag in the morning brief; the concierge decides whether to follow up with the leasing team. No automated message goes to a resident, ever.

Chapter 02

Authorised vs unauthorised contractor entry

Pre-registered contractors — the lift engineer, the boiler service, the cleaning rota — get a frictionless entry log: same vector, expected window, no flag. An unregistered face that repeats across multiple entries inside a week is the row the concierge wants to see.

What it solves: BTR buildings run a contractor rota that nobody centrally tracks past the front-desk sign-in sheet. The lift engineer comes in three times a quarter; the cleaning team is twice a week; the rough sleeper who learned the buzzer code is also in three times a week and nobody on the desk knows. Today the operator finds out when a resident complains about a stranger in the bin room. ReID flips the surface area: contractors register their vector once (consent-on-file, recorded against the supplier record, not the person), repeated entries by a non-registered vector raise a low-confidence flag for the concierge to review.
ICO posture: ReID via embeddings, not facial recognition. Contractor 'registration' is a supplier record — the embedding vector is linked to the company plus the named operative on the work order, not to a biometric identity store. The system distinguishes 'seen-before, expected' from 'seen-before, not expected'; it does not identify anybody. Lawful basis: UK GDPR Art 6(1)(f), legitimate interests — supplier governance and building safety, with a contractor DPA in place.
Data retention: Raw frames: 72-hour ring buffer on the edge node, never written to durable storage. Embedding vectors: 30-day rolling window for unregistered vectors; registered contractor vectors held for the duration of the active supplier contract and deleted on contract close.
What the concierge does: Human-in-loop, always. The system shows a row in the daily exception list — 'unregistered face, 4 entries this week, lobby + service door' — the concierge cross-checks against the work-order log and decides whether to escalate.

Chapter 03

Anti-tailgating at the building entrance

A resident swipes the front door. Within three seconds, a second person enters in the same direction without a swipe. The system flags the moment to the concierge at low confidence, with a single thumbnail strip — not an alert that locks anything, not an action against the resident.

What it solves: Tailgating is the failure mode every BTR Head of Operations names without prompting. Today the duty manager finds out 40 minutes later when a resident calls the desk. With ReID and access-control timing fused, the same-direction-within-3-seconds window is a deterministic trigger; the concierge sees the thumbnail strip in the live exception feed and decides whether to investigate. The 20-minute footage scrub described in pain 02 above collapses to a 30-second concierge glance.
ICO posture: ReID via embeddings, not facial recognition. The trigger is a swipe event plus a same-direction motion vector inside a 3-second window — the embedding is only used downstream if the concierge wants to follow the tailgater through the building. The system never identifies the resident who swiped and never identifies the tailgater; it surfaces a moment for human review. Lawful basis: UK GDPR Art 6(1)(f), legitimate interests — physical security in private residential space, with a DPIA on file documenting the proportionality of the 3-second trigger.
Data retention: Raw frames: 72-hour ring buffer on the edge node, never written to durable storage. Embedding vectors: 30-day rolling window. Tailgate flag itself (event metadata, no biometric) retained 90 days for incident-pattern review.
What the concierge does: Human-in-loop, always. Low-confidence alert into the live exception feed; the concierge decides whether to dispatch a walk-through. No door is locked by the system, no resident is contacted by the system, no automated incident report is filed.

Chapter 04

Lost child or vulnerable resident — last cross-camera sighting

A resident's family calls the concierge: 'we can't find Dad, he was last seen heading to the residents' lounge around 14:00'. The concierge enters the description — clothing, approximate time, last known camera — and the system surfaces the cross-camera trace inside a 4-hour window.

What it solves: This is the scenario every BTR operator has had to handle without good tools. A vulnerable resident wanders, a child goes missing in a 400-door building, the family is on the desk and the duty manager has six cameras to search. Today the concierge calls a building walk and starts scrubbing footage; the trace is often available but takes the rest of the shift to assemble. With ReID, the concierge runs a similarity query against the last known sighting and gets the cross-camera trail — lobby 14:02, lift 14:03, fourth-floor corridor 14:05, fire exit 14:11 — in seconds.
ICO posture: ReID via embeddings, not facial recognition. The search is initiated by the concierge with an explicit purpose recorded against the query log (welfare search, family-initiated); the system surfaces vector matches against the 30-day rolling store. No identity is asserted by the system; the concierge confirms identity from the trace plus the family's description. Lawful basis: UK GDPR Art 6(1)(f), legitimate interests — vital interests are also engaged where the resident is at risk, and Art 6(1)(d) is the alternative footing the DPO can cite in the welfare-search case.
Data retention: Raw frames: 72-hour ring buffer on the edge node, never written to durable storage. Embedding vectors: 30-day rolling window. The welfare-search query log itself is retained for 12 months as evidence of proportionate use, reviewed by the DPO at the annual audit.
What the concierge does: Human-in-loop, always. The concierge initiates the query, the concierge reads the trace, the concierge makes the welfare call. The system shortens the time-to-trace from a 40-minute footage scrub to a 30-second glance; the human still does the welfare work.

Chapter 05

After-hours common-room misuse

Same person appears in the gym or residents' lounge at 03:00 across three or more nights inside a fortnight, without a corresponding key-card swipe. The system flags the pattern to the concierge — not a single late-night use, but a recurring one without a record.

What it solves: BTR common areas — gym, lounge, co-working room — are a recurring source of friction. Residents who tailgate a friend through the gym door, ex-residents who never gave back the fob, party-room use outside the booking schedule. Today the operator finds out from the cleaning team or a complaint. ReID detects repeat sightings of the same vector in an after-hours common area without a matching swipe; the concierge sees the pattern in the weekly brief and has the conversation early.
ICO posture: ReID via embeddings, not facial recognition. The flag is a count of vector sightings in a defined zone outside the access-control schedule; the system never identifies the person. The concierge investigates by looking at the trace + the access-control log, then deciding whether the resident is misusing the common area or whether a former resident still has access. Lawful basis: UK GDPR Art 6(1)(f), legitimate interests — common-area governance and lease compliance.
Data retention: Raw frames: 72-hour ring buffer on the edge node, never written to durable storage. Embedding vectors: 30-day rolling window. After-hours-misuse pattern flags (event metadata, no biometric) retained 90 days for the building-level monthly review.
What the concierge does: Human-in-loop, always. The pattern flag goes into the weekly brief — not the live exception feed — because this is a slow-burn issue, not an incident. The concierge decides whether to have a conversation with the resident or with the leasing team.

§ WHAT WE DON'T DO

The negative space is the product.

What we deliberately don't build is what makes the residents' association vote land the right way. Each item below is a line we will not cross, on the record, in the contract, and in the DPIA the customer's DPO signs.

01

Facial recognition

We do not run a facial-recognition model in the request path, do not maintain a face store anywhere in our infrastructure, and do not enrich the embedding with face landmarks. The ICO has been explicit on facial recognition in private settings (Facewatch, Serco). We sit deliberately outside that category.
02

Biometric identity verification

We do not verify a resident's identity by any biometric signal. The embedding is a similarity vector, not an identity claim. Resident identity is asserted off-system through the lease record, the fob, and the concierge.
03

Advertising attribution

We do not sell footfall data, do not stream embeddings to a third-party attribution graph, and do not let the building owner use the system to measure resident behaviour for commercial purposes. The lawful basis is physical security; commercial use would void it.
04

Sentiment analysis

We do not run an emotion classifier, do not flag 'agitated' or 'aggressive' postures, and do not let the concierge dashboard score a resident's mood. Emotion AI is on the EU AI Act prohibited list in workplace and education settings, and the ICO posture in private residential is the same.
05

Behaviour scoring

We do not assign a resident a behaviour score, a risk score, or any kind of ongoing rating. Every flag is a single event for human review and decays out of the system on the embedding-store expiry. No resident accumulates a profile.

Pain 01

Three buildings. One duty officer. No screens to watch.

What we see

Movement across cameras inside the same building, and across cameras in sister buildings on the same estate. Cross-camera matches surface as a thumbnail strip on the duty-officer console, not as a live wall of feeds.

What we don’t see

Facial features — no face image is stored, encoded or compared.
Names — the system has no link to the property-management database.
ID documents — tenancy paperwork sits in a separate system the camera stack cannot read.
Biometric templates — no fingerprint, no iris, no face vector. The embedding is body-shape + clothing-colour only.
Voice — microphones are disabled at the appliance level.

What concierge does

Edge appliance flags a cross-camera match within the operator's chosen confidence band (configurable per building).
Duty officer sees a 3-thumbnail strip with timestamps + camera IDs — not a live feed wall.
Officer either clears the match (legitimate resident, repeat visitor) or escalates per the building's policy.
Cleared matches drop out of the queue; escalated matches are logged with the officer's note for the manager's morning review.

Data lifecycle

Raw video sits in a 72-hour ring buffer on the on-prem edge appliance, then auto-overwrites — we never copy frames off the site. Embeddings (the abstract vectors the system actually compares) live for 30 days in the UK-resident database. Event records (a timestamp + a camera ID + a similarity score) live for 90 days for investigation continuity, then auto-purge. None of the three layers contain a face image, a name, or an ID document.

Legal posture

Processed under UK GDPR Art 6(1)(f) — legitimate interest in operator safety, balanced against a data subject who is not identified by the system. ICO registration: ZA-class data-controller posture (no biometric-processing escalation; embeddings of body-shape + clothing carry no Schedule 1 special category by construction). DSPT v8 self-assessment shared with the customer's DPO under NDA before contract; written legal opinion on the embeddings-vs-facial-recognition distinction included.

Procurement Q&A

Can a duty officer search by resident name?: No. There is no resident name in the system to search by. The only lookup the console supports is by camera ID + time window. If your management team wants to investigate a specific resident, that's a different system and a different lawful basis.
What stops a rogue officer copying off footage?: Raw video never leaves the on-prem edge appliance — the operator console renders thumbnails from the appliance over the building's LAN, and the appliance refuses USB writes. Console screen-capture is a policy control, not a technical one; we cover it in the deployment runbook.
How does this survive a residents' association vote?: We share the full DPIA addendum + written legal opinion + DSPT v8 self-assessment with the residents' DPO and the management committee before the vote. Three operators have already done this; we'll introduce you to two of them once we're under NDA.

Pain 02

Stranger followed a resident through the front door at 22:14.

What we see

The same body-shape + clothing-colour embedding moving from the front-door camera at 22:14 through the lift-lobby camera at 22:16 to the seventh-floor landing camera at 22:18. A single thumbnail strip, three frames, three timestamps.

What we don’t see

Whose face it is — the system never extracted face features in the first place.
Whether the resident knew the follower — that's a conversation with the resident, not a database query.
What the follower said — no audio.
Where the follower went after the seventh floor camera lost line-of-sight — the trace stops where the cameras stop.

What concierge does

Resident in 7F reports the tail-gate to the duty officer at 22:25.
Officer queries by camera + time window (front-door, 22:10–22:20) and the matching embedding surfaces in seconds.
Officer follows the embedding forward through lift + landing cameras to confirm where it lost line-of-sight.
If the trace ends inside the building, the officer escalates to on-call security. If the trace exits, the officer notes the time and camera ID for the morning manager review.

Data lifecycle

Legal posture

Procurement Q&A

How long does the tail-gate investigation take?: From the resident's call to a complete cross-camera trace: under five minutes in the deployments we've seen. Manual review of the same scenario without ReID is 20–60 minutes depending on building.
What if the follower changed jacket between cameras?: The embedding includes body-shape (gait + height + build proxies), not just clothing. A jacket swap drops the similarity score but doesn't collapse it. The officer sees the lower score and uses judgement; the system doesn't auto-escalate borderline matches.
Can the police request the footage?: Yes — Schedule 2 Part 1 of the DPA 2018 covers prevention/detection of crime. We document the lawful-basis handoff in the runbook, and the raw 72-hour ring buffer is exactly where police requests live in practice.

Pain 03

The residents' association needs to read it before they vote on it.

What we see

Nothing yet — this scenario is about what the residents' DPO reads before the building deploys anything. The drawer here doubles as the DPIA addendum's plain-English summary.

What we don’t see

Faces, names, IDs, biometric templates — see the technical breakdown on /how-it-works.
Cross-building data without an explicit estate-level Data Sharing Agreement signed by every participating building.
Any data leaving UK soil — UK-resident database, UK-resident object storage, UK compute for the model.

What concierge does

We share the DPIA addendum + written legal opinion + DSPT v8 self-assessment with the residents' DPO under NDA.
The DPO walks the residents' committee through it in plain English, with our pre-vote Q&A pack as backup.
Residents' committee votes. If yes, we sign the Data Sharing Agreement covering the estate footprint. If no, no system is installed — we don't run this against a residents' association veto.
Post-deployment, the building's House Manager publishes a quarterly transparency note to residents (we provide the template).

Data lifecycle

Legal posture

UK GDPR Art 6(1)(f) — legitimate interest, balanced against an explicit residents' vote in favour. ICO ZA-class registration; embedding-only ReID treated as continuous with the existing CCTV DPIA, not a new biometric category. DSPT v8 self-assessment available to the residents' DPO and the management committee. Written legal opinion on the embeddings-vs-facial-recognition distinction shared before the vote.

Procurement Q&A

What if a single resident objects after the vote?: The Art 21 right to object stands. Operationally that means: an objecting resident's flats + their lift-lobby cameras are excluded from cross-camera matching by the operator. We document the exclusion in the runbook and the building's House Manager owns the configuration.
Is this 'spying on residents'?: We use that question in our pitch deck, deliberately. The honest answer: the system observes movement and notices when the same shape moved across cameras. It does not know who anyone is. We say so on the record, with written legal opinion behind it, before the vote.
What happens if the regulator inspects?: ICO inspection is in scope of the contract. We provide: DSPT v8 self-assessment, embedded-vs-facial-recognition legal opinion, runbooks, training records and a 90-day event-record export. The 72-hour ring buffer means there is rarely raw footage to surrender; that's a feature, not a bug.

§ ICO POSTURE FOR BTR

The residents' association test.

The political reality of UK build-to-rent: any new security technology gets walked into a residents' meeting. The question that ends every wrong technology choice is "is this facial recognition?"

We say no, on the record, with written legal opinion. The ICO has been explicit on facial recognition in private settings (Facewatch, Serco). What we do — ReID via embeddings — sits in a different category. We share the full legal opinion with the customer's DPO under NDA.

§ PRICING (BTR)

Per camera, per month. Discounted above 50 cameras.

BTR buildings typically run 30-120 cameras per building. Our published BTR pricing starts at from £14 per camera, per month, with a volume discount applied for buildings or portfolios above 50 cameras. Pricing includes the edge node, the embedding store, the concierge dashboard, and a named UK-resident engineer on Slack for the operator's DPO and Head of Operations.

This is a placeholder anchor while the pilot cohort is in flight; the contracted price for the first three operators is held in commercial discussion and not published here. Talk to us and we'll quote the actual building.

§ CUSTOMERS

BTR operators on the pilot list.

Logos appear here once the first three pilots land.

We're in active conversation with the four operators named above and the wider BTR cohort. The pilot terms are held in commercial discussion; until those three are live, this page stays honest and shows a placeholder rather than fake or implied logos.

Read the rest of the stack.

Book a pilot conversation → How it works → The UK posture → Pricing →