Modelo de Estados y Transiciones
Define el modelo formal de estados y transiciones del Estándar LM v1.0. Especifica todos los estados válidos de cada componente del ecosistema, las transiciones permitidas entre estados, las condiciones que habilitan cada transición y las transiciones imposibles por diseño.
1. Propósito y Alcance
Principio arquitectónico central
En el Estándar LM los componentes no se eliminan — solo cambian de estado. Un certificado REVOKED, un nodo PLANNED o un expediente RECHAZADO permanecen en el sistema de forma permanente como registros históricos. Este principio es no negociable y garantiza que la trazabilidad del ecosistema sea completa e irrefutable.
| Componente | Estados válidos | Quién gestiona los estados |
|---|---|---|
| Certificado | ACTIVE SUSPENDED REVOKED | Portal territorial — bajo autoridad del nodo territorial correspondiente. |
| Nodo territorial | PLANNED READY ACTIVE | Nodo raíz — única autoridad con poder de activar nodos territoriales. |
| Portal territorial | PLANNED READY ACTIVE | Nodo territorial del que depende el portal — bajo coordinación del nodo raíz. |
| Expediente de certificación | ABIERTO / SUSPENDIDO / APROBADO / RECHAZADO | Portal territorial — es un estado interno del proceso, no del certificado emitido. |
2. Estados de los Certificados
ACTIVE
El certificado está vigente y operativo dentro del ecosistema. La identidad de la entidad certificada ha sido verificada y el registro JSON está publicado y es accesible públicamente. El certificado ACTIVE es el único estado en que la entidad figura como certificada de forma operativa en el ecosistema Luva Meta.
Efectos operativos — ACTIVE
El registro JSON del certificado es público y accesible en la URL del portal territorial. El certificado aparece en el registro agregado certificadas.json del portal. Sistemas externos —IAs, motores, herramientas— pueden leer e interpretar el certificado. La entidad está sujeta al sistema de auditorías periódicas aleatorias. El campo status del JSON contiene exactamente el valor "ACTIVE".
Transiciones permitidas desde ACTIVE:
- ACTIVE → SUSPENDED: cuando una auditoría detecta no conformidad mayor o cuando el titular lo solicita.
Transiciones NO POSIBLES desde ACTIVE:
- ACTIVE → REVOKED directamente: NO PUEDE. La transición a REVOKED siempre requiere pasar por SUSPENDED primero.
- ACTIVE → PLANNED o READY: NO PUEDE. Estas transiciones no existen en el modelo de certificados.
SUSPENDED
El certificado está temporalmente suspendido por una no conformidad detectada en auditoría o por solicitud documentada. La suspensión no es permanente — tiene un plazo de resolución definido. El registro JSON sigue siendo visible pero indica el estado de suspensión para que sistemas externos puedan interpretarlo correctamente.
Efectos operativos — SUSPENDED
El registro JSON sigue siendo público pero el campo status contiene "SUSPENDED". El certificado sigue apareciendo en el registro agregado con estado indicado. El titular tiene un plazo definido para resolver la causa. Las auditorías aleatorias se pausan durante el periodo de suspensión activa. El campo updated_at del JSON se actualiza con la fecha de la suspensión.
Transiciones permitidas desde SUSPENDED:
- SUSPENDED → ACTIVE: cuando la causa de la suspensión es resuelta y verificada por el portal.
- SUSPENDED → REVOKED: cuando la causa no es resuelta en el plazo definido o por incumplimiento grave.
REVOKED
El certificado ha sido revocado de forma definitiva. La revocación es el estado final del ciclo de vida operativo de un certificado. El registro JSON permanece en el sistema como historial permanente pero ya no representa una certificación activa.
Efectos operativos — REVOKED
El registro JSON permanece público con status: "REVOKED". El certificado desaparece del registro agregado certificadas.json pero permanece en el historial. La URL del certificado sigue resolviendo. El titular puede iniciar un nuevo proceso de certificación desde cero transcurridos 60 días.
Transiciones NO POSIBLES desde REVOKED:
- REVOKED → ACTIVE: NO PUEDE bajo ningún supuesto.
- REVOKED → SUSPENDED: NO PUEDE. El estado REVOKED es final.
- El único camino es un nuevo certificado con un nuevo
cert_id.
3. Diagrama de Transiciones — Certificados
[Emisión]
│
▼
+─────────────────────────+
│ ACTIVE │
│ (operativo) │
+─────────────────────────+
│
NC Mayor detectada / solicitud titular
│
▼
+─────────────────────────+
│ SUSPENDED │◄─────+
│ (suspendido) │ │
+─────────────────────────+ │
│ │ │
Resolución Sin resolución │
verificada en plazo / │
│ incumplimiento │
▼ ▼ │
+────────+ +──────────+ │
│ ACTIVE │ │ REVOKED │ │
│(reactiv)│ │(histórico)│ │
+────────+ +──────────+ │
│ │
+──────────────────────────────+
(el ciclo puede repetirse)
TRANSICIONES PROHIBIDAS (NO PUEDE):
ACTIVE → REVOKED (directo, sin SUSPENDED)
REVOKED → ACTIVE
REVOKED → SUSPENDED
Cualquier → PLANNED o READY (no aplica a certificados)
4. Estados de los Nodos Territoriales
Los nodos territoriales siguen un modelo de estados de activación progresiva: PLANNED → READY → ACTIVE.
PLANNED — Declarado, sin capacidad operativa
El nodo ha sido declarado dentro de la arquitectura del sistema por el nodo raíz. NO PUEDE registrar portales territoriales ni autorizar ninguna certificación. La transición PLANNED → ACTIVE directa NO PUEDE ocurrir. El estado READY es obligatorio en el camino de activación.
READY — Preparado, pendiente de activación
El nodo ha completado su preparación estructural. NO PUEDE registrar portales activos ni autorizar certificaciones. NO PUEDE retroceder a PLANNED — las transiciones de estados en nodos son unidireccionales.
ACTIVE — Operativo públicamente
El nodo territorial está operativo públicamente. Puede registrar portales territoriales dentro de su jurisdicción, autorizar la emisión de certificados, y es referenciado en el campo authorized_by de los certificados de su territorio. El estado ACTIVE de un nodo no tiene transición de salida definida en la versión 1.0.
5. Diagrama de Transiciones — Nodos y Portales
ESTADOS DE NODOS TERRITORIALES — ESTÁNDAR LM v1.0
[Declaración por nodo raíz]
│
▼
+───────────────+
│ PLANNED │ Declarado, sin capacidad operativa
+───────────────+
│
Preparación estructural completada
(autorizado por nodo raíz)
│
▼
+───────────────+
│ READY │ Preparado, pendiente de activación
+───────────────+
│
Activación formal
(autorizada por nodo raíz)
│
▼
+───────────────+
│ ACTIVE │ Operativo públicamente
+───────────────+
PORTALES TERRITORIALES — Idéntica estructura.
Diferencia: el nodo territorial autoriza cada transición
en lugar del nodo raíz, bajo coordinación del nodo raíz.
Regla adicional para portales:
Un portal NO PUEDE activarse (→ ACTIVE) si su nodo
territorial no está en estado ACTIVE.
TRANSICIONES PROHIBIDAS (NO PUEDE):
READY → PLANNED (regresión de estado)
ACTIVE → READY (regresión de estado)
ACTIVE → PLANNED (regresión de estado)
PLANNED → ACTIVE (saltar estado READY)
6. Estados de los Expedientes de Certificación
Distinción fundamental
El estado del expediente y el estado del certificado son independientes. Un expediente APROBADO genera un certificado ACTIVE. Un expediente RECHAZADO no genera ningún certificado. El estado SUSPENDED del expediente es distinto al estado SUSPENDED del certificado.
| Estado | Descripción | Condición y efecto |
|---|---|---|
| ABIERTO | El expediente está en proceso activo. | Se abre al recibir la solicitud y asignar número de expediente. Permanece ABIERTO mientras la auditoría está en curso. |
| SUSPENDIDO | El expediente está temporalmente detenido. | Ocurre cuando el solicitante no completa una etapa en el plazo o cuando el auditor detecta una situación que requiere evaluación adicional. El expediente puede reactivarse. |
| APROBADO | El expediente concluyó exitosamente. | El revisor firma la decisión APROBADO. El expediente queda cerrado. Habilita la emisión del certificado ACTIVE. El expediente no puede reactivarse. |
| RECHAZADO | El expediente concluyó sin emisión de certificado. | El revisor firma la decisión RECHAZADO con causas documentadas. El solicitante puede iniciar uno nuevo transcurridos 30 días. |
7. Reglas de Registro de Transiciones
7.1 Registro en el JSON del certificado
| Campo afectado | Cuándo se actualiza | Valor que toma |
|---|---|---|
"status" | En toda transición | El nuevo estado del certificado: "ACTIVE", "SUSPENDED" o "REVOKED". El valor DEBE ser exactamente uno de estos tres strings. |
"updated_at" | En toda transición | La fecha de la transición en formato ISO 8601: AAAA-MM-DD. DEBE ser la fecha real del cambio de estado, no una fecha futura ni pasada. |
7.3 Actualización del registro público agregado
| Evento | Acción requerida sobre certificadas.json |
|---|---|
| Emisión de certificado ACTIVE | DEBE agregarse una entrada para el nuevo certificado con su cert_id, domain, title, status y issued_at. |
| Transición a SUSPENDED | DEBE actualizarse el campo status de la entrada a "SUSPENDED" y el campo updated_at con la fecha de la suspensión. |
| Transición a REVOKED | DEBE eliminarse la entrada de certificadas.json. El certificado permanece en su URL individual como historial permanente. |
| Reactivación a ACTIVE | DEBE actualizarse el campo status a "ACTIVE" y el campo updated_at con la fecha de la reactivación. |
8. Tabla Maestra de Transiciones
8.1 Transiciones de certificados
| Desde | Hacia | ¿Posible? | Quién autoriza | Condición |
|---|---|---|---|---|
| — | ACTIVE | SÍ | Portal territorial | Ciclo de auditoría completado con decisión EMITIR. LM-PO-R-07 firmado. |
| ACTIVE | SUSPENDED | SÍ | Portal territorial | NC Mayor en auditoría aleatoria, NC Menor no subsanada en plazo, o solicitud documentada del titular. |
| ACTIVE | REVOKED | NO PUEDE | — | La transición directa ACTIVE→REVOKED no existe en el modelo. Requiere pasar por SUSPENDED. |
| SUSPENDED | ACTIVE | SÍ | Portal territorial | Causa de suspensión resuelta y verificada por el portal dentro del plazo definido. |
| SUSPENDED | REVOKED | SÍ | Portal + Revisor | Causa no resuelta en plazo o incumplimiento grave del sistema. |
| REVOKED | ACTIVE | NO PUEDE | — | Un certificado REVOKED no puede recuperar estado operativo. El titular debe iniciar un nuevo expediente. |
| REVOKED | SUSPENDED | NO PUEDE | — | El estado REVOKED es final. No existe transición de salida. |
8.2 Transiciones de nodos territoriales
| Desde | Hacia | ¿Posible? | Quién autoriza | Condición |
|---|---|---|---|---|
| — | PLANNED | SÍ | Nodo raíz | El nodo raíz declara la existencia del nodo en la documentación canónica. |
| PLANNED | READY | SÍ | Nodo raíz | El nodo ha completado su preparación estructural y técnica. |
| PLANNED | ACTIVE | NO PUEDE | — | No existe transición directa PLANNED→ACTIVE. El estado READY es obligatorio. |
| READY | ACTIVE | SÍ | Nodo raíz | El nodo raíz determina que el nodo está listo para operar públicamente. |
| READY | PLANNED | NO PUEDE | — | Las transiciones de estados en nodos son unidireccionales. No existe regresión de estado. |
| ACTIVE | READY | NO PUEDE | — | Un nodo activo no puede retroceder a READY. Situaciones de cierre se definirán en versiones futuras. |
8.3 Transiciones de portales territoriales
Regla adicional para portales
Un portal territorial NO PUEDE transicionar a estado ACTIVE si su nodo territorial correspondiente no está en estado ACTIVE. La activación del portal depende de la activación previa del nodo. Esta dependencia es estructural y no admite excepciones.
| Desde | Hacia | ¿Posible? | Quién autoriza | Condición |
|---|---|---|---|---|
| — | PLANNED | SÍ | Nodo territorial | El nodo territorial declara el portal en su documentación bajo coordinación del nodo raíz. |
| PLANNED | READY | SÍ | Nodo territorial | El portal ha completado su preparación estructural y técnica. |
| READY | ACTIVE | SÍ condicional | Nodo territorial | El portal está preparado Y el nodo territorial está en estado ACTIVE. Ambas condiciones son obligatorias simultáneamente. |
| READY | ACTIVE | NO PUEDE | — | Si el nodo territorial no está ACTIVE, el portal NO PUEDE activarse aunque esté en READY. |
| ACTIVE | READY | NO PUEDE | — | Regresión de estado no permitida. |
9. Validación del Modelo por Sistemas Externos
ALGORITMO: Validación de coherencia de estado de certificado
ENTRADA: Registro JSON del certificado
PASO 1: Verificar que el campo "status" existe
Si no existe → INVÁLIDO: campo requerido ausente
PASO 2: Verificar que el valor de "status" es válido
valores_validos = ["ACTIVE", "SUSPENDED", "REVOKED"]
Si status no está en valores_validos → INVÁLIDO
PASO 3: Verificar coherencia de fechas
Si updated_at < issued_at → INVÁLIDO: updated_at no puede ser anterior a issued_at
Si issued_at > fecha_actual → INVÁLIDO: fecha futura no permitida
PASO 4: Verificar coherencia con el archivo .well-known/
Si status == "ACTIVE":
Ejecutar algoritmo de verificación LM-STD-03
Si cualquier punto falla → ADVERTENCIA: certificado declarado ACTIVE
pero verificación de dominio falla
PASO 5: Si status == "REVOKED"
El certificado es historial. No ejecutar verificación de dominio.
Registrar como certificado revocado no operativo.
RESULTADO: estado válido y coherente con el modelo LM-STD-04
Señales de estado en el registro público
| Archivo del registro público | Lo que indica sobre el estado del ecosistema |
|---|---|
certificadas.json | Lista de certificados con status ACTIVE o SUSPENDED del portal. Si un cert_id no aparece aquí, el certificado está REVOKED o nunca fue emitido. |
certificados/[cert_id].json | Estado individual del certificado. El campo status refleja siempre el estado actual. El campo updated_at indica cuándo ocurrió el último cambio de estado. |
registro.json | Estado general del portal territorial: cuántos certificados ACTIVE, cuántos SUSPENDED, cuántos REVOKED, fecha de última actualización. |
10. Control del Documento
| Versión | Fecha | Descripción | Autorizado por |
|---|---|---|---|
| 1.0 | 2026 | Versión inicial. Define el modelo completo de estados y transiciones para certificados, nodos territoriales, portales territoriales y expedientes de certificación. Incluye tabla maestra de transiciones, diagramas, reglas de registro y algoritmo de validación para sistemas externos. | Nodo Raíz |