Correspondencia de compliance

Los compradores y los fabricantes de receptores responden ante marcos públicos de resiliencia. Esta carpeta hace corresponder, fila por fila, lo que Kshana calcula y registra con esos marcos, y kshana compliance-report rellena la correspondencia a partir de las ejecuciones que usted tiene realmente.

Redacción. Las salidas de Kshana aportan evidencias a favor de un requisito. No son una calificación ni una aprobación de ningún producto, y ninguno de estos archivos es una declaración de un organismo de evaluación; Kshana no lo es. El texto de los requisitos se parafrasea, nunca se reproduce.

Los paquetes de normas (0,38) convierten un marco en escenarios puntuados: cada paquete tiene escenarios, umbrales fijados antes de la ejecución y filas a favor de las cuales aporta evidencias. kshana standards-pack list los muestra.

Cada archivo enumera sus documentos fuente con la versión, la URL, la fecha de lectura y lo que se comprobó y lo que no. Las fuentes se leyeron el 2026-10-09 (el perfil del NIST el 2026-10-18; el boletín de la EASA y las páginas del catálogo de EN 16803 se comprobaron de nuevo el 2026-10-10). Cuando una fuente solo pudo leerse a través de un espejo o de una página de catálogo, el archivo lo indica.

El informe#

kshana compliance-report spoof-detect.result.json integrity-raim.result.json session.result.json

escribe compliance-report.compliance.md y compliance-report.compliance.json (--out <base> cambia el nombre). Las entradas son archivos de resultados de ejecuciones anteriores: la ejecución de un escenario escribe <name>.result.json junto a <name>.toml, y kshana receiver-trust escribe el suyo. El tipo de escenario de cada ejecución se lee del archivo de escenario contiguo al resultado, del contenido de un resultado de receiver-trust o de un kind de nivel superior, y debe ser un tipo de escenario que el motor conozca. Un resultado se enumera como no utilizado, con el motivo, y no cuenta para nada cuando no se encuentra su tipo de escenario, no es un tipo de escenario conocido, o el escenario contiguo y el kind del propio resultado discrepan. (El scenario_hash del resultado y un hash del archivo de escenario no se comparan: el motor calcula el primero sobre su escenario analizado y un hash de archivo se calcula sobre el texto, de modo que son magnitudes distintas.)

Una etiqueta de tipo de escenario por sí sola no es evidencia. Una ejecución cuenta para una capacidad solo cuando su resultado lleva también los campos que escribe ese tipo de escenario (por ejemplo, un resultado jamming necesita sus cifras de mérito y sus filas por época; un resultado integrity necesita sus recuentos de muestras). Los campos se enumeran en src/compliance/mapping.rs (KIND_FIELDS) y un resultado al que le falte uno no se cuenta. Un hash que no es hexadecimal no se notifica como hash. Un resultado de receiver-trust cuyos recuentos no son números enteros, o cuyo recuento de detectados o coincidentes supera su recuento de evaluables, se excluye y se enumera como no utilizado.

Para cada fila, el informe da uno de estos valores:

La columna de brecha se imprime para cada fila, incluidas las que cuentan con evidencias: una ejecución que aporta evidencias a favor de una capacidad deja aún la mayor parte de un requisito a otras evidencias. El informe repite la regla de redacción al principio. --mapping imprime las tablas estáticas y --sources la lista de fuentes.

Las ejecuciones de receiver-trust aportan además los recuentos que indican (sucesos detectados de los evaluables, predicciones coincidentes de las evaluables). Estos describen ese registro, puntuado frente a sucesos y tolerancias fijados antes de la ejecución, y se notifican tal como los indica la ejecución.

Capacidades#