Sentinel

Phone and card theft on and around public transport is a persistent, high-volume crime. The pattern is familiar: a card or phone is taken, and within minutes the offender is moving through the transport network. The window in which the offender is physically close to a known location is short, and the data that could place them there is fragmented across separate systems: the card-acceptance system knows a tap happened, CCTV knows what a location looked like, and dispatch knows where officers are. None of these talk to each other in the moment that matters.

The result is that a strong, time-bound signal, a stolen card being presented at a specific gate at a specific second, is rarely converted into an actionable lead while it is still useful.

The most valuable moment is not the stolen card being used successfully. It is the moment it is rejected.

A cancelled card cannot pass a gate. So when an offender presents a stolen card and it is rejected, they must immediately present a second card that works to get through the same barrier, seconds later. This rejected-then-working sequence at a single gate is a far stronger lead than a single tap or a CCTV frame alone, for three reasons:

1. The rejected tap is enough on its own. Even if the stolen card is tried only once and discarded, that single rejected tap at a known gate and time is sufficient to trigger CCTV retrieval. The signal does not depend on continued use.
2. The working card is traceable to an identity. A CCTV frame yields a face; a card yields an account holder through the issuing bank. Offenders very often use their own valid card to pass the gate after a stolen one fails, which can tie a named individual to the scene.
3. It tightens attribution. A stolen-card rejection immediately followed by a successful entry at the same gate links the person at that gate closely to the stolen card, in time and place. This addresses the weakness that "whoever uses the card is not always the thief".

Sentinel calls this second, working card the bridge card. It is the heart of the concept, and also the part that demands the most careful handling, because that card may belong to an innocent person.

The workflow is deliberately linear and auditable:

1. Watchlist. A card reported stolen, with its crime reference, is placed on a watchlist. Only cards on this watchlist can ever trigger the system.
2. Detection. When a watchlisted card is presented at a reader, a match event is generated with the reader id and timestamp.
3. Correlation. If the watchlisted tap was rejected, the system looks for a successful tap at the same gate within a few seconds and records it as a candidate bridge card, held anonymously.
4. CCTV linkage. The system retrieves a short CCTV clip for the camera covering that gate, by location and time. No facial recognition is performed.
5. Alert. It computes the nearest available officer and surfaces a lead with location, time and footage.
6. Human decision. An officer reviews the lead and decides what to do. Nothing is automated beyond surfacing it.
7. Audit. Every sensitive action is written to an audit log with a timestamp and an actor.

Sentinel is a surveillance-adjacent tool, and the case for it stands or falls on whether its limits are real. These safeguards are properties of the system, not promises around it.

• Targeted, not mass surveillance. The system only ever acts on a card already on the stolen watchlist. It does not scan, score, or track the travelling public.
• No facial recognition. CCTV is retrieved by location and time, then reviewed by a human. The system never matches faces.
• The bridge card stays anonymous. A working card captured during a correlation is held anonymously by default. Identifying its holder requires a logged human decision and a lawful basis, never an automatic lookup, because that card is not itself reported stolen and may belong to an innocent person.
• Human in the loop. Alerts are leads, not decisions. The system surfaces; a person acts.
• Audit trail. Every sensitive action, viewing CCTV, de-anonymising a bridge card, actioning an alert, is logged and visible.

The line the design refuses to cross

A system that already sees taps across a network is one step away from reconstructing an individual's journey, entry to exit. Sentinel deliberately does not do this. The distinction, a point-in-time event versus a tracked trajectory, is what keeps the concept defensible. The safeguards above exist precisely to resist the pressure to expand scope once the data is within reach.

Sentinel is a cross-platform application with a clean separation between the user interface, the application state, and the data sources, so that real feeds can replace fabricated ones without rewriting the app.

Application. React Native and Expo (SDK 52), TypeScript, expo-router for navigation, and Zustand for in-memory state. The map uses react-native-maps on native platforms and Leaflet with OpenStreetMap tiles on the web. CCTV playback uses expo-video.

Provider layer. All data flows through a provider interface with two implementations, selected at runtime:

• Demonstration (dummy). Fabricated, in-memory data driven by a simulation engine. It runs the full workflow end to end with no external dependencies and no keys.
• Live (TfL). Real network topology (lines, stations, gate readers) fetched from the TfL Unified API. Station readers are derived from real stations, including the real gate count per station.

Internal feeds, stubbed by design. The TfL public API exposes network topology, status and arrivals only. It does not expose individual contactless taps or CCTV, which are internal systems. In Sentinel these are interface stubs, ready to be connected to authorised endpoints once a data-sharing agreement is in place. This is not a technical gap; it is the real institutional dependency, made explicit in the architecture.

Credential hygiene. The public TfL key is build-time and non-sensitive. Internal feed credentials are kept separate, per feed, never embedded in a public client build, following least-privilege. This is the same security discipline the system itself advocates.

The prototype is functionally complete as a demonstration, and is organised around a landing screen that presents two distinct experiences in a deliberate order:

• Demonstration tells the story: a stolen card rejected, the bridge card correlated and held anonymous, CCTV retrieved by location and time, the nearest officer alerted, the lead reviewed, and every sensitive action logged. This is the full system in action, on fabricated data.
• Live TfL data proves the integration is real: the map is hydrated from the live TfL API, showing the real network (over two hundred station readers across multiple lines, filterable by line), with a runtime badge that makes the data source explicit and never lets a failed live fetch masquerade as working live data.

The two are separate because they answer different questions. The demonstration answers "what does the system do"; the live view answers "is this real". Keeping them distinct, rather than as an ambiguous toggle, prevents the live map, which has no alert flow by design, from being mistaken for a broken system.

Verification. The prototype type-checks cleanly, passes its unit tests (covering the correlation logic, nearest-officer computation, distance maths and match construction), and bundles for both web and native targets.

A concept is only credible if its limits are stated plainly.

• The card user is not always the thief. Cards may be passed on, or theft and use may be separated in time. The rejected-tap correlation tightens attribution considerably, but the output remains a lead, not proof.
• The decisive feeds are not public. Tap and CCTV data are internal. Without a data-sharing agreement, the live integration can prove the map is real but cannot run the full workflow on real events. This is deliberate, and it is the main dependency for any move from demonstration to pilot.
• Coverage is uneven. Gatelines, camera placement and officer availability vary by station, so the real-world signal quality would vary too.
• It is a demonstrator, not a product. All workflow data is fabricated. It is not affiliated with or endorsed by any police service or transport authority.

The path to a real trial is institutional more than technical. It would require an authorised, privacy-reviewed data-sharing agreement covering the internal tap and CCTV feeds; a defined lawful basis for the bridge-card de-anonymisation step; an independent review of the proportionality safeguards; and a bounded pilot at a small number of stations with clear success and abort criteria. The architecture is built so that, on the day those approvals exist, the internal feeds plug into the existing interfaces without redesigning the system.

Sentinel began with a street robbery and the simple observation that a rejected tap is a signal, not a dead end. It became an exercise in building a surveillance-adjacent tool that takes its own limits seriously: targeted rather than broad, surfacing leads rather than making decisions, and refusing the easy expansion from "detect an event" to "track a person". The prototype shows the idea working end to end, and proves it can speak to real transport data today. What remains is not code, but the institutional trust and process that any tool touching this kind of data must earn.

El robo de móviles y tarjetas en el transporte público y sus alrededores es un delito persistente y de gran volumen. El patrón es conocido: se sustrae una tarjeta o un móvil y, en cuestión de minutos, el autor ya se mueve por la red de transporte. La ventana en la que el autor está físicamente cerca de un punto conocido es corta, y los datos que podrían situarlo allí están fragmentados en sistemas separados: el sistema de aceptación de tarjetas sabe que hubo una validación, el CCTV sabe qué aspecto tenía un lugar, y la sala de coordinación sabe dónde están los agentes. Ninguno habla con los demás en el momento que importa.

El resultado es que una señal potente y acotada en el tiempo, una tarjeta robada presentada en un torno concreto en un segundo concreto, rara vez se convierte en una pista accionable mientras todavía sirve.

El momento más valioso no es el de la tarjeta robada usándose con éxito. Es el momento en que es rechazada.

Una tarjeta cancelada no puede pasar un torno. Así que cuando un autor presenta una tarjeta robada y es rechazada, tiene que presentar de inmediato una segunda tarjeta que sí funcione para cruzar la misma barrera, segundos después. Esta secuencia de rechazo seguido de validación correcta en un mismo torno es una pista mucho más fuerte que una sola validación o un fotograma de CCTV por separado, por tres razones:

1. El rechazo basta por sí solo. Aunque la tarjeta robada se pruebe una sola vez y se descarte, ese único rechazo en un torno y un instante conocidos basta para disparar la recuperación del CCTV. La señal no depende de que se siga usando.
2. La tarjeta que funciona es rastreable hasta una identidad. Un fotograma de CCTV da una cara; una tarjeta da un titular de cuenta a través del banco emisor. Los autores a menudo usan su propia tarjeta válida para cruzar el torno después de que falle una robada, lo que puede vincular a una persona concreta con la escena.
3. Estrecha la atribución. Un rechazo de tarjeta robada seguido de inmediato por una entrada correcta en el mismo torno vincula estrechamente a la persona de ese torno con la tarjeta robada, en tiempo y lugar. Esto aborda la debilidad de que "quien usa la tarjeta no siempre es el ladrón".

Sentinel llama a esta segunda tarjeta, la que funciona, la tarjeta puente. Es el corazón del concepto, y también la parte que exige el trato más cuidadoso, porque esa tarjeta puede pertenecer a una persona inocente.

El flujo es deliberadamente lineal y auditable:

1. Lista de búsqueda. Una tarjeta denunciada como robada, con su número de referencia del delito, se coloca en una lista de búsqueda. Solo las tarjetas de esta lista pueden llegar a activar el sistema.
2. Detección. Cuando una tarjeta de la lista se presenta en una lectora, se genera un evento de coincidencia con el identificador de la lectora y la marca temporal.
3. Correlación. Si la validación de la tarjeta en lista fue rechazada, el sistema busca una validación correcta en el mismo torno en pocos segundos y la registra como tarjeta puente candidata, conservada de forma anónima.
4. Enlace con CCTV. El sistema recupera un clip breve de CCTV de la cámara que cubre ese torno, por ubicación y hora. No se realiza reconocimiento facial.
5. Alerta. Calcula el agente disponible más cercano y eleva una pista con ubicación, hora e imágenes.
6. Decisión humana. Un agente revisa la pista y decide qué hacer. Nada se automatiza más allá de elevarla.
7. Auditoría. Cada acción sensible se escribe en un registro de auditoría con su marca temporal y su actor.

Sentinel es una herramienta cercana a la vigilancia, y su justificación se sostiene o se cae según si sus límites son reales. Estas salvaguardas son propiedades del sistema, no promesas a su alrededor.

• Vigilancia dirigida, no masiva. El sistema solo actúa sobre una tarjeta que ya está en la lista de robadas. No escanea, no puntúa ni rastrea al público que viaja.
• Sin reconocimiento facial. El CCTV se recupera por ubicación y hora, y luego lo revisa una persona. El sistema nunca compara caras.
• La tarjeta puente sigue siendo anónima. Una tarjeta que funciona y se captura durante una correlación se conserva de forma anónima por defecto. Identificar a su titular exige una decisión humana registrada y una base legal, nunca una búsqueda automática, porque esa tarjeta no está denunciada como robada y puede pertenecer a una persona inocente.
• Humano en el bucle. Las alertas son pistas, no decisiones. El sistema eleva; una persona actúa.
• Rastro de auditoría. Cada acción sensible, ver el CCTV, desanonimizar una tarjeta puente, actuar sobre una alerta, queda registrada y a la vista.

La línea que el diseño se niega a cruzar

Un sistema que ya ve validaciones por toda una red está a un paso de reconstruir el trayecto de una persona, de la entrada a la salida. Sentinel deliberadamente no hace esto. La distinción, un evento puntual frente a una trayectoria rastreada, es lo que mantiene el concepto defendible. Las salvaguardas anteriores existen precisamente para resistir la presión de ampliar el alcance una vez que los datos están al alcance de la mano.

Sentinel es una aplicación multiplataforma con una separación limpia entre la interfaz de usuario, el estado de la aplicación y las fuentes de datos, de modo que los feeds reales puedan sustituir a los ficticios sin reescribir la app.

Aplicación. React Native y Expo (SDK 52), TypeScript, expo-router para la navegación y Zustand para el estado en memoria. El mapa usa react-native-maps en plataformas nativas y Leaflet con teselas de OpenStreetMap en web. La reproducción del CCTV usa expo-video.

Capa de proveedores. Todos los datos fluyen a través de una interfaz de proveedor con dos implementaciones, seleccionadas en tiempo de ejecución:

• Demostración (ficticia). Datos ficticios en memoria, impulsados por un motor de simulación. Ejecuta todo el flujo de principio a fin sin dependencias externas ni claves.
• En vivo (TfL). Topología de red real (líneas, estaciones, lectoras de torno) obtenida de la API Unified de TfL. Las lectoras de cada estación se derivan de estaciones reales, incluido el número real de tornos por estación.

Feeds internos, simulados por diseño. La API pública de TfL solo expone topología de red, estado y llegadas. No expone las validaciones contactless individuales ni el CCTV, que son sistemas internos. En Sentinel son stubs de interfaz, listos para conectarse a endpoints autorizados en cuanto exista un acuerdo de compartición de datos. No es una carencia técnica; es la dependencia institucional real, hecha explícita en la arquitectura.

Higiene de credenciales. La clave pública de TfL es de tiempo de compilación y no sensible. Las credenciales de los feeds internos se mantienen separadas, por feed, nunca incrustadas en una compilación pública del cliente, siguiendo el mínimo privilegio. Es la misma disciplina de seguridad que el propio sistema defiende.

El prototipo está funcionalmente completo como demostración, y se organiza en torno a una pantalla de inicio que presenta dos experiencias distintas en un orden deliberado:

• Demostración cuenta la historia: una tarjeta robada rechazada, la tarjeta puente correlacionada y conservada anónima, el CCTV recuperado por ubicación y hora, el agente más cercano alertado, la pista revisada y cada acción sensible registrada. Es el sistema completo en acción, sobre datos ficticios.
• Datos en vivo de TfL demuestra que la integración es real: el mapa se hidrata desde la API en vivo de TfL, mostrando la red real (más de doscientas lectoras de estación en varias líneas, filtrables por línea), con una insignia en tiempo de ejecución que hace explícita la fuente de datos y nunca deja que una petición en vivo fallida se haga pasar por datos en vivo funcionando.

Las dos están separadas porque responden a preguntas distintas. La demostración responde a "qué hace el sistema"; la vista en vivo responde a "es esto real". Mantenerlas distintas, en lugar de como un conmutador ambiguo, evita que el mapa en vivo, que por diseño no tiene flujo de alertas, se confunda con un sistema averiado.

Verificación. El prototipo pasa la comprobación de tipos limpiamente, supera sus pruebas unitarias (que cubren la lógica de correlación, el cálculo del agente más cercano, las matemáticas de distancia y la construcción de coincidencias) y empaqueta tanto para web como para destinos nativos.

Un concepto solo es creíble si sus límites se exponen con claridad.

• Quien usa la tarjeta no siempre es el ladrón. Las tarjetas pueden pasarse de mano, o el robo y el uso pueden separarse en el tiempo. La correlación del rechazo estrecha bastante la atribución, pero el resultado sigue siendo una pista, no una prueba.
• Los feeds decisivos no son públicos. Los datos de validaciones y de CCTV son internos. Sin un acuerdo de compartición de datos, la integración en vivo puede demostrar que el mapa es real, pero no puede ejecutar todo el flujo sobre eventos reales. Esto es deliberado, y es la dependencia principal para cualquier paso de la demostración a un piloto.
• La cobertura es desigual. Las líneas de tornos, la ubicación de las cámaras y la disponibilidad de agentes varían según la estación, así que la calidad de la señal en el mundo real también variaría.
• Es un demostrador, no un producto. Todos los datos del flujo son ficticios. No está afiliado ni respaldado por ningún cuerpo policial ni autoridad de transporte.

El camino hacia una prueba real es más institucional que técnico. Requeriría un acuerdo de compartición de datos autorizado y revisado en materia de privacidad que cubriera los feeds internos de validaciones y CCTV; una base legal definida para el paso de desanonimización de la tarjeta puente; una revisión independiente de las salvaguardas de proporcionalidad; y un piloto acotado en un número reducido de estaciones con criterios claros de éxito y de aborto. La arquitectura está construida para que, el día en que existan esas aprobaciones, los feeds internos se enchufen a las interfaces existentes sin rediseñar el sistema.

Sentinel empezó con un robo en la calle y la simple observación de que un rechazo es una señal, no un callejón sin salida. Se convirtió en un ejercicio de construir una herramienta cercana a la vigilancia que se toma en serio sus propios límites: dirigida en vez de amplia, elevando pistas en vez de tomando decisiones, y rechazando la fácil expansión de "detectar un evento" a "rastrear a una persona". El prototipo muestra la idea funcionando de principio a fin, y demuestra que hoy puede hablar con datos reales de transporte. Lo que queda no es código, sino la confianza institucional y el proceso que cualquier herramienta que toque este tipo de datos debe ganarse.