Mapa de capacidades: o que o Kshana faz, faz parcialmente e não faz

O Kshana é um motor de evidências de desempenho e resiliência de PNT (posicionamento, navegação e temporização), não um conjunto completo de ferramentas de sistemas espaciais. Ele prioriza a temporização e o holdover, seu domínio mais bem validado (veja POSITIONING.md). Esta página é o mapa honesto do escopo: para cada área de capacidade que um revisor de aquisição ou de pesquisa possa conferir, ela indica o status, o que realmente existe no código, o que está faltando e onde isso se situa no roteiro. O status é um destes:

completo: implementado de ponta a ponta e validado até um nível indicado na linha;
parcial: um modelo real, porém limitado (escopo explicitamente delimitado abaixo);
nenhum: não modelado (fora do escopo atualmente).

Estes três são os únicos valores que a coluna de status assume. Eles classificam a maturidade da capacidade, que é um eixo diferente da classificação VALIDATED / MODELLED / PARTNER em VERIFICATION-MATRIX.md: aquela classifica a proveniência da evidência, linha por linha, e é verificada por máquina a partir de src/verification.rs.

Nada aqui é aspiracional: "parcial" nunca significa "quase pronto", significa "isto tanto e nada além". Veja também VALIDATION.md, INTEGRITY.md, QUANTUM-MODELS.md e o registro de encerramento de afirmações exageradas CLAIMS-VS-REALITY.md (cada afirmação exagerada histórica, como foi resolvida e uma verificação de CI (integração contínua) que a mantém resolvida).

PNT central (onde o Kshana realmente atua)#

Capacidade	Status	O que existe	O que está faltando	Roteiro
Determinação de órbita e propagação	parcial	SGP4/SDP4 sem dependências (SGP4: Simplified General Perturbations 4; SDP4: Simplified Deep-space Perturbations 4), validado a 4,12 mm contra todos os 666 vetores AIAA (American Institute of Aeronautics and Astronautics) 2006-6753 (posição e velocidade, esta última a 1 mm/s); kepleriano analítico + J2 secular; velocidade inercial exposta e levada de ponta a ponta por meio do cenário `ephemeris` executável (`src/ephemeris.rs`, acessível por CLI/Python/WASM/MCP (CLI: interface de linha de comando; WASM: WebAssembly; MCP: Model Context Protocol)): a cada passo ele emite o estado TEME (true equator, mean equinox) e GCRS (Geocentric Celestial Reference System) (posição + velocidade), a posição ITRF/ECEF (ITRF: International Terrestrial Reference Frame; ECEF: Earth-centred, Earth-fixed), a projeção da trajetória no solo (ground track) do subsatélite WGS-84 (WGS: World Geodetic System) (lat/lon/alt), e azimute/elevação/distância de estação + taxa de variação da distância/Doppler (a taxa radial de variação da distância coincide com a derivada verdadeira da posição, livre de ruído de JD (JD: data juliana), a 6e-9 m/s), e por meio da exportação de efemérides com velocidade em OEM (Orbit Ephemeris Message) do CCSDS (Consultative Committee for Space Data Systems) (`--export-oem`). Um propagador numérico (Cowell) (`src/propagator.rs`) integra um modelo de forças de gravidade zonal configurável: o campo zonal completo da Terra até o grau 6 (`forces::zonal_accel`, o `J2..J6` publicado do EGM-96 (EGM: Earth Gravitational Model)), com a escolha de um integrador adaptativo, seja o RK4 (Runge–Kutta de quarta ordem) com duplicação de passo, seja o par embutido Dormand–Prince RK5(4) (`integrate_dopri` / `propagate_dopri`, uma estimativa de erro embutida mais barata, com 7 avaliações, que satisfaz o mesmo critério de Kepler e concorda com o caminho RK4 a <1 m em uma órbita J2..J6), confrontado com uma verdade analítica mais forte do que uma verificação cruzada numérica entre ferramentas: a órbita sem perturbações reproduz a solução de Kepler exata em variáveis universais com precisão submétrica em 24 h (um critério mais apertado do que o "contra a referência < 10 m" do marco), a energia e o momento angular se conservam a ~1e-9 em termos relativos, a regressão nodal de J2 concorda com a taxa secular em forma fechada pela teoria de primeira ordem, verifica-se que a aceleração zonal é o gradiente exato do seu próprio potencial (e que se reduz à forma fechada de J2 validada com 666 vetores), e `solve_kepler_checked` devolve `Err` em vez de uma resposta errada quando o Newton não converge (por exemplo, perto do perigeu com e = 0,999). A gravidade de terceiros corpos (Sol e Lua) conduzida pela época é ligada ao integrador variável no tempo (`ForceModel::third_body` / `accel_at`, com as efemérides de baixa precisão do Sol e da Lua de Montenbruck & Gill em `src/ephem.rs`; nenhum kernel DE/SPK (DE: Development Ephemeris; SPK: kernel de efemérides planetárias) é necessário): cada avaliação do RHS (lado direito da equação) amostra as posições dos perturbadores na época avançada `epoch_jd_tt + t/86400`, de modo que o Sol e a Lua se movem ao longo de suas órbitas durante a integração. Verifica-se que a perturbação é o gradiente exato do seu potencial perturbador, que se anula no geocentro e que tem as magnitudes típicas de LEO (órbita terrestre baixa) (~5e-7 m/s² do Sol, ~1.1e-6 m/s² da Lua); as efemérides do Sol atingem âncoras de J2000 derivadas à mão (distância do periélio, declinação de solstício de ~−23°, movimento de ~1°/dia) e as da Lua, seu envelope de perigeu/apogeu, distância média de ~384.400 km, limite de inclinação ≤ 5,3° e retorno da direção após o mês sideral; e a ligação com a integração é comprovada exata bit a bit (o termo do RHS é igual a `third_body_accel` na posição amostrada em t = 0 e t = 1 dia), com um deslocamento de época de um quarto de ano produzindo uma trajetória diferente. A pressão de radiação solar (SRP) usa o mesmo RHS conduzido pela época (`forces::srp_accel` / `ForceModel::solar_radiation`): o modelo de bola de canhão `ν·P☉·cᵣ·(A/m)·(AU/d)²·d̂` com um fator de eclipse de umbra + penumbra `forces::conical_shadow` (ν suave ∈ [0.1], verificado como decaindo por uma penumbra monotônica que se estende além do cilindro da umbra), verificada contra a pressão de livro-texto a 1 AU (AU: unidade astronômica) (≈ 4.54e-6 N/m²), a magnitude de ~1.36e-7 m/s² em LEO empurrando para longe do Sol, a queda com o inverso do quadrado (dobrar a distância ao Sol a reduz a um quarto), uma aceleração exatamente nula no cilindro da umbra, e um deslocamento propagado que escala ~linearmente com A/m. O arrasto atmosférico é o primeiro termo dependente da velocidade (`forces::drag_accel` / `ForceModel::drag` + o novo RHS `accel_rv` / com passagem de velocidade): arrasto quadrático `−½·ρ(h)·(C_D·A/m)·\|v_rel\|·v_rel` contra a atmosfera em co-rotação `v_rel = v − ωₑ ẑ × r`, com `ρ` a `forces::atmospheric_density` exponencial por partes de Vallado, verificado pela âncora de 1,225 kg/m³ ao nível do mar, um decaimento em LEO estritamente monotônico com uma altura de escala física de ~58 km, a magnitude de arrasto de ~2e-6 m/s² opondo-se à velocidade relativa, e a assinatura de dissipação (uma órbita de 300 km perde energia específica de forma monotônica e seu semieixo maior decai a ~km/dia limitados, enquanto a órbita no vácuo conserva a energia). A correção relativística pós-newtoniana (Schwarzschild) é o segundo termo dependente da velocidade (`forces::relativistic_accel` / `ForceModel::relativity`): a forma `β = γ = 1` do IERS (International Earth Rotation and Reference Systems Service) `a = (μ/c²r³)·{[4μ/r − v²]·r + 4(r·v)·v}`, o principal responsável pelo avanço relativístico do perigeu, verificada contra seu valor circular em forma fechada `3μ²/(c²r³)·r̂` (radial, para fora), sua razão de livro-texto `≈1.9e-9` em relação ao problema de dois corpos em LEO, a forma simplificada à mão de velocidade radial e a assinatura conservativa (ela perturba a órbita, mas mantém o semieixo maior abaixo de um metro/dia, o oposto estrutural do arrasto). O termo de arrasto de referencial de Lense–Thirring (`forces::lense_thirring_accel` / `ForceModel::lense_thirring`, IERS 2010 §10) é a correção gravitomagnética além de Schwarzschild: opcional, ~1–2 ordens de grandeza abaixo dele em LEO, verificado como se anulando sem a rotação da Terra e como ficando abaixo da magnitude de Schwarzschild. A determinação de órbita (OD, `src/orbit_determination.rs`) fecha o ciclo das observações de volta a um estado: um corretor de lote de Gauss–Newton (`src/batch_ls.rs`) leva um `[r, v]` candidato ao melhor ajuste das distâncias de estações terrestres propagadas ao longo do arco (submétrico / mm·s⁻¹ a partir de distâncias sem ruído; ~2 m com um resíduo pós-ajuste no piso de ruído de 5 m, a assinatura de um ajuste de mínimos quadrados consistente), com uma variante recursiva sequencial sobre o filtro unscented	O modelo de forças padrão de Cowell traz apenas o campo zonal: o campo tesseral de alto grau do EGM2008 (Earth Gravitational Model 2008) (`src/gravity_sh.rs`, grau/ordem 70, com um carregador `from_gfc` para arquivos ICGEM (International Centre for Global Earth Models)) é composto apenas no mecanismo preciso de ajuste de efemérides (`src/precise_od.rs`; veja `AGENCY-ORBIT-VALIDATION.md`); a densidade de arrasto é a exponencial por partes de Vallado, estática (independente da atividade solar), e não o NRLMSISE-00 (o modelo de atmosfera Naval Research Laboratory Mass Spectrometer and Incoherent Scatter Radar Extended; a cláusula de densidade termosférica < 5 %); a SRP é o modelo de bola de canhão com uma sombra geométrica cônica de umbra + penumbra (sem escurecimento de limbo solar, sem sombra de Terra oblata, sem forma/atitude do satélite); a relatividade cobre os termos de Schwarzschild e de Lense–Thirring (arrasto de referencial), ambos opcionais, mas sem ajuste de parâmetros PPN (PPN: pós-newtoniano parametrizado); terceiros corpos/SRP usam as efemérides de baixa precisão (~0,005° para o Sol, ~0,3° para a Lua), e não a exatidão de um kernel DE/SPK. Os níveis conservativos do modelo de forças (dois corpos → J2–J6 → Sol/Lua → SRP) são VALIDATED contra o Orekit 12,2 (pior caso 0,08 m em 24 h, `tests/numerical_cowell_propagator_reference.rs`), e a determinação de órbita em lote/sequencial é VALIDATED contra os estimadores do Orekit 12,2 (`tests/batch_sequential_orbit_determination_reference.rs`); o nível de arrasto e a fidelidade absoluta das entradas de efemérides/densidade permanecem MODELLED; não há verificação cruzada com o GMAT (General Mission Analysis Tool)	gravidade tesseral no modelo padrão de Cowell + arrasto NRLMSISE-00 + escurecimento de limbo solar + efemérides de nível DE + validação cruzada com o GMAT + medições de taxa de variação da distância/ângulo na OD e STM analítica (matriz de transição de estado): P2+
Sistemas de tempo	parcial	`src/timescales.rs`: API de data juliana (civil↔JD, MJD (data juliana modificada)), UTC↔TAI (UTC: Tempo Universal Coordenado; TAI: Tempo Atômico Internacional) por meio da tabela completa de segundos intercalares do IERS (10→37 s, 1972→2017), TAI→TT (TT: Tempo Terrestre), UT1 (Tempo Universal 1, tempo de rotação da Terra) por meio de DUT1 (o tempo de rotação da Terra menos o Tempo Universal Coordenado) e o Ângulo de Rotação da Terra IAU-2000 (IAU: União Astronômica Internacional) (ERA validado bit a bit contra o vetor `eraEra00` do SOFA (Standards of Fundamental Astronomy)). A aproximação DUT1≈0 do caminho SGP4 está explicitamente documentada no ponto de chamada de `gstime` (um erro de GMST (tempo sideral médio de Greenwich) de ≤ ~13″, bem dentro do erro do próprio modelo SGP4), e o cenário `ephemeris` aceita parâmetros explícitos `dut1_s`/`xp_arcsec`/`yp_arcsec` ou uma série IERS `finals2000A` real incorporada (`eop_finals2000a` / `kshana --eop <file>`, interpolada pelo mesmo `EopSeries` que `precise_od` usa), de modo que a projeção no solo (ground track) seja reduzida por meio do UT1 e do movimento polar reais do IERS, e não apenas dos escalares nominais	Os caminhos de órbita terrestre ainda usam uma JD de `f64` único (resolução de ~50 µs perto de 2020; este, e não o algoritmo, é o piso de uma verificação cruzada por diferenças finitas); existe uma JD de duas partes (`timescales::TwoPartJd`, usada pelos caminhos radiométrico, CCSDS-TDM, do simulador de segmento terrestre e do sistema solar, e por `src/jd2.rs` `Jd2`) que é aplicada ao longo do SGP4 (`Sgp4::propagate_at(Jd2)`), à predição de passagens, à geometria e aos projetos Walker (validada contra o SOFA, `tests/jd2_sofa_time_oracle.rs`), e à rotação da Terra no caminho de órbita (`jd2::gmst82`, `cio::gcrs_to_itrs_matrix_jd2`, `orbit::Propagator::position_in_frame_jd2`, o `two_part_jd` opcional do cenário de efemérides; VALIDATED contra o ERFA, `tests/jd2_earth_rotation_erfa_oracle.rs`), com conversões sem perdas entre `Jd2` e `TwoPartJd`; os caminhos padrão de órbita terrestre mantêm a data de `f64` único, a menos que `two_part_jd` esteja definido, e a época do modelo de forças de Cowell permanece de `f64` único de propósito (seu erro analítico de Sol/Lua é muito maior que um arredondamento de 40 µs); o UTC de segundo elástico anterior a 1972 (1960–1971) é modelado no caminho de duas partes (`jd2`, `timescales::tai_minus_utc_on_date`, VALIDATED contra o ERFA, `tests/jd2_pre1972_sofa_oracle.rs`), mas o `timescales::tai_minus_utc` de `f64` único ainda limita a 10 s antes de 1972; um preditor de orientação da Terra por mínimos quadrados + autorregressivo (`src/eop_ls_ar.rs`, comparado com o Boletim A do IERS como um achado) agora pode estender uma série de EOP além de sua última linha (`EopSeries::with_ls_ar_prediction`, opcional; `tests/eop_prediction_beyond_table.rs`), de modo que os argumentos de referencial além da tabela seguem a previsão em vez de serem limitados; a série padrão ainda limita, e nenhuma chave de cenário ativa ainda a predição	concluído (fundação); JD de duas partes até a rotação da Terra no caminho de órbita: concluído (opcional no cenário de efemérides) ; predição de EOP além da tabela: concluído (biblioteca, opcional); UTC anterior a 1972 no caminho de duas partes: concluído
Referenciais	completo	`src/frames.rs`: TEME↔ECEF baseado em GMST, geodésica WGS-84↔ECEF (exata + inversa iterativa, com precisão de máquina em todas as altitudes) e um observador geodésico de estação terrestre (azimute/elevação/distância); precessão IAU 2006 (`src/precession.rs`: os ângulos de Fukushima–Williams `(γ̄, φ̄, ψ̄, ε̄_A)` + a matriz de viés-precessão GCRS↔média da data); nutação IAU 2000A/2000B + cadeia completa TEME→GCRS (`src/nutation.rs`: a série IAU 2000A completa, com 678 termos lunissolares + 687 planetários, `nutation_iau2000a` / `nutation_matrix_2000a`, tabela gerada por máquina a partir da referência `nut00a` do ERFA (Essential Routines for Fundamental Astronomy) por `tools/gen_nut00a.py`, ao lado da série 2000B de 77 termos, argumentos de Delaunay, a matriz de nutação `iauNumat` do SOFA, a equação dos equinócios e `teme_to_gcrs(r, v, jd_tt)` por meio de TEME→TOD→MOD→GCRS (verdadeiro da data, médio da data); ambas as séries validadas bit a bit contra os vetores de referência `nut00a`/`nut00b` do SOFA/ERFA, Δψ/Δε a 1e-13 rad); movimento polar do IERS PEF→ITRF (pseudo-fixo à Terra para terrestre) (`teme_to_itrf` / `polar_motion_matrix`, `iauPom00` do SOFA, `x_p`/`y_p` fornecidos pelo chamador, um efeito de dezenas de metros no raio orbital); redução IAU 2006/2000A baseada no CIO (CIO: Origem Intermediária Celeste) (`src/cio.rs`: a cadeia GCRS↔CIRS↔ITRS livre de equinócio (CIRS: Sistema de Referência Intermediário Celeste; ITRS: Sistema de Referência Terrestre Internacional), com o CIP (Polo Intermediário Celeste) `X,Y` a partir da matriz NPB (nutação-precessão-viés) 2006/2000A, a série de 66 termos do localizador de CIO `s`, `gcrs_to_cirs_matrix`, o ângulo de rotação da Terra e o `gcrs_to_itrs_matrix` completo, validada bit a bit contra os vetores `eraXys06a`/`eraC2ixys`/`eraEra00` do SOFA). As transformações de ponta a ponta agora estão fixadas a um exemplo trabalhado publicado de referência, e não apenas à autoconsistência: contra o estado Vallado AIAA 2006-6753 (2004-04-06, com seus EOP (parâmetros de orientação da Terra) do IERS; `tests/frame_reference_vectors.rs`), TEME→PEF coincide a 0,1 mm, TEME→ITRF a 0,6 mm, o GCRS→ITRS completo por CIO a 4 mm, e ECEF→geodésica reproduz lat/lon/alt do Exemplo 3-3 de Vallado até o último dígito publicado. A cadeia inteira é acessível ao usuário por meio do cenário `ephemeris` (posição ITRF/ECEF + projeção da trajetória no solo do subsatélite WGS-84 a cada passo)	A cadeia padrão TEME→GCRS usa 2000B (~1 mas, abaixo de sua própria simplificação da rotação do referencial de velocidade); o caminho completo de < 0,1 mas (2000A) está disponível por `nutation_matrix_2000a`, e a redução rigorosa CIO (X, Y, s) está disponível por `src/cio.rs`. O caminho TEME legado usa o GMST IAU-1982 (convenção do SGP4). A verificação cruzada numérica independente com ANISE/SPICE (ANISE: Attitude, Navigation, Instrument, Spacecraft, Ephemeris — um kit de ferramentas de geometria planetária em Rust puro; SPICE: Spacecraft, Planet, Instrument, C-matrix, Events) está entregue (`xval/anise-frames/`: `gcrs_to_itrs_matrix` contra o GCRF→ITRF93 do ANISE (GCRF: Referencial Celeste Geocêntrico; ITRF93: Referencial Terrestre Internacional 1993) em oito épocas de 2020–2023, ≤ 0,86 m no solo, ≤ 3,6 m em órbita de GNSS (sistema global de navegação por satélite)); é um crate independente, fora das verificações padrão de CI. `precession_matrix` e `teme_to_gcrs_matrix` também são verificadas diretamente contra o ERFA em 40 épocas de 1950–2100, e a cadeia CIO aceita os deslocamentos do polo celeste do IERS dX, dY (`cio::gcrs_to_cirs_matrix_with_offsets`; `tests/frames_erfa_vector_oracle.rs`); os caminhos padrão ainda desprezam dX, dY. A matriz de verificação classifica esta linha como VALIDATED (vetores SOFA/ERFA + Vallado)	TEME↔ECEF + geodésica: concluído (verificado com Vallado); TEME→GCRS inercial: concluído (2000B + 2000A completa); ITRF com movimento polar: concluído (verificado com Vallado); GCRS→ITRS por CIO: concluído (verificado com Vallado)
Temporização e frequência	parcial	Relógio de Kalman de dois estados com Q exata de van Loan (NIST (National Institute of Standards and Technology) SP (Special Publication) 1065) com uma atualização de covariância estabilizada de Joseph (semidefinida positiva sob razões Q/R extremas, verificada por Cholesky na CI) e um monitor de saúde da consistência do filtro (`src/filter_health.rs`): uma avaliação NIS/NEES (NIS: inovação normalizada ao quadrado; NEES: erro de estimação normalizado ao quadrado) de Monte Carlo contra bandas de confiança χ², exposta como `filter_health` no JSON (JavaScript Object Notation) do resultado e como um cartão verde/âmbar no playground, com um teste de varredura de descasamento Q/R que prova que o monitor passa a inconsistent quando a sintonia está errada (Bar-Shalom §5,4); estimadores sobrepostos de ADEV (desvio de Allan), MDEV (desvio de Allan modificado), TDEV (desvio de tempo), HDEV (desvio de Hadamard) + intervalos de confiança baseados em χ² com graus de liberdade efetivos específicos do tipo de ruído (formas fechadas da Tabela 5 do NIST SP 1065 para WPM/FPM/WFM/FFM/RWFM (WPM: modulação de fase branca; FPM: modulação de fase flicker; WFM: modulação de frequência branca; FFM: modulação de frequência flicker; RWFM: modulação de frequência por passeio aleatório), o conjunto que o Stable32 usa; a curva ADEV exportada identifica o tipo de lei de potência do registro a partir de sua inclinação MDEV e anexa uma banda de 95% por τ — `src/allan.rs`), validados numericamente contra os desvios de referência do Stable32 para o conjunto de dados canônico NBS14 a 1e-4 (`tests/allan_reference.rs`) e o edf verificado de forma cruzada por um conjunto de Monte Carlo de FM (modulação de frequência) branca; uma FoM (figura de mérito) de holdover honesta, limitada pela grade; conjuntos de relógios; um modelo de transferência de tempo bidirecional com cancelamento de atraso recíproco + um piso de atraso diferencial não recíproco de FM por passeio aleatório (`src/timetransfer.rs`, assinatura de Allan relatada); uma calculadora de holdover de relógio sem GNSS (`src/holdover.rs`) que expõe o crescimento do erro em deriva de van Loan em forma fechada `σ_x²(t) = q_wf·t + q_rw·t³/3 + q_drift·t⁵/20` como uma inversão voltada ao usuário de holdover até o limiar (por quanto tempo um relógio funciona livremente antes que seu erro de temporização exceda o orçamento), com classes representativas de relógios quânticos (rede óptica/íon aprisionado/íon de mercúrio): modelada, não validada externamente, verificada de forma cruzada contra a recursão de covariância de múltiplos passos de `clock_state`, e declarando honestamente que, para um relógio muito estável, o holdover até um limiar apertado é *governado pelo piso de ruído vermelho de tau longo assumido, e não pelo ADEV citado* (use pisos medidos para obter um número defensável). Um Nível de Proteção de Temporização condicional (`src/tpl.rs`) se apoia na mesma maquinaria de holdover para o caso de spoofing: um limite sobre o erro de tempo não detectado dada uma verificação cruzada independente (um piso de monitor de k-σ mais a variância de deriva de van Loan sobre a latência de detecção mais um tempo até o alarme de CUSUM (soma cumulativa)), calibrado em um spoof real gravado (JammerTest 2024, Zenodo 15911589) e reproduzível por meio de `cargo run --example tpl_jammertest`. Composição modelada, condicionada à detecção: não existe um limite incondicional finito (uma rampa suficientemente lenta escapa de um único monitor auxiliado por relógio). O erro máximo de intervalo de tempo (MTIE) e o TDEV são VALIDATED contra `allantools` (`tests/mtie_reference.rs`, `tests/mdev_tdev_reference.rs`), e a inversão da variância de deriva do holdover é VALIDATED contra o SciPy (`tests/gnss_denied_clock_holdover_reference.rs`); o tipo de cenário `telecom-timing` os aplica às máscaras G.8272 / G.8272.1 / G.8273.2 / G.8271.1 do ITU-T (União Internacional de Telecomunicações, Setor de Normalização das Telecomunicações); veja `TELECOM-TIMING.md`	edf completo pelo algoritmo de Greenhall (as formas fechadas simples têm viés limitado, mas são mais grosseiras que o BasicSum exato) e identificação de misturas de múltiplos ruídos	edf exato + identificação de ruído misto: P2
Processamento GNSS / PNT	parcial	Uma simulação de pseudodistância no domínio da medição (tipo de cenário `gnss-sim`, `src/gnss_sim.rs`): por satélite visível, ela sintetiza `ρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipath` e o Doppler em L1, com a ionosfera monofrequência de Klobuchar (IS-GPS-200 (IS: Especificação de Interface; GPS: Sistema de Posicionamento Global) §20.3.3.5.2.5) e a troposfera zenital de Saastamoinen (Davis 1985) projetadas pela função de mapeamento de Niell (1996), cada modelo testado em unidade contra cálculo manual, e então alimenta os resíduos ao RAIM instantâneo (monitoramento autônomo de integridade pelo receptor) para obter HPL/VPL (HPL: nível de proteção horizontal; VPL: nível de proteção vertical) por época, e emite um array `gnss_measurements[]` (pseudodistância, Doppler, C/N₀, correções de iono/tropo por SV (veículo espacial, ou seja, um satélite)). Além disso, DOP/disponibilidade (DOP: diluição de precisão) e RAIM de separação de soluções a partir de órbitas; ingestão de NAV multi-GNSS RINEX (Receiver Independent Exchange Format) 3 (GPS/Galileo/QZSS/BeiDou (QZSS: Sistema de Satélites Quase-Zenitais do Japão) via IS-GPS-200, GLONASS (Sistema Global de Navegação por Satélite da Rússia) por vetor de estado) interpretada → posição ECEF do SV e viés do relógio, utilizável como fonte `Propagator` de primeira classe E como bloco `rinex` de constelação embutido (`scenarios/orbit-rinex.toml`); ingestão de OBSERVAÇÃO RINEX 3 (espera-se que o layout de observação 4,00 seja interpretado, mas nenhum arquivo 4,00 foi exercitado; os arquivos de NAVEGAÇÃO RINEX 4 são recusados pelo nome em vez de decodificados incorretamente); um solucionador de posicionamento por ponto único (tipo de cenário `pvt`, `src/pvt.rs`) que transforma pseudodistâncias de código RINEX reais + efemérides transmitidas em uma posição do receptor por mínimos quadrados ponderados iterados: correção de Sagnac/rotação da Terra, relógio do satélite transmitido com `−TGD`, a combinação livre de ionosfera de dupla frequência L1/L2 (ou Klobuchar de frequência única), troposfera de Saastamoinen/Niell, ponderação por elevação, DOP e RAIM instantâneo, validado em dados reais do IGS (International GNSS Service) (estação ABMF, Guadalupe, 2018-05-13) a 5,7 m de RMS (raiz do valor quadrático médio) 3-D / 1,1 m horizontal contra a coordenada levantada da estação (`tests/pvt_abmf.rs`, `scenarios/pvt-abmf.toml`); e leitura/escrita de órbitas precisas SP3 (Standard Product 3, o formato de órbitas precisas)	Um motor de posicionamento por código e, a partir da 0,36, processamento de fase da portadora em observações reais: o solucionador `pvt` calcula uma posição real a partir de medições reais de código (posicionamento por ponto único, nível de metro, com a combinação livre de ionosfera de dupla frequência); `rtk_real::run_rtk` faz RTK de linha de base curta em código e fase GPS reais de dupla frequência (diferenças duplas, um filtro de Kalman float, fixação de ambiguidade inteira LAMBDA com teste de razão, `src/lambda.rs`), e um filtro PPP float estático é executado em código e fase reais com órbitas e relógios finais do IGS. Ambos são VALIDATED contra coordenadas ITRF2020 publicadas de estações do IGS (WTZR/WTZZ, `tests/rtk_real_wettzell_oracle.rs`, `tests/ppp_real_wettzell_oracle.rs`, limiares fixados antecipadamente); o que continua ausente é a resolução de ambiguidade inteira em PPP, o RTK cinemático ou em rede e a operação em tempo real. O alisamento de portadora de Hatch é um achado MODELLED fixado (seus limiares fixados antecipadamente não foram atingidos). O tipo de cenário `leo-ppp` executa um filtro PPP float sobre medições que ele mesmo simula, para estudos de convergência; o pacote direto `gnss-sim` continua sendo um simulador a partir da verdade de referência; BeiDou-GEO (GEO: órbita geoestacionária) excluído	Fixação de ambiguidade em PPP, RTK cinemático ou em rede, operação em tempo real: use RTKLIB/gLAB (RTKLIB: uma biblioteca de código aberto de posicionamento cinemático em tempo real)
Fusão de sensores / navegação estimada (dead-reckoning) com INS (sistema de navegação inercial)	completo	Biblioteca strapdown de 3 eixos (`src/inertial/{attitude,mechanization,imu_errors}.rs`): atitude por quatérnios com compensação de coning/sculling, mecanização NED (norte-leste-baixo) completa (taxa da Terra + taxa de transporte, gravidade de Somigliana WGS-84) e um modelo determinístico de erros de IMU (unidade de medição inercial) (fator de escala, desalinhamento, sensibilidade a g, quantização, rampa de taxa modelados). O navegador strapdown agora está ligado a um pacote GNSS/INS fracamente acoplado executável com uma figura de mérito (`src/fusion/pack.rs`, `kind = "gnss-ins"`): a mecanização de três eixos é disciplinada pelo EKF de estado de erro de 15 estados (filtro de Kalman estendido) (`src/fusion/{gnss_ins_ekf,closed_loop}.rs`, realimentação de posição/velocidade/atitude/viés) enquanto o GNSS está disponível, e depois segue em deriva durante a interrupção, substituindo o reajuste à verdade de referência por fusão genuína e relatando o erro horizontal fundido contra a deriva do INS livre em malha aberta. O pacote `inertial` legado separado ainda executa o orçamento escalar de 1 DOF (DOF: grau de liberdade) com reajuste à verdade de referência. Uma atualização de pseudodistância fortemente acoplada (`update_tightly_coupled` / `fuse_tightly_coupled`) também está implementada: ela forma a inovação no domínio da distância (jacobiana de linha de visada em δp) e continua corrigindo com menos de quatro satélites, onde uma solução PVT (posição, velocidade e tempo) fracamente acoplada não existe. Um filtro de Kalman unscented (UKF) GNSS/INS fortemente acoplado de 17 estados completo (`src/fusion/tightly_coupled17.rs`) carrega posição, velocidade, erro de atitude, vieses de acelerômetro e de giroscópio e o relógio do receptor (viés + deriva), com navegação estimada (dead-reckoning) quântica CAI (CAI: interferômetro de átomos frios): o ruído de processo de passeio aleatório de velocidade é o `q_va` derivado do acelerômetro de átomos frios, mantendo uma interrupção de 120 segundos limitada a algumas centenas de metros (contra os quilômetros de um INS livre de classe de navegação). Este UKF de 17 estados agora está exposto como um cenário executável (`src/fusion/hybrid_ukf.rs`, `kind = "hybrid-ukf"`, acessível por CLI/Python/WASM/MCP): os 15 estados de erro do INS são aumentados com a correção de viés do acelerômetro derivada do CAI (o interferômetro de átomos frios define o piso de passeio aleatório de velocidade `q_va`) e um relógio de 2 estados de fase + frequência cujo ruído de processo vem do motor de relógio por parâmetros q (`clock_state::q_from_allan`, perfil de Allan → `q_wf`/`q_rw`), conduzido pelo modelo de erro do CAI delimitado por limites, de modo que a execução demonstre a hibridização de curto prazo da IMU clássica + longo prazo quântica. Sua figura de mérito é a autoconsistência do filtro: NEES + brancura da inovação (NIS) agregados sobre um conjunto de Monte Carlo contra suas bandas χ² de 95% (o filtro casado fica dentro das bandas; um filtro mal sintonizado é sinalizado, um critério verificável de forma objetiva). Esta é uma afirmação de AUTOCONSISTÊNCIA sob o ruído modelado, NÃO uma garantia de exatidão no mundo real: as entradas de CAI/relógio são delimitadas/modeladas, o hardware CAI pertence ao parceiro, e nada aqui implica TRL (nível de maturidade tecnológica)>3, herança de voo ou validação externa. O modelo determinístico de erros de IMU é configurável por sensor a partir do arquivo de cenário `gnss-ins` TOML (Tom's Obvious Minimal Language) (`[imu_*.error_model]`: fator de escala, desalinhamento, sensibilidade a g, quantização, rampa de taxa), assumindo por padrão uma fonte de viés constante pura quando omitido	O acoplamento forte é apenas por pseudodistância (fase da portadora está no roteiro); o cenário `hybrid-ukf` usa uma única trajetória nivelada de velocidade constante, na qual os estados de erro de atitude e de viés da IMU são apenas fracamente observáveis, de modo que a consistência NEES é avaliada sobre o subconjunto estimável (posição, velocidade, relógio = 8 estados); a observabilidade completa de 17 estados exige uma trajetória com manobras (roteiro); o par viés do acelerômetro/inclinação em acoplamento fraco é pouco separável, portanto a calibração por viés não é afirmada; o modelo de erros de IMU omite a retificação de vibração e a deriva por gradiente de temperatura; o UKF de 17 estados e os caminhos fortemente acoplados são autovalidados (integração analítica de velocidade constante, convergência do auxílio GNSS, recuperação de viés, o limite de interrupção de 120 s limitado pelo CAI e a referência independente de consistência χ² de NEES/NIS); a mecanização strapdown em si é VALIDATED contra o NaveGo v1.4 (`tests/classical_strapdown_ins_reference.rs`: atitude idêntica bit a bit, velocidade/posição dentro de limites analíticos nomeados), mas nenhuma validação cruzada em nível de filtro (NaveGo ou o conjunto de dados de veículo KF-GINS) foi executada	acoplamento forte com fase da portadora, observabilidade completa de 17 estados com trajetória de manobras, biblioteca de trajetórias, validação cruzada em nível de filtro com NaveGo/KF-GINS: P2
Integridade / RAIM / ARAIM (monitoramento autônomo avançado de integridade pelo receptor)	parcial	RAIM instantâneo real em `src/raim.rs`: solução de mínimos quadrados + detecção de falhas por χ² dos resíduos (limiar exato a partir de um χ² de gama incompleta sem dependências) e HPL/VPL baseados em inclinação (pbias a partir de um χ² não central para os P_fa/P_md configurados); RAIM de separação de soluções (MHSS) com detecção/identificação de falhas; orçamento de risco de integridade (P_HMI) do ARAIM (`araim_raim`) que resolve o menor HPL/VPL cujo `P_HMI = Σ_k p_fault,k·Q((PL−T_k)/σ_k)` somado satisfaz uma alocação explícita de risco de integridade, o modo de falha em toda a constelação para duas ou mais constelações (`araim_dual_raim`, ARAIM TN (nota técnica) da UE (União Europeia) / DO-316; `P_const = 0` ⇒ `araim_raim` bit a bit), uma mensagem de suporte à integridade explícita (`IntegritySupportMessage`: σ_URA/σ_URE/b_nom/P_sat/P_const, com os valores de referência GPS+Galileo do WG-C (WG: Grupo de Trabalho)), além de um diagrama de integridade de Stanford(-ESA, a Agência Espacial Europeia) (o tipo de cenário `integrity` e um renderizador independente `stanford_svg` das quatro zonas + fronteira `PL=error`). Documentado de ponta a ponta em `ARAIM_REFERENCE.md`. Além disso, a autoconsistência de filtro da FoM do cenário (limite de k-σ)	O RAIM é acessível pelo tipo de cenário `integrity` e (0,36, opcional) ao lado da FoM de relógio/holdover como um bloco `integrity_fom` separado (`[integrity]`: RAIM instantâneo em um céu predefinido a partir de um local declarado, indisponível enquanto o GNSS está negado; MODELLED), nunca incorporado à FoM de holdover, que continua relatando autoconsistência; o RAIM instantâneo traz FDE (detecção e exclusão de falhas) de um único satélite (`raim::snapshot_raim_fde`, VALIDATED contra o RTKLIB `raim_fde` em `tests/integrity_snapshot_raim_rtklib_oracle.rs`); a separação de soluções de múltiplas hipóteses do ARAIM ADD v4.2 com determinação de subconjuntos de vários satélites está em `src/araim_reference.rs` (VALIDATED contra o Stanford MAAST, `tests/integrity_araim_stanford_oracle.rs`), mas o orçamento `raim::araim_raim` de sigma uniforme ainda cobre apenas falhas de um único SV e de toda a constelação e não é aderente à norma ADD (0,36, opcional: falhas simultâneas em subconjuntos de vários SVs pela regra de subconjuntos do ADD v4.2 generalizada além de pares, `araim_subset_raim`, `add_v42_protection_levels_to_order`; MODELLED, sem execução do MAAST além de pares), e a exclusão de vários SVs não é modelada; e `araim_dual_raim` está ligado ao executor de cenários TOML por meio do sinalizador `araim_dual` (`scenarios/araim-gps-galileo.toml`), com um caminho de disponibilidade por época `araim_dual_constellation_availability`; os núcleos instantâneo/MHSS/ARAIM são exercitados em geometria real de órbita precisa (SP3) do IGS (`tests/igs_real_data.rs`) e em TLEs reais de GPS+Galileo do Celestrak (`tests/araim_dual_real_data.rs`, com todos os satélites propagados até uma época UTC comum, a época de TLE (conjunto de elementos de duas linhas) mais recente do conjunto, 2026-06-07T07:21:04, para um usuário de 400 km com inclinação de 45° em 24 h: a disponibilidade sob um VAL (limite de alerta vertical) de 12 m / HAL (limite de alerta horizontal) de 10 m é 0,993 só com GPS, 1,000 com GPS+Galileo combinados e 0,990 no modo duplo robusto a falhas de constelação; o valor publicado antes aqui, 0,21→0,67 com o modo robusto "limitado", veio da propagação de cada satélite a partir da sua própria época de TLE, um céu que nunca existiu, e está retirado); a comparação anterior da "Tabela A-3 do EU-ARAIM-TN" está retirada (sem fonte pública), e uma reprodução das entradas de URA máxima do Marco 3 do ARAIM do WG-C UE-EUA, públicas (Tabelas 5 a 7, linhas Depleted e Baseline), é tentada em `xval/araim-m3/` sob desvios declarados (MODELLED, veja INTEGRITY.md); não certificado DO-229/ARAIM	ARAIM com múltiplas falhas (ADD v4.2): concluído; subconjuntos de vários SVs em `raim` + paridade com o gLAB no domínio do receptor + ligação à FoM: P2 (veja `INTEGRITY.md`)
Modelagem de ameaças de spoofing / jamming	parcial	Um detector estocástico de spoofing de tempo (tipo de cenário `spoof`, `src/spoof.rs` + `src/detection.rs`): quatro formas de injeção (rampa linear, salto em degrau, meaconing, repetição/replay) contra um monitor auxiliado por relógio com um teste de energia χ²₁ bilateral / de Neyman–Pearson, com o limiar de detecção definido a partir de um orçamento-alvo de alarmes falsos `P_fa`, e a probabilidade de não detecção `P_md` relatada tanto em forma fechada quanto por Monte Carlo (as duas concordam a alguns ×1/√N); a figura de mérito de segurança é `1 − P_md`. Além disso, um modelo de jamming por orçamento de enlace (tipo de cenário `jamming`, `src/jamming.rs`): razão entre jammer e sinal a partir da geometria (perda de propagação no espaço livre + ganho da antena de recepção por direção), a equação padrão de C/N₀ efetivo anti-jam (ganho de processamento de desespalhamento + fator de separação espectral `Q`; Kaplan & Hegarty §9,4), perda de travamento por satélite em um limiar de rastreamento configurável e uma figura de mérito `availability_under_jamming` sobre uma constelação Walker. Além disso, uma suíte multicamada de monitores de spoofing de RF/medição (RF: radiofrequência) (`src/spoof_monitors.rs`): um teste de paridade de consistência RAIM de vários satélites (`parity_raim_test`, SOS (soma dos quadrados) ponderada dos resíduos contra um limiar χ²(m−4); e ele sinaliza corretamente que um viés de modo comum é invisível ao RAIM), um monitor de AGC (controle automático de ganho) (`AgcMonitor`, excesso de potência recebida acima do piso esperado), um monitor de qualidade do sinal / SQM (monitoramento da qualidade do sinal) (`SqmMonitor`, desequilíbrio dos correladores Early/Late) e um combinador de fusão de camadas (`fuse_spoof_layers`). Eles se compõem em um `CombinedSpoofDetector` integrado cujo `evaluate` ingere uma época de observáveis (geometria + resíduos, potência do AGC, taps Early/Late) e executa as três camadas pela fusão ponderada em uma única chamada, devolvendo os diagnósticos por camada; ele é exposto como o cenário `spoof-detect` executável (`src/spoof_detect.rs`, acessível por CLI / Python / playground, JSON + SVG (Scalable Vector Graphics)) e caracterizado contra os parâmetros publicados dos cenários do TEXBAT (Texas Spoofing Test Battery) (Humphreys et al., ION (Institute of Navigation) GNSS 2012; `tests/spoof_texbat_validation.rs`), reproduzindo o padrão documentado de detectabilidade, inclusive os resultados negativos: o ds2 superpotente capturado por AGC + SQM, o ds3 de potência igualada só pelo SQM, o ds4 de empurrão de posição pelo RAIM, e o ds7 de potência igualada com fase da portadora alinhada deixado (corretamente) ao detector auxiliado por relógio	O tipo de cenário `jamming` é um orçamento de enlace: ele não tem multipercurso nem dinâmica de AGC no tempo. Desde a 0,36 ele aceita quatro seções opcionais: `[crpa]`, um feixe de arranjo adaptativo por canal (anulação de direção ou MVDR a partir de `src/crpa.rs`, verificado contra um recálculo independente em numpy; MODELLED), e `[terrain]`, a perda por difração em gume de faca único do caminho do jammer sobre um bloco SRTM (`src/jamming_terrain.rs`, ITU-R P.526-15 §4,1, verificada contra um recálculo independente em numpy em um bloco real; MODELLED, apenas um gume de faca), `[acquisition]`, a histerese entre aquisição e rastreamento, e `[front_end]`, a leitura estabilizada do AGC e a perda do quantizador do ADC para entrada gaussiana (`src/jamming_rx.rs`; sinalizada como não válida para jammers não gaussianos; MODELLED). O multipercurso especular, o desvanecimento em móvel terrestre e o AGC existem na camada IQ (`src/iq/channel/multipath.rs`, `src/iq/channel/land_mobile.rs`, `src/iq/frontend/agc.rs`) e não estão ligados ao tipo de cenário `jamming`; a tabela `Q` de separação espectral guarda os valores de livro-texto por tipo (CW e banda estreita 1, banda larga e varrido 2 desde a 0,36), fixados aos coeficientes derivados das densidades espectrais de potência (PSD) em `navsignal` (veja a linha de sinal de navegação). O detector de spoofing auxiliado por relógio é de relógio único; os monitores de RF/medição agora estão integrados (`CombinedSpoofDetector`) e *caracterizados contra os parâmetros* publicados dos cenários do TEXBAT (Humphreys et al.); o que resta é a validação contra os vetores brutos**: amostras IQ (fase/quadratura) do TEXBAT (que exigem um front-end de aquisição/rastreamento SDR (rádio definido por software) que o kshana não tem, por ser um simulador, não um receptor) ou um cenário Spirent licenciado, um desdobramento documentado	auxiliado por relógio + detector combinado integrado de consistência RAIM multi-SV + AGC + SQM + caracterização com parâmetros do TEXBAT: concluído; validação com vetores brutos (IQ do TEXBAT / Spirent licenciado): desdobramento futuro
Modulação do sinal de navegação e desempenho de rastreamento de código	parcial	`src/navsignal.rs`: o nível do sinal entre o orçamento de enlace e o domínio da medição. Densidades espectrais de potência de área unitária para BPSK-R(n) (modulação por deslocamento de fase binária, chips retangulares) e BOC-seno(m,n) (portadora com deslocamento binário) (validadas na CI para área unitária, para a forma fechada do coeficiente de separação espectral (SSC) próprio do BPSK `κ = 2/(3R_c)` e para a divisão espectral do BOC: nulo na portadora, picos em ±f_s); o coeficiente de separação espectral `κ = ∫ G_s(f)G_i(f) df`, que agora deriva o `Q` anti-jam usado por `jamming` a partir dos espectros reais do sinal e do jammer (`Q = 1/(R_c·κ)`) em vez de uma constante representativa (a referência de banda larga é verificada de forma cruzada na CI); a largura de banda RMS (de Gabor) (BOC > BPSK: a medida de informação de distância / de Cramér–Rao); o jitter de ruído térmico do rastreamento de código por DLL (malha de travamento de atraso) coerente early–late (Kaplan & Hegarty §8; ~submétrico para o C/A a 45 dB-Hz, monotônico em C/N₀); e o envelope de erro de multipercurso (EML (early-minus-late) coerente, obtido localizando o zero do discriminador composto; supressão do correlador estreito verificada). Uma camada de compromisso de projeto de códigos de distância (`CodeFamily`) acrescenta o lóbulo lateral da autocorrelação periódica de sequências m/Gold (`1/L` para uma sequência m) e o limite de correlação cruzada de Gold de três valores `t(n)/L`, reproduzindo a correlação cruzada de Gold publicada do GPS C/A de −23,9 dB (uma âncora externa) e a contagem de sequências m `φ(2ⁿ−1)/n`, além da inversão entre comprimento do código e distância não ambígua; as garantias de Gold devolvem honestamente None onde não existe par preferencial (`n mod 4 = 0`), em vez de relatar um limite que não vale.	Desde a 0.31.0, a camada IQ separada (`src/iq/`, os comandos `kshana iq`; projeto em `design/GNSS-IQ-PLAN.md`) acrescenta uma cadeia de receptor por software: aquisição por FFT (transformada rápida de Fourier), um banco de rastreamento multicanal com DLL/PLL/FLL (malhas de travamento de atraso, de fase e de frequência), filtragem de front-end e quantização de 1 a 14 bits, e transmissão contínua (streaming) de conjuntos de dados gravados. Um receptor por software independente recupera a verdade de referência injetada em suas cenas, e os códigos GPS L1 C/A e os bits LNAV (mensagem de navegação legada) são idênticos bit a bit aos do gps-sdr-sim. Ainda falta: os discriminadores das malhas supõem o triângulo de correlação BPSK ideal, de modo que não há resolução da ambiguidade de rastreamento do BOC; os modelos de canal e de malha são MODELLED, verificados contra formas fechadas e a verdade de referência injetada, e não contra IQ de campo medido; apenas malhas escalares (sem rastreamento vetorial). O projeto de hardware de antena/carga útil de RF (diagramas de radiação, front-end) está deliberadamente fora do escopo: é o papel de um parceiro de carga útil.	ambiguidade do BOC + validação da camada IQ com IQ de campo: P2+
Física de sensores quânticos de PNT	parcial	A maioria dos sensores usa coeficientes publicados de Allan/orçamento de ruído (CSAC, óptico), mais um acelerômetro de interferômetro de átomos frios (CAI) a partir de primeiros princípios em `src/inertial/quantum_imu.rs`: a fase de Mach–Zehnder de três pulsos `Φ = k_eff·a·T²`, o ruído de projeção quântica (shot) `σ_Φ = 1/(C√N)`, a PSD de passeio aleatório de velocidade derivada `q_va` que a pilha inercial consome, o decaimento de contraste, a função de transferência de vibração `\|H(ω)\|` + variância de PSD branca e, agora, os sistemáticos de Coriolis/rotação (`coriolis_phase`, viés equivalente `2Ω×v`) e de deslocamento luminoso AC-Stark (AC: corrente alternada) (`ac_stark_phase`, cancelamento simétrico) + uma varredura de deriva do tempo de ciclo (`cai_drift_sweep`), e um orçamento de erro de navegação estimada (dead-reckoning) inercial quântico composto (`QuantumNavBudget`) que reúne o passeio aleatório de velocidade de ruído branco do CAI com o viés residual (`½·b·t²`, verificado de forma cruzada contra o integrador de Euler independente `AccelModel`), o erro de fator de escala e uma degradação opcional de estabilidade de longo prazo (distinta da decoerência por disparo) em uma única figura de deriva de posição ao longo do holdover mais um holdover inercial até o limiar, o gêmeo de navegação estimada do holdover do relógio. O piso quântico modelado é delimitado por limites (não igualado) contra os 96 nm/s²/√Hz do gravímetro móvel de Freier et al. 2016 (arXiv:1512,05660): ele fica abaixo e a cerca de ~2 ordens de grandeza dele. Documentado em `QUANTUM.md`	Os sistemáticos de frente de onda/apontamento do feixe não são modelados; o limite de ambiguidade de franjas de Mach–Zehnder é modelado (`max_unambiguous_accel`, `dynamic_range_cells` em `src/inertial/quantum_imu.rs`), mas resolver a ambiguidade não é; os orçamentos exatos de teste em voo do CARIOQA-PMP (CARIOQA: Cold Atom Rubidium Interferometer in Orbit for Quantum Accelerometry) / Boeing-AOSense (que exigem PSDs de plataforma publicadas + SNR (relação sinal-ruído) por disparo) e uma predefinição de playground em JS (JavaScript) são resíduos	sistemáticos de frente de onda + reprodução de teste em voo: P2+ (`QUANTUM-MODELS.md`)
Projeto de constelações	parcial	Walker sintético (tanto kepleriano analítico quanto de elementos médios do SGP4, este propagado pelo núcleo validado a 4,12 mm: `src/walker.rs`) + visibilidade e DOP de multiconstelação com TLEs reais (GPS+Galileo até 100%), validado contra um instantâneo real do gps-ops do Celestrak (`tests/igs_real_data.rs`); uma varredura de projeto de PDOP (diluição de precisão de posição) sobre a grade `{planes × sats × inclination}` e figuras de mérito de fração de cobertura / tempo de revisita; o tipo de cenário `constellation-design` executável (padrões Walker delta e estrela na convenção i: T/P/F, listas explícitas de elementos, projetos de várias camadas e predefinições publicadas, em torno da Terra, da Lua, de Marte ou de qualquer outro corpo catalogado), cuja geometria Walker e cujos slots publicados de GPS, Galileo e GLONASS são VALIDATED contra as tabelas publicadas e cuja diluição de precisão global de linha de base do GPS é VALIDATED contra o padrão de desempenho do Serviço de Posicionamento Padrão do GPS, enquanto os mapas de cobertura para projetos arbitrários permanecem MODELLED; um otimizador de projeto sem gradiente (`optimize_walker_design`) que pesquisa a grade pelo melhor projeto sob um objetivo escolhido (`MinSatellitesForCoverage` / `MaxCoverage` / `MinWorstPdop`), validado para devolver o vencedor por força bruta; e geometria analítica de ruas de cobertura (`coverage_half_angle_rad`, `street_half_width_rad`; formas fechadas de Rider/Beste, verificadas à mão: GPS com máscara de 5°: λ ≈ 71,2°, meia-largura da rua de 4 satélites ≈ 62,8°)	Existe um dimensionamento idealizado de número mínimo de satélites por ruas de cobertura (`walker::StreetsCoverageDesign`); a correção exata de junção de Rider na fronteira de planos em contrarrotação não está implementada; o playground desenha uma vista 3-D de órbitas sem dependências (`web/studio/lib/orbit3d.mjs`), e uma exportação CZML (Cesium Language), `--export czml`, carrega a geometria no globo do CesiumJS; o núcleo de DOP é VALIDATED contra o gnss_lib_py (`tests/dop_reference.rs`), e todo o pipeline de visibilidade de multiconstelação é verificado de forma cruzada de ponta a ponta contra o Orekit 12,2 + gnss_lib_py (`tests/coverage_dop_full_oracle.rs`): os projetos para a Terra concordam em todos os limiares, mas os projetos para a Lua e Marte não atingem o limiar de DOP em geometria numericamente singular, de modo que a linha permanece MODELLED; "acima" geodésico versus geocêntrico no referencial do DOP	dimensionamento por ruas de cobertura + vista 3-D de órbitas + verificação cruzada de ponta a ponta para a Terra: concluído; correção exata de junção de Rider + DOP fora da Terra mal condicionado: P2
Verificação e validação	parcial	Verificações com referência independente externa em todo o motor (SGP4 contra 666 vetores AIAA, a família de Allan contra o Stable32 e o allantools, referenciais contra SOFA/ERFA, modelo de forças e determinação de órbita contra o Orekit, ARAIM contra o exemplo trabalhado do WG-C, e mais; a contagem atual é o cabeçalho gerado de `VERIFICATION-MATRIX.md`); verificações determinísticas de Allan; uma matriz de verificação verificada por máquina (`src/verification.rs`), uma referência cruzada requisito→módulo→teste→referência independente→status cujas invariantes de honestidade são testadas em unidade: uma linha só pode ser rotulada validada se trouxer uma referência independente externa (NIST/AIAA/SOFA/IGS/valor publicado), de modo que uma verificação interna de autoconsistência não possa se passar por validação; é renderizada para Markdown/CSV (CSV: valores separados por vírgula) para uma referência cruzada de verificação ECSS-E-ST-10-02 (ECSS: European Cooperation for Space Standardization) e registra como tais as quatro lacunas de hardware/PA (PA: garantia do produto) pertencentes a parceiros	Até agora, os conjuntos de calibração cobrem três verificações de semente única (`CALIBRATION-ENSEMBLES.md`, fixadas antecipadamente: o intervalo de bootstrap de Monte Carlo cobre em 96 % de 200 sementes; uma tolerância de percentil é frágil em relação à semente, NOT MET a 91,5 %); as demais linhas ainda são calibradas em sementes únicas. A matriz impõe a classificação das linhas, e a CI agora também verifica que todo teste, arquivo e item interno do crate citado por uma linha existe (`tests/verification_rows_name_a_test_that_exists.rs`, `tests/verification_rows_cite_evidence_that_exists.rs`) e que as figuras publicadas ainda são reproduzidas (`tests/published_figures_still_reproduce.rs`); ela não avalia a própria referência independente, que um revisor ainda lê	conjuntos de calibração: P1
LEO-PNT (posicionamento, navegação e temporização a partir da órbita terrestre baixa)	parcial	Sete tipos de cenário, agnósticos de sistema, com predefinições públicas nomeadas: `leo-signal` (projetos de sinal de qualquer banda e estrutura: BPSK, BOC, MBOC (BOC multiplexado) ou componentes planos do tipo OFDM (multiplexação por divisão de frequências ortogonais), rastreamento de código, aquisição, compatibilidade com GNSS, compromisso de banda), `leo-pass` (uma passagem projetada, de elementos, de TLE ou Walker com orçamento de enlace por banda: chuva, cintilação e perda de entrada em edificações do ITU-R (Setor de Radiocomunicações da União Internacional de Telecomunicações), ionosfera, antena, Doppler, contra os satélites GNSS MEO (órbita terrestre média) em visada), `leo-navmsg` (efemérides e relógio transmitidos sobre a base kepleriana do ICD (documento de controle de interface) do Galileo ou modelos LEO selecionáveis, ajustados e codificados com verificação de quadro CRC-24Q (verificação de redundância cíclica de 24 bits)), `leo-pvt` (posicionamento fundido MEO + LEO por pseudodistância e Doppler sobre quaisquer constelações), `leo-ppp` (convergência de PPP com e sem aumento por LEO, em medições simuladas), `ntn-positioning` (limites de posicionamento 5G NTN, rede não terrestre, a partir da largura de banda do sinal) e `leo-pnt-chain` (um sistema de ponta a ponta, com a saída de cada etapa repassada à seguinte). Peças VALIDATED: os termos de enlace do ITU-R contra as tabelas e os exemplos de validação das Recomendações, o Doppler máximo contra uma tabela publicada, o algoritmo de usuário do Galileo contra o RTKLIB a 1 mm, o CRC-24Q, os pesos de SISRE (erro de alcance do sinal no espaço)	Sem dados de campo nem sinais gravados; as figuras de posicionamento, PPP, NTN e temporização são MODELLED (formas fechadas, consistência de filtro, comparações com tendências publicadas); as predefinições vêm de fontes públicas ou são derivadas, não são dados de operadores	validação com sinais gravados reais: P3
Espectro / ambiente de RF	parcial	Tipo de cenário `spectrum` (`src/spectrum.rs`): a banda L do GNSS (e projetos multibanda de frequência ultra-alta (UHF), banda S e banda C) como uma única densidade espectral de potência, com a frequência na horizontal e o tempo na vertical, sob uma linha do tempo roteirizada de jammers (jammers de onda contínua, de banda estreita, chirp e de banda larga casada), com J/S (razão entre jammer e sinal) por banda e C/N₀ (densidade de portadora sobre ruído) efetivo; gravações SigMF de entrada e saída e estimativas espectrais de Welch de amostras complexas. Os espectros de sinal em forma fechada e os coeficientes de separação espectral são VALIDATED; o waterfall é MODELLED	Sinais GLONASS, BeiDou e Galileo E6 não são modelados; sem validação de front-end de receptor nem de IQ (fase/quadratura) gravado	comparação com sinais gravados: P3
Confiança em registros de receptor (embarcação e geral)	parcial	`src/receiver_trust/`: monitores sobre o próprio registro de um receptor (densidade de portadora sobre ruído, consistência de posição, velocidade e rumo, tempo) com eventos e previsões declarados antes da execução; em uma plataforma de embarcação, uma pontuação de 0-100 com os motivos; modo ao vivo sobre um fluxo com a sentença `$PKSHT` e um portão (gate) opcional. MODELLED; consultivo, não é um equipamento de navegação homologado	Os limiares são padrões declarados, não medidos em receptores em campo; um registro pontua somente aquele registro; sem entrada nem saída de radiofrequência; não é um equipamento de navegação homologado	`docs/RECEIVER-TRUST.md`, `docs/MARITIME-TRUST.md`
Pacotes de evidências e telemetria de confiança	parcial	`src/evidence/`: um pacote assinado e encadeado por hash de uma janela do registro, sua configuração e o resultado do motor, verificável offline, com um token de carimbo de tempo RFC 3161 opcional. `src/telemetry/`: o fluxo de confiança como métricas Prometheus, eventos syslog (CEF ou LEEF) e OpenTelemetry opcional, com um painel Grafana de exemplo	Um pacote é um registro técnico, não um parecer jurídico, e não diz o que causou um evento; a assinatura da autoridade de carimbo de tempo não é verificada; a telemetria transmite somente telemetria	`docs/EVIDENCE-PACKS.md`, `docs/TRUST-TELEMETRY.md`
Fluxos para treinamento de tripulações e mapas de interferência	parcial	`src/nmea_synth/`: NMEA de ponte sintético com eventos roteirizados de jamming, arrasto (drag-off), falsificação de tempo e repetição (replay) e um registro do instrutor (somente texto). `src/interference_map/`: mapas agregados de navegação degradada a partir de relatórios de aeronaves e navios com licença aberta e a exposição de uma rota, a partir de arquivos locais	Os fluxos são dados de treinamento, nunca para os sistemas de navegação em operação de uma embarcação; os mapas são agregados, não uma previsão, e dependem dos relatórios fornecidos	`docs/NMEA-TRAINING.md`, `docs/INTERFERENCE-MAP.md`
Exportação para test bench	parcial	`src/interop/testbench.rs`: o movimento do veículo e os eventos de um cenário `gnss-ins`, `jamming` ou `gnss-sim` como um CSV de movimento, NMEA, texto de waypoints e arquivos de eventos para um simulador GNSS de laboratório	Nenhum sinal é gerado; nenhum desempenho de simulador ou de receptor é afirmado; os arquivos são verificados como relidos pelos leitores de movimento de um simulador de código aberto (gps-sdr-sim), mas a física da própria trajetória de verdade de referência do cenário não é verificada externamente	`docs/TEST-BENCH.md`
Verificação do OSNMA do Galileo	parcial	`src/osnma/` e `kshana osnma verify`: lê páginas I/NAV do Galileo ou um fluxo UBX e informa, por satélite e época, se os dados de navegação estão autenticados (chave assinada com raiz de Merkle, cadeia TESLA, MACs), com o motivo da falha de uma verificação e um tempo de referência independente opcional para frescor; também `osnma_verify` em Python e WebAssembly	Autentica dados contra chaves fornecidas pelo usuário; não afirma desempenho anti-spoofing e não é um serviço de integridade de navegação nem um equipamento homologado; verificado em vetores sintéticos, os vetores de teste oficiais do ICD são um download externo	`docs/OSNMA.md`
Mapeamento de compliance para frameworks públicos	parcial	`src/compliance/` e `kshana compliance-report`: saídas do Kshana mapeadas para seis frameworks e normas públicos de resiliência, com fontes e uma lacuna em cada linha; uma execução só conta quando seu resultado traz os campos que seu tipo de cenário escreve	Um mapeamento é um julgamento; o relatório diz em que um conjunto de execuções fornece evidências em apoio de, nunca que um framework é satisfeito nem que um produto foi aprovado; a EN 16803 é citada apenas a partir do texto do catálogo	`docs/compliance/README.md`
Integrações marítimas	parcial	Um plugin Signal K, o OpenCPN por NMEA em modo gate sobre TCP e uma compilação de referência para um computador pequeno ao lado do receptor (`integrations/`, `deploy/`)	Testado em saída sintética gravada; o plugin não está publicado no npm; consultivo, não é um equipamento de navegação homologado	`docs/MARINE-INTEGRATIONS.md`

Domínios mais amplos de sistemas espaciais (fora do escopo atualmente)#

Vários destes são nenhum; outros agora são modelos partial de primeira ordem (os tipos de cenário de análise de missão / ambiente adicionados na série v0.17.0): listados para que o escopo seja inequívoco, e não implícito pelo silêncio. O Kshana é um simulador de PNT, não um GMAT/STK/Orekit (STK: Systems Tool Kit); esses modelos adjacentes são deliberadamente de primeira ordem e MODELLED, nunca ferramentas de voo validadas.

Capacidade	Status	Nota / roteiro
Projeto de missão / otimização de trajetória	parcial	`src/maneuver.rs`: nós impulsivos de ΔV com propagação de covariância 6×6 (referenciais de erro de execução ECI/LVLH (ECI: inercial centrado na Terra; LVLH: vertical local, horizontal local)), integração de queima finita verificada contra a equação de Tsiolkovsky em forma fechada a < 0,01 %, um solucionador de Lambert de revolução única de Izzo-2015 + um propagador de Kepler exato em variáveis universais (saídas de Lambert reconduzidas contra a verdade de referência de dois corpos) e uma varredura porkchop (lançamento × chegada) de C3 / V∞ de chegada emitida como uma grade de contornos em JSON cujo mínimo é verificado contra o piso analítico de Hohmann. Sem otimizador de trajetória; um solucionador de Lambert de múltiplas revoluções (`maneuver::lambert_multirev`, até três revoluções, ambos os ramos) é VALIDATED contra o pykep 3.0.1 (`tests/lambert_multirev_oracle.rs`); o porkchop é executado sobre o modelo sintético circular coplanar ou, com `maneuver::porkchop_kernel`, sobre um SPK DE440 (VALIDATED contra estados do SPICE + o Lambert do pykep, `tests/porkchop_de440_oracle.rs`); `maneuver::optimise_transfer_kernel` encontra o ótimo contínuo de data (C3 mínimo ou V∞ de chegada mínimo, Tipo I ou II) em DE440, VALIDATED contra um otimizador independente SPICE + pykep + SciPy (`tests/transfer_optimiser_oracle.rs`); contra os mínimos Terra–Marte de 2026 publicados no NASA/TM-2010-216764, ele coincide com os valores do Tipo II e erra o C3 mínimo do Tipo I em −5,18 % (registrado). O próprio GMAT não foi executado; o pykep é a referência independente da biblioteca. Uma interface de efemérides planetárias de espaço profundo (`src/ephem_provider.rs`) e uma verificação cruzada com a DE440 (Development Ephemeris 440) (`xval/anise-mars-od`, 137 m em um arco de Marte de 1 dia) agora existem; veja a linha de PNT de espaço profundo / interplanetário. A camada de simulação de desempenho acima do GMAT/Orekit, não uma substituição. P3
AOCS (sistema de controle de atitude e órbita) / GNC (guiamento, navegação e controle) / atitude	parcial	Tipo de cenário `attitude-budget` (`src/attitude_budget.rs`): torque de gradiente de gravidade de pior caso `1.5·(μ/R³)·ΔI` + orçamento de erro de apontamento RSS (raiz da soma dos quadrados) sobre termos de 1σ por contribuinte: um orçamento escalar MODELLED de apontamento/perturbação anterior ao hardware. A dinâmica de atitude de corpo rígido sem torque, com estado em quatérnio (`src/attitude_dynamics.rs`: equações de Euler + cinemática de quatérnios, RK4), é VALIDATED contra o hub de espaçonave do Basilisk 2.9.1 (`tests/attitude_dynamics_basilisk_oracle.rs`, quatérnio dentro de 1e-9 em 1e4 s), e o pico do torque de gradiente de gravidade contra o GravityGradientEffector do Basilisk (`tests/attitude_gg_torque_basilisk_oracle.rs`); a determinação de atitude de Wahba está em `src/wahba.rs`. Tipo de cenário `aocs` (`src/aocs.rs`, `src/aocs_kind.rs`, `AOCS.md`): uma manobra de apontamento inercial com rodas de reação balanceadas sob realimentação MRP, torques de roda de norma mínima com limites de motor; a malha fechada é VALIDATED contra o Basilisk 2.9.1 em três casos fixados antecipadamente, até o erro de arredondamento. Um MEKF a partir de um giroscópio e de um rastreador estelar (`src/aocs_mekf.rs`) pode fechar a malha sobre sua estimativa (MODELLED, consistência de filtro). Sem guiamento de rastreamento, realimentação integral, gerenciamento de momento angular, magnetorquers, propulsores, atrito de roda nem limites de velocidade; sem ambiente de torques externos na dinâmica de atitude; não é um controlador de voo. P3
Referenciais → fixos à Terra	completo	Concluído: TEME→ECEF/ITRF, o movimento polar e a cadeia GCRS→ITRS baseada no CIO estão implementados e VALIDATED (bit a bit contra SOFA/ERFA; 4 mm de ponta a ponta contra Vallado). Veja a linha de Referenciais acima
Comunicações e orçamentos de enlace	parcial	`src/linkbudget.rs`: um orçamento de enlace de Friis de espaço profundo (potência de Tx · ganhos de antena · ruído → C/N₀ · Eb/N₀ · margem) que alimenta o caminho radiométrico/GSE (GSE: equipamento de apoio em solo), além dos enlaces ópticos/RF de transferência de tempo (`src/timetransfer.rs`), e o tipo de cenário `link-budget`* executável: a equação de enlace unidirecional CCSDS-401/DSN-810-005 (DSN: Deep Space Network) `C/N₀ = EIRP − FSPL − L_other + G/T − k` com entradas de EIRP (potência isotrópica radiada efetiva) / G-T e seleção de banda S/X/Ka (orçamento de enlace de engenharia MODELLED, não uma folha de dados calibrada de terminal). Sem programação de acessos, sem codificação adaptativa. P2
Segmento terrestre e operações	parcial	Tipo de cenário `passes` (`src/passes.rs`): predição de passagens de nascer/pôr de uma estação terrestre: AOS/TCA/LOS (AOS: aquisição do sinal; TCA: instante de maior aproximação; LOS: perda do sinal), elevação máxima, duração por passagem e acesso total ao longo de um horizonte, a partir de um conjunto de elementos SGP4 no referencial fixo à Terra IAU 2006/2000A com refração ITU-R P.834-9 e tempo de luz, VALIDATED contra o Orekit 13.1.8 em estações ao nível do mar (60 casos / 1210 passagens, `tests/pass_predictor_on_path_orekit_oracle.rs`); o `passes::predict_passes` geométrico é VALIDATED contra o detector de elevação do Orekit 12,2 (22 cenários / 129 passagens, `tests/ground_station_pass_prediction_reference.rs`); sem otimizador de programação nem resolução de conflitos. P3
Telemetria / TT&C / CCSDS	parcial	TOML de entrada/JSON de saída sob medida; *exportação e importação* de OEM (Orbit Ephemeris Message) do CCSDS (502.0-B KVN (notação palavra-chave-valor), GMAT/Orekit/STK) por meio do tipo de cenário `oem-interop` executável (ponte de ida e volta `src/oem.rs` `parse_oem`; a troca aderente à norma de objeto único é VALIDATED contra o interpretador independente `oem` 0.4.5); interpretação + emissão de Tracking Data Message CCSDS-TDM (503) (`src/ccsds_tdm.rs`, o formato de intercâmbio radiométrico de espaço profundo); e o tipo de cenário `space-packet` (`src/space_packet.rs`): codificação/decodificação do cabeçalho primário de Space Packet CCSDS 133.0-B com ida e volta exata bit a bit. Um gravador de OMM do CCSDS (Orbit Mean-Elements Message, 502.0-B-2, parte da família ODM) (`src/omm.rs`) publica elementos médios do SGP4 em KVN, e um leitor de kernels NAIF SPICE** em Rust puro (`src/naif_kernel.rs`: contêiner DAF, SPK tipo 2, PCK binário tipo 2) sustenta `ephem_provider::KernelEphemeris`. Outros tipos de mensagem CCSDS (OPM, OCM, AEM (AEM: Attitude Ephemeris Message)) e a escrita de SPICE continuam como item do roteiro (P2)
Interoperabilidade e normas (RINEX/SP3/SPICE/CCSDS)	parcial	NAV multi-GNSS RINEX 3 — GPS, Galileo, QZSS, BeiDou MEO/IGSO (IS-GPS-200) e GLONASS (vetor de estado PZ-90 (PZ: Parametry Zemli, o datum geodésico russo) com RK4) — ingerido + propagado + executável como uma única constelação mista; interpretador de OBSERVAÇÃO RINEX 3 (pseudodistância/portadora/Doppler/SNR por código de observação, com sinalizadores LLI/SSI (LLI: indicador de perda de travamento; SSI: indicador de intensidade do sinal); espera-se que a 4,00 seja interpretada, não testada); ida e volta de leitura ↔ escrita de efemérides precisas SP3-c/d (interpretação + exportação para Ginan/RTKLIB/gLAB) e um propagador de Lagrange de 10ª ordem (11 pontos) (`Propagator::Sp3Precise`); a exportação SP3 é exposta na CLI (`kshana <orbit.toml> --export-sp3 out.sp3`, ou `export_sp3 = true`) e validada por ida e volta contra a constelação GPS real a <0,5 m em 24 h (`tests/sp3_export_roundtrip.rs`); gravador de efemérides OEM 2,0 do CCSDS, a exportação de estado TEME com velocidade para ferramentas de dinâmica de voo, agora exposto na CLI (`kshana <orbit.toml> --export-oem out.oem`, ou `export_oem = true`) e verificado por ida e volta contra o estado do propagador (`tests/sp3_export_roundtrip.rs`). O interpretador de observações RINEX agora alimenta uma solução de posicionamento por ponto único (`pvt`, validada em dados reais do IGS; veja a linha GNSS / PNT). Além disso, interpretação + emissão de mensagem de dados de rastreamento CCSDS-TDM (503) (`src/ccsds_tdm.rs`). Exportações de geometria para visualizadores e ferramentas de análise de missão: CZML, KML (Keyhole Markup Language), GeoJSON e efemérides STK (`--export`, `src/interop/`), cada uma lida de volta por um validador escrito a partir da especificação do formato (`tests/interop_formats.rs`), uma importação de rotas GeoJSON (`--import-route`), gravações SigMF (Signal Metadata Format) de entrada e saída para o tipo de cenário `spectrum`, e texto no estilo RINEX 4 / CSV para a mensagem de navegação LEO (`INTEROP.md`, `STANDARDS.md`). Ainda sem BeiDou-GEO, sem fixação de ambiguidade inteira em PPP nem RTK cinemático (existem PPP float estático e RTK de linha de base curta em dados reais, veja a linha GNSS / PNT), sem gravador SPICE e sem OPM/AEM (o leitor de OEM existe por meio do tipo de cenário `oem-interop`, o gravador de OMM em `src/omm.rs` e um leitor de SPK/PCK do SPICE em `src/naif_kernel.rs`) — P2 "anexar domínios adjacentes por meio de formatos padrão"
Clima espacial / ambiente (iono/atmo/radiação)	parcial	Tipo de cenário `space-weather` (`src/space_weather.rs`): índices solares/geomagnéticos (tabela de 28 passos Kp↔ap da IAGA (Associação Internacional de Geomagnetismo e Aeronomia), Ap diário, F10.7a centrado de 81 dias), temperatura exosférica de Jacchia-71 e um acoplamento de densidade termosférica conduzido pela atividade sobre uma atmosfera estática: MODELLED de primeira ordem, NÃO um modelo de densidade absoluta NRLMSISE. Ionosfera: o modelo transmitido de Klobuchar (VALIDATED contra o RTKLIB) e um leitor de mapas TEC (conteúdo total de elétrons) IONEX (formato de intercâmbio de mapas da IONosfera) (`src/ionex.rs`, testado em unidade). Um mapa global de ionosfera real do CODE (`CODG1330.18I`) é a referência independente medida da linha de TEC oblíquo livre de geometria (`tests/geometry_free_tec_gim_oracle.rs`), mas esse teste avalia o mapa em seu próprio gerador de fixtures, de modo que o leitor `src/ionex.rs` em si ainda não foi verificado de forma cruzada contra um produto real; sem modelo de ionosfera baseado em física nem conduzido pelo clima espacial; P2+
Navegação por mapa de gravidade / alt-PNT	parcial	`src/gravimeter.rs`: um modelo de medição de gravímetro de átomos frios cujo piso de ruído branco é derivado da ASD do acelerômetro CAI (`σ = ASD/√τ`), um campo de anomalia de gravidade em harmônicos esféricos totalmente normalizados de baixo grau (validado contra as funções de Legendre em forma fechada e uma anomalia de termo único derivada à mão) mais mascons sintéticos, e um filtro de partículas de casamento com mapa de gravidade (compondo `mapmatch` + `particle_filter`) que recupera uma trajetória sem GPS a partir da sequência de anomalias que ela atravessa. O benchmark de 60 minutos sem GPS (`run_gps_denied_gravity_nav`, `scenarios/gps-denied-gravity-nav.toml`) voa uma interrupção de ~700 km / uma hora em que a solução inercial deriva até ≈ 70 km, e um casador hierárquico do grosseiro ao fino, com o ruído branco determinístico com semente do gravímetro, a recupera a ≈ 145 m (< 500 m), estável entre realizações de ruído e comprovadamente limitada pelo refinamento (uma única grade grosseira estaciona em ~2 km). Além disso, um modelo completo do campo principal geomagnético IGRF-14 (IGRF: Campo Geomagnético Internacional de Referência) (`src/igrf.rs`: o campo em harmônicos esféricos normalizados de Schmidt da IAGA até grau/ordem 13, 2025,0 + variação secular, coeficientes gerados por máquina a partir do `igrf14coeffs.txt` oficial; validado contra o dipolo inclinado em forma fechada, uma diferença finita do potencial escalar e o polo/intensidade geomagnéticos conhecidos), o campo magnético com que uma plataforma pode fazer o casamento de mapas para navegação por anomalia magnética. Além disso, navegação referenciada ao terreno (TERCOM/SITAN (TERCOM: casamento de contornos de terreno; SITAN: Sandia Inertial Terrain-Aided Navigation)) e o navegador combinado de gravidade + magnetismo + terreno (`src/altpnt/terrain.rs`): um interpretador artesanal de modelo digital de elevação (DEM) `.hgt` do SRTM (Shuttle Radar Topography Mission) (inteiros de 16 bits com sinal, big-endian, ordem por linhas, linha norte primeiro, vazio -32768; validado contra a especificação do driver SRTMHGT (formato de arquivo de altura da Shuttle Radar Topography Mission) do GDAL (Geospatial Data Abstraction Library) e uma referência independente em forma fechada do ponto médio bilinear), um modelo de altímetro radar/barométrico e um casador `run_terrain_nav` que recupera uma trajetória sem GPS a partir do perfil de elevação do terreno contra o DEM, e `run_combined_altpnt`, que funde três canais de campo escalar por waypoint (Δg mGal · \|B\| nT de anomalia crustal · elevação m), de modo que a posteriori conjunta é mais aguda (CRLB (limite inferior de Cramér–Rao) menor) do que qualquer campo isolado: limitada a < 500 m ao longo da interrupção de 60 min e, em expectativa, não pior que o melhor canal isolado. Além disso, navegação sequencial (recursiva) referenciada ao terreno: o SITAN como um filtro em execução (`src/altpnt/sequential.rs`, `run_sequential_trn`): o mesmo modelo de medição altímetro-contra-DEM executado época a época pelo motor SIR (reamostragem por importância amostrada) de `particle_filter` (predição pelo incremento do INS + ruído de processo → reponderação pelo casamento com o terreno → reamostragem na degeneração), de modo que uma deriva do INS variável no tempo é rastreada ao longo da trajetória, enquanto o casador em lote só recupera um único deslocamento constante: a estimativa recursiva permanece limitada e reconverge (final ≈ 70 m), enquanto a solução sem auxílio diverge sem limite até ≈ 5 km, com o erro por época acompanhando a distintividade do terreno e um monitor de saúde do tamanho efetivo da amostra. Escopo honesto: o mapa é conhecido e fixo, uma localização recursiva contra um DEM armazenado (a metade de localização do SLAM de terreno (localização e mapeamento simultâneos)); a estimação conjunta do mapa é o RBPF separado abaixo. Todos os quatro agora estão ligados ao motor de cenários `kind=` (`gravity-map`, `terrain-nav`, `combined-altpnt`, `terrain-slam`) com um gráfico SVG de deriva (`scenarios/terrain-nav.toml`, `scenarios/combined-altpnt.toml`, `scenarios/terrain-slam.toml`). 0,36 (WP-10): o navegador `gravity-map` aceita um campo de referência real opcional (`[reference]`: EGM2008 incluído até o grau 70, ou um arquivo `.gfc` do ICGEM), cuja síntese de anomalia coincide com o Serviço de Cálculo do ICGEM a cerca de 1e-8 mGal (VALIDATED, `xval/icgem-egm2008/`); nesse campo de grau 70, o benchmark de 60 min termina em 3106 m, de modo que o limiar de < 500 m é NOT MET (fixado antecipadamente e previsto: o grau 70 é suave demais). Um Monte Carlo opcional de erro de mapa (`[map_error_mc]`, `scenarios/gravity-map-error-mc.toml`) mostra que a fixação sintética de 144 m supõe um mapa exato (1 de 20 realizações dentro de 500 m sob um erro correlacionado de 2 mGal; exploratório). `combined-altpnt` aceita uma grade magnética crustal EMAG2v3 opcional (`[magnetic_grid]`; o EMAG2 é baixado, não incorporado ao repositório, e nenhum resultado de navegação é afirmado com ele). `terrain-nav` permanece apenas com DEM por projeto: é o casador TERCOM/SITAN de canal único, e o casamento magnético fica em `combined-altpnt`, que funde o terreno com os canais magnético e de gravidade; um canal magnético em `terrain-nav` o duplicaria, de modo que o item de auditoria "EMAG2 em terrain-nav" é coberto pela ligação em `combined-altpnt` (RM-16). As verificações com SRTM real são executadas na CI em dois recortes de resolução total versionados (nó a nó iguais ao GDAL 3.8.4, `xval/srtm-ungate/`). Existe estimação conjunta do mapa (`run_sequential_trn_on_map`, um RBPF no estilo FastSLAM): em uma única passagem, ela ganha 1,5 % sobre o SITAN com mapa conhecido em um mapa errôneo, deixando de atingir seu limiar de 10 % fixado antecipadamente (`xval/terrain-slam-rbpf/`). Ainda falta: um modelo de gravidade de alto grau em uma execução de navegação (exige um novo pré-registro), um resultado de navegação magnética com grade real e um caso de SLAM com revisita (fechamento de laço). P3
Reentrada / EDL (entrada, descida e pouso), análise de lançamento, EO/carga útil (EO: observação da Terra)	parcial	Geometria MODELLED de primeira ordem por meio de três tipos de cenário executáveis: `reentry` (`src/reentry.rs`, corredor balístico de Allen-Eggers: desaceleração de pico, velocidades de pico de g e de pico de aquecimento, altitude de pico de g), `launch-window` (`src/launch.rs`, azimute de lançamento de dois corpos `sin Az = cos i/cos lat`, Δv de mudança de plano, bônus de rotação do local, oportunidades diárias) e `eo-coverage` (`src/eo_payload.rs`, geometria de faixa / GSD (distância de amostragem no solo) / acesso / revisita de EO pelo triângulo espacial do SMAD (Space Mission Analysis and Design)). Sem simulação EDL/aerotérmica de 6-DoF, sem otimizador de trajetória, sem radiometria de sensor/MTF (MTF: função de transferência de modulação). P3
PNT lunar / cislunar (LunaNet)	parcial	`src/lunar.rs`: um motor de ARAIM lunar que reutiliza o núcleo MHSS do lado da Terra com os parâmetros do LNIS (LunaNet Interoperability Specification) da LunaNet (σ_URE ≈ 30 m, P_sat ≈ 1e-4), a redução de referencial cislunar MCI↔MCMF (MCI: inercial centrado na Lua; MCMF: centrado e fixo à Lua) (`mci_to_mcmf` / `mcmf_to_mci`, um modelo simplificado de rotação média à taxa sideral) e lat/lon/alt selenográficos (`mcmf_to_selenographic`), e uma passagem de nível de proteção no polo sul (`south_pole_hpl_pass`) que quantifica a lacuna de integridade: com alcance de 30 m, o HPL é finito, mas excede um limite de alerta de operações em superfície de 50 m. `src/cr3bp.rs` acrescenta o CR3BP Terra–Lua (problema circular restrito de três corpos) (dinâmica em referencial girante + propagador RK4 + constante de Jacobi + os cinco pontos de Lagrange, validado contra os valores publicados de L1/L2/L3 e os exatos de L4/L5), o núcleo de três corpos de que uma NRHO (órbita de halo quase retilínea) real precisa, e um corretor diferencial de tiro simples com matriz de transição de estado (`cr3bp_jacobian`, `propagate_state_stm`, `differential_correct_halo`) que produz órbitas de halo/NRHO L2 genuinamente periódicas: a STM é validada contra diferenças finitas, os halos corrigidos se fecham sobre si mesmos com precisão de máquina (conservando Jacobi), e a semeadura com o estado de apolune publicado reproduz a NRHO L2 sul 9:2 (a órbita do Gateway) com período ≈ 6,57 d e perilune ≈ 3.250 km, consistente com o publicado ≈ 6,56 d / ≈ 3.370 km \| As ICs (condições iniciais) da NRHO corrigidas por diferenciais agora estão ligadas, mas a transformação selenocêntrica (MCI/MCMF) desnormalizada da órbita corrigida e a continuação de família ainda são desdobramentos futuros; a orientação lunar de eixos principais da DE440 com libração física real existe (`src/lunar_orientation.rs`, a partir do PCK `moon_pa_de440`, verificada contra o SPICE `pxform` em `tests/lunar_pa_orientation_spice_oracle.rs`), mas o caminho `lunar::mci_to_mcmf` mais antigo ainda usa a rotação média sem libração nem o polo em precessão; a NRHO é uma solução do CR3BP (circular, sem Sol), não validada contra uma efeméride real de LANS/Gateway (LANS: Lunar Augmented Navigation Service); um tipo de cenário `lunar-integrity` executável (`scenarios/lunanet-araim.toml`) expõe a passagem do polo sul pela CLI \| transformação selenocêntrica + continuação de família + interface SPICE/LunaNet: P3
PNT de espaço profundo / interplanetário (Marte, radiométrico)	parcial	Entregue na v0.17.0. Um motor de navegação radiométrica: tempo de luz iterativo + atraso de Shapiro, Doppler e distância bidirecional/unidirecional/tridirecional (duas pernas de Moyer), retorno coerente do transponder, medição de distância regenerativa/PN (PN: pseudoaleatório) (CCSDS 414), Δ-DOR (CCSDS 506), meios de plasma solar/tropo/iono (`src/radiometric.rs`); interpretação + emissão CCSDS-TDM (503) (`src/ccsds_tdm.rs`); um SRIF de dinâmica reduzida (filtro de informação em raiz quadrada) com acelerações empíricas RTN (radial, transversal, normal) + um relógio de bordo de 3 estados + arrasto de Marte (`src/deepspace_od.rs`, `clock_state.rs`, `mars_atmos.rs`) que faz OD de Marte-LMO (LMO: órbita baixa de Marte) ≈ 0,2 m em uma malha fechada sintética; fusão unidirecional + bidirecional; um núcleo de dinâmica de múltiplos corpos (`src/body.rs`, Mars GMM-3 (GMM: Goddard Mars Model), referencial IAU de Marte `src/mars_frame.rs`, uma interface `EphemerisProvider` `src/ephem_provider.rs`, JD de duas partes + TT↔TDB (TDB: Tempo Dinâmico Baricêntrico)); e o cenário de PNT por retransmissão `mars-pnt` (constelação areoestacionária MARCONI, `src/mars_pnt.rs`) + um simulador de desempenho de GSE de ponta a ponta (`src/gse_sim.rs`). Validado por simulação (FoM de covariância/malha fechada); dinâmica centrada no Sol verificada de forma cruzada contra a DE440 do JPL (Jet Propulsion Laboratory) (137 m em um arco de 1 dia, `xval/anise-mars-od`). Falta: validação com dados reais de rastreamento da DSN/ESTRACK (ESTRACK: rede europeia de rastreamento espacial); gravidade de Marte em seu referencial nativo (o campo GMM-3 de grau/ordem 120 é carregado da tabela SHADR do PDS, `from_shadr`, VALIDATED contra o pyshtools, e é anexado por meio de `Body::with_gravity_field`, mas é avaliado no referencial IAU e não no seu próprio referencial Konopliv-2006); efemérides de nível DE no núcleo (condicionadas a kernel no xval). P3
Sistema solar e PNT em torno de qualquer corpo	parcial	Tipo de cenário `solar-system`: posições, velocidades e constantes físicas do Sol, dos planetas, de Plutão, da Lua e de sete luas principais em uma época, com o tempo de luz entre corpos; as posições dos planetas (elementos de Standish do JPL) e o tempo de luz são VALIDATED contra o JPL Horizons (`tests/solar_system_horizons_reference.rs`); as luas, Plutão e a tabela dos planetas externos permanecem MODELLED. Tipo de cenário `body-pnt`: um orbitador ou módulo de pouso em torno de qualquer corpo catalogado (Marte, a Lua, Europa, Ganimedes, Titã e os demais) navegando por pseudodistâncias unidirecionais de uma constelação Walker local, mais uma distância bidirecional opcional a partir da Terra: MODELLED. Sem kernel de efemérides planetárias no núcleo (elementos analíticos); as órbitas de retransmissão de `body-pnt` usam apenas J2 (os campos completos GMM-3 de Marte de grau/ordem 120 e GRAIL GL0660B da Lua de grau/ordem 660 são carregados de tabelas SHADR do PDS e anexados a um `Body` para o propagador, `src/gravity_pds.rs`). P3
Campanhas / composição de missões	parcial	Tipo de cenário `campaign` (`src/campaign.rs`): tipos de cenário existentes encadeados em uma única linha do tempo compartilhada (por exemplo jamming, depois spoofing, depois holdover com um INS em deriva, depois um alarme de integridade, depois recuperação), varreduras de parâmetros e conjuntos de Monte Carlo com sementes sobre qualquer tipo de cenário, e vários cenários sob condições compartilhadas com um resumo combinado; todo número é lido de uma execução real do tipo de cenário do membro. As identidades de composição são testadas (`tests/campaign_composition_reference.rs`: uma campanha de uma fase reproduz a execução isolada byte a byte); MODELLED. Uma seção `[optimize]` (grade ou Nelder–Mead limitado sobre uma a três chaves, uma métrica, minimizar, maximizar ou atingir um alvo) satisfaz seus limiares de forma fechada e de força bruta fixados antecipadamente (`tests/campaign_optimize_reference.rs`); MODELLED, uma busca local sem afirmação de ótimo global e sem método de gradiente nem bayesiano. P3
Relatórios, animação e saídas	parcial	Toda execução grava `result.json`, um gráfico e um relatório (`report.html`, `report.json`) cujos rótulos são lidos da matriz de verificação e cujo comando registrado reproduz o resultado byte a byte (`tests/advanced_report_cli.rs`); `--animate` (svg, html ou frames) renderiza uma série temporal como uma animação (`src/animation.rs`, `ANIMATION.md`); `--export` grava os formatos de intercâmbio da linha de interoperabilidade. Essas são renderizações da execução, não evidência sobre a física.

Ecossistema e prontidão (acompanhados com honestidade, não uma capacidade de código)#

Área	Status	Nota
Bindings de linguagem e empacotamento	parcial	Rust + Python (abi3) + WASM em três registros. Superfícies tipadas (0,36, CAP-34): `RunOutput` em Python com acessores NumPy (`array`, `columns`, `series`) e `ScenarioKind` / `ErrorKind` / `KindMeta` com tipagem por stubs; `run_typed` em JavaScript (um objeto `RunOutput` tipado) e `scenario_kinds`, com o mesmo vocabulário nas declarações TypeScript. Os documentos de resultado continuam sendo JSON por tipo de cenário, tipados apenas pelo seu envelope compartilhado (`units`, versões)
Educação / UX (experiência do usuário) de integração	parcial	Playground de navegador com modo guiado entregue: controles deslizantes guiados adaptados ao cenário (`web/studio/lib/guided.mjs`, até seis ajustes por cenário) e um tour guiado interativo (`web/studio/lib/tour.mjs`, que pode ser repetido no playground). Cada execução também recebe uma frase de significado em linguagem simples e suas figuras principais, lidas do documento de resultado (`web/studio/lib/meaning.mjs`, com modelos por tipo de cenário em `meaning-kinds.mjs`; um tipo de cenário sem modelo recebe sua primeira figura de destaque declarada de forma simples). Falta: explicações guiadas por figura além dessa frase (o `GLOSSARY.md` em linguagem simples as cobre)
Comunidade / governança	parcial	Estrutura de governança presente: `GOVERNANCE.md` (modelo de mantenedor benevolente + critério técnico + fronteira entre aberto e fechado), `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, `SECURITY.md`, modelos de issues/PR (PR: pull request), `FUNDING.yml`, dependabot. Fundador único; uma comunidade externa ativa (contribuidores, citações) depende de pessoas/tempo e ainda está se formando (divulgação pendente de revisão)
Financiamento e prontidão para aquisições	nenhuma	TRL ~3; ainda sem citações/contratos de agências (veja as notas de estratégia)

Atualizado em 2026-10-29 para o motor 0.40.0 (92 tipos de cenário, a partir de kshana kinds --json; novos na 0.40.0: mission-thread, lunar-orbit-rendezvous, lunar-descent, lunar-surface e lunar-ascent). 2026-10-22: motor 0.39.0, 87 tipos, nenhum tipo novo. 2026-10-19: motor 0.38.0, 87 tipos (novos na 0.38.0: holdover-test, gnss-ssv e lunar-infrastructure). 2026-10-18: 84 tipos (novo na 0,37: optical-atmosphere). 2026-10-16: 83 tipos (novos na 0,36: acm-link, aocs, ascent-losses, contact-schedule, entry-heating, eo-radiometry, lunar-station-coverage e time-transfer-budget). 2026-10-10: motor 0.35.0, 75 tipos, nenhum tipo novo. 2026-10-09 e 2026-10-08: revisões anteriores. 2026-10-04: a linha Nav-signal anota a camada IQ da 0.31.0. 2026-09-29: linhas de LEO-PNT, espectro, PNT do sistema solar / de qualquer corpo, campanha e saída adicionadas. Antes: alinhado à matriz de 27 linhas de capacidades da grande auditoria de 2026-06-02; linha de PNT de espaço profundo / Marte adicionada na v0.17.0. As adições de PNT quântico (holdover de relógio sem GNSS src/holdover.rs, orçamento composto de navegação inercial-quântica por estima QuantumNavBudget, estudo de compromisso de projeto de códigos de alcance CodeFamily, matriz de verificação verificada por máquina src/verification.rs) foram incorporadas às linhas de Temporização, sensor de PNT quântico, Nav-signal e V&V — cada uma rotulada como validada ou modelada conforme a sua referência independente real.

Adições da demonstração FutureNAV (modeladas, verificadas internamente de forma cruzada, não validadas externamente): (1) Bancada de avaliação de detecção de degradações de RF por aprendizado de máquina src/impairment_eval.rs: um corpus rotulado sintético de degradações (ancorado em parâmetros, não em IQ) + um harness ROC/AUC/confusão/Pfa-Pmd (ROC: característica de operação do receptor; AUC: área sob a curva) agnóstico quanto ao detector, com proteção contra vazamento e partição estratificada; os detectores incluídos são linhas de base transparentes de métodos publicados, não o estado da arte, e uma AUC alta aqui demonstra o pipeline, não desempenho em campo. (2) Motor de compromisso PNT quântico versus clássico src/quantum_trade.rs: ingestão de ADEV medido (ajuste NNLS (mínimos quadrados não negativos) de σ_y²(τ)=q_wf/τ + q_rw·τ/3 + q_drift·τ³/20, verificado por ida e volta contra q_from_allan), uma tabela de benefício de holdover de temporização/inercial que carrega no artefato a ressalva da hipótese de piso e um envelope de resiliência versus tempo sem GNSS; ele quantifica o benefício quântico de um parceiro e nunca valida o dispositivo. Ambos revisados de forma adversarial (um erro de base de deriva τ²→τ³ e uma afirmação falsa de resiliência "limitada indefinidamente" foram detectados e corrigidos). 911 testes da biblioteca no momento dessa adição, fmt+clippy limpos.

Adição de intercâmbio / formato padrão (src/interchange.rs): o Kshana Interchange Format (KIF), um Envelope neutro, versionado e autodescritivo que envolve qualquer artefato (cenário, resultado, estudo de compromisso) com uma etiqueta format reconhecível, o SCHEMA_VERSION como fonte única de verdade (a versão do esquema, antes copiada como literal em 15 lugares, agora pertence a uma única constante que o crate inteiro referencia), o engine_version produtor e um contrato de compatibilidade explícito e testado (compatibility(): mesma versão principal / versão secundária igual ou mais antiga é legível sob a disciplina de campos aditivos; uma versão secundária mais nova ou uma versão principal diferente é recusada na fronteira por Envelope::parse em vez de ser interpretada incorretamente em silêncio). Com ida e volta (wrap→to_json→parse→payload_as::<T>()) para qualquer carga Deserialize; deliberadamente sem carimbo de tempo, para preservar a reprodutibilidade bit a bit do Kshana. Documentado em SCHEMA.md, de modo que o formato seja citável, e não apenas emitido: o posicionamento de "padrão em espera" do núcleo aberto. 923 testes da biblioteca no momento dessa adição, fmt+clippy limpos.

Adições da versão de dominância FutureNAV (modeladas, verificadas internamente de forma cruzada, não validadas externamente): (1) Camada frugal de custo por cobertura / ROI (retorno sobre o investimento) src/frugal.rs: uma camada de enquadramento de benefícios sobre o motor de dimensionamento de constelações (walker) que relata o custo por ponto percentual de cobertura e o ROI de cobertura por euro em relação a uma linha de base; o custo por satélite é uma faixa baixa/nominal/alta fornecida pelo chamador e com fonte (sem preços pontuais inventados), de modo que as saídas são intervalos, e não pontos espúrios; um enquadramento econômico modelado de uma figura de cobertura modelada, não uma cotação. (2) Mapeamento do impacto de integridade de uma detecção perdida src/integrity_impact.rs: mapeia um viés de posição não detectado induzido por spoofing/jamming para seu erro efetivo → região de Stanford (disponível / sistema indisponível / enganosa / perigosamente enganosa) contra limites de alerta específicos do contexto (céu aberto versus urbano, HAL versus VAL), compondo o classify_stanford do RAIM ancorado externamente; a ponte entre detecção perdida e limite de alerta é modelada, não uma alocação de integridade certificada. Ambos são mapeados na matriz de verificação verificada por máquina (src/verification.rs, invariante Validado⇒ExternalDataset intacta; a contagem atual de linhas é o cabeçalho gerado de VERIFICATION-MATRIX.md). A validação cruzada / proteção contra vazamento / partição estratificada por parâmetros para o harness de avaliação de IA já havia sido entregue em src/impairment_eval.rs (stratified_split, Split::has_leakage). 951 testes da biblioteca no momento dessa adição, fmt+clippy limpos.

Adições do estudo de lacuna de otimismo FutureNAV (modeladas, verificadas internamente de forma cruzada contra formas fechadas, não validadas externamente, não uma afirmação de transferência da simulação para o campo): um estudo sintético controlado da lacuna de otimismo da AUC entre dentro e fora da distribuição para detectores de degradações de RF. (1) Detectores aprendidos src/impairment_ml.rs: um mapa de atributos fixo + padronizador ajustado no treino, uma linha de base de regressão logística (descida de gradiente determinística em lote completo) e um MLP (perceptron multicamada; backprop com SGD (descida de gradiente estocástica) com semente) de uma camada oculta, por trás do mesmo trait ImpairmentDetector que as linhas de base de métodos publicados usam. (2) Estatísticas derivadas à mão src/eval_stats.rs: intervalos de confiança (ICs) por bootstrap de percentis, variância/IC da AUC de DeLong, ρ de Spearman e regressão ridge, cada um verificado contra uma forma fechada (AUC binormal Φ(d′/√2), uma variância de DeLong calculada à mão, um ρ de postos empatados de livro-texto, recuperação exata por OLS (mínimos quadrados ordinários)). (3) O estudo src/impairment_study.rs: AUC por classe, a tendência de lei de escala por (detector,class) (lacuna versus 1−severidade) e um preditor ridge de lacuna apenas com dados dentro da distribuição que estima a lacuna de otimismo apenas a partir de diagnósticos dentro da distribuição, pontuado por exclusão de um detector e por exclusão de uma classe contra uma linha de base que prevê a média. Artefato de um único comando por cargo run --release --example optimism_study. Todo número é uma AUC sobre rótulos derivados de modelo em um corpus sintético ancorado em parâmetros; a lacuna é um deslocamento de severidade sintético→sintético, nunca um resultado de detecção em campo. Mapeado na matriz de verificação verificada por máquina (src/verification.rs, invariante Validado⇒ExternalDataset intacta).