One regulated surface. One evidence loop. Thirty minutes.

What we do in the pilot

1. Choose one UK surface.
   For example a financial-limit entry point, public consent journey or evidence/monitoring workflow.
2. Agree what is observable.
   We separate browser-observable evidence from account-state, legal and backend-enforcement questions.
3. Review evidence.
   Timestamped screenshots, redacted technical observations and source-linked regulatory context where supported.
4. Define the repeatable check.
   If the surface is a fit, we show how it can become monitoring/regression evidence rather than a one-off screenshot.

What you should expect

Good fit · Product and compliance need the same proof

You are an operator or B2B platform supplier that controls a UK digital journey changing before or after 30 September 2026, or a PECR/consent surface where technical behaviour matters more than banner copy.

Good fit · You want reviewable evidence

The goal is to help compliance, product and engineering discuss the same observed state and later detect regressions.

Not the offer · Legal opinion or regulator certification

Lexsentra does not certify compliance, provide legal advice or replace an accredited test house where one is required.

What you leave with

• A bounded record of the surface and control family reviewed.
• Browser evidence showing what was actually observable at that point in time.
• An explicit split between observed, partial / inconclusive and not-observable questions.
• A human-review path for deciding whether the evidence is acceptable for your internal QA process.
• One candidate regression check only if the same observable state can be repeated safely.

The success criterion is whether Product/Engineering and Compliance would keep and reuse the evidence—not whether Lexsentra manufactures a PASS label.

Bring four things — no deck required

• One URL or named product surface. The exact UK journey or page your team wants to review.
• One control family. RTS 12B / financial limits, PECR / consent, or another already-supported observable control.
• Access boundary. Tell us whether the surface is public or genuinely requires an authorised dedicated test account.
• Release context. The release, change or regression question that makes the evidence useful now.

No platform integration is required for the public first step. No real-money action is needed. If the surface is not technically observable, that is a valid pilot result rather than a forced finding.

Inspect the synthetic evidence model before the call → · Use the RTS 12B evidence checklist →

Safe execution boundary

Public first value starts from a URL and does not require broad cloud or integration credentials.

• Public HTTP/browser checks are bounded to public HTTPS targets.
• Authenticated observation requires explicit authorization and a dedicated test account.
• Authenticated journeys are read-only and same-origin by default.
• No deposits, withdrawals, wagers or live financial-limit mutations.
• CAPTCHA/MFA and unsupported flows fail closed rather than being bypassed.

Review implemented security controls →

Why now

The UK Gambling Commission moved the RTS 12B second-phase implementation date to 30 September 2026 specifically to allow further operator technical-development time. The requirement includes gross deposit-limit availability, naming/prominence rules and fixed timeframes for gross deposit limits.