Procedencia: cada parámetro es trazable hasta una fuente publicada

La disciplina central de honestidad de Kshana es que cada parámetro de sensor, cada modelo físico y cada conjunto de datos de validación es trazable hasta una fuente publicada: una hoja de datos, un artículo revisado por pares, un ICD (documento de control de interfaz) de señal en el espacio o una norma. Este documento reúne esas cadenas de procedencia en una única tabla de referencia citable.

La procedencia no es solo documentación: cada tabla de sensor de un escenario (por ejemplo [clock_quantum] y [clock_classical]) lleva una cadena provenance (ModelSpec en src/types.rs; with_provenance en src/inertial/imu_errors.rs para el modelo de errores de la unidad de medida inercial (IMU)) que pasa al JSON del resultado (JavaScript Object Notation) como quantum.spec.provenance y classical.spec.provenance, de modo que cada ejecución lleva sus propias citas de parámetros. El bloque units del resultado también etiqueta cada campo numérico con una clase de procedencia (input, computed, closed-form, internal-consistency, …). Las tablas siguientes son el índice consolidado y legible de esas cadenas, además de la procedencia algorítmica y de validación tomada de los comentarios del código fuente.

La madurez se etiqueta con honestidad en todo el documento: calificado para vuelo (ha volado), laboratorio en tierra / cohete sonda (demostrado, no volado) o objetivo espacial sobre hardware de tierra (una cifra aspiracional para hardware que no ha volado; en particular, toda cifra de reloj de red óptica de estroncio). Véase VALIDATION.md para las etiquetas validated / modelled / not modeled de cada cifra y QUANTUM-MODELS.md para el análisis de madurez entre laboratorio en tierra y vuelo.

---

1. Parámetros de reloj y de referencia de frecuencia#

El coeficiente de ruido blanco de frecuencia de Allan que usa el modelo de holdover es q_wf = σ_y(1 s)²; la modulación de frecuencia de flicker (flicker FM) y el envejecimiento se modelan solo cuando se fija explícitamente un flicker_floor (véase VALIDATION.md); en caso contrario, no se modelan.

2. Parámetros de sensores inerciales#

3. Parámetros de transferencia de tiempo y frecuencia#

4. Modelos de órbita, de sistemas de tiempo y de marcos#

5. Modelos GNSS del dominio de medida y de resiliencia#

6. Conjuntos de datos de validación#

Política de incorporación al repositorio. Incorporamos una copia literal de cada conjunto de datos de validación cuya licencia permita la redistribución y cuyo tamaño quepa con holgura en git, de modo que un clon pueda reproducir la validación sin conexión, sin red y sin enlaces rotos. Un conjunto de datos queda condicionado a su descarga (se descarga con un asistente scripts/fetch_*.sh en el directorio realdata-cache/, ignorado por git, y solo se incorporan los pequeños valores de referencia derivados) únicamente cuando su licencia no permite con claridad la redistribución o cuando es demasiado grande para git. Cada conjunto de datos condicionado registra abajo su motivo concreto; nada se condiciona por comodidad.

El estado de licencia de cada conjunto de datos condicionado a la descarga se investigó frente a la autoridad de origen; los dos conjuntos de datos de reloj «poco claros» siguen condicionados a la espera de una cesión explícita de redistribución (ya incorporamos los valores que sí tenemos licencia para publicar), y el conjunto JammerTest se condiciona por razones de tamaño y de copyleft pese a su licencia abierta.

7. Dominios más recientes: de dónde proceden sus parámetros#

Los tipos de escenario añadidos desde las tablas anteriores mantienen la misma regla. Cada fila nombra la fuente y el estado en la matriz de verificación de la capacidad construida sobre ella (VERIFICATION-MATRIX.md tiene la fila completa).

---

Pie de procedencia del gráfico#

Todo gráfico que Kshana genera (en el entorno de pruebas del navegador, en la exportación *.chart.svg de la CLI (interfaz de línea de comandos) y en el gráfico del informe imprimible *.report.html (HTML, HyperText Markup Language)) lleva estampado, abajo a la derecha:

Kshana v<version> · scenario <hash> · kshana.dev

scenario <hash> son los primeros 12 caracteres hexadecimales del hash del escenario de la ejecución: un SHA-256 (SHA: Secure Hash Algorithm) de la definición canónica del escenario (semilla, umbrales, parámetros del modelo, ventanas GNSS, etc.). Es la misma huella que aparece en el resumen de una línea de la ejecución y en el campo scenario_hash del JSON del resultado. (Los tipos de escenario cuyo documento de resultado no incluye scenario_hash, como los informes de integridad y lunares, recurren a un SHA-256 del TOML (Tom's Obvious, Minimal Language) fuente del escenario, de modo que todo gráfico conserva una huella estable.)

Como el hash es determinista y sensible a la entrada, una imagen de gráfico guardada o pegada se identifica por sí misma: registra la versión del motor, el escenario exacto que la produjo (para su reproducción bit a bit) y la fuente; y cualquier parámetro alterado produce un hash distinto, de modo que un gráfico mal etiquetado se puede detectar.

Cómo citar y reproducir#

Todo resultado es reproducible a partir de scenario + seed + engine version. Cite el motor mediante CITATION.cff / el DOI de concepto de Zenodo 10.5281/zenodo.20528627, y cite las fuentes de los parámetros indicadas arriba para las cifras de las que depende una ejecución determinada; viajan en los campos provenance del JSON del resultado, de modo que un resultado publicado se documenta a sí mismo.

Cuando una cifra es un objetivo espacial sobre hardware de tierra (toda cifra de reloj óptico de estroncio) o una demostración de laboratorio en tierra (acelerómetro de átomos fríos), este documento y la procedencia del resultado lo indican de forma explícita. Kshana no presenta cifras de laboratorio ni cifras objetivo como rendimiento en vuelo.