The PUI query model, explained
PUI does not watch your guests live: it works by query. The search authority asks about a reported person and the establishment responds from its registry. This page explains how that model operates —what is asked, what is answered and why it is not mass monitoring—, to reassure owners and pin down the point for lawyers and consultants.
The core idea: a person is asked about, not everyone watched
PUI’s design rests on a simple principle: the search authority frames a narrow query about a specific person reported missing, and the establishment responds from its own registry if that person checked in. There is no continuous flow in which the government observes all of a hotel’s guests in real time. It is a targeted question, not a permanent transmission.
This distinction is not a nuance: it completely changes the nature of the obligation. For an owner, it means the registry is not “exposed” openly or dumped en masse; it only answers a concrete question when there is one. For a lawyer or a consultant, it means the model resembles a targeted query under a search basis, and not generalized surveillance.
The purpose that justifies the whole mechanism is the LGMDFP’s: to locate people reported missing. The query model is the way to serve that purpose without turning every lodging record into a point of permanent monitoring.
How the query works, step by step
From the reported person to the establishment’s response, in a clear sequence.
- A missing person is reportedThe search authority needs to trace where a specific person reported missing may have been.
- The narrow query is framedThrough the system, that person is asked about, identified by data such as their CURP or name. The question is about a person, not about all guests.
- The establishment responds from its registryIf that person checked in, the system responds securely; if not, there is no match. The response comes from the lodging’s own registry.
- Compliance without a mass data dumpHaving registered identity and being able to answer the query is exactly what the law requires. The full registry is not handed over: the question is answered.
Why it is NOT mass monitoring
The reasons the model is a targeted query and not continuous surveillance.
The question is about a person
The query refers to a specific reported person, not to an open list of all your guests.
It is not a registry dump
Answering a query is not handing over the full guest database; it is responding whether there is a match with the person sought.
On demand, not continuous
There is no permanent data flow: the query happens when the authority searches for someone, not all the time.
Grounded in the search
The model is exercised within the LGMDFP framework, for the purpose of locating people reported missing.
Identity, not spending
What is registered and queried is identity (CURP, name, document), never a credit card or how much the guest spent.
Complying means being ready to answer
The duty is met by properly registering identity and being able to answer the query when it arrives.
What is asked and what is answered, precisely
In the query model, the question identifies a specific person with identity data, typically their CURP or name. The establishment’s response is, in essence, whether that person appears in its registry. It is not about displaying all guests’ information, but about confirming or ruling out a match for the person sought.
For the technical aspects of how that query and response travel, Technical Manual v1.0 (DOF, 23 January 2026) defines a REST/JSON architecture, JWT token authentication and end-to-end encryption with AES-256-GCM, plus SHA3-256 hashing and TLS transport. In other words, the query is not an email or an informal call: it is an exchange encrypted and authenticated by design.
It is worth restating the material limit of the data: what is registered and queried is identity. The guest’s credit card, the amount paid and what they consumed are not part of the model. Whoever explains this model to an owner can state it with confidence; whoever analyzes it as a lawyer can hold it precisely.
Official sources
Framework: General Law on the Forced Disappearance of Persons (LGMDFP), Art. 12 Bis (registration obligation) and Art. 43 Bis (penalty). Bodies: SEGOB and the National Search Commission (CNB) in the search function; RENAPO in identity; ATDT in technical support.
Technical specifications: Technical Manual v1.0 published in the Federal Official Gazette (DOF) on 23 January 2026 (REST/JSON architecture, JWT, AES-256-GCM, SHA3-256, TLS). Other publications: LGMDFP reform in July 2025; Guidelines on 27 November 2025; SNIP Operations Manual, pending as of June 2026.