La puntuación fue la parte fácil

Un feed de transporte público puede pasar la validación y aun así fallarle a quien viaja.

La mayoría de quienes viajan nunca abrirá uno. Lo encuentra a través de una aplicación que propone una ruta, muestra una salida o indica si una parada o un viaje está marcado para acceso en silla de ruedas. La Especificación General de Feeds de Transporte, conocida como GTFS (se abre en una pestaña nueva) es el formato compartido detrás de muchas de esas respuestas. Agrupa paradas, rutas, horarios, tarifas y campos de accesibilidad para que el software pueda leerlos. Cuando esa información está desactualizada, incompleta o es ambigua, el problema llega hasta quien viaja.

Empecé GTFS Scorecard en junio de 2026 con dos sistemas locales, Unitrans y Yolobus, y lo que parecía una tarea de ingeniería acotada. Ejecutar el validador establecido del estándar. Convertir sus hallazgos en una calificación. Publicar el resultado. Entonces tuve que decidir qué hallazgos importaban más, qué significaba un campo ausente y qué debía corregir primero una persona responsable del transporte que había heredado un feed de un proveedor.

Calcular una puntuación resultó ser la parte fácil. En el momento en que asigné pesos, traduje avisos de una máquina en consecuencias para quienes viajan y prioricé reparaciones, dejé de limitarme a informar sobre datos. Estaba haciendo una afirmación pública. Esa brecha se convirtió en el proyecto.

El proyecto creció más allá de una página con una calificación. Ahora produce fichas, guías de reparación, informes para juntas, vistas de programas, alertas, una comprobación previa a la publicación, una API pública, exportaciones de datos, un servicio de datos de solo lectura para herramientas de IA y una acción reutilizable de GitHub. Quienes mantienen los feeds, los enlaces de programas, las juntas, las personas investigadoras y quienes desarrollan software pueden acercarse a la misma evidencia desde funciones distintas. La pregunta de producto más difícil es si un hallazgo puede pasar del registro público a una acción respetuosa y luego a una nueva comprobación comparable sin cambiar la evidencia subyacente.

Artefacto del proyecto

La interfaz pública es una promesa sobre la evidencia subyacente

Explorar GTFS Scorecard (se abre en una pestaña nueva)Revisar el código fuente (se abre en una pestaña nueva)

Un validador puede encontrar un error. No puede decidir qué importa

MobilityData ya mantiene el validador canónico de código abierto (se abre en una pestaña nueva). Volver a implementar cientos de reglas estructurales habría creado otra fuente de desacuerdo y habría aportado poco valor a quien mantiene un feed. Reutilicé el motor de reglas compartido y traté su resultado como material de origen, no como una respuesta pública terminada.

Scorecard conserva la versión del validador, el código del aviso, la gravedad y el número de ejemplos. El trabajo creado por el proyecto empieza después: explicar el hallazgo con lenguaje claro, conectarlo con una consecuencia para quien viaja, priorizar unas pocas reparaciones y conservar suficiente evidencia para que otra persona pueda cuestionar la interpretación. La calificación describe información publicada. No califica el servicio de transporte, determina el cumplimiento ni certifica la accesibilidad física.

La primera hipótesis de producto fue que tres reparaciones priorizadas ayudarían a una persona responsable del transporte a actuar. La ficha, las alertas y los recibos públicos ya pueden apoyar el descubrimiento y la priorización. La siguiente hipótesis es más difícil: ¿puede una acción aceptada rastrearse hasta datos nuevos del mismo feed previsto y cerrarse con evidencia comparable? Los últimos pasos de la línea de entrega son el flujo que el proyecto prueba ahora, no un resultado demostrado.

Una calificación es una decisión editorial acompañada de matemáticas

La rúbrica publicada (se abre en una pestaña nueva) asigna 35 por ciento a la corrección, 20 por ciento a la vigencia, 25 por ciento a la experiencia de viaje y 20 por ciento al tiempo real cuando las cuatro categorías pueden medirse. Esos pesos no provienen de la naturaleza ni de una autoridad oficial de GTFS. Yo los elegí. Los campos de accesibilidad reciben un peso considerable porque la información ausente puede eliminar un viaje del conjunto de opciones utilizables por una persona. Es un valor del producto expresado como aritmética.

La ausencia de una fuente de tiempo real no equivale a una fuente de tiempo real defectuosa. Algunas requieren una clave. Algunos operadores no publican datos en tiempo real. Cuando esa categoría no puede medirse, Scorecard vuelve a calcular la calificación usando solo las categorías que pudo medir en vez de insertar un cero en silencio. Sin medir, no aplicable, desconocido, inaccesible y deficiente son estados diferentes.

Esa distinción sirve mucho más allá del transporte público. La ausencia de datos salariales en un directorio laboral no significa salario cero. No tener un resultado de inspección registrado no equivale a aprobar una inspección. Un sensor ambiental fuera de línea no significa que el aire esté limpio. El software cívico debe conservar la incertidumbre en su esquema en vez de borrarla en la presentación.

Por eso cada artefacto registra su perfil de puntuación y la versión del validador. La calificación con letra es una perspectiva creada por el proyecto sobre la calidad del feed publicado. No es una conclusión legal, una calificación oficial de GTFS, un juicio sobre el servicio de la agencia ni una prueba de que una parada sea físicamente accesible.

Una misma cadena de evidencia debe apoyar muchas decisiones

El proyecto publica un registro de origen versionado y permite que la página de la agencia, el informe para juntas, la vista para preparar una reunión, la biblioteca de reparaciones, la insignia, la API pública, la línea de comandos y la acción de GitHub lo lean de distintas maneras. Una persona de una junta y alguien que desarrolla software necesitan presentaciones diferentes, pero la afirmación subyacente no debe cambiar según la audiencia. Esa separación también permitió trasladar los futuros resultados diarios fuera de Git y hacia almacenamiento de objetos sin enseñar un nuevo modelo de datos a cada superficie pública.

La arquitectura seguía teniendo memoria. Para el 8 de julio, las copias diarias habían contribuido a que los datos de Git crecieran hasta 884 MB y el árbol de artefactos publicados hasta 534 MB. Dejé de guardar futuros resultados diarios, pero no reescribí el historial citado del que ya dependían etiquetas, solicitudes de cambio, identificadores de commits y este ensayo. La decisión documentada (se abre en una pestaña nueva) trata ese historial como evidencia que debe sobrevivir a una interfaz, no como residuos desechables de una compilación.

Publicar una calificación sobre una organización pública identificada también crea deberes de procedimiento. La política de listados (se abre en una pestaña nueva) ofrece a las agencias un camino directo para corregir un nombre, una fuente o un detalle y para solicitar la eliminación. El proyecto evita clasificaciones y percentiles públicos, mantiene privados por defecto los datos de responsables y tickets y trata un listado incorrecto o no deseado como un defecto del producto que debe corregirse, no como una discusión que deba ganarse.

Un ensayo de reparación debe poder fallar

Sin acceso a las agencias, ejecuté el experimento honesto más limitado: copiar los dos feeds públicos locales, aplicar solo correcciones deterministas y volver a puntuar las copias. No completé campos de accesibilidad, inventé tarifas o contactos ni eliminé registros. Esos cambios requieren una persona responsable que sepa qué es cierto.

La primera corrección de Yolobus falló su propia verificación. Scorecard cambió route_long_name, pero los avisos del validador estaban principalmente en route_desc, por lo que los 15 permanecieron. Cambié la receta, regeneré la copia y ejecuté el validador de nuevo. La verificación redujo los avisos a dos y elevó la corrección de 90,0 a 92,0. El primer intento fallido pertenece a la evidencia porque cambió la herramienta.

La escala expuso todos los supuestos ocultos

A pequeña escala, un identificador de feed puede parecer un nombre de archivo y una ejecución de publicación puede parecer un único trabajo lineal. A mayor escala, esos atajos se convierten en errores públicos. Un operador puede publicar autobuses y trenes por separado. Un conjunto regional puede representar a varios operadores. Una dirección de origen puede cambiar mientras la identidad pública debe mantenerse. Varios procesos pueden terminar correctamente por separado y aun así combinar sus resultados en datos públicos desactualizados.

Ninguna de las dos fallas se resolvió con más reintentos. Los procesos paralelos tuvieron que publicar solo los registros que acababan de producir. El directorio duplicado necesitaba una única lista revisada que definiera qué debía ser público. El modelo de identidad (se abre en una pestaña nueva) ahora separa la organización, el feed que publica, la dirección utilizada para obtenerlo y cualquier nombre o dirección anterior. Una URL no equivale a una agencia y un directorio de almacenamiento no equivale a una lista de publicación.

La cobertura responsable incluye decidir cuándo no puntuar

El primer trabajo de internacionalización no fue la traducción. Fue encontrar cada lugar donde había confundido a Estados Unidos con un valor predeterminado. El núcleo compartido de GTFS puede funcionar en distintos países. Las medidas del National Transit Database y del censo de Estados Unidos no. Esas se convirtieron en módulos explícitamente regionales. La exploración pasó a organizarse primero por país y la cobertura regional limitada ya no podía parecer un rendimiento deficiente del feed.

La hoja de ruta de cobertura (se abre en una pestaña nueva) también establece un límite para la curación central. Un feed abierto formal con condiciones claras de reutilización puede revisarse a partir de fuentes primarias. Los datos de transporte comunitarios o informales necesitan una persona responsable local, evidencia de consentimiento o reutilización, atribución y un camino de eliminación antes de que el proyecto deba incorporarlos o puntuarlos. A veces, la decisión responsable sobre datos es no contar.

Para este ensayo, revisé el commit del registro del 18 de julio (se abre en una pestaña nueva), que registra 1.609 feeds configurados vinculados a 1.590 identidades de organizaciones en 33 países. La ejecución de puntuación anterior completada (se abre en una pestaña nueva) había usado la copia anterior de 1.518 registros y había publicado 1.501 fichas. Los 91 registros nuevos llegaron después de que esa ejecución tomara sus datos de entrada. Son conteos operativos fechados. Configurado no significa publicado, un registro de feed no siempre equivale a una agencia y un registro grande no es un censo del servicio de transporte.

El mismo trabajo del 18 de julio hizo concreta la carga de investigación. Una revisión de los listados de gtfs-data.jp en Japón (se abre en una pestaña nueva) agregó 40 registros. Una octava revisión europea (se abre en una pestaña nueva) agregó 51 más. Lo importante es lo que esos totales ocultan: cada candidato necesitó condiciones de reutilización de primera parte, un archivo descargable, servicio vigente, una revisión de tamaño y una ubicación verificada. Ampliar la cobertura no fue ingerir una lista. Fue trabajo de evidencia.

La evidencia lingüística necesitaba la misma disciplina. El archivo translations.txt puede mostrar que la información para quienes viajan se publica en más de un idioma. No indica si las personas pueden usar la interfaz de Scorecard en ese idioma. La búsqueda revisada en /es/ (se abre en una pestaña nueva) es una superficie acotada que prioriza el español, no un permiso para afirmar que toda la interfaz está localizada. Medir contenido y ofrecer acceso lingüístico son obligaciones distintas.

El criterio para la beta europea toma la misma decisión de forma ejecutable. El conjunto configurado llegó a 251 feeds revisados en 22 países y superó sus umbrales numéricos de cobertura. A las 00:08 UTC del 19 de julio, el estado conservado del criterio (se abre en una pestaña nueva) todavía devolvía not_ready porque la evidencia puntuada más reciente y otras condiciones de lanzamiento todavía no se habían puesto al día. Un conteo del registro puede superar su umbral antes que la evidencia pública. Prefiero publicar un criterio que diga «no está listo» antes que inferir preparación desde la configuración o hacer una afirmación de lanzamiento que no puedo defender.

La vara de medir forma parte de la evidencia

Una actualización del validador puede cambiar miles de avisos sin que ninguna agencia cambie un solo byte. Un ajuste de la rúbrica puede mover calificaciones aunque el feed de origen sea idéntico. Si el sitio dibuja una línea de tendencia continua a través de esos límites, convierte un cambio metodológico en una historia falsa sobre el rendimiento de una agencia.

La política de comparación (se abre en una pestaña nueva) ahora se niega a llamar tendencia a dos resultados a menos que la identidad del feed y el método de medición sean comparables. El protocolo de actualización gobernada (se abre en una pestaña nueva) ejecuta las reglas nuevas junto a las anteriores sobre un grupo pequeño y revisado, e informa qué resultados cambiarían antes de que el nuevo método entre en vigor. Si cambio la vara de medir, necesito mostrar las consecuencias antes de llamarlo una mejora.

Los datos accesibles y un producto accesible son obligaciones distintas

Una letra es fácil de leer y fácil de usar mal. La ficha solo es útil si quien mantiene el feed puede pasar de la letra a la categoría, de la categoría al hallazgo y del hallazgo a una reparación respaldada por la fuente. Los datos detrás del recibo de Unitrans que aparece a continuación no son una maqueta. La presentación personalizada conserva el JSON, el perfil de puntuación, la versión del validador, el cálculo por categorías y las mejoras priorizadas de una ejecución publicada.

Recibo publicado

Una ficha que conserva la evidencia

Corrección

84.8

Vigencia

100

Experiencia de viaje

60

Tiempo real

Sin medir

Mejoras de mayor impacto

1Las paradas no indican el estado de acceso en silla de ruedas296 registros · 25 puntos

Completar wheelchair_boarding solo con datos de origen verificados. Un valor desconocido debe seguir siendo desconocido hasta que la agencia pueda respaldar la afirmación.

2Los viajes no indican la accesibilidad para sillas de ruedas3,071 registros · 15 puntos

Completar wheelchair_accessible en cada viaje a partir de datos verificados de flota y operación. La ficha no lo infiere del tipo de ruta.

3Hay trazados publicados que ningún viaje utiliza54 registros · 8 puntos

Eliminar los trazados sin uso o conectarlos con los viajes correspondientes. Este hallazgo proviene del aviso unused_shape del validador canónico.

Descargar el JSON de origenAbrir la ficha actual (se abre en una pestaña nueva)

Esta ficha conservada está fechada el 10 de julio de 2026. Una puntuación describe el feed publicado en un momento concreto. No certifica la calidad del servicio ni la accesibilidad física.

Las dos oportunidades más grandes se refieren a campos sobre sillas de ruedas. Eso no prueba que 296 paradas o 3.071 viajes sean inaccesibles. Prueba que el feed publicado no indica su estado. Un feed puede afirmar que una parada es accesible. No puede certificar que la parada sea utilizable. La reparación debe empezar con datos operativos verificados, no con una inferencia diseñada para mejorar la calificación.

La misma distinción se aplica al propio producto. La norma de accesibilidad de GTFS Scorecard (se abre en una pestaña nueva) tiene como objetivo WCAG 2.2 AAA y trata el acceso por teclado, el contraste, la redistribución del contenido y las comprobaciones automatizadas como requisitos de publicación. Su informe público de accesibilidad (se abre en una pestaña nueva) también registra una limitación real: aún no se han documentado pruebas humanas con NVDA y VoiceOver. La automatización no puede certificar la usabilidad vivida, del mismo modo que un campo de un feed no puede certificar la acera, el andén o el vehículo que encuentra una persona.

El alcance no es impacto

El proyecto tiene pruebas automatizadas extensas, pero su documento de investigación con personas usuarias (se abre en una pestaña nueva) declara de forma explícita que las personas y citas originales son sintéticas. Más tarde, una persona real de la comunidad MobilityData encontró funciones útiles, poca facilidad para encontrarlas, falta de evidencia sobre traducciones para quienes viajan, filtros limitados y escasa cobertura europea. Lo traté como una señal acotada. Justificó una navegación más clara, una medida de traducción sin calificación y un criterio de cobertura prudente, no una afirmación de validación de mercado ni un lanzamiento global.

La próxima prueba es un piloto acompañado de 90 días (se abre en una pestaña nueva). El proyecto seguirá un número pequeño de hallazgos desde una alerta, pasando por una persona responsable y una acción aceptadas, hasta una copia nueva del feed exacto previsto. Solo emitirá un recibo de cierre cuando la identidad del feed y el método de medición sean comparables. Ese ciclo está en prueba, no es un resultado demostrado. Hasta que personas responsables reales lo completen, el proyecto puede demostrar alcance técnico y revisión pública, no impacto operativo.

Lo que llevaría al próximo proyecto cívico

• Empezar con la decisión pública, no con el validador o el panel. Preguntar quién necesita actuar, qué evidencia necesita y cómo puede cuestionar el resultado.
• Reutilizar el estándar canónico. Añadir valor propio del proyecto en el traspaso humano, donde un hallazgo técnico se convierte en consecuencia, prioridad y posible reparación.
• Tratar una métrica pública como política. Publicar sus pesos, estados desconocidos, exclusiones, derechos de corrección y límites, no solo el número atractivo.
• Modelar la identidad y los denominadores antes de escalar. Organizaciones, feeds, puntos de acceso, alias, registros configurados y resultados publicados son cosas distintas.
• Versionar la evidencia y la metodología. Negarse a comparar resultados cuando haya cambiado la identidad de la fuente o la vara de medir.
• Diseñar la accesibilidad tanto en los datos como en la entrega. El cumplimiento automatizado es evidencia útil, pero no sustituye la experiencia humana.
• Medir reparaciones cerradas, no conteos de feeds, tráfico o uso del panel. Un hallazgo se vuelve valioso cuando la persona adecuada puede verificarlo, actuar y probar que la fuente cambió.

GTFS Scorecard empezó con una pregunta sobre datos de transporte público y sigue devolviéndome a otra más difícil: ¿qué le debe una persona que trabaja en tecnología cívica al público cuando el software convierte registros desordenados en una respuesta clara?

Cada número necesita un denominador. Cada estado necesita un significado. Cada cambio de metodología necesita una versión. Cada hallazgo necesita una ruta de regreso a la evidencia y hacia la reparación. Quien viaja no debería tener que confiar en la calificación, y quien mantiene el feed no debería tener que adivinar qué hacer con ella.

Puedes revisar el proyecto en vivo (se abre en una pestaña nueva), leer el código fuente y las decisiones documentadas (se abre en una pestaña nueva) y cuestionar los supuestos de la rúbrica. Ese es el objetivo. Los datos públicos confiables no son los que piden confianza. Son los que dejan el trabajo abierto.