Por qué es importante

Las arquitecturas de governance para sistemas de altas consecuencias se están desarrollando rápidamente. Múltiples layers independientes están convergiendo en torno a preocupaciones institucionales similares: evidencia en tiempo de ejecución, admisibilidad, continuidad, cierre evidencial y suficiencia de la revisión. Sin un mecanismo estándar de declaración, se repiten tres modos de fallo estructural:

• Revisión de boundary sin semántica declarada: las arquitecturas adyacentes se revisan o comparan frente a estándares de referencia externos sin que el layer revisado haya declarado su propia semántica de interoperabilidad, creando ambigüedades de posicionamiento que podrían haberse evitado.
• Solapamiento semántico no declarado: los sistemas adyacentes desarrollan vocabulario o descripciones funcionales solapados sin un mecanismo canónico para distinguir el alcance declarado de la convergencia incidental.
• Ambigüedad en las compras: compradores, auditores y reguladores no pueden determinar de forma segura o coherente qué declara o excluye un governance layer sin leer documentación extensa del proveedor, sujeta a interpretación.

GLM aborda esto publicando una declaración estructurada, versionada y hasheable en una URL well-known predecible – haciendo que la semántica de los governance layers sea descubrible por máquinas sin exigir la sustitución de la documentación legible por humanos.

Estructura del Manifest

Un punto de entrada conforme a GLM es un archivo JSON publicado en /.well-known/governance-layer-manifest.json en el dominio canónico. A partir del schema 1.3, este punto de entrada puede ser un manifest de layer único o un organization index que apunta a manifests de layers publicados de forma independiente en ubicaciones well-known separadas (véase manifest_kind más abajo). Un manifest de layer único contiene las siguientes secciones principales:

• schema_version – versión de la especificación del schema GLM (p. ej. “1.4”)
• manifest_kind – declara si este archivo es un único governance layer ("layer", el valor por defecto) o un artefacto de descubrimiento a nivel de organización ("organization_index"), introducido en el schema 1.3
• manifest_version – versión de este documento manifest concreto, distinta de la versión del schema GLM (p. ej. “7.0” para el manifest de EVIDE)
• valid_from – fecha a partir de la cual esta versión del manifest está en vigor (ISO 8601)
• valid_until – fecha en la que esta versión del manifest fue sustituida, o null si está activa actualmente
• layer – nombre del producto, propietario, layer_type (vocabulario controlado), descriptor del proveedor
• timing_axis – posición en el eje bind-time (pre-bind / at-bind / post-bind / cross-cutting)
• operational_scope – qué hace y qué no hace el layer
• claims_boundary – claim autoritativo del layer, non-claims explícitos, restricción de boundary para el consumidor, forbidden_interpretations
• controlling_test – principio normativo de nivel superior para evaluar los claims de interoperabilidad
• interoperability_doctrine – el principio fundacional de la componibilidad GLM
• composition – tipos de layer componibles y URLs de manifests declaradas
• machine_readable_status – boundary_readiness, authority_dependency, execution_capability
• public_anchors – referencias documentales verificables de forma independiente
• glm_compatibility – familia de schema, rango de versiones soportadas, políticas de cambio
• manifest_digest – verificación de integridad del contenido SHA-256 con método de canonicalización y, a partir del schema 1.4, un canonicalization_id opcional despachable por máquina
• vendor_framework_constructs – bloque opcional para declarar constructos conceptuales definidos por el proveedor con URIs canónicas, sin importarlos al vocabulario controlado GLM

Vocabulario de Layer Type (controlado, extensible)

El campo layer_type utiliza un vocabulario controlado para permitir la comparación automática entre implementaciones. El vocabulario es extensible mediante futuras revisiones del schema. Los nombres específicos del proveedor se declaran por separado en vendor_layer_name y vendor_layer_descriptor.

Definiciones de Campos Clave

responsibility-bearing closure state (estado de cierre portador de responsabilidad): la configuración responsable que existe en el momento en que una decisión finalizada y atribuible cruza un boundary evidencial – incluidas las condiciones de autoridad declaradas, las condiciones de supervisión y el estado de calidad observacional. Este estado es específico del momento del cruce y no puede reconstruirse a partir de artefactos posteriores sin perder su valor evidencial.

externally verifiable artifact (artefacto verificable externamente): un artefacto estructurado de modo que un revisor independiente pueda interpretarlo y verificarlo sin acceso al sistema de origen, a sus operadores ni a su contexto de ejecución. La verificación no debe depender de la explicación del productor.

authoritative_layer_claim: una única frase que declara qué hace este layer que ningún layer adyacente afirma hacer. Utilizado por los sistemas de compras y de composición para determinar el no solapamiento sin requerir una revisión bilateral.

consumer_boundary_constraint: una declaración de lo que los consumidores posteriores no deben inferir de las salidas de este layer. Distinto de los non-claims – la restricción de boundary para el consumidor aborda cómo pueden y no pueden usarse las salidas tras su recepción.

forbidden_interpretations: un array legible por máquina de usos semánticos explícitamente prohibidos para las salidas de este layer. Distinto de explicit_non_claims (que declara lo que el layer no hace) – forbidden_interpretations declara lo que los sistemas posteriores no deben concluir ni inferir de las salidas del layer. Permite la validación automatizada frente al colapso semántico.

controlling_test: un principio normativo de nivel superior para evaluar los claims de interoperabilidad. Declarado en la raíz del manifest (no dentro de claims_boundary) porque se aplica como postura general de governance en todas las secciones del manifest, no solo al claims boundary. En la v1.0 es un principio legible por humanos, no una restricción ejecutable por máquina.

interoperability_doctrine: el principio filosófico fundacional de la componibilidad GLM, declarado como campo de nivel superior. GLM no establece interoperabilidad entre sistemas. Hace que el boundary, los claims, los non-claims y las condiciones de componibilidad de un governance layer sean legibles por máquina y legibles de forma independiente, de modo que la interoperabilidad potencial entre layers pueda evaluarse mediante la inspección y comparación de sus manifests – no mediante acuerdos bilaterales de integración entre proveedores.

glm_compatibility: declara la familia de schema y el rango de versiones soportadas para este manifest. Permite a los ecosistemas multiactor verificar la compatibilidad declarada con el schema GLM sin requerir comunicación directa entre implementadores. El campo schema_family identifica explícitamente el framework GLM (no la versión del layer del proveedor) como referencia para las declaraciones de compatibilidad.

supersedes / supersedes_digest: campos de cadena de custodia para el versionado del manifest. A partir del schema 1.2, supersedes es un objeto estructurado que declara el digest SHA-256 de la versión anterior y la url pública de archivo. El manifest anterior referenciado sigue siendo la fuente autoritativa de sus propios valores de valid_from y valid_until. El campo supersedes_digest en la raíz se mantiene por retrocompatibilidad con las herramientas de los schemas 1.0 y 1.1. Cuando ambos campos están presentes, supersedes_digest DEBE coincidir con supersedes.digest. Un manifest en el que estos valores difieren es no conforme.

La finalidad arquitectónica de esta cadena va más allá del versionado técnico. Las versiones anteriores del manifest deben permanecer públicamente accesibles en la URL declarada en supersedes.url. Esto permite a cualquier parte independiente – incluidos los auditores externos – recuperar la declaración exacta que estaba en vigor durante un periodo específico, verificar su integridad mediante el digest y reconstruir la cadena completa de versiones sin depender del relato retrospectivo del propietario del layer.

valid_until: declarado en la raíz del manifest, este campo registra la fecha en la que este manifest dejó de ser la declaración activa. DEBE ser null en el manifest activo actualmente y solo se rellena cuando la versión se archiva. No debe usarse para predeclarar una fecha de caducidad futura.

manifest_digest vs manifest_signature: GLM v1.0 utiliza manifest_digest (SHA-256 del archivo tal como se sirve) para la verificación de integridad del contenido. Una manifest_signature (firma criptográfica que vincula el digest a una identidad) se declara por separado cuando está disponible. El digest verifica la integridad del contenido; la firma verifica la autoría.

Vocabulario de machine_readable_status: los valores de boundary_readiness (stable | provisional | experimental) y reviewability_state (portable | partial | environment_dependent) son vocabularios de trabajo propuestos en la v1.0. Todavía no son enumeraciones normativas definidas por un organismo de estandarización. Futuras revisiones del schema podrán formalizar estos vocabularios.

boundary_readiness – definiciones (aclaración): boundary_readiness describe el estado de madurez/estabilidad de la propia definición del boundary declarado – su clasificación estructural y el contenido de sus campos – y nada más. Es independiente de la madurez operativa del sistema subyacente, del estado de deployment, de la capacidad de ejecución, de la reviewability de los outputs, de la autoridad, de la interoperabilidad, del cumplimiento normativo, o de la veracidad de cualquier claim.

• stable – La definición del boundary está consolidada y sujeta a control explícito de versión/cambio como interfaz declarada estable.
• provisional – La definición del boundary está especificada en su sustancia y constituye la declaración actualmente vigente para el boundary, pero todavía no ha sido congelada como interfaz declarada estable. Es el contenido de sus campos – no su clasificación estructural (layer_type, timing_axis y el conjunto completo de campos utilizados) – lo que permanece sujeto a revisión.
• experimental – La definición del boundary se utiliza intencionadamente con fines exploratorios o evaluativos, de modo que es su propia clasificación estructural – incluyendo layer_type, timing_axis, o el enfoque arquitectónico general usado para representar el boundary – lo que permanece bajo examen.

Las declaraciones de componibilidad son unilaterales – un layer puede declarar compatibilidad con un layer adyacente sin que esa declaración sea recíproca. Las herramientas que obtienen ambos manifests pueden determinar si la componibilidad está declarada mutuamente.

vendor_framework_constructs: un bloque opcional que permite al propietario de un layer declarar públicamente constructos conceptuales definidos por el proveedor, sin importarlos al vocabulario controlado GLM. Cada constructo lleva una canonical_uri para el aislamiento del namespace, un vendor_local_alias para la legibilidad, una label, una descripción purpose y una version. El bloque incluye forbidden_interpretations para evitar la herencia semántica o la interoperabilidad implícita por parte de sistemas posteriores. El campo purpose es descriptivo, no normativo. Declara la intención operativa definida por el proveedor para el constructo y no debe interpretarse como comportamiento semántico estandarizado.

manifest_kind / organization_index: a partir del schema 1.3, un manifest puede declarar manifest_kind: "organization_index" en lugar del valor por defecto implícito "layer". Un organization index no es un governance layer. No declara ningún claims_boundary, no ocupa ninguna posición en timing_axis y no formula ningún claim de governance. Su única función es el descubrimiento: enumera las URLs de los manifests de los layers GLM publicados de forma independiente pertenecientes a la misma organización, opcionalmente anclados por el digest de cada manifest enumerado. Un organization index DEBE declarar timing_axis: null y DEBE declarar forbidden_interpretations que cubran como mínimo organization_as_layer, authority_transfer_between_listed_layers, implied_composability e interoperability_certification. Cada layer referenciado por un organization index sigue siendo un manifest completo e independiente conforme a las reglas de los schemas 1.0-1.2, con su propio claims_boundary, su propio timing_axis y su propia cadena supersedes. La componibilidad entre los layers enumerados, si existe, sigue declarándose exclusivamente a través del campo composable_with_manifests de cada layer. El principio rector: un organization index descubre layers. No los compone.

Organization Index (Schema 1.3)

Implementación Proponente Inicial

Lo siguiente ilustra la estructura del manifest GLM usando EVIDE como implementación proponente inicial. El manifest completo está disponible en https://www.certifywebcontent.com/.well-known/governance-layer-manifest.json.

Cómo Implementar GLM

Publicar un manifest conforme a GLM requiere tres pasos:

Verificación Independiente

Cualquier tercero puede verificar de forma independiente que un manifest GLM publicado no ha sido alterado desde que se calculó su digest. La verificación no requiere herramientas especiales – solo una shell de línea de comandos y los comandos de abajo.

La verificación funciona descargando el archivo en vivo, sustituyendo el valor del digest declarado por el placeholder estándar, calculando el SHA-256 del archivo normalizado y comparando el resultado con el valor declarado en manifest_digest.value. Si coinciden, el archivo está intacto.

Los pasos siguientes son la ruta de verificación legacy/manual. Son anteriores a canonicalization_id y localizan manifest_digest.value mediante sustitución de texto en lugar de mediante la ubicación estructural JSON Pointer, y no gestionan la sustitución de manifest_signature.value. Siguen siendo válidos para cualquier manifest que no declare un canonicalization_id.

Canonicalization ID (Schema 1.4)

canonicalization_method describe en prosa la transformación aplicada para el digest. Un verificador no debería tener que interpretar lenguaje natural para determinar qué transformación aplicar antes de recalcular un digest. canonicalization_id da nombre a esa transformación como identificador despachable por máquina y versionado. canonicalization_method sigue presente junto a él como descripción legible por humanos; los dos campos no son alternativos entre sí.

glm-digest-v1 – algoritmo normativo

Entrada: el archivo manifest exactamente como se sirve, como secuencia de bytes. El archivo DEBE ser UTF-8 válido. Si no lo es, un verificador que aplique glm-digest-v1 DEBE rechazarlo con el motivo “not valid UTF-8 – cannot apply glm-digest-v1” en lugar de intentar cualquier otra codificación.

Paso 1 – Localizar mediante JSON Pointer, nunca mediante búsqueda de texto. Usando un parser JSON capaz de informar del desplazamiento en bytes de cada token, localiza:

• el rango de bytes del valor de cadena JSON (incluidos los caracteres de comillas que lo rodean) en el JSON Pointer /manifest_digest/value;
• si la clave manifest_signature existe, y su subcampo value está presente con tipo JSON string (no null, no ausente): el rango de bytes del valor de cadena JSON en el JSON Pointer /manifest_signature/value.

Localizar mediante ruta estructural en lugar de mediante contenido de cadena es lo que hace segura la transformación: un valor de cadena idéntico que aparezca bajo cualquier otra clave se encuentra en un JSON Pointer distinto y nunca se examina. No existe ningún escenario, bajo este algoritmo, en el que se altere una cadena que coincida por casualidad en otra parte del archivo.

Paso 2 – Sustituir, dejando intacto cualquier otro byte. Sustituye el rango de bytes localizado para /manifest_digest/value por el literal de bytes UTF-8 exacto, comillas JSON incluidas:

Si en el Paso 1 se localizó un rango de bytes para /manifest_signature/value, sustitúyelo por el literal de bytes UTF-8 exacto, comillas JSON incluidas:

Estos dos literales están fijados como parte de la definición de glm-digest-v1 y no pueden alterarse sin definir un nuevo canonicalization_id. La sustitución se realiza directamente sobre el búfer de bytes original en los rangos de bytes identificados en el Paso 1 – el archivo nunca se parsea completamente ni se vuelve a serializar. Cada byte fuera de los rangos identificados – espacios en blanco, orden de las claves, indentación, terminadores de línea, una marca de orden de bytes inicial si está presente, un salto de línea final si está presente – permanece idéntico byte a byte al archivo servido. Todos los desplazamientos de bytes usados en los Pasos 1 y 2 son desplazamientos dentro de la secuencia de bytes original completa, marca de orden de bytes incluida cuando está presente: el BOM, si existe, se preserva exactamente y nunca se elimina, reubica ni excluye de la secuencia sobre la que se calculan los desplazamientos.

Paso 3 – Hash. Calcula el SHA-256 sobre la secuencia de bytes producida por el Paso 2, sin ninguna transformación adicional.

Dos implementaciones independientes que sigan esta definición, usando cualquier parser JSON que informe de los desplazamientos en bytes de los tokens parseados – una capacidad ampliamente disponible, no a medida – producen bytes de salida idénticos y un digest SHA-256 idéntico.

Declaraciones de Componibilidad

El campo composable_with_manifests permite a un layer identificar los manifests específicos con los que declara componibilidad. Esto permite a las herramientas construir un grafo de componibilidad entre los layers participantes.

Las declaraciones de componibilidad son unilaterales: un layer puede declarar compatibilidad con un layer adyacente sin que esa declaración sea recíproca. Cuando ambos layers se declaran mutuamente en sus respectivos manifests, la componibilidad está declarada mutuamente y es comprobable de forma independiente obteniendo ambos manifests. Esta declaración recíproca no constituye prueba de interoperabilidad operativa. Esto permite:

• Verificación automatizada en compras sin requerir documentación bilateral
• Construcción del grafo de composición a partir de archivos manifest públicamente disponibles
• Evaluación de las relaciones de componibilidad declaradas por parte de los sistemas que consumen las declaraciones de los governance layers
• Validación de scenario packs que confirma declaraciones coherentes entre los layers participantes

Preguntas Planteadas Durante la Revisión Arquitectónica

Las siguientes preguntas surgieron durante la revisión arquitectónica y el debate público de la especificación GLM y de la implementación de referencia EVIDE. Se conservan aquí porque aclaran distinciones estructurales que no resultan inmediatamente evidentes a partir de la especificación por sí sola.

¿Puedo implementar GLM en mi propio proyecto comercial o de investigación?

Sí. GLM se diseñó específicamente para fomentar implementaciones independientes. Puedes implementar, adaptar, extender o publicar un manifest conforme a GLM para proyectos comerciales, académicos, gubernamentales, de código abierto o propietarios. La implementación proponente no impone ningún permiso, registro, acuerdo de licencia ni requisito de atribución. Se fomentan las implementaciones independientes porque ayudan a evaluar el valor del propio modelo de declaración para la evaluación de la interoperabilidad. Las organizaciones que publican un manifest GLM público pueden, opcionalmente, ser citadas en los ejemplos públicos de implementación: Valida aquí tu manifest GLM

¿Por qué GLM recomienda la publicación en una well-known URI?

Porque la descubribilidad forma parte del modelo de interoperabilidad. Una declaración de boundary que no puede localizarse de forma predecible no puede ser consumida automáticamente por los sistemas adyacentes. El uso de well-known URIs sigue el mismo principio arquitectónico que otros mecanismos de descubrimiento a escala de internet: la declaración debería ser descubrible sin coordinación bilateral previa.

¿Puede un governance layer publicar un manifest GLM sin implementar EVIDE?

Sí. GLM es independiente de EVIDE. Cualquier governance layer puede publicar un manifest conforme a GLM con independencia de si realiza witnessing, evaluación de admisibilidad, governance de la ejecución, estabilización evidencial, reviewability o cualquier otra función de governance. GLM describe boundaries. No prescribe la implementación.

¿Publicar un manifest GLM crea autoridad o legitimidad de governance?

No. Un manifest GLM declara lo que un layer afirma, lo que no afirma, dónde opera y cómo se presenta para la composición. La publicación no crea autoridad, legitimidad, fiabilidad ni interoperabilidad. Crea una superficie de declaración legible por máquina. La validez de los claims declarados sigue siendo responsabilidad del propietario del layer.

¿Puede un layer ser conforme a GLM aun declarando claims muy amplios o poco realistas?

Sí. GLM no valida la veracidad, la calidad, la corrección ni la viabilidad de los claims de un layer. Un manifest puede ser sintácticamente válido y a la vez contener claims incompletos, exagerados u operativamente poco realistas. GLM hace que esos claims sean legibles por máquina y revisables de forma independiente. No los certifica. La responsabilidad sobre el contenido declarado recae íntegramente en el propietario del layer.

¿Por qué GLM no certifica la interoperabilidad?

Porque los claims de interoperabilidad y las declaraciones de interoperabilidad son funciones distintas. GLM declara boundaries, claims, non-claims, posición temporal y postura de composición. No determina si dos sistemas son realmente compatibles, ni certifica que se haya alcanzado la interoperabilidad. Declarar un boundary no es lo mismo que validar una relación a través de los boundaries.

¿Por qué GLM incluye forbidden_interpretations?

Porque muchos fallos de governance surgen de suposiciones y no de claims explícitos. Un layer puede no haber afirmado nunca una capacidad y, sin embargo, los sistemas adyacentes pueden empezar gradualmente a tratar esa capacidad como si existiera. forbidden_interpretations hace que esas herencias semánticas prohibidas sean legibles por máquina en lugar de dejarlas implícitas.

¿Por qué GLM se centra tanto en los non-claims?

Porque los fallos de governance a menudo surgen de capacidades que se dieron por supuestas en lugar de afirmarse explícitamente. En ecosistemas de governance componibles, entender lo que un layer no determina puede ser tan importante como entender lo que hace. Los non-claims reducen el riesgo de transferencia implícita de autoridad, herencia semántica y ambigüedad de boundary.

GLM define un layer type “boundary”. ¿Tienen alguna opinión sobre qué debería ocupar esa posición en la práctica, o se deja intencionadamente abierto?

Intencionadamente abierto. GLM define la posición en el eje temporal y la función operativa, pero no prescribe qué sistema debe ocuparla. El boundary layer resuelve la admisibilidad en el bind-time de la ejecución antes de que la consecuencia se confirme. Qué sistema realiza esa función es una decisión de implementación soberana que se deja al propietario de ese layer.

EVIDE parece situarse principalmente post-bind / del lado del closure. ¿Cómo gestionan las situaciones en las que el propio estado de autoridad pre-bind está en disputa?

EVIDE no resuelve la autoridad pre-bind en disputa. Eso queda explícitamente fuera de su alcance. Lo que EVIDE hace es registrar el estado de autoridad declarado en el momento del cierre, incluyendo si ese estado estaba en disputa, era provisional o no era verificable. Un estado pre-bind en disputa no bloquea la estabilización. Pasa a formar parte del registro evidencial, con sus limitaciones declaradas en lugar de ocultas.

Cuando EVIDE registra el contexto de clasificación declarado, ¿valida la estabilidad de esa taxonomía ascendente o simplemente preserva lo que se declaró en ese momento?

Se preserva tal como se declaró. EVIDE no valida la estabilidad ni la corrección de la taxonomía ascendente. Registra lo que se declaró en el momento del cruce. Si la taxonomía cambia posteriormente o pasa a estar en disputa, el registro evidencial refleja lo que se declaró en ese momento concreto – que es precisamente su valor forense.

¿Cómo explican la diferencia entre “apoya la defendibilidad” y “satisface un requisito regulatorio”?

La distinción es estructural. EVIDE apoya la defendibilidad produciendo un registro evidencial verificable de forma independiente de las condiciones de cierre. Que ese registro satisfaga un requisito regulatorio específico depende de lo que exija la regulación y de cómo evalúe el registro la autoridad competente. EVIDE no determina el cumplimiento. Proporciona la infraestructura evidencial que hace que la defendibilidad sea posible y reconstruible de forma independiente.

¿Aspiran a que GLM se convierta en un estándar formal, o el objetivo actual es establecer una superficie de declaración práctica de facto?

El objetivo inmediato es una superficie de declaración práctica. GLM es actualmente una especificación abierta destinada a establecer un patrón: declaraciones de boundary legibles por máquina publicadas en well-known URIs, verificables de forma independiente, sin requerir coordinación bilateral ni transferencia de autoridad. Que ese patrón evolucione finalmente hacia un esfuerzo formal de estandarización sigue siendo una cuestión abierta. El valor inmediato es práctico más que institucional.

Si existen múltiples declaraciones de boundary para el mismo objeto operativo y esas declaraciones son mutuamente incompatibles, ¿proporciona GLM algún mecanismo de precedencia o de resolución de conflictos?

No, y de forma intencionada. GLM puede hacer visible un conflicto. No resuelve el conflicto. En cuanto un sistema empieza a determinar qué declaración prevalece o cómo deben resolverse las incompatibilidades, ha pasado de la declaración a la governance. Cualquier modelo de precedencia, mecanismo de arbitraje o proceso de resolución de conflictos pertenece al layer que reclame explícitamente la responsabilidad de esa función. GLM declara. GLM no adjudica.

GLM hace que un constructo sea descubrible y que su significado declarado sea legible por máquina. Pero ¿garantiza que los sistemas gobernados de forma independiente mantendrán interpretaciones compatibles a lo largo del tiempo?

No. La descubribilidad y la compatibilidad interpretativa a lo largo del tiempo son problemas estructuralmente distintos. GLM hace que un constructo sea localizable y que su significado declarado sea legible en el momento de la declaración. No garantiza que los observadores gobernados de forma independiente mantengan interpretaciones compatibles a medida que acumulan sus propias suposiciones en torno a él. Precisamente por eso el manifest se centra tanto en forbidden_interpretations, non-claims explícitos, boundaries de autoridad y restricciones de composición – no como garantías de permanencia semántica, sino como mecanismos para reducir el colapso semántico silencioso durante la interoperabilidad. Que las interpretaciones divergentes requieran una realineación explícita sigue siendo un problema de coordinación fuera de la superficie de declaración GLM.

¿Cómo siguen siendo válidos los manifests GLM cuando la autoridad, el estado y las condiciones operativas cambian con el tiempo?

GLM aborda esto mediante el versionado y no mediante una suposición de permanencia. Un manifest no pretende describir la postura de governance de un layer indefinidamente. Declara lo que un layer afirma, lo que excluye y cómo se presenta para la composición en un momento concreto – anclado por valid_from, un digest calculado y una cadena supersedes que enlaza con las versiones anteriores.

Cuando la autoridad, el estado o las condiciones operativas cambian, la expectativa es que se publique una nueva versión del manifest – con la versión anterior permaneciendo verificable de forma independiente mediante su digest. Esto es estructuralmente similar a cómo EVIDE gestiona el estado de cierre: el valor del registro no está en que siga siendo verdadero para siempre, sino en que capture con precisión lo que se declaró en el momento en que se externalizó.

Que el versionado por sí solo sea suficiente para entornos de governance de alta frecuencia o altamente dinámicos es una cuestión abierta – y probablemente cada vez más relevante a medida que estos ecosistemas maduren.

GLM hace que las declaraciones sean descubribles y legibles por máquina en el momento de la publicación. Pero ¿qué ocurre cuando los sistemas gobernados de forma independiente siguen evolucionando después de publicarse una declaración – pueden las interpretaciones compatibles mantenerse estables aunque la propia declaración original permanezca sin cambios?

Este es un problema estructuralmente distinto de la descubribilidad. GLM se diseñó para hacer que las declaraciones sean descubribles, legibles por máquina y comparables en el momento en que se publican. Permite a un layer declarar qué es, dónde opera, qué afirma y qué no afirma explícitamente.

Lo que GLM no intenta determinar es si las interpretaciones se mantienen alineadas a lo largo del tiempo tras la publicación. Un manifest puede permanecer sin cambios mientras el ecosistema circundante evoluciona, surgen nuevos layers, cambian las suposiciones o las relaciones de composición se vuelven más complejas. Esas cuestiones pertenecen a un espacio de problemas distinto.

Desde la perspectiva de GLM, el objetivo es más acotado: proporcionar una superficie declarativa estable que permita a los sistemas gobernados de forma independiente exponer sus boundaries de forma coherente y revisable. Que la alineación semántica persista a través del tiempo, las revisiones y las composiciones en evolución requeriría mecanismos más allá de la propia declaración – mecanismos que, por diseño, quedan fuera de la superficie de declaración GLM.

En ese sentido, la revisión de la extensión del vocabulario fue valiosa no simplemente porque se aceptó una nueva categoría, sino porque ayudó a aclarar dónde termina la responsabilidad de GLM y dónde empiezan otras cuestiones de governance.

¿Qué impide a un governance layer cambiar unilateralmente sus boundaries declarados tras la publicación?

GLM no intenta estabilizar permanentemente los boundaries como primitiva arquitectónica. Asume que un governance layer ya tiene un boundary definido y se centra en hacer que ese boundary esté explícitamente declarado, sea legible por máquina y revisable de forma independiente en el momento de la publicación.

La evolución del boundary no es necesariamente una condición de fallo. Los sistemas, los modelos de governance y las restricciones operativas pueden cambiar legítimamente con el tiempo. Lo que importa desde una perspectiva evidencial es si esos cambios pueden reconstruirse de forma independiente. Un governance layer puede declarar un conjunto de boundaries hoy y otro distinto más adelante. La declaración histórica sigue siendo verificable de forma independiente mediante su digest, y la cadena supersedes hace transparente la evolución de los boundaries declarados a lo largo del tiempo.

En este sentido, el foco está menos en impedir el cambio de boundary y más en impedir la pérdida de reconstruibilidad cuando el cambio de boundary se produce. Que la ambigüedad del boundary se origine en una declaración inicial insuficiente, en una deriva del boundary o en factores estructurales es una pregunta que se vuelve respondible precisamente porque las declaraciones históricas siguen siendo verificables de forma independiente.

¿Deberían mantenerse las versiones anteriores del manifest públicamente accesibles tras publicarse una nueva versión?

Sí. Esta es la finalidad arquitectónica de la cadena supersedes. La URL del manifest actual sirve siempre la última versión. Las versiones anteriores deberían permanecer públicamente accesibles en una URL estable de tu elección – una ruta de archivo en tu dominio, un archivo versionado o cualquier otra ubicación públicamente accesible.

La razón es evidencial. Cualquier parte independiente que revise un evento de governance, una decisión, una disputa o una auditoría pasados debería poder recuperar la declaración que estaba en vigor cuando se produjo ese evento – y verificar mediante el digest publicado que la declaración no se ha alterado desde entonces. Sin versiones anteriores públicamente accesibles, esa reconstrucción no es posible ni siquiera cuando la propia cadena supersedes está intacta.

Un governance layer puede actualizar legítimamente sus boundaries a medida que evoluciona. Lo que preserva la cadena de versiones es la capacidad de determinar qué se declaró en cualquier momento concreto del pasado, sin depender del relato retrospectivo del propietario del layer. Esa independencia es precisamente lo que hace significativa la cadena de custodia.

Lo que sigue siendo recuperable y lo que sigue siendo admisible pueden no ser lo mismo. ¿Cómo gestiona GLM las situaciones en las que las condiciones de autoridad o admisibilidad que originalmente respaldaban una decisión de governance ya no existen?

GLM no intenta determinar si las condiciones históricas de autoridad siguen siendo válidas, exigibles o admisibles en el presente. Lo que intenta preservar es la capacidad de reconstruir de forma independiente qué se declaró, cuándo se declaró y cómo evolucionaron esas declaraciones a lo largo del tiempo.

Un governance layer puede cambiar legítimamente sus boundaries, dependencias, estructuras de autoridad o suposiciones operativas a medida que evoluciona. Desde la perspectiva de GLM, la cuestión crítica no es si se produce el cambio, sino si el estado histórico sigue siendo reconstruible de forma independiente después de que se produzca el cambio. Si un governance layer publica un conjunto de declaraciones hoy y otro distinto más adelante, la declaración anterior sigue siendo verificable de forma independiente mediante su digest publicado y su cadena supersedes.

La distinción entre recuperabilidad y admisibilidad es importante y deliberada. GLM apoya la recuperabilidad. No determina la admisibilidad. Que una declaración recuperada sea admisible en un contexto de governance, legal o institucional concreto depende de factores fuera de la superficie de declaración GLM – incluidos los marcos de autoridad, los requisitos regulatorios y los mandatos institucionales que GLM no fue diseñado para resolver.

Cuando coexisten múltiples governance layers válidos y sus claims de autoridad se solapan parcialmente, ¿cómo deberían las instituciones determinar qué declaración de governance prevalece?

GLM no debería determinar qué declaración de governance prevalece. Eso trasladaría a GLM de un layer de declaración a un layer de resolución de autoridad, que no es su función. GLM está diseñado para hacer que los claims de governance, los non-claims, la posición temporal, las suposiciones de componibilidad y los boundaries declarados sean explícitos, legibles por máquina y revisables de forma independiente.

Cuando coexisten múltiples governance layers válidos y sus claims de autoridad se solapan parcialmente, la cuestión de la prevalencia debería resolverse mediante una base de autoridad externa: la ley, un mandato institucional, una jerarquía contractual, un estatuto de governance interno, una obligación regulatoria u otro marco de autoridad decisoria explícitamente reconocido. GLM puede exponer el solapamiento. Puede hacer visible el conflicto. Puede mostrar dónde dos layers reclaman responsabilidades adyacentes o competidoras. Pero no debería decidir silenciosamente la legitimidad.

Aquí es donde EVIDE resulta complementario. EVIDE tampoco resuelve el conflicto de autoridad. Su función es preservar evidencia reconstruible de qué se declaró, qué layer actuó, qué base de autoridad se invocó, qué traspaso o escalada se produjo y cómo se estabilizó o se disputó posteriormente la cadena de decisión.

GLM declara el boundary de governance. Los marcos de autoridad determinan la precedencia. EVIDE preserva la evidencia de cómo se aplicó esa precedencia. Esta separación es importante porque, de lo contrario, un layer técnico de declaración podría convertirse involuntariamente en un layer constitucional oculto.

¿Qué mecanismo del modelo GLM garantiza que la semántica de governance pueda reconstruirse de forma independiente en un momento concreto sin depender de una continuidad de estado implícita?

El mecanismo es la combinación de tres requisitos estructurales. Primero, el propio manifest debe publicarse contemporáneamente y ser verificable de forma independiente – el manifest_digest y la cadena de versiones hacen que el contenido declarado sea comprobable de forma independiente a lo largo del tiempo. Segundo, el timing_axis obliga a cada layer a declarar explícitamente dónde opera respecto al momento del bind, impidiendo que la continuidad se dé por supuesta silenciosamente a través de los límites temporales. Tercero, explicit_non_claims y forbidden_interpretations hacen visibles los límites de la reconstrucción – un layer que no pueda garantizar la externalización contemporánea debe declarar esa limitación en lugar de dejarla inferencial. GLM no garantiza la reconstrucción. Hace que las condiciones bajo las cuales la reconstrucción es, o no es, posible sean legibles por máquina y revisables de forma independiente. En EVIDE concretamente, esa brecha se aborda mediante la externalización contemporánea en el momento del cruce: la configuración responsable se externaliza cuando existe, no se reconstruye después.

Estado de la Especificación

GLM-BD (Governance Layer Manifest — Boundary Declarations) es actualmente una especificación abierta propuesta en la versión de schema 1.4. Se desarrolló dentro del EVIDE Governance Lab en mayo de 2026 como parte del trabajo sobre la interoperabilidad de governance layers en arquitecturas de sistemas de altas consecuencias.

• Estado: Especificación abierta propuesta – todavía no adoptada por ningún organismo de estandarización
• Licencia: Permisiva para la implementación – cualquier governance layer puede implementar GLM sin restricciones ni requisitos de atribución hacia el proveedor proponente
• Autoridad del manifest: GLM declara la semántica de los layers. No decide la validez, la legitimidad, la adopción ni la conformidad. Un manifest no debe convertirse en una metaautoridad sobre primitivas de governance soberanas. Un manifest GLM es metadato de infraestructura autodeclarado, no certificación de terceros.
• Extensión del vocabulario: Los nuevos valores de layer_type requieren una justificación documentada y un incremento de la versión del schema
• Primera extensión externa del vocabulario: El layer_type formation y el calificador temporal source-anchored fueron aceptados el 2026-06-12 tras una revisión formal de la justificación. Implementación proponente: NOUS (Hlias Staurou). Maintainer revisor: EVIDE Governance Lab. Esto constituye la schema_version 1.1. Digest de la justificación (SHA-256): fad8c5a839f601893114b9072f5bedb96d01837bb844c9635339db321d7404bd
• Schema 1.2: El campo supersedes pasó de ser una cadena simple a un objeto estructurado que lleva el digest de la versión anterior y la url pública de archivo. El campo supersedes_digest se mantiene como contrato estable para las herramientas de los schemas 1.0 y 1.1, que pueden seguir leyendo supersedes_digest e ignorar el nuevo objeto estructurado. Bajo este planteamiento, el schema 1.2 es un cambio aditivo no disruptivo, coherente con la política de incremento de versión menor. El campo supersedes_digest en la raíz se mantiene por retrocompatibilidad y DEBE coincidir con supersedes.digest cuando ambos están presentes. También se añadió un campo valid_until en la raíz para registrar cuándo una versión archivada del manifest dejó de estar activa. Esto constituye la schema_version 1.2.
• Schema 1.3: Introduce manifest_kind, un campo opcional en la raíz que distingue un manifest de layer único ("layer", el valor por defecto implícito para todos los manifests de los schemas 1.0-1.2) de un artefacto de descubrimiento a nivel de organización ("organization_index"). La extensión responde a las organizaciones que publican múltiples governance layers independientes y que anteriormente no tenían una forma estándar de declarar, en una única ubicación predecible, qué manifests de layers existen y dónde están publicados. Un organization index no formula ningún claim de governance, no ocupa ninguna posición en el eje temporal y no debe interpretarse como que implica componibilidad o transferencia de autoridad entre los layers que enumera. Parte proponente: EVIDE Governance Lab. Maintainer revisor: Stone Shi (CLARIXO/TGTRACING). Revisado y aprobado en principio el 2026-06-17, siguiendo la misma separación propuesta/revisión utilizada para la extensión formation del schema 1.1. Principio rector: un organization index descubre layers. No los compone. Esto constituye la schema_version 1.3. Nota sobre la compatibilidad hacia adelante: un consumidor que no reconozca manifest_kind DEBE tratar el artefacto como opaco y omitir la validación, en lugar de recurrir al valor por defecto implícito layer y señalar como no conformidad la ausencia de claims_boundary o de una posición en timing_axis. Esto preserva una compatibilidad hacia adelante segura para las herramientas anteriores a la 1.3.
• Schema 1.4: Introduce manifest_digest.canonicalization_id, un campo de cadena opcional junto al ya existente canonicalization_method legible por humanos. Mientras que canonicalization_method describe en prosa la transformación aplicada para el digest, canonicalization_id le da nombre como identificador despachable por máquina y versionado sobre el que un verificador puede actuar sin interpretar lenguaje natural. El campo es aditivo y OPCIONAL: un manifest que lo omita sigue siendo plenamente conforme en cualquier versión del schema y los verificadores lo tratan como que requiere verificación manual. El primer identificador definido es glm-digest-v1 – véase Canonicalization ID más abajo para su definición normativa completa. Una vez publicada, la transformación vinculada a un valor dado de canonicalization_id no puede cambiar; una transformación futura requiere un nuevo identificador (glm-digest-v2 y así sucesivamente), nunca la redefinición de uno existente. El schema 1.4 también documenta machine_readable_status.authority_dependency (con su campo complementario authority_dependency_note) como campo de vocabulario opcional y transversal a las implementaciones: observado de forma independiente en uso por más de una implementación GLM con el mismo valor declarado (external_to_execution_system), y documentado aquí por esa razón. No es obligatorio, y su presencia o ausencia no afecta a la conformidad. Esto constituye la schema_version 1.4.
• Modificaciones del schema: Los cambios disruptivos requieren un incremento de la versión mayor. Las adiciones no disruptivas pueden introducirse como incrementos de la versión menor. La retrocompatibilidad dentro de una versión mayor es un objetivo de diseño.
• Comentarios: Los comentarios arquitectónicos y los informes de implementación son bienvenidos en [email protected]