Alegações versus realidade: registro de alegações exageradas
Uma auditoria independente de uma versão anterior do Kshana catalogou quatorze alegações exageradas (OC-0…OC-13): lugares em que uma superfície voltada ao público (README, playground, rótulos de FoM (figura de mérito), pacotes de cenário) descrevia uma capacidade de forma mais forte do que o código entregava. Esta página é o registro de encerramento: cada linha apresenta a alegação exagerada original, como foi resolvida e a evidência. Aparecem dois tipos de resolução:
- Alegação retirada: o texto foi corrigido para corresponder ao código (reenquadramento honesto, sem mudança de capacidade). "Zero código = zero alegação."
- Substituída: a capacidade real foi construída e testada depois, de modo que a alegação forte passou a ser exata.
Uma proteção contra regressão (tests/no_overclaims.rs) examina as superfícies públicas em vigor (README.md, docs/CAPABILITY.md, docs/GLOSSARY.md, web/capabilities.json, web/index.html, web/README.md e as páginas iniciais do crates.io, do PyPI (Python Package Index) e do npm, README.crates.md, README.pypi.md, README.npm.md) a cada execução da CI (integração contínua) e falha se qualquer das expressões de alegação exagerada simples retiradas reaparecer sem ressalva, de modo que uma linha não possa regredir silenciosamente de GREEN.
Todas as quatorze linhas estão GREEN.
| OC (alegação exagerada) | Alegação exagerada original | Resolução | Status | Evidências |
|---|---|---|---|---|
| OC-0 | "estimador de fusão de Kalman conjunto" sugeria um único filtro de covariância cruzada; o código executava dois estimadores independentes | Substituída: foi construído um filtro de Kalman real de relógio+posição acoplado por covariância cruzada | 🟢 | src/fusion/coupled.rs (7 testes, incluindo um conjunto de 100 tentativas, acoplado contra desacoplado, que exige que o RMS (raiz do valor quadrático médio) de posição do filtro acoplado seja inferior a 0,6× o do desacoplado e que o filtro acoplado vença em pelo menos 90 das 100 tentativas); CAPABILITY "Fusão de sensores" → completa |
| OC-1 | "RAIM (monitoramento autônomo de integridade pelo receptor) de detecção de spoofing auxiliado por relógio" sugeria um detector RAIM de vários satélites | Alegação retirada → Substituída: reenquadrada como um limite de detectabilidade de spoofing pela estabilidade do relógio; o RAIM/ARAIM real (HPL/VPL (HPL: nível de proteção horizontal; VPL: nível de proteção vertical)) foi incorporado depois | 🟢 | src/raim.rs (30 testes: ARAIM de instantâneo + separação de soluções, HPL/VPL, FDE (detecção e exclusão de falhas), diagramas de Stanford); docs/INTEGRITY.md |
| OC-2 | "demonstrador de jamming" sem nenhum código de jamming por trás | Substituída: foi construído um modelo de jamming por orçamento de enlace J/S → C/N₀ efetivo → perda de travamento | 🟢 | src/jamming.rs (10 testes); linha "Resiliência" do README |
| OC-3 | "Modelo completo de ruído de variância de Allan de IMU (unidade de medição inercial) em uma tríade de IMU": o modelo era de um único eixo | Alegação retirada → Substituída: reenquadrada como um orçamento de erro de 1-DOF (DOF: grau de liberdade); um INS (sistema de navegação inercial) strapdown de três eixos foi então entregue | 🟢 | src/inertial strapdown de três eixos (atitude por quatérnio, mecanização NED (norte-leste-baixo), coning/sculling); ROADMAP "Inercial" |
| OC-4 | "Integração PNT (posicionamento, navegação e temporização) híbrida" sugeria um filtro GNSS/INS (GNSS: sistema global de navegação por satélite) acoplado; era um orçamento de erro de navegação por estima | Alegação retirada → Substituída: reenquadrada como navegação por estima com uma retravação configurável; a fusão GNSS/INS fortemente acoplada real foi então entregue | 🟢 | src/fusion/tightly_coupled17.rs (filtro de Kalman unscented (UKF) de 17 estados com navegação por estima quantum-CAI (CAI: interferômetro de átomos frios)); CAPABILITY "Fusão de sensores" → completa |
| OC-5 | "validado ~2%" sugeria um portão rígido imposto | Alegação retirada: VALIDATION.md declara o portão imposto (20–25% com média entre sementes); "~2%" passou a ser rotulado como observação típica, e não como o portão |
🟢 | docs/VALIDATION.md, cabeçalho "Sobre as tolerâncias" |
| OC-6 | "determinístico entre plataformas" sem evidência registrada | Alegação retirada: cadeia de ferramentas fixada em uma versão exata; hashes de referência (golden) por cenário registrados com um portão de reprodutibilidade. (Idêntico bit a bit entre SO/arquitetura (SO: sistema operacional) continua sendo um item em aberto, declarado honestamente.) | 🟢 | rust-toolchain.toml (canal 1.93.0); tests/golden.rs (valores numéricos até 1e-6); tests/cross_platform_golden.rs (hash da impressão digital de entrada e da forma de cada resultado, executado na matriz de CI de Linux, macOS e Windows); scripts/check-reproducible.sh |
| OC-7 | "simulador PNT híbrido quântico-clássico" sugeria física quântica de primeiros princípios | Alegação retirada → Substituída: reenquadrada como um simulador de resiliência PNT que usa modelos de desempenho de sensores quânticos; a física CAI de Mach–Zehnder de primeiros princípios foi então incorporada | 🟢 | src/inertial/quantum_imu.rs (26 testes: fase de Mach–Zehnder, ruído de projeção 1/√(N·C²·T²), função de transferência de vibração, sistemáticos de Coriolis + AC-Stark (AC: corrente alternada)); docs/QUANTUM.md |
| OC-8 | A FoM "Desempenho de Integridade" sugeria integridade HPL/VPL/RAIM de aviação | Alegação retirada + Substituída (em camadas): a FoM do cenário por execução é rotulada honestamente como autoconsistência do filtro (não como integridade de aviação); o HPL/VPL real do ARAIM é apresentado separadamente, de modo que os dois nunca sejam confundidos | 🟢 | src/fom.rs:80 (integrity: autoconsistência, com ressalva); src/raim.rs + docs/INTEGRITY.md (ARAIM real) |
| OC-9 | FoM de Segurança apresentada como sempre significativa, mesmo sem ataque | Alegação retirada: a FoM de Segurança (1 − P_md) é enquadrada no contexto do detector de spoofing e só é significativa quando um cenário de ataque está configurado |
🟢 | Linha "Resiliência" do README; a FoM de Segurança é definida no ponto de especificação operacionalmente danoso |
| OC-10 | A FoM "Desempenho de Posicionamento" sugeria precisão completa no domínio da posição | Alegação retirada: rotulada como um pos_rms_m de 1-DOF para os pacotes inercial/híbrido, explicitamente não como uma precisão 2-D CEP/2DRMS (CEP: erro circular provável) ou ponderada por DOP (DOP: diluição de precisão) |
🟢 | Tabela de figuras de mérito do README (linha "Desempenho de Posicionamento") |
| OC-11 | números de FoM inercial lidos como estatísticas de conjunto a partir de sementes únicas | Alegação retirada: uma execução única é sinalizada com monte_carlo: false; runs = N informa média/dispersão/IC bootstrap de 95% |
🟢 | Tabela de FoM do README; testes de envelope de cobertura de cenários |
| OC-12 | o cenário "constelação GPS (Sistema de Posicionamento Global) SGP4 (Simplified General Perturbations 4)" usava TLEs (conjuntos de elementos de duas linhas) sintéticos de substituição | Substituída: o cenário agora incorpora um instantâneo genuíno do Celestrak gps-ops com data, com somas de verificação estritas |
🟢 | scenarios/orbit-sgp4-gps.toml (gps-ops real, strict_checksum); tests/scenario_coverage.rs |
| OC-13 | A cadeia de versão do README divergiu de Cargo.toml |
Alegação retirada: um portão de CI verifica que o selo de situação do README corresponde a Cargo.toml |
🟢 | scripts/check-version-sync.sh |
0,35: alegações mantidas estreitas e uma correção#
Os recursos da 0,35 foram escritos com seus limites declarados ao lado da alegação, e as mesmas proteções (tests/no_overclaims.rs e a proteção de redação em tests/compliance_report.rs) examinam as páginas que os descrevem. Esta tabela não faz parte do registro de quatorze linhas acima; ela registra, para as novas superfícies, o que é alegado e o que não é.
| Superfície | O que é alegado | O que não é |
|---|---|---|
Pontuação de confiança da embarcação (receiver_trust, $PKSHT, portão, Signal K, OpenCPN) |
uma pontuação de 0-100 e motivos a partir do próprio NMEA de um receptor, MODELLED | consultivo, não um equipamento de navegação homologado; a pontuação de um registro não é uma afirmação sobre outros receptores; não torna um fixo mais preciso |
| Fluxos NMEA para treinamento de tripulações | NMEA sintético de ponte de comando com eventos roteirizados e um registro do instrutor | apenas texto, sem saída de radiofrequência; nunca para os sistemas de navegação em operação de uma embarcação; consultivo, não um equipamento de navegação homologado |
| Pacotes de evidências | um registro técnico assinado que pode ser verificado offline | não é um parecer jurídico; não diz o que causou um evento, quem foi responsável, nem que o registro mostra o que o receptor realmente recebeu |
| Mapa de interferência | células agregadas de navegação degradada a partir de relatórios de licença aberta | não é uma previsão; a exposição de uma rota é uma parcela de células, não um risco |
| Exportação para test bench | o movimento do veículo e os eventos de um cenário em arquivos que um simulador de laboratório pode ler | nenhum sinal é gravado; não se alega desempenho de nenhum simulador ou receptor |
| Mapeamento de compliance para frameworks públicos | para quais linhas um conjunto de execuções fornece evidências em apoio de, com uma lacuna em cada linha | nunca que uma estrutura de referência foi atingida ou que um produto foi aprovado; um rótulo de tipo de cenário, por si só, não é evidência |
Correção registrada na 0,35. Uma versão anterior de docs/RESILIENCE-CROSSWALK.md e dos comentários do módulo de resiliência descrevia sete "categorias de técnicas" do DHS Resilient PNT Conformance Framework. A versão 2,0 dessa estrutura define funções centrais (Prevent, Respond, Recover), níveis de 0 a 4 e oito requisitos numerados, e nenhuma lista de sete categorias. Os sete nomes de subpontuação que o motor de pontuação emite são do próprio Kshana, e a correspondência agora diz isso.
Como uma linha permanece GREEN#
As alegações fortes (OC-0/2/7/8 e as metades substituídas de OC-1/3/4/12) estão GREEN porque a capacidade foi entregue e testada, e não porque o texto tenha sido suavizado. As linhas com alegação retirada estão GREEN porque o texto em vigor corresponde ao código. O teste de proteção torna a segunda categoria exigível: se uma expressão de alegação exagerada retirada voltar a uma superfície pública, a CI fica vermelha. Veja tests/no_overclaims.rs.