Reglamento Oficial

SMIO × Hexaly Location Routing Challenge · Monterrey 2026

Versión: 1.3 (borrador previo al lanzamiento) Fecha de emisión: [por definir — anuncio en EPIO, 22–24 de abril de 2026] Autoridad emisora: Consejo Directivo de la Sociedad Mexicana de Investigación de Operaciones (SMIO) Patrocinador Diamante: Hexaly

Este reglamento rige la participación en el SMIO–Hexaly Location Routing Challenge 2026 (en adelante, «el Reto»). Al registrarse, las personas participantes y sus equipos aceptan de manera íntegra las disposiciones aquí establecidas.


1. Información general

1.1. Organización

El Reto es organizado por la Sociedad Mexicana de Investigación de Operaciones (SMIO) con el patrocinio Diamante de Hexaly. Está vinculado al XIV Congreso de la SMIO (XIV CSMIO), por celebrarse del 7 al 9 de octubre de 2026 en la Universidad de Monterrey, Nuevo León, México.

1.2. Objeto

El Reto invita a la comunidad de Investigación de Operaciones a resolver un conjunto de 30 instancias del Problema de Ruteo con Localización Capacitado (Capacitated Location Routing Problem, CLRP), utilizando cualquier método de su elección. Las mejores soluciones encontradas por los equipos participantes se integran a una biblioteca de referencia permanente.

1.3. Documentos complementarios

El presente reglamento se acompaña de los siguientes documentos, que forman parte integral de la normativa por referencia:

En caso de contradicción entre documentos, prevalece el presente reglamento.


2. Definiciones

Para efectos de este reglamento:


3. Elegibilidad

3.1. Membresía

Cada equipo debe satisfacer, al momento del registro, dos requisitos de membresía:

La información sobre categorías de membresía SMIO y su renovación está disponible en smio.org.

3.2. Alianza ALIO

En el marco de la alianza con la Asociación Latino-Iberoamericana de Investigación Operativa (ALIO), la membresía vigente en una sociedad nacional hermana de la comunidad ALIO (países latinoamericanos, España y Portugal) es por sí misma una membresía válida para efectos del requisito de equipo de §3.1.

Adicionalmente, las personas afiliadas a dichas sociedades pueden, si lo desean, gestionar su membresía SMIO con descuento o exención, según convenio vigente. El procedimiento se detalla en la página de registro.

3.3. Exclusiones

No pueden participar en el Reto:


4. Categorías y composición de equipos

4.1. Categoría de Licenciatura

Equipos de hasta tres personas cursando una licenciatura o carrera técnica de nivel superior, más una persona guía. La persona guía puede ser cualquier persona que no sea estudiante de Licenciatura al momento del registro (por ejemplo, estudiantado de posgrado, profesorado, personal de la industria).

La condición de estudiante de Licenciatura se determina en la fecha de registro del equipo. Una persona que se gradúa durante la ventana de competencia no pierde su elegibilidad retroactivamente. Asimismo, se considera estudiante de Licenciatura a la persona cuyo último periodo lectivo de licenciatura o carrera técnica de nivel superior haya sido el semestre enero–junio/julio de 2026, aun cuando ya se haya graduado a la fecha de registro o de la competencia.

4.2. Categoría Abierta

Equipos de hasta tres personas, sin restricciones de perfil. Pueden participar estudiantes, personal académico e integrantes de la industria.

4.3. Una persona, un equipo

Cada persona puede pertenecer a un único equipo. La pertenencia se verifica al momento del registro.

4.4. Fijación y modificaciones del roster

El roster de un equipo queda fijo al cerrarse el registro formal de equipos en junio de 2026. No se permiten incorporaciones posteriores. El retiro de alguna persona integrante durante la ventana de competencia, por causa justificada, debe notificarse a la SMIO; el equipo continúa con el roster reducido y no hay ajuste retroactivo de puntaje.

4.5. Rol de la persona guía (Categoría de Licenciatura)

La persona guía ocupa un rol de mentoría. Está autorizada a:


5. Registro

5.1. Ventanas de registro

5.2. Auto-declaración y aprobación administrativa

El registro se realiza mediante auto-declaración en la Plataforma. Cada persona integrante declara, bajo protesta de decir verdad:

La SMIO revisa cada registro de equipo y lo aprueba antes de habilitar el envío de soluciones. En caso de rechazo, se notifica el motivo y el equipo puede corregir y reenviar el registro.

5.3. Datos requeridos

Cada equipo debe proporcionar al momento del registro:


6. Problema y datos oficiales

6.1. Especificación técnica

La formulación del problema, los parámetros, la función objetivo y las restricciones se detallan en la especificación técnica complementaria. En resumen, el problema consiste en decidir simultáneamente: qué depósitos abrir, cómo asignar clientes a depósitos abiertos y cómo diseñar las rutas de vehículos, minimizando el costo total (apertura de depósitos + costo fijo por ruta + distancia total recorrida) sujeto a restricciones de capacidad de depósitos, capacidad de vehículos y número máximo de vehículos por depósito.

6.2. Instancias oficiales

Se publicarán 30 instancias oficiales al inicio de la ventana de competencia, distribuidas entre escalas pequeña, mediana y grande, cubriendo entre 200 y 3,000 clientes y entre 10 y 50 depósitos. Las instancias de escala pequeña y mediana usan distancias euclidianas en coordenadas sintéticas; las de escala grande usan distancias reales de red vial de la Zona Metropolitana de Monterrey, que pueden ser asimétricas.

Las instancias oficiales no se publicarán antes del inicio de la ventana de competencia. Previo al inicio, la SMIO publicará un generador de instancias de código abierto (junio de 2026) para que los equipos puedan desarrollar y probar sus métodos con instancias sintéticas análogas.

6.3. Línea base de Hexaly

Antes del inicio de la ventana de competencia, Hexaly ejecutará su solver Hexaly Optimizer sobre las 30 instancias oficiales para producir una solución de referencia para cada una. Estas soluciones:

6.4. Verificador oficial

La SMIO pone a disposición un verificador oficial de código abierto que evalúa la factibilidad y el costo de cualquier solución. Los equipos pueden usarlo localmente para validar sus propias soluciones antes de enviarlas.

El verificador oficial en ejecución en la Plataforma es el árbitro único en materia de factibilidad y costo. Cualquier discrepancia entre implementaciones locales y el verificador oficial se resuelve a favor del oficial.


7. Envío de soluciones

7.1. Plataforma oficial

Todos los envíos deben realizarse a través de la Plataforma oficial del Reto. No se aceptan envíos por correo electrónico, por mensajería ni por ningún otro canal.

7.2. Formato

Las soluciones deben cumplir el formato especificado en la especificación técnica complementaria. Cualquier solución que no pueda ser procesada por el verificador por errores de formato será rechazada con diagnóstico, y el envío no impactará el tiempo de liderato.

7.3. Marca de tiempo de referencia

La marca de tiempo oficial de un envío es la hora de recepción del archivo por parte de la Plataforma, registrada en UTC. Esta marca se utiliza para el cálculo del tiempo de liderato. Los tiempos de procesamiento posteriores (verificación, escritura en base de datos) no afectan la marca de tiempo oficial.

Todas las horas en la interfaz pública de la Plataforma se muestran en zona horaria América/Monterrey (UTC−6, sin horario de verano), con la marca UTC disponible al pasar el cursor.

7.4. Verificación

Cada envío se somete al verificador oficial. El resultado puede ser:

7.5. Desempate en costos iguales

En caso de que un envío factible tenga un costo exactamente igual al de la BKS actual, la BKS incumbente se mantiene. El equipo que estableció primero la BKS conserva el liderato. La tolerancia numérica para determinar igualdad es la misma que aplica el verificador: 10^{-4} absoluto.

7.6. Límites de envío

Para preservar la estabilidad de la Plataforma y evitar envíos accidentales masivos:

Los envíos infactibles no cuentan para estos límites.

7.7. Publicación

La evolución cronológica de la BKS por instancia se publica en tiempo real durante la ventana de competencia. Para cada instancia, la Plataforma muestra públicamente:

Los archivos de solución propiamente dichos (los .sol) y los metadatos a que se refiere §7.8 (tiempo de cómputo, descripción del entorno) no se publican durante la ventana: se incorporan a la biblioteca de referencia permanente al cierre, conforme a la sección 13.

7.8. Información adicional en envíos que establecen BKS

Cuando un envío resulta en una nueva BKS para una instancia, la Plataforma solicita al equipo, mediante un aviso posterior a la verificación, información adicional sobre ese envío específico:

Esta información puede completarse en cualquier momento antes del cierre de la ventana de competencia. La Plataforma envía un recordatorio por correo electrónico 24 horas antes del cierre a los equipos con información pendiente. La información recolectada se incluye en la biblioteca de referencia junto con la solución correspondiente. Su omisión no afecta la puntuación del equipo, pero la entrada correspondiente en la biblioteca de referencia se marca como «metadatos incompletos».


8. Puntuación y tabla de clasificación

8.1. Tiempo de liderato por ventanas deslizantes de 24 horas

Para cada instancia \ell y cada equipo t, se define:

\Delta_{\ell,t} = \text{tiempo acumulado, medido en días, durante el cual el equipo } t \text{ sostuvo la BKS de la instancia } \ell.

El cálculo se realiza con precisión de segundos y se expresa en días decimales (por ejemplo, 36 horas equivalen a 1.5 días). Las ventanas son deslizantes: el cronómetro de un equipo inicia en el instante exacto de la marca de tiempo oficial del envío que establece su BKS, y detiene en el instante exacto en que otro equipo la desplaza o se cierra la ventana de competencia.

No se acumula tiempo de liderato sobre una instancia antes de que algún equipo haya establecido la primera BKS factible para esa instancia.

8.2. Bono por BKS final

Para cada instancia \ell y cada equipo t, se define:

b_{\ell,t} = \begin{cases} 1 & \text{si el equipo } t \text{ sostiene la BKS final de la instancia } \ell \text{ al cierre de la ventana de competencia} \\ 0 & \text{en caso contrario} \end{cases}

8.3. Puntaje total del equipo

El puntaje total del equipo t es:

S_t = \sum_\ell \Delta_{\ell,t} + B \cdot \sum_\ell b_{\ell,t}

donde B es el bono por BKS final, expresado en días equivalentes. El Consejo Directivo selecciona el valor de B con el criterio de equilibrar el incentivo de liderato sostenido con el incentivo de cierre fuerte.

Valor de B para el Reto 2026: B = 3 días. Decisión del Consejo Directivo de la SMIO, 1 de junio de 2026. La elección se ubica en aproximadamente el 14 % de la duración nominal de la ventana de competencia, en el mismo orden de magnitud que un tiempo de liderato típico durante la ventana; equilibra la recompensa por sostener una BKS hasta el cierre sin desincentivar el envío temprano de soluciones.

8.4. Equipo ganador

En cada Categoría (Licenciatura y Abierta) se declara un equipo ganador: aquel con el mayor puntaje total S_t dentro de su Categoría. En caso empate exacto en el puntaje total, el Consejo Directivo aplicará los siguientes criterios de desempate, en orden:

  1. Mayor número de BKS finales sostenidas.
  2. Mayor tiempo total de liderato.
  3. Marca de tiempo más temprana del primer envío factible del equipo.

8.5. Tablas de clasificación públicas

Durante la ventana de competencia, la Plataforma mantiene cuatro vistas públicas:

Al cierre de la ventana se publican adicionalmente los archivos de solución de cada BKS histórica (los .sol propiamente dichos) y los metadatos de §7.8, integrándose a la biblioteca de referencia permanente.


9. Descripción del Método

9.1. Requisito

Cada equipo debe entregar una Descripción del Método en formato PDF a través de la Plataforma. Debe ser una descripción breve y concisa del método empleado; no se exige una extensión máxima fija.

9.2. Momento de entrega

La Descripción del Método se entrega al formalizar el equipo en el registro. La Plataforma no permite completar el registro de un equipo sin la carga previa del archivo.

9.3. Contenido mínimo

La Descripción del Método debe incluir, como mínimo, las secciones de la plantilla oficial (apéndice A):

9.4. Idioma

La Descripción del Método puede entregarse en español o en inglés, a elección del equipo.

9.5. Consecuencia de la no entrega

Equipo que no entregue Descripción del Método no puede participar.

9.6. Revisión

El Consejo Directivo revisa cada Descripción del Método antes de la adjudicación de premios. En caso de que el documento sea excesivamente extenso, omita secciones requeridas o no permita identificar claramente el método empleado, el Consejo puede solicitar una versión revisada dentro de un plazo adicional de 72 horas.


10. Colaboración, herramientas y hardware

10.1. Independencia de equipos

Cada equipo trabaja de manera independiente. No se permite el intercambio entre equipos de soluciones, código fuente, configuraciones de solver, ni resultados intermedios durante la ventana de competencia.

10.2. Asesoría externa informal

Se permite la consulta informal con personas ajenas al equipo (asesores académicos, colegas, comunidad en línea) para aclarar dudas conceptuales sobre el problema o sobre métodos de optimización en general. Lo que no se permite es la contribución sistemática de código o de soluciones por parte de personas ajenas al equipo: tales aportaciones constituirían una extensión de facto del roster y violan la sección 4.

La distinción clave es: preguntas pertinentes son asesoría; entrega de código funcional es participación.

10.3. Herramientas de cómputo y solvers

Se permite el uso de cualquier herramienta de cómputo o solver, incluyendo:

Licencias académicas gratuitas de Hexaly Optimizer están disponibles para todos los académicos participantes registrados en el Reto, independientemente de si usan Hexaly o no para competir. El procedimiento de solicitud se indica en la Plataforma.

10.4. Herramientas de IA y modelos de lenguaje

Se permite el uso de herramientas de inteligencia artificial, incluyendo asistentes de programación basados en modelos de lenguaje grandes (por ejemplo, Claude, Copilot, ChatGPT, Cursor).

10.5. Hardware

No existen restricciones de hardware. Los equipos pueden utilizar cualquier recurso computacional a su disposición: computadoras personales, clústeres institucionales, servicios de cómputo en la nube, hardware especializado (GPU, TPU).

Para propósitos de la biblioteca de referencia, cada equipo debe auto-reportar en su Descripción del Método la configuración de hardware utilizada y el tiempo de reloj real aproximado por instancia.


11. Premios

11.1. Premios por Categoría

Categoría de Licenciatura — equipo ganador:

Categoría Abierta — equipo ganador:

11.2. Beneficios para todo el padrón

Independientemente de su ranking final, toda persona participante recibe:

11.3. Logística del viaje

El apoyo de viaje se coordina entre la SMIO, Hexaly y el equipo ganador en el transcurso de agosto y septiembre de 2026. La persona beneficiaria es designada por el propio equipo; no es transferible a personas ajenas al roster registrado.

En caso de que ninguna persona del equipo ganador pueda viajar a CSMIO 2026 por causa justificada, el espacio de presentación puede cubrirse de manera remota.


12. Descalificación

12.1. Causales

Constituyen causales de descalificación:

12.2. Consecuencias

La descalificación conlleva:

La descalificación de un equipo no provoca recálculo retroactivo del tiempo de liderato de otros equipos. Las BKS históricas establecidas por el equipo descalificado se mantienen como hitos cronológicos; los tiempos que otros equipos hubieran sostenido «en ausencia» del equipo descalificado no se acreditan retroactivamente.

12.3. Procedimiento

La descalificación se declara por acuerdo del Consejo Directivo, previa audiencia del equipo afectado a través del canal oficial de contacto. El equipo cuenta con 48 horas hábiles para responder a la notificación de causal antes de la decisión final.


13. Derechos sobre datos, código y publicación

13.1. Propiedad del código

Cada equipo conserva la propiedad intelectual sobre su código fuente. La SMIO y Hexaly no solicitan la entrega, divulgación ni licenciamiento del código.

13.2. Soluciones BKS

Al participar, cada equipo otorga a la SMIO una licencia perpetua, no exclusiva, mundial y gratuita para:

Cada equipo puede publicar libremente análisis, comparativos o artículos académicos basados en su propio trabajo y sus propias soluciones. No puede publicar soluciones de otros equipos sin autorización expresa. Puede referenciar la biblioteca de referencia citando (conjunto de datos, año, número de instancia).

13.3. Descripciones del Método

La licencia a favor de la SMIO para la publicación de las Descripciones del Método es perpetua, no exclusiva y con atribución al equipo.

13.4. Instancias

Las 30 instancias oficiales se publican bajo las siguientes licencias:


14. Disposiciones administrativas

14.1. Canal oficial de contacto

El canal oficial para consultas relacionadas con el Reto es smio.mexico@gmail.com, con el asunto que inicie con [Reto 2026].

14.2. Idioma autoritativo

Este reglamento existe en versiones en español y en inglés. En caso de discrepancia entre las versiones, prevalece la versión en español.

14.3. Zona horaria de referencia

Todos los plazos y marcas de tiempo del Reto se registran internamente en UTC. La interfaz pública muestra también la hora en América/Monterrey (UTC−6, sin horario de verano).

14.4. Aceptación del reglamento

Al completar el registro formal de equipo, cada persona integrante acepta el presente reglamento en su totalidad. La aceptación se registra por medios electrónicos en la Plataforma.

14.5. Protección de datos personales

La SMIO trata los datos personales de las personas participantes conforme a su aviso de privacidad, disponible en smio.org. Los datos se utilizan únicamente para fines del Reto y para las comunicaciones oficiales de la SMIO.


Apéndice A — Plantilla de Descripción del Método

Se proporciona como plantilla LaTeX y plantilla Word, disponibles en la Plataforma. Estructura mínima:

SMIO × Hexaly Reto 2026 — Descripción del Método

Equipo: [nombre del equipo]
Categoría: [Licenciatura | Abierta]
Integrantes: [lista de nombres]
Persona guía: [nombre, solo Categoría de Licenciatura]

1. Reformulación del problema
   [Una o dos oraciones sobre qué formulación se utilizó,
    si alguna: MIP de dos índices, partición de conjuntos,
    formulación directa de heurística, etc.]

2. Descripción general del método
   [Un párrafo. ¿Qué hace el método? ¿Es exacto, heurístico,
    matheurístico, basado en aprendizaje? ¿Cuáles son sus
    componentes principales?]

3. Herramientas y solvers
   - Lenguajes y bibliotecas: [ejemplo: Python 3.11, NumPy, AMPL]
   - Solvers: [ejemplo: Gurobi 11.0, Hexaly 14.0]
   - Versiones específicas.

4. Hardware
   - Núcleos: [ejemplo: 32 núcleos]
   - RAM: [ejemplo: 128 GB]
   - GPU: [si aplica, modelo y uso]

5. Presupuesto de cómputo
   - Tiempo típico por instancia grande: [ejemplo: 2 horas por
     instancia de 3,000 clientes]

6. Referencias (opcional)
   [Trabajos previos en los que se basa el método]

(Descripción breve, en formato PDF)

Apéndice B — Resumen de fechas clave

Las fechas son aproximadas y serán confirmadas oportunamente. Las fechas específicas de la ventana de competencia se anunciarán al menos un mes antes de su inicio.

Evento Fecha aproximada
Anuncio público en EPIO 22–24 de abril de 2026
Liberación del generador de instancias Junio de 2026
Apertura del registro formal de equipos Junio de 2026
Cierre del registro formal de equipos Inicio de la ventana de competencia
Inicio de la ventana de competencia Mediados de julio de 2026
Cierre de la ventana de competencia Principios de agosto de 2026
Publicación de resultados finales Agosto de 2026
XIV CSMIO · sesión del Reto, taller Hexaly, ceremonia 7–9 de octubre de 2026

Apéndice C — Registro de cambios


Fin del Reglamento Oficial. Versión 1.3 (borrador). Consejo Directivo SMIO, 2026.