LM-STD-01 v1.0 2026 VIGENTE

Vocabulario Normativo del Estándar LM

Define con precisión el significado y nivel de obligatoriedad de cada término prescriptivo utilizado en los documentos del estándar, garantizando que cualquier implementación interprete los requisitos de forma idéntica y sin ambigüedad.

Este documento es prerequisito de: LM-STD-02 LM-STD-03 LM-STD-04 LM-STD-05

1. Propósito y Alcance

Este documento define el vocabulario normativo del Estándar LM. Es el primer documento que DEBE leerse antes de cualquier otra especificación del Estándar LM. Su función es eliminar la ambigüedad interpretativa que surge cuando los mismos términos se usan con significados distintos en contextos diferentes.

Principio fundamental

Los términos definidos en este documento tienen un significado técnico preciso y controlado dentro del Estándar LM. Ese significado puede diferir de su uso coloquial en castellano. Cuando un término definido aparezca en cualquier especificación del Estándar LM, DEBE interpretarse exactamente según la definición contenida en este documento.

Alcance de aplicación

Este vocabulario aplica a:

Todos los documentos del Estándar LM (LM-STD-01 a LM-STD-05 y versiones posteriores).
Todos los procedimientos internos del ecosistema Luva Meta (LM-PI-001, LM-PO-001 y derivados).
Todos los registros JSON de certificados emitidos por portales territoriales.
Toda documentación canónica publicada en wiki.luvameta.com y estandar.luvameta.com.
Cualquier implementación de terceros que declare conformidad con el Estándar LM.

2. Términos Prescriptivos del Estándar LM

Los términos prescriptivos determinan el nivel de obligatoriedad de un requisito. El Estándar LM adopta y adapta el modelo de niveles de requisito del RFC 2119 (IETF) con ajustes de vocabulario para el idioma castellano.

Término LM	Equivalente RFC 2119	Nivel	Efecto si no se cumple
DEBE	MUST	Obligatorio absoluto	Invalida la implementación o activa cambio de estado del certificado.
NO DEBE	MUST NOT	Prohibición absoluta	Su ocurrencia invalida la implementación o activa cambio de estado.
DEBERÍA	SHOULD	Recomendado fuerte	Su incumplimiento DEBE documentarse y justificarse. Puede generar No Conformidad Menor.
NO DEBERÍA	SHOULD NOT	Desaconsejado fuerte	Su ocurrencia DEBE documentarse y justificarse. Puede generar No Conformidad Menor.
PUEDE	MAY	Opcional	No genera hallazgo. El implementador decide libremente.
NO PUEDE	(no aplica)	Restricción estructural	Indica que una acción está técnicamente vedada en el contexto del Estándar LM.

DEBE — Obligatorio absoluto

Requisito que toda implementación conforme DEBE cumplir sin excepción. No existen circunstancias que justifiquen su incumplimiento dentro del Estándar LM. Una implementación que no cumpla un requisito DEBE no puede ser considerada conforme con el estándar.

Nota: El término DEBE aparece en mayúsculas sostenidas siempre que se usa como término normativo. Su uso en minúsculas ("debe") dentro de un texto indica uso coloquial, no normativo.

Ejemplo: El campo "status" del JSON DEBE tener exactamente uno de los valores: ACTIVE, SUSPENDED o REVOKED.

NO DEBE — Prohibición absoluta

Acción o condición que ninguna implementación conforme puede ejecutar o permitir. El NO DEBE es la contraparte obligatoria del DEBE.

Nota: La distinción entre NO DEBE y NO PUEDE es importante: NO DEBE indica una prohibición normativa que el implementador tiene capacidad técnica de violar pero no debe hacerlo. NO PUEDE indica una restricción estructural del sistema.

Ejemplo: El campo "root_authority" NO DEBE contener ninguna URL distinta a "https://luvameta.com".

DEBERÍA — Recomendado fuerte

Requisito que toda implementación conforme DEBERÍA cumplir salvo que existan razones documentadas y justificadas para no hacerlo. El incumplimiento de un DEBERÍA es aceptable únicamente cuando se acompaña de documentación explícita de la causa y evaluación del impacto.

Nota: En el contexto de auditorías del sistema, el incumplimiento de un DEBERÍA sin justificación documentada genera una No Conformidad Menor. Con justificación documentada genera una Observación.

Ejemplo: El campo "owner.role" DEBERÍA estar presente en el bloque subject del certificado.

NO DEBERÍA — Desaconsejado fuerte

Acción o condición que las implementaciones conformes NO DEBERÍAN realizar salvo que existan razones documentadas y justificadas. Es la contraparte del DEBERÍA.

Ejemplo: Un certificado NO DEBERÍA permanecer en estado SUSPENDED por más de 30 días sin que el portal documente la causa y el estado de la subsanación.

PUEDE — Opcional

Elemento cuya presencia o ausencia es completamente libre para el implementador. El PUEDE no establece preferencia ni genera ningún tipo de hallazgo si se omite o si se incluye.

Ejemplo: El sitio PUEDE incluir un archivo humans.txt en la raíz del dominio.

NO PUEDE — Restricción estructural

Condición que el sistema no permite por razón de su arquitectura o lógica interna. A diferencia del NO DEBE —que es una prohibición normativa— el NO PUEDE describe una imposibilidad funcional dentro del Estándar LM.

Ejemplo: Un certificado en estado REVOKED NO PUEDE pasar directamente a estado ACTIVE. La única ruta es iniciar un nuevo expediente desde la fase de investigación.

3. Términos del Sistema Luva Meta

Además de los términos prescriptivos, el Estándar LM define un conjunto de términos técnicos propios del sistema cuyo significado preciso es obligatorio para la interpretación correcta de cualquier especificación. Se presentan en orden alfabético.

A

Autoridad raíz

El nodo raíz del ecosistema Luva Meta, identificado por el dominio luvameta.com. Es el único componente con autoridad para definir la arquitectura global del sistema, activar nodos territoriales y modificar el Estándar LM. Ningún otro componente del ecosistema puede asumir las funciones de la autoridad raíz ni declararse equivalente a ella.

Auditoría de ingreso

Proceso de evaluación técnica y semántica completo ejecutado una sola vez sobre una entidad digital al momento de solicitar el estado ACTIVE para su certificado. Es el proceso más exhaustivo del ciclo de certificación y prerequisito para la emisión del certificado.

Auditoría periódica aleatoria

Proceso de verificación de vigilancia activa ejecutado por el portal territorial sobre entidades con certificado ACTIVE, en un momento no comunicado previamente al titular dentro de una ventana de tiempo definida. La aleatoriedad de la fecha dentro de la ventana es un mecanismo deliberado de integridad del sistema. El titular NUNCA conoce el día exacto de la auditoría.

C

Categoría de identidad

Clasificación tipológica de una entidad digital dentro del ecosistema Luva Meta. Solo son válidas las categorías definidas en el vocabulario del sistema: semantic_identity_company, digital_project, organization, tech_platform, personal_professional. Cualquier otro valor en el campo "category" invalida el certificado.

Certificado

Registro JSON público que documenta la identidad verificada de una entidad digital dentro del ecosistema Luva Meta. El certificado no es un archivo decorativo ni un sello visual. Es un archivo JSON con una URL pública estable que cualquier sistema externo puede consultar y verificar en cualquier momento. Ejemplo: CL-0001, AR-0002.

Coherencia transversal

Condición en que todos los elementos de identidad de una entidad certificada —el JSON del certificado, los metadatos HTML del sitio, el manifest.json, el llms.txt, los documentos institucionales y el contenido visible— son mutuamente consistentes. Es un requisito obligatorio para la emisión del certificado ACTIVE.

E

Estado del certificado

Condición operativa de un certificado en un momento dado. Solo existen tres estados válidos: ACTIVE SUSPENDED REVOKED. Ninguna implementación puede asignar un valor de estado distinto a estos tres. Cada transición de estado DEBE quedar registrada con fecha en el campo updated_at del JSON.

H — I — N

Hallazgo

Resultado documentado de una auditoría que identifica una desviación entre el estado real de un elemento y el criterio del Estándar LM. Se clasifica en tres niveles: No Conformidad Mayor, No Conformidad Menor y Observación.

Identidad semántica

Representación estructurada de una entidad digital que describe su naturaleza, propósito, territorio de operación y responsable, registrada en el bloque subject del certificado JSON. Define qué información DEBE ser verificable, no solo cuál información se declara.

Nodo raíz

Punto central de referencia del ecosistema Luva Meta. Dominio: luvameta.com. Equivalente a la autoridad raíz.

Nodo territorial

Componente estructural que organiza el sistema según contextos geográficos o jurisdiccionales. No emite certificados directamente. Solo puede operar con estado ACTIVE. Ejemplo: chile.luvameta.com.

P — R — T — V

Portal territorial

Componente operativo del ecosistema encargado de gestionar certificaciones dentro de un nodo territorial. Es el único componente con autoridad para emitir, suspender y revocar certificados. Ejemplo: cl.luvameta.com.

Trazabilidad — Principio fundamental

Principio según el cual todo cambio de estado, decisión operativa y emisión de certificado DEBE quedar registrado con fecha en el sistema de forma permanente. Los registros no se eliminan: solo se actualizan. Este principio garantiza que el historial completo de cualquier componente sea siempre verificable.

Ventana de auditoría

Periodo de tiempo definido por el portal territorial dentro del cual DEBE ejecutarse al menos una auditoría periódica aleatoria. La entidad NUNCA conoce el día exacto dentro de la ventana. Ventanas válidas en v1.0: mensual, bimestral y trimestral.

Verificación de dominio

Proceso mediante el cual una entidad demuestra control técnico real sobre el dominio que desea certificar, publicando un archivo de verificación en la ruta estándar /.well-known/luvameta.txt. El archivo DEBE contener el challenge criptográfico generado por el portal y el hash SHA-256 correspondiente.

4. Formatos y Vocabularios Controlados

4.1 Formatos de datos obligatorios

Campo JSON	Formato requerido	Especificación
`"language"`	ISO 639-1	Código de dos letras minúsculas. Válidos: `"es"`, `"en"`, `"pt"`. Inválidos: `"ESP"`, `"espanol"`.
`"country"` / `"territory_scope"`	ISO 3166-1 alpha-2	Código de dos letras mayúsculas. Válidos: `"CL"`, `"AR"`. Inválidos: `"Chile"`, `"cl"`.
`"issued_at"` / `"updated_at"`	ISO 8601 — fecha	Formato AAAA-MM-DD. Válido: `"2026-04-12"`. Inválidos: `"12/04/2026"`, `"abril 2026"`.
`"domain"` / URLs	URL HTTPS	Debe comenzar con `"https://"`. No se aceptan URLs `http://` ni sin protocolo.
`"cert_id"`	[PAIS]-[SECUENCIAL]	ISO 3166-1 alpha-2 + guión + mínimo 4 dígitos. Válidos: `"CL-0001"`. Inválidos: `"cl-0001"`, `"CHILE-1"`.
`"hash_algo"`	Valor fijo	Único valor válido en v1.0: `"sha256"`. Cualquier otro valor invalida la verificación criptográfica.

4.2 Vocabulario controlado de estados

Estado	Contexto de uso	Definición normativa
ACTIVE	Certificado, Nodo, Portal	El componente está operativo públicamente dentro del ecosistema.
SUSPENDED	Certificado	El certificado está temporalmente suspendido. El registro sigue siendo visible pero indica el estado de suspensión.
REVOKED	Certificado	El certificado fue revocado de forma definitiva. Permanece como historial pero ya no es operativo. NO PUEDE volver a ACTIVE directamente.
READY	Nodo, Portal	El componente está preparado para activación pero aún no opera públicamente.
PLANNED	Nodo, Portal	El componente está declarado dentro de la arquitectura pero aún no está preparado para activación.

4.3 Vocabulario controlado de categorías de identidad

Valor en JSON	Nombre descriptivo	Descripción normativa
`semantic_identity_company`	Empresa con identidad semántica	Entidad con estructura empresarial o comercial y presencia digital estructurada. Implica responsable legal identificado.
`digital_project`	Proyecto digital	Iniciativa digital con propósito definido. No requiere estructura empresarial formal pero sí responsable identificado.
`organization`	Organización	Entidad sin fin de lucro, asociación, fundación o colectivo con identidad digital propia. No requiere personalidad jurídica comercial.
`tech_platform`	Plataforma tecnológica	Sistema, aplicación, API o plataforma tecnológica en operación pública con usuarios o consumidores.
`personal_professional`	Persona profesional	Presencia digital personal de carácter profesional vinculada a una persona natural que opera como profesional independiente o creador.

4.4 Vocabulario controlado de tipos de operador

Valor en JSON	Descripción normativa
`"Person"`	El operador es una persona natural identificada por nombre real. El campo `"owner.name"` DEBE contener el nombre real de la persona.
`"Organization"`	El operador es una entidad jurídica o colectiva. El campo `"owner.name"` DEBE contener el nombre oficial de la organización.

5. Reglas de Interpretación del Estándar LM

Las siguientes reglas rigen la interpretación de cualquier documento del Estándar LM cuando exista ambigüedad o aparente conflicto entre disposiciones.

Regla	Principio	Aplicación
R-01	Específico prevalece sobre general	Cuando una especificación particular define un criterio que parece contradecir este vocabulario, la especificación particular prevalece únicamente en el ámbito que define. El vocabulario normativo prevalece en todo lo demás.
R-02	Término normativo en mayúsculas	Un término prescriptivo solo tiene valor normativo cuando aparece en mayúsculas sostenidas. En minúsculas dentro de un texto es uso coloquial sin efecto normativo.
R-03	Silencio no implica permiso	Si el Estándar LM no menciona un elemento o acción en particular, eso no implica que sea permitido. Solo son permitidos los elementos que el estándar declara explícitamente.
R-04	Trazabilidad es no negociable	El principio de trazabilidad es el único principio del Estándar LM que no admite excepciones. Ningún registro puede ser eliminado. Ningún estado puede cambiar sin registro. Esta regla prevalece sobre cualquier otra disposición.
R-05	Versión vigente prevalece	En caso de conflicto entre versiones del Estándar LM, la versión más reciente publicada en `estandar.luvameta.com` prevalece sobre versiones anteriores, salvo que la propia versión más reciente establezca compatibilidad retroactiva explícita.

6. Control del Documento

Versión	Fecha	Descripción	Autorizado por
1.0	2026	Versión inicial. Define términos prescriptivos, términos del sistema, formatos controlados y reglas de interpretación.	Nodo Raíz

LM-STD-02 — JSON Schema del Certificado