Proveniência — cada parâmetro rastreável até uma fonte publicada

A principal disciplina de honestidade do Kshana é que cada parâmetro de sensor, modelo físico e conjunto de dados de validação é rastreável até uma fonte publicada — uma folha de especificações, um artigo revisto por pares, um ICD (documento de controlo de interface) de sinal no espaço ou uma norma. Este documento reúne essas cadeias de proveniência numa única tabela de referência citável.

A proveniência não é apenas documentação: cada tabela de sensor num cenário (por exemplo [clock_quantum] e [clock_classical]) traz uma cadeia provenance (ModelSpec em src/types.rs; with_provenance em src/inertial/imu_errors.rs para o modelo de erros da unidade de medição inercial (IMU)) que passa para o JSON de resultado (JavaScript Object Notation) como quantum.spec.provenance e classical.spec.provenance, pelo que qualquer execução traz as suas próprias citações de parâmetros. O bloco units do resultado rotula também cada campo numérico com uma classe de proveniência (input, computed, closed-form, internal-consistency, …). As tabelas abaixo são o índice consolidado e legível por humanos dessas cadeias, mais a proveniência algorítmica e de validação extraída dos comentários do código-fonte.

A maturidade é rotulada com honestidade em todo o lado: qualificado para voo (já voou), laboratório de solo / foguetão de sondagem (demonstrado, não voou) ou objetivo espacial em hardware de solo (um valor aspiracional para hardware que não voou — nomeadamente todos os valores de relógios óticos de rede de estrôncio). Consulte VALIDATION.md para os rótulos validated / modelled / not modeled por valor e QUANTUM-MODELS.md para a discussão da maturidade laboratório de solo versus voo.

---

1. Parâmetros de relógios e de referências de frequência#

O coeficiente de ruído branco de frequência de Allan usado pelo modelo de holdover é q_wf = σ_y(1 s)²; a modulação de frequência flicker (flicker FM) e o envelhecimento só são modelados quando um flicker_floor é definido explicitamente (consulte VALIDATION.md); caso contrário, não são modelados.

2. Parâmetros de sensores inerciais#

3. Parâmetros de transferência de tempo e de frequência#

4. Modelos de órbita, de sistemas de tempo e de referenciais#

5. Modelos de domínio das medições GNSS e de resiliência#

6. Conjuntos de dados de validação#

Política de inclusão no repositório. Registamos uma cópia literal de cada conjunto de dados de validação cuja licença permita a redistribuição e cuja dimensão caiba com folga no git, para que um clone possa reproduzir a validação offline, sem rede e sem ligações quebradas. Um conjunto de dados tem obtenção condicionada (descarregado por um auxiliar scripts/fetch_*.sh para realdata-cache/, ignorado pelo git, com apenas os pequenos valores de referência derivados registados) apenas quando a sua licença não permite claramente a redistribuição, ou quando é demasiado grande para o git. Cada conjunto condicionado regista abaixo o seu motivo específico; nada é condicionado por conveniência.

O estatuto de licença de cada conjunto de dados de obtenção condicionada foi investigado junto da autoridade de origem; os dois conjuntos de dados de relógios "pouco claros" permanecem condicionados até haver uma concessão explícita de redistribuição (já registamos os valores que estamos licenciados para publicar), e o conjunto JammerTest é condicionado por razões de dimensão/copyleft apesar da sua licença aberta.

7. Domínios mais recentes — de onde vêm os seus parâmetros#

Os tipos acrescentados desde as tabelas acima mantêm a mesma regra. Cada linha nomeia a fonte e o estado na matriz de verificação da capacidade construída sobre ela (VERIFICATION-MATRIX.md tem a linha completa).

---

Rodapé de proveniência do gráfico#

Cada gráfico que o Kshana renderiza — no playground no navegador, na exportação *.chart.svg da CLI (command-line interface) e no gráfico dentro do relatório imprimível *.report.html (HTML, HyperText Markup Language) — é carimbado, em baixo à direita, com:

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

O scenario <hash> são os primeiros 12 carateres hexadecimais do hash do cenário da execução: um SHA-256 (SHA: Secure Hash Algorithm) sobre a definição canónica do cenário (semente, limiares, parâmetros dos modelos, janelas GNSS, etc.). É a mesma impressão digital que aparece no resumo de uma linha da execução e no campo scenario_hash do JSON de resultado. (Os tipos cujo documento de resultado não traz scenario_hash, como os relatórios de integridade e lunares, recorrem a um SHA-256 do TOML (Tom's Obvious, Minimal Language) de origem do cenário, para que todos os gráficos tenham sempre uma impressão digital estável.)

Como o hash é determinista e sensível à entrada, uma imagem de gráfico guardada ou colada identifica-se a si própria: regista a versão do motor, o cenário exato que a produziu (para reprodução bit a bit) e a origem — e qualquer parâmetro alterado produz um hash diferente, pelo que um gráfico mal rotulado é detetável.

Como citar e reproduzir#

Cada resultado é reproduzível a partir de scenario + seed + engine version. Cite o motor através de CITATION.cff / do DOI de conceito do Zenodo 10.5281/zenodo.20528627, e cite as fontes dos parâmetros acima para os valores de que uma dada execução depende — viajam nos campos provenance do JSON de resultado, pelo que um resultado publicado é autodocumentado.

Quando um valor é um objetivo espacial em hardware de solo (todos os números de relógios óticos de estrôncio) ou uma demonstração de laboratório de solo (acelerómetro de átomos frios), este documento e a proveniência do resultado dizem-no explicitamente. O Kshana não apresenta valores de laboratório ou de objetivos como desempenho em voo.