Protocolo DPM · Datos Por Minuto
Cada cuánto se refresca un dato, medido por reloj.
El Protocolo DPM es el régimen bajo el cual un sistema declara, mide y presume la frescura de los datos que entrega a las personas. Tres clases, y solo tres, se presumen: por minuto, por segundo y por milisegundo. La clase no la asigna nadie: la fija el reloj, y se cae sola cuando el reloj deja de cumplirse. Ninguna cifra del protocolo se dice en público si no la produjo el pulso que aparece más abajo.
§1 · Qué mide
Una sola cosa: la frescura.
La frescura de un dato es cada cuánto el sistema vuelve a obtenerlo de su fuente, o cuánto tarda en llevarlo a la persona desde que ocurrió. El protocolo no mide si el dato es correcto: eso lo gobiernan la verificación y las reglas del observatorio. Un dato en clase que está mal, está mal.
- DPM
Datos Por Minuto
Clase que se presume cuando el dato se refresca cada 60 segundos o menos.
- DPS
Datos Por Segundo
Clase que se presume cuando cada segundo o menos.
- DPMS
Datos Por Milisegundo
Clase que se presume cuando cada milisegundo o menos.
Todo lo que se refresca más lento, por hora, por día, por mes o por año, se guarda en el registro con su cadencia escrita en palabras y no lleva sigla, insignia ni mención pública como clase. La mayor parte de lo que el observatorio custodia se publica por mes o por año, y se rige por sus reglas de verificación, no por este protocolo. El protocolo gobierna el subconjunto de datos que se mueven en minutos o menos.
§2 · Los tres relojes
Todo dato bajo el protocolo declara tres relojes.
Y los declara donde el dato se muestra o se sirve: en los metadatos de una API, al pie de un gráfico, en la ficha de un tablero. La declaración es obligatoria; la clase es consecuencia.
- 01
Reloj de la fuente.
Cada cuánto la fuente publica observaciones nuevas. Si la fuente publica por calendario, es un periodo. Si publica por evento, como un mensaje, una cita o la lectura de un sensor, es la latencia con la que el evento llega al sistema.
- 02
Reloj del refresco.
Cada cuánto el sistema vuelve a obtener el dato, cuando la persona lo consulta; o cuánto tarda en llevárselo desde que ocurrió el evento, cuando el sistema se lo entrega sin que lo pida.
- 03
Reloj de la verificación.
Cuándo fue la última vez que el sistema cotejó el dato contra la fuente, por conteo, por suma o por identidad. Es lo que el observatorio llama «al peso».
Un dato no puede tener una clase más fina que el reloj de su fuente. Refrescar cada segundo un dato que la fuente publica cada quince minutos no lo convierte en DPS: su clase queda acotada por la fuente. La regla existe para que la clase describa la frescura real de la observación y no la insistencia del sistema.
§3 · La etiqueta se cae sola
Ninguna persona asigna la clase de un dato. La asigna el reloj.
El pulso evalúa cada dato una vez por minuto sobre una ventana de sesenta minutos. Dentro de la ventana manda el peor intervalo: un solo hueco de 61 segundos saca al dato de DPM durante esa hora. La pérdida de clase es inmediata y automática. La recuperación también.
Un dato que pierde su clase no se oculta: se sigue mostrando con sus tres relojes y sin la clase. La regla es estricta a propósito. Prefiere que la clase aparezca poco y sea cierta, a que aparezca mucho y sea aproximada.
La clase publicada lleva cinco minutos de retraso respecto del reloj. Es el plazo que tiene cada sistema para reportar un minuto cerrado, y es el precio de no corregir nunca una clase hacia atrás: lo que llega tarde cuenta para la historia, no para la etiqueta.
Un sistema pasa de adhesión declarada a verificada cuando lleva siete días civiles completos reportando sin falta, y vuelve a declarada tras siete días de silencio. Solo los sistemas verificados aportan a las dos cifras del protocolo: el caudal de observaciones y los usuarios DPM diarios.
§4 · El pulso, en vivo
Lo que el pulso sabe en este momento.
Esta sección se lee directamente del pulso, cada minuto. Es la única fuente autorizada de las cifras del protocolo; nada de lo que aparece aquí se escribió a mano.
Leyendo el pulso…
§5 · Cómo se adhiere un sistema
Cinco condiciones y dos estados.
Cualquier sistema que entregue datos a personas puede adherirse: un sitio, una API, una app, un tablero interno. El protocolo no es exclusivo del observatorio; es una forma de trabajar que el observatorio escribió primero para sí mismo.
- 01
Declara los tres relojes de cada dato que muestra o sirve.
- 02
Reporta al pulso, cada minuto, un resumen de sus refrescos y, una vez al día, cuántas personas distintas recibieron sus datos. Nunca identificadores: conteos.
- 03
Acepta que la clase la fija el reloj y no el operador.
- 04
Tiene ficha en el registro público del protocolo.
- 05
Muestra la insignia del protocolo, que sirve el pulso y cambia sola con el estado y la clase vigente.
Un sistema con adhesión declarada tiene ficha y compromiso, pero el pulso aún no recibe sus reportes; no aporta cifras públicas. Con adhesión verificada, el pulso lleva siete días civiles completos recibiéndolo y sus clases se calculan por reloj.
La especificación completa, el contrato técnico del pulso, el registro de sistemas y la historia de versiones están en el repositorio público del protocolo: github.com/Datos-Mexico/datos-mexico-dpm. La documentación de la API del pulso está en api.datosmexico.org/docs, etiqueta «dpm».
Anunciar es más barato que demostrar. Por eso el protocolo no promete velocidad: la mide, la publica con su ventana y la retira cuando deja de ser cierta.
El Protocolo DPM se formalizó el 31 de octubre de 2026 y es artefacto vivo: se versiona en su repositorio y cada cambio queda en su historial con fecha y motivo. Este documento es la explicación pública; donde parezcan divergir, manda el texto del protocolo. Erratas y correcciones, bajo el mismo régimen que el resto del observatorio.
Leer el protocolo · Registro de sistemas · Historial de versiones