Validador

Preparación privada: El validador descrito aquí se envía dentro del secani/oscal kit de herramientas, que permanece privado mientras está preparado para el código abierto. Todos los recuentos, cotizaciones y localizadores que aparecen a continuación se toman del registro legible por máquina en el kit de herramientas. validation/ directorio y son re-verificables a través de pnpm verify.

Resumen

El kit de herramientas OSCAL de Secani valida los documentos OSCAL de NIST con lo que realmente afirman las fuentes NIST fijadas, no con lo que hace cualquier implementación de referencia. Alcanza la paridad de capacidad total con la superficie Java OSCAL CLI 3.2.0 y luego la supera de cuatro maneras que la pila de Java no intenta:

1. Una prueba de integridad verificada por máquina: cada una de las 348 apariciones de restricciones detectables en los ocho metaesquemas raíz de OSCAL 1.2.2 se concilia individualmente: se ha demostrado que se aplica, está cubierta por un esquema comprobado o se excluye explícitamente con una justificación escrita. Cero están desaparecidos.
2. Semántica nativa de OSCAL 1.2.2 con soporte para múltiples versiones (1.1.2, 1.1.3, 1.2.1, 1.2.2), donde Java CLI 3.2.0 incorpora enlaces OSCAL 1.2.1 y puede procesar documentos 1.2.2 solo según compatibilidad.
3. Validación del flujo de trabajo entre documentos: resolución y verificación del gráfico de referencia entre SSP, planes de evaluación, resultados de evaluación y POA&M, que está completamente fuera de la superficie de validación de la CLI de Java.
4. Una base de código TypeScript que se ejecuta en todos los lugares donde se encuentran los documentos: los mismos validadores precompilados se ejecutan en el navegador, en rutas API sin servidor, en la CLI y en el backend, sin JVM en ninguna parte.

El proceso también reveló defectos en las propias fuentes del NIST (ver Encontrar errores – en ambas direcciones), que es lo que se esperaría de la verificación a nivel de ocurrencia (y la evidencia más sólida al respecto).

El modelo de autoridad: fuentes sobre implementaciones

La regla de alcance vinculante del proyecto:

La fuente NIST OSCAL es la autoridad. Java es un comparador de compatibilidad y evidencia de implementación, nunca la autoridad.

Concretamente, cada afirmación semántica está anclada a bytes:

• Autoridad: usnistgov/OSCAL, etiqueta v1.2.2, commit 21403b4ad2f162ef1201e5ee70e8b93f254f51ac: los ocho módulos raíz de Metaschema (catálogo, perfil, definición de componentes, SSP, plan de evaluación, resultados de evaluación, POA&M y mapeo), sus importaciones comunes (metadatos, controles, implementación, evaluación y mapeo) y las entidades de restricciones externas. Todos se almacenan en caché byte por byte y se fijan mediante hashes SHA-256.
• Resolución de perfil: el borrador de la especificación del NIST src/specifications/profile-resolution/profile-resolution-specml.xml. porque es borrador/WIP, sus requisitos se implementan detrás de una capacidad explícita y nunca se incorporan silenciosamente a una validación ordinaria.
• Comparador: Java OSCAL CLI 3.2.0 con liboscal-java 7.2.0, que incorpora enlaces OSCAL 1.2.1. La evidencia comparativa se registra con localizadores exactos de ocurrencia; las referencias sin bytes almacenados en caché y localizadores exactos están etiquetadas como inspección de fuente no calificada y no pueden cerrar una puerta de procedencia.

Esta es la inversión que importa: la mayoría de las herramientas tratan la implementación de referencia como una verdad fundamental. Tratamos las fuentes de la norma como verdad fundamental y tratamos la implementación de referencia como un testigo que debe ser interrogado.

Ejemplo: cómo se ve un reclamo fijado por un localizador. El registro no dice "admitimos verificaciones de roles de parte responsable". Dice: restricción oscal-metadata-responsible-party-role-ids, fuente oscal_metadata_metaschema.xml@L400, archivo fuente SHA-256 anclado, aplicado por regla META-002.a, probado mediante una prueba nombrada cuyo hash AST se registra. Si el NIST cambia esa línea, el pin se rompe y el reclamo debe volver a calificarse.

El cierre de integridad: tener en cuenta cada restricción

Las fuentes de Metaschema definen restricciones (allowed-values, is-unique, matches, index, index-has-key, has-cardinality, expect) repartidos en miles de líneas de XML. Un validador puede afirmar que "admite restricciones OSCAL" sin que nadie pueda comprobar lo que eso significa. Lo hicimos comprobable.

El cierre de integridad inventaria léxicamente 348 ocurrencias de restricciones en el gráfico del módulo fijado, incluidas 17 ocurrencias anónimas y 8 ocurrencias retenidas dentro de los comentarios de la fuente, porque decidir que no cuentan es en sí misma una decisión revisable. La identidad de ocurrencia incluye la ruta y la línea de origen, por lo que los ID de restricción repetidos nunca colapsan.

Cada suceso debe aterrizar exactamente en un grupo de evidencia cerrado:

Ejemplo: qué significa en el código "evidencia exacta de ocurrencia". Cada ocurrencia comprobada tiene una declaración como esta en el conjunto de pruebas:

closureEvidenceTest(
  {
    assertionIds: ["META-012.b"],
    name: "allowed-values assessment-common oscal-assessment-objective-types@L65 occurrence",
    releases: [],
    subject: "evaluateBuiltinAllowedValues",
  },
  () => {
    const evaluation = evaluateBuiltinAllowedValues(
      {
        "assessment-results": {
          "local-definitions": {
            "objectives-and-methods": [{ parts: [{ name: "assessment" }] }],
          },
        },
      },
      "assessment-results",
    );
    expect(evaluation).toMatchObject({
      evaluatedInventoryIds: expect.arrayContaining([
        "oscal_assessment-common_metaschema.xml#oscal-assessment-objective-types@L65",
      ]),
    });
  },
);

La prueba conduce al evaluador real sobre un documento mínimo y afirma que se evaluó la ocurrencia fuente exacta (archivo, identificación de restricción, línea). El formato de la evidencia es deliberadamente difícil de falsificar: el AST de TypeScript de la declaración se verifica (el sujeto declarado debe ejecutarse exactamente una vez; su resultado debe fluir exactamente a un nivel superior expect), y se fijan la declaración, su expediente y el SHA-256 de su cierre transitivo de importación. Cambie el evaluador y cada hash de evidencia dependiente quedará obsoleto hasta que se vuelva a derivar mecánicamente. Una prueba renombrada, un cuerpo no operativo o un ayudante mutado invalidan la evidencia automáticamente.

Las 44 exclusiones no son un gesto manual: 5 ocurrencias se encuentran dentro de comentarios XML en las fuentes del NIST (texto inactivo), 2 son defectos ascendentes (ver más abajo), 3 son elementos de límites de modelo documentados y 34 son restricciones activas que se aplican en tiempo de ejecución de forma predeterminada pero quedan fuera del inventario bloqueado de 93 aserciones del registro de investigación; cada exclusión nombra la evaluador generado que lo hace cumplir.

Con unresolved = 0, el artefacto se voltea exhaustiveRequirementClaimAllowed: true – una bandera que el generador calcula a partir de los recuentos de depósitos, no una frase que escribe un humano.

Registro de requisitos: 40 de 42, con retenciones honestas

Por encima del nivel de ocurrencia se encuentra un registro de 42 requisitos de investigación (93 afirmaciones atómicas) que abarcan el enrutamiento de esquemas, la semántica de metadatos y el catálogo./profile reglas, resolución de perfiles, resolución entre documentos y validación de flujos de trabajo. 40 son implemented; cada giro requirió una ruta de tiempo de ejecución con nombre más un valor real positivo/negative pruebas. Los dos elementos abiertos son retenciones deliberadas y documentadas:

• PRES-004 (importar asignaciones de identificadores): el borrador de la especificación dice que la asignación tiene cinco subsecciones opcionales pero solo define una de manera concreta (mapping[].controls[{from,to}]), y el perfil 1.2.2 anclado Metaschema no define mapping en import en absoluto. Implementamos la forma respaldada por ejemplo y cerramos todo lo demás:

  $ oscal-cli resolve-profile --to JSON profile-with-param-mapping.json
  oscal-cli: unsupported import mapping subsection 'params' in pinned draft

Reclamar soporte completo para el mapeo significaría inventar una semántica que la fuente no contiene.

• META-013 (representaciones de recursos alternativos equivalentes): la fuente requiere múltiples rlink/base64 representaciones de un recurso para "contener información equivalente" sin definir operativamente la equivalencia (¿igualdad de bytes? ¿igualdad semántica después de la conversión de formato?). La aplicación de la ley permanece pendiente de una definición, en lugar de inventarla.

Qué hace el validador que Java CLI 3.2.0 no hace

Semántica nativa 1.2.2, enrutamiento de múltiples versiones

Java CLI 3.2.0 incorpora liboscal-java 7.2.0 con enlaces OSCAL 1.2.1; una ejecución sin cambios sobre un documento 1.2.2 es compatibilidad observacional, no validación 1.2.2. Secani ofrece enrutamiento de esquemas con reconocimiento de versiones y validadores precompilados para 1.1.2, 1.1.3, 1.2.1 y 1.2.2, con 1.2.2 como objetivo de implementación semántica, y falla al cerrar las versiones que no ha calificado en lugar de validar silenciosamente contra la generación incorrecta.

La capa de restricción semántica generada.

La capa semántica ordinaria (activada por defecto) evalúa, por documento, el inventario de restricciones fijadas: todas 200 activas allowed-values ocurrencias (incluidos objetivos del eje descendente y objetivos con bandera como action/@type), todos 27 con alcance is-unique ocurrencias, 24 de 25 activos matches ocurrencias (el día 25 se aplica mediante una regla de propiedad de metadatos), el generado expect, has-cardinality, y archivo local index/index-has-key evaluadores y los metadatos/catalog/profile/SSP familias de reglas semánticas. Cada diagnóstico tiene su procedencia NIST. Este es el resultado literal en tiempo de ejecución de un catálogo cuyos metadatos action declara "type": "invented-type":

{
  "ruleId": "oscal-metadata-action-type-values",
  "sourceId": "https://raw.githubusercontent.com/usnistgov/OSCAL/21403b4ad2f162ef1201e5ee70e8b93f254f51ac/src/metaschema/oscal_metadata_metaschema.xml#L877",
  "sourceType": "oscal-constraint",
  "authority": "nist-metaschema",
  "severity": "error",
  "phase": "semantic",
  "path": "/catalog/metadata/actions/0/type",
  "message": "value \"invented-type\" is not one of the allowed values: \"approval\", \"request-changes\"",
  "keyword": "allowed-values"
}

El sourceId no es una etiqueta, es un puntero fijado en el que se puede hacer clic y que apunta a la línea exacta de Metaschema que exige la regla. (Este diagnóstico en particular también es un diferencial en vivo: Java CLI 3.2.0 acepta este documento exacto, en JSON y XML, aunque la restricción se encuentra en L877 de los metadatos 1.2.1 de Metaschema que incorporan sus propios enlaces; consulte el recibo R4 a continuación).

Resolución de perfil completo según el borrador de la especificación

resolve-profile implementa el proceso de resolución de borradores del NIST de principio a fin, y falla cuando el borrador no está definido en lugar de adivinar:

$ oscal-cli resolve-profile --to JSON baseline-profile.json resolved-catalog.json
$ oscal-cli resolve-profile --to JSON legacy-combine.json
oscal-cli: deprecated combine method 'merge' has undefined resolution behavior

$ oscal-cli resolve-profile --to JSON mixed-major.json
oscal-cli: major OSCAL version mismatch between '1.2.2' and '2.0.0' at 'file:///…/legacy.json'

Cubierto: adquisición de importación con ciclo/depth/byte presupuestos, internos #uuid Las importaciones que incluyen documentos integrados en base64 incluyen/exclude selección con with-child-controls expansión, keep/use-first combinar semántica, as-is/custom/flat la estructuración, los parámetros deterministas y la aplicación de alteraciones, y el material de fondo se fusionan con las reglas de ordenamiento exactas del borrador (los duplicados posteriores se reemplazan en la posición posterior; una keep=always bloques de recursos reemplazo sin marcar).

En la finalización del resultado es donde residen varias garantías sutiles: la declaración oscal-version del resultado se fija en la versión más alta admitida del mismo nivel mayor; las claves se emiten en orden OSCAL canónico; y el catálogo resuelto se revalida (esquema y restricciones semánticas) antes de la serialización, por lo que un resultado de resolución no válido es un rechazo, no un resultado. La CLI de Java no realiza esa verificación en su propia salida: su solucionador escribirá un catálogo que su propio validador luego rechazará (recibo R6 a continuación).

Validación del flujo de trabajo entre documentos (no en la superficie de Java)

Este es el diferenciador. Los artefactos de cumplimiento de OSCAL forman un gráfico (un resultado de evaluación importa un plan de evaluación, que importa un SSP, que importa un perfil, que se resuelve en catálogos) y la documentación del modelo establece relaciones que ningún esquema JSON puede verificar. El validador de gráficos de documentos resuelve esos bordes y los verifica.

Ejemplo. Un SSP afirma implementar el control ac-99, pero la línea de base que importa nunca proporciona ese control. Con las reglas interpretativas habilitadas, el validador de gráficos resuelve la línea de base a través del canal completo de resolución de perfil hasta sus catálogos, calcula el conjunto de control seleccionado y emite (forma de problema textual):

{
  "ruleId": "SSP-003.b",
  "sourceId": "secani:oscal-ssp-import-profile-interpretation:v1",
  "sourceType": "validation-dispatch",
  "authority": "secani-policy",
  "severity": "warning",
  "phase": "resolution",
  "path": "/system-security-plan/control-implementation/implemented-requirements/1/control-id",
  "message": "implemented control 'ac-99' is not supplied by the resolved import-profile 'file:///…/baseline.json'",
  "keyword": "implemented-control-supplied"
}

Nótese la disciplina de procedencia incluso aquí: la autoridad es secani-policy bajo una fuente de interpretación versionada – no nist-metaschema – porque esta verificación es nuestra interpretación documentada, no la restricción de la máquina del NIST. Desde la CLI, se puede acceder a las comprobaciones a través de oscal-cli validate --resolve-imports --interpretive SSP-003.b ssp.json (repetible, o --interpretive all; --warnings-as-errors los promueve a una salida fallida).

La familia de reglas completa, cada una de ellas fijada en su ancla en las fuentes:

Ejemplo: implementar la prosa exactamente. El comentario del POA&M Metaschema dice:

"Se debe importar un SSP basado en OSCAL o se debe especificar una identificación de sistema única. Ambos pueden estar presentes." – oscal_poam_metaschema.xml @L58-60

POAM-001.a advierte solo cuando ninguno está presente. Una prueba indica que el suministro de ambos permanece en silencio, porque inventar una exclusiva o la fuente no lo indica es exactamente el tipo de sobrevalidación que este proyecto se niega a hacer.

Dos decisiones de diseño importan tanto como las comprobaciones:

• Honestidad interpretativa. Estas relaciones están documentadas en prosa, no como limitaciones de la máquina; es revelador que el propio plan de evaluación index-has-key para estos UUID existe en la fuente NIST sólo como un "ejemplo falso" comentado. Por lo tanto, las reglas están desactivadas de forma predeterminada, emiten advertencias, nunca convierten un documento en inválido y se ejecutan solo cuando una persona que llama los nombra explícitamente.
• Alcance fijado antes del código. La nota de registro de cada regla registra, por campo de referencia, el alcance y localizador de la resolución documentada, y lo que se excluyó por nombre. subject-uuid, por ejemplo, está documentado que se resuelve en "todos los archivos importados directa o indirectamente" (@L652-654) (transitivamente entre documentos), por lo que está explícitamente fuera de alcance en lugar de implementarse a medias.

Superficie CLI: paridad plus

Las 22 capacidades de Java CLI orientadas a OSCAL están cubiertas con contratos de aceptación observables (comando, opciones, entrada, éxito)./failure salida, códigos de salida): validar/convert a través de JSON/XML/YAML, resolve-profile, list-allowed-values, SARIF determinista (--sarif-include-pass, --sarif-timing), --threads partición de trabajadores con orden de resultados canónicos, metapath/xpath/jsonpointer representación de rutas, alias de comandos de modelo, finalización de shell. Encima: --prune, --interpretive, exportaciones de esquemas fijados por versión y la API de diagnóstico programático.

Por qué TypeScript

1. Un artefacto, cada tiempo de ejecución. Los validadores son módulos Ajv precompilados independientes: JavaScript simple generado, sin compilación de esquemas de tiempo de ejecución, sin reflexión, sin intérprete de Metaschema. La ruta de código idéntica se ejecuta en el navegador, en rutas API sin servidor, en Node (CLI) y dentro del backend. La pila de Java requeriría una JVM en cada una de esas ubicaciones o un puerto con pérdidas.

2. La plataforma es donde viven los documentos. El producto de Secani es una plataforma web; su API de validación, su banco de trabajo de creación y su servidor MCP consumen el kit de herramientas como una biblioteca escrita en proceso:

   import { createDiagnosticsOscalProcessor } from "@secani/oscal/diagnostics";
   
   const processor = createDiagnosticsOscalProcessor({ maxIssues: 50 });
   const result = processor.validate(document);
   // OscalValidationResult:
   // { ok, complete, modelType, oscalVersion, layers,
   //   errors, issues, totalIssueCount, truncated }

Sin subproceso IPC contra un binario de Java, sin contenedor sidecar, sin arranque en frío de JVM. 3. Determinismo como característica. Los validadores precompilados + los evaluadores generados + el ordenamiento de claves canónicas hacen que los resultados sean estables en bytes, que es lo que permite al sistema de evidencia fijar hashes sobre el comportamiento en primer lugar. 4. Distribución. Un paquete escrito con puntos de entrada dedicados (., ./browser, ./versioned, ./diagnostics) llega al ecosistema donde realmente se crean las UI de cumplimiento. 5. Seguridad de tipos frente al modelo. Los mapas de modelo generados hacen que "esta restricción apunta a una bandera, no a un elemento" sea una propiedad verificable estáticamente, con una prueba de protección que no afirma ninguna bandera/element Existe una colisión de nombres en las 1.011 formas de nodos del modelo fijado.

Lo que TypeScript no nos compró es la exención de la prueba: el cierre de integridad existe precisamente para que la elección del idioma esté respaldada por evidencia a nivel de ocurrencia, no por afirmaciones sobre la experiencia del desarrollador.

Encontrar errores – en ambas direcciones

La verificación a nivel de ocurrencia encontró defectos reales en ambos lados, que es el argumento más fuerte de que la metodología funciona.

En nuestro propio evaluador (encontrado junto a la puerta de cierre). Dos restricciones de metadatos apuntan a banderas (atributos) en lugar de elementos secundarios: los valores permitidos de action/@system y action/@type (oscal_metadata_metaschema.xml @L874, @L877). Se compilaron en el inventario admitido pero nunca se activaron: el recorrido del evaluador resolvió los pasos secundarios solo contra los elementos del modelo, por lo que ambas restricciones no evaluaron nada en silencio. La puerta de cierre se negó a aceptar pruebas en su favor, y así fue como surgió el error. Se corrigió con la resolución adecuada de pasos de bandera; una caminata estática sobre el gráfico de definición demostró exactamente que esos dos sucesos se vieron afectados.

En nuestro propio evaluador (encontrado por la ejecución diferencial en vivo, ambos arreglados el mismo día). Primero, el index El evaluador trató un valor de campo clave faltante como un error, lo que rechazó cualquier catálogo que contuviera un prop sin un uuid – incluido el catálogo SP 800-53 rev5 del propio NIST (20 errores informados; Java 3.2.0 lo acepta). La especificación de Metaschema es explícita en cuanto a que un valor de campo clave faltante produce una clave de índice nula, no una infracción; 800-53 ahora valida limpio. En segundo lugar, el vocabulario de tipo de acción de OSCAL permaneció limitado incluso cuando action/@system declaró un URI personalizado, contradiciendo los comentarios del NIST de que @system "proporciona un medio para segmentar el espacio de valores para el type" por organización. Ambas correcciones se enviaron con pruebas de regresión y hash de evidencia redirigida.

En las fuentes del NIST:

• Una restricción huérfana. oscal_mapping-common_metaschema.xml @L657 restringe un indicador definido en @L652, al que nunca hace referencia ningún flag ref. Ningún nodo modelo lo lleva; la restricción es insatisfactoria para cualquier documento que pueda existir.
• Un predicado imposible. oscal_implementation-common_metaschema.xml @L567 restringe los nombres de accesorios bajo un @type predicado en inventory-item - pero inventory-item declara no type bandera (su hermana asset-id flag está comentado en @L456-461). El predicado nunca puede coincidir.
• Restricciones que viven dentro de los comentarios. Cinco ocurrencias, incluida una with-child-controls Vocabulario de valores en el perfil Metaesquema: existe solo dentro de los bloques de comentarios: texto que un lector léxico encuentra pero el esquema compilado nunca aplica.

Cada uno se registra como excluded-with-rationale con su localizador exacto, auditable y reportado en sentido ascendente: usnistgov/OSCAL#2254 (bandera huérfana), #2255 (predicado imposible), #2256 (limitaciones en los comentarios). La brecha en la aplicación de banderas en las herramientas de referencia se informa como metaschema-framework/oscal-cli#279.

La carrera diferencial en vivo: recibos, en ambas direcciones

El 18 de julio de 2026 cerramos la brecha entre las afirmaciones del comparador inspeccionadas en la fuente y la evidencia ejecutada: Java OSCAL CLI 3.2.0 se descargó de Maven Central, se verificó por bytes contra el SHA-256 fijado en el registro./SHA-512, y ejecute una familia de accesorios diseñada cuyos documentos de referencia se validan limpiamente en ambas cadenas de herramientas, de modo que cada diferencial sea atribuible a un único cambio inyectado. Su compromiso OSCAL incorporado (26df0501) es la confirmación del lanzamiento del parche 1.2.1, que confirma la brecha de enlaces en tiempo de ejecución. Las transcripciones completas, los accesorios y los códigos de salida se registran en los recibos diferenciales junto con el registro.

Tres patrones, honestamente separados: R1–R3 son diferenciales puros de vinculaciones obsoletas – 1.2.2 cambió exactamente dos restricciones más allá de los cambios de versión, ambas en el modelo SSP, y Java está en el lado equivocado de los tres comportamientos observables (un falso negativo, dos falsos positivos, uno de ellos con error por la ausencia de un campo opcional). R4 es una brecha de aplicación independiente de la versión sesgada: el texto de la restricción es idéntico en bytes en las fuentes incrustadas de Java, y la clase afectada está completamente mapeada: una enumeración mecánica sobre el inventario fijado muestra exactamente 2 de 200 indicadores de destino de ocurrencias de valores permitidos activos; el único miembro con grado de error es el que se probó en vivo, por lo que no hay miembros no probados. el resto existe. R5 es una brecha de capacidad, no un defecto, y nuestra verificación sigue siendo una advertencia de inclusión voluntaria porque la fuente es prosa, no una restricción de la máquina. R6 y R7 se abrieron paso primero y fueron reparados el mismo día; permanecen en la tabla porque un arnés diferencial que solo encuentra los insectos del otro lado no es un arnés.

Lo que deliberadamente no afirmamos

• La especificación de resolución del perfil es borrador; El comportamiento de la familia PRES está controlado por funciones y las restricciones de nivel NIST WARNING permanecen como advertencias.
• Las reglas del flujo de trabajo son interpretaciones de relaciones documentadas, marcadas como tales y desactivadas de forma predeterminada.
• La evidencia del comparador del registro permanece etiquetada como fuente inspeccionada; la ejecución diferencial en vivo lo complementa con recibos ejecutados y codificados, pero no actualiza silenciosamente el nivel de evidencia del registro: el plegado de las transcripciones en la puerta de calificación formal se rastrea por separado.
• 34 restricciones impuestas en tiempo de ejecución esperan una revisión de alcance antes de obtener afirmaciones de registro de primera clase; su aplicación en tiempo de ejecución no se ve afectada.
• el alojado API de validación actualmente expone el nivel de esquema; la capa de restricción semántica que se describe aquí se incluye en una versión posterior de la API.

Apéndice: referencias fijadas

• Fuentes OSCAL: usnistgov/OSCAL @ 21403b4ad2f162ef1201e5ee70e8b93f254f51ac (v1.2.2) – Metaesquemas, esquemas JSON, borrador de especificación de resolución de perfil
• Versiones de OSCAL compatibles: 1.1.2, 1.1.3, 1.2.1, 1.2.2 (objetivo semántico: 1.2.2)
• Documentación modelo: https://pages.nist.gov/OSCAL/
• Comparador: Java OSCAL CLI 3.2.0 / liboscal-java 7.2.0 (enlaces OSCAL 1.2.1)
• Aceptación legible por máquina: validation/requirements.json (42 requisitos / 93 afirmaciones), validation/capabilities.json (22 contratos de capacidad), validation/completeness-closure.json (348 ocurrencias), validation/scope-lock.json
• Verificación: más de 1000 pruebas; pnpm verify (verificación de tipos → pruebas → 13 puertas de artefactos generados → compilación → comprobaciones de paquetes → humo)