変更履歴

Kshana の注目すべき変更はすべて、ここに記録しています。

書式は Keep a Changelog に基づき、このプロジェクトは Semantic Versioning に従います。プロジェクトが 1.0 より前の間は、公開されているシナリオ／結果スキーマが変更される可能性があり、互換性を損なう変更は明示します。

未リリース#

[0.40.0] - 2026-10-29#

0.40 では、Artemis級のミッションスレッドとその月のセグメント、実行が書き出すすべての数値と表のエビデンスラベル、測定したクロックの取り込みと当てはめ、データパートナーの提出物の検査、ADS-B または AIS の報告から推定した発信源領域、0.40 のベンチマーク再キャンペーン、そして英語に加えて十七言語でのコマンドライン、レポート、Studio（機械可読の文書は英語のまま）を追加しました。検証マトリクスは 388 行から 401 行に増え、内訳は VALIDATED が 176 行（変更なし）、MODELLED が 221 行（以前は 208 行）、PARTNER が 4 行です。VALIDATED に昇格した行はありません。シナリオ kind は 87 種類から 92 種類に増えました。事前登録した比較で未達だった合格基準はすべて、下に明記したとおり固定されたままで、緩めたものはありません。助言に関する記述は変わりません。Kshana は助言用ソフトウェアであり、型式承認を受けた航法装置ではなく、認証でもありません。運用者が引き続き責任を負います。

既知の制約#

• 英語以外での実行には約二倍の時間がかかります。シナリオを二回実行するためです（機械可読ファイル用に英語で一回、利用者向けに選んだ言語で一回）。
• Studio の一部の文は断片から組み立てられるため、文法上の性を持つ言語では冠詞が欠けることがあります。
• 翻訳は機械翻訳であり、ネイティブスピーカーによる確認は行われていません。英語版が基準です。

追加#

• 英語に加えて十七言語で、エンジンの人が読むテキスト、サイト、Studio を提供します：nl、pl、pt-BR、pt-PT、fi、sv、da、nb、cs、uk、ru、de、fr、es、et、ja、zh-Hans（--lang、KSHANA_LANG、ロケール変数。ライブラリ、Python、WebAssembly、MCP の呼び出しではlang）。コマンドラインのメッセージとエラー、実行サマリー、チャートのテキスト、report.html、kind の説明、助言は翻訳されます。機械可読の文書（JSON、CSV、エラーコード、検証マトリクス）は英語のままで、英語以外の実行では、機械可読ファイル用に英語で一回、利用者向けに選んだ言語で一回、シナリオを実行します（docs/i18n.md）。翻訳は機械翻訳であり、ネイティブスピーカーによる確認は行われていません。英語版が基準です。各言語のREVIEW.mdには、レビュー担当者が最初に確認すべき点が挙げられており、サイトのページにもその旨の注記があります。判定の語、エビデンスのティア、助言の適用範囲（「型式承認を受けていない」「認証ではない」「運用者が引き続き責任を負う」）は、すべての言語でそのまま保たれます。
• kshana interference-map locate：ADS-B または AIS の報告から求める推定した発信源領域です。劣化した位置報告の発生源がありうる場所についての事後分布で（4/3 地球半径での電波の見通し線、発信源アンテナの高さと電力は周辺化し、影響を受けた航空機は引き寄せ、見通し線のある影響を受けていない航空機は押し戻します）、50、90、95% の領域、不確かさ楕円を伴う重心（単独の点は示しません）、時間方向のセッション（開始、終了、継続時間、影響を受けた面積、公開下限を超える異なる航空機）、時刻別のプロファイルと一日あたりの時間数として書き出し、geolocationによる TDOA 測位解の任意の融合も行えます。出力は GeoJSON、JSON サマリー、セッションの CSV、SVG の図で、いずれもライセンス、帰属表示、手法 ID、前提、制約、エビデンスラベルを備えます。ライブラリはinterference_map::api::emitter_regions_from_*、Python と WebAssembly はinterference_emitter_regionsです。MODELLED（台帳の行VM-bc70cb57。マトリクスは現在 401 行で、VALIDATED が 176、MODELLED が 221、PARTNER が 4）。較正は合成データのみで行い、Jammertest 2025 の送信地点との比較は事前登録して一度実行しました。ADS-B と AIS はいずれも NOT ASSESSABLE（公開データで予定されたセッションが少なすぎました）のため、この行は MODELLED のままです（docs/emitter-region/RESULTS.md）。中立的な表現とし、集計のみです。公開オブザバトリーでの発信源領域の公開はオフのままです。合成データの例はexamples/emitter-region/にあります（docs/INTERFERENCE-MAP.md）。
• 測定したクロックログ。 src/clock_log.rsは、測定したクロックログを一つの位相系列に読み込みます。対応する形式は八つ（RINEX clock、TimeLab、TICC、linuxptp のptp4l、phc2sys、ts2phc、chrony のトラッキングと統計）で、それぞれ文書化された部分集合です。その外にあるものは、見つかった内容を示すエラーとともに拒否されます。これはtelecom-timing（[series.clock_log]）とクロック kind（[clock_log]。ログの SHA-256 と重なりありの ADEV、TDEV、MTIE を含むmeasuredブロックが加わります）で使われ、同梱のclock-measured-logシナリオ（docs/CLOCK-LOG-FORMATS.md）もあります。実際の公開データで allantools と比較し、事前登録した合格基準に照らしました。最初の実行は B1（11 件中 5 件で、すべてf64として保持した TICC のタイムスタンプ）、B2、B3（24 件中 7 件）、B4（ヘッダーのバージョンを検査していませんでした）に届きませんでした。修正後、B1、B3、B4 は達成し、B2 は一組の MTIE を除いて達成しました。その一組は固定してあり、エンジンの欠陥ではありません（allantools 2024.6 は積分する前に平均周波数を除きます。位相モードの MTIE と比べると、エンジンは 1e-10 以内で一致します）。この行は MODELLED のままです（tests/fixtures/clock_log_real/RESULTS.md）。
• 当てはめた測定系列で駆動するホールドオーバー：クロック kind の[clock_fit]は、測定した系列のノイズを当てはめ、それでホールドオーバーを駆動します（src/clock_fit.rs、同梱のclock-fitted-logシナリオ）。事前登録した比較：F1(b)、F3、F4 は達成。F1(a)（登録したランダムウォーク FM の復元）は、C3 のレコードでNOT MET（構造上、識別できません）、C4 の三つのレコードのうち二つでも未達でした（ランダムウォーク FM がフリッカー FM とドリフトに吸収されました）。F2（allantools に対するノイズの識別）は、十二件のレコードのうち十一件と D3 で達成、D2 では登録どおりにNOT MET でした（同じ条件での比較では達成）。未達はすべて固定されています（tests/clock_fit_known_noise.rs）。fittedブロックと、それで駆動するホールドオーバーは MODELLED のままです（tests/fixtures/clock_fit/RESULTS.md）。
• 0.40 のベンチマーク再キャンペーンは、所有者の承認を得て、実行の前に事前登録しました。A3（EXPLORATORY、agc_k_sigmaのフォルダークラスタリングによるブートストラップ AUC、2.5 % 分位点 0.8502、基準 0.80）、D3（EXPLORATORY、五つの検出器のうち三つが、スケール 0.25 で楽観ギャップ 0.05 を超える）、R3（AUC 1.0）、R4（P_fa 0.0、P_d 1.0）：すべて MET で、すべて MODELLED です。A2、D1、R1 には手を加えておらず、NOT MET のままです。ここにあるものは、それらを解消しません（xval/bench/RESULTS-0.40.md、Bench）。
• kshana partner check <submission.toml>：データパートナーの提出物の形式とメタデータ（kshana.partner-submission/1：デバイス、データファイルとその SHA-256、取得方法、提出する対象の MODELLED の行、ライセンス、記述）を検査し、エンジン自身のクロックログまたは IMU リーダーでデータを読み込みます。採点はせず、検証もしません。合成データの例はexamples/partner-submission/にあります。
• docs/PARTNER-DATA.md：測定データによって昇格しうる MODELLED の台帳の行、受け付ける形式、提出物をどう検査し、事前登録した合格基準に照らして採点し、評価に反映するか、そして PARTNER と VALIDATED がそれぞれ何を意味するか。所有者向けの働きかけ文書の草案はdocs/drafts/PARTNER-OUTREACH.mdにあります（何も送信していません）。
• gnss-ssvとlunar-infrastructureの未達だった合格基準に対する第二のキャンペーンを、事前登録のとおり実行しました（xval/gnss-ssv/PREREGISTRATION-v2.md、xval/lunar-infra/PREREGISTRATION-v2.md。いずれも実行の前に承認済み）。最初の未達はすべて NOT MET のままで、固定されています。gnss-ssv：対照実験は実行 1 をセルごとに再現します。単一の読み取りの五つのアブレーションにより、未達だった 78 セルのうち 2 セルが許容差に収まります（EXPLORATORY、合格基準なし）。新しい合格基準 S7b（Classic IIR パネルで当てはめた、ロールオフとフロアを持つ送信形状）は、IIR-M パネルで 3.83 から 3.95 dB となり、3 dB に対して NOT MET です。保留していた公開受信データによるキャンペーンは実行しませんでした（データ源が固定されていません）（xval/gnss-ssv/RESULTS-v2.md）。lunar-infrastructure：新しい合格基準 C3a、C3b（検出限界は約 3e-9 m/s2）、Q3a、Q3b（正確な正規分布の CDF により 1.7e-6 の差がなくなります）、G3'' は、それぞれの合格基準として達成し、例示的な事前分布を用いた G3' は達成して EXPLORATORY と記しています（xval/lunar-infra/RESULTS-v2.md）。すべて MODELLED のままです。新しい公開項目：kshana::lambda::{erfc_accurate, normal_cdf_accurate, bootstrap_success_rate_accurate}。
• 実行が書き出すすべての数値と表のエビデンスラベル。結果の JSON にはevidenceキーが、チャートの SVG にはメタデータ要素とプロットの下の一行が、CSV の表には# evidence:コメント行が付きます。内容は、ティア（VALIDATED、MODELLED、PARTNERのうち、行の中で最も弱いもの）と、その実行が依拠する検証マトリクスの行の ID です。行とステータスは手入力ではなく、マトリクスから読み取ります。ID は安定しています（VM-と十六進数 8 桁。docs/VERIFICATION-MATRIX.mdの新しいID列。tests/fixtures/evidence_ids.txtの固定リスト）。receiver-trust、jammertest score、iq acquire/sweep/track/monitor、経路の被曝レポート、そして署名されたconfig.jsonの内側にあるすべてのエビデンスパックにも付きます（config_version 1.1。kshana evidence verifyはティアを報告します。0.40 より前に作られたパックは変わらずに検証されます）。tests/evidence_labels_doc_sync.rsは、数値にラベルがない場合、ラベルがマトリクスと食い違う場合、新しいファイル書き出し処理にラベルも、理由を添えた登録もない場合に失敗します。ラベルを持たない出力はdocs/SURFACES.mdに挙げています。README の三つのデモチャートは、ラベル付きで描き直しました（ラベルを取り除くと、元のバイト列に戻ります。docs/revisions/STUDIO15-evidence-label-0.40.md）。主張は何も変わっていません。
• mission-threadシナリオ kind（scenarios/mission-thread-artemis-class.toml、docs/MISSION-THREAD.md）：打ち上げから再突入までの一連のフェーズの航法・時刻誤差バジェット。すべての数値は MODELLED で、すべての入力は明記されています。八つのフェーズ kind：launch-ascent、leo-rendezvous（センサー区間にわたる Clohessy-Wiltshire の相対共分散、ドッキング窓）、tli-and-cruise（有限差分の状態遷移行列を伴う Cowell 伝播、噴射誤差、gnss-ssvと地上追跡の更新、任意の DE440 カーネルの切り出しからの月）、entry（経路角のシグマ、回廊の確率、回廊の両端でのピーク減速度、着地フットプリント）、そして四つの月の kind です。引き継ぎ規則（carry、inflate、reacquire）、独立したバジェットの行としての座標系と時刻系の変換、各フェーズの追跡デューティを定める任意の地上ネットワークのオーバーレイ、明記した要求に対する余裕、最も弱い部分も備えます。この例は、公開されている NASA の運用構想のスライドの順序に従い、ILLUSTRATIVE な数値を用いた、11 フェーズにわたる、地球と月のセグメントを含む Artemis級のエンドツーエンドの例です。地球・月間空間の伝播は、公開されている Artemis I の軌道と 72 時間の弧で比較し、基準は実行の前にxval/mission-thread/PREREGISTRATION.mdで固定しました。結果はNOT MET です（5 km と 0.05 m/s に対して 45.3 km と 0.25 m/s）。診断は、未達の原因を、参照軌道にある五つの小さなインパルス的イベントに求めています。それらの間では、力モデルは 一時間ごとの状態を誤差の中央値 0.4 m で再現します。この行は MODELLED のままです（xval/mission-thread/RESULTS.md）。
• Artemis級のミッションスレッドの月のセグメント：四つのシナリオ kind で、それぞれmission-threadインターフェース（src/mission_thread/lunar/）のフェーズ kind でもあり、すべて MODELLED です。
  • lunar-orbit-rendezvous：100 km の円形極軌道、または 100 km × 3000 km の楕円極軌道でのドッキングまでの相対航法（scenarios/lunar-orbit-rendezvous.toml、...-elfo.toml）。弧にわたるバッチ Gauss-Newton 推定が、例示的な LCNS 級の中継衛星の組による各機の絶対測位解、（両機に共通のものと独立のものがある）持続的な信号空間の誤差、クロスリンクの距離を、クレートの月の力モデルのもとで融合します。目標の局所軸での相対位置と相対速度、測位解の可用性、期待値に対する平均の正規化推定誤差の二乗、重力調和項を無視した場合のコスト、信号のみの値と並べた終端の相対センサーモデル、そして引き継がれる 6x6 共分散を報告します。
  • lunar-descent：南極域の着陸地点での着陸分散バジェット（scenarios/lunar-descent.toml。lunar-descent-lola.tomlは LOLA DEM をチェックアウトから読み込みます）。軸ごとの五状態の慣性誤差モデル、AFS 測位解（単独、またはlunar-differential-pntの補正リンク残差を用いた差動）、地形相対測位解（合成起伏に対するterrain-navマッチャー、または LOLA DEM との照合のクラメール・ラオ下限）、そして機体のクロックを通じた月時刻（lunar-time-offset）。3 シグマの着地楕円、すべての補助の組み合わせ、楕円のモンテカルロによる較正を報告します。
  • lunar-surface：地点と季節ごとの測位と時刻の可用性（scenarios/lunar-surface.toml。lunar-surface-terrain.tomlは、レイマーチングした LOLA の地平線を加えます）。単一地点の測位の数値は、moonlight-service-volumeのものとビット単位で一致します。季節とともに変わるのは、解析的エフェメリスによる地球と太陽の可視性です。
  • lunar-ascent：ランデブー軌道への上昇と、軌道へ引き継がれる位置・速度共分散（scenarios/lunar-ascent.toml）。エンジン停止時の分散を併せて報告します。
  • docs/MISSION-THREAD-LUNAR.md。事前登録、その修正、未達を含むすべての結果は、xval/mission-thread-lunar/にあります。

エビデンス#

• 実行の前にxval/mission-thread-lunar/PREREGISTRATION.mdで事前登録しました。日付つきの六つの修正があります（修正 6 を除き、いずれもデータを取得する前に行いました。この修正は、取得の後、A2 の結果が出る前に、状態数の計算の誤りを訂正したものです。すべての修正はファイルで開示しています）。基準を緩めたものはありません。
• A1（JPL Horizons の再構成された LRO 軌道に対する伝播器、24 時間）：MET。3 次元の最大差は 33 m で基準の 500 m に対して、半径方向の RMS 差は 2.4 m で 60 m に対して満たしています。
• A2（同じ伝播器の、6.5 日の一周にわたる CAPSTONE NRHO に対する比較）：NOT MET。終端位置の差は 136.8 km で基準 25 km に対して、接触近点半径の差は 28.4 km で 10 km に対して未達です。この行は MODELLED のままで、未達はtests/mission_thread_lunar_oracles.rsで固定されています。
• B1（ランデブー推定の、自身のモデルとの整合性）は、四番目の推定器設計で MET で、平均 NEES は 5.85 から 5.93 となり、帯域 [5.2, 6.8] に収まります。それ以前の三つの設計（拡張カルマンフィルターの三つの変形）は未達でした。五番目の変更は、同梱の 2 時間のシナリオで 50 回の試行のうち 4 回が局所解に落ちる（平均 NEES 1e9）と分かった後に行ったもので、Gauss-Newton の当てはめを、ステップ半減を伴って弧を拡大しながら実行します。B1 はこれによって変わらず、同梱のシナリオでは 6.51 と 6.33 になります。履歴はxval/mission-thread-lunar/RESULTS.mdにあります。
• ここにあるものは、VALIDATED ではありません。オラクルの行が検証するのは共有する伝播器であり、航法フィルター、信号、バジェットではありません。

[0.39.0] - 2026-10-22#

新機能はありません。コマンドラインの修正が一件、クロスバリデーション用ツールの依存関係の更新、そしてドキュメントです。エンジンの結果は 0.38.0 から変わりません。

修正#

• 標準出力が閉じられたとき（kshana kinds | head）、コマンドラインは「failed printing to stdout: Broken pipe」でパニックする代わりに、ステータス 141 で静かに終了します。141 は 128 に SIGPIPE を加えた値で、シェルが yes | head について報告するステータスです。処理するのは閉じられたパイプのみです。ディスクがいっぱいの場合やその他の書き込みエラーは従来どおり報告され、閉じられたソケットに書き込むライブフィードも書き込みエラーを受け取ります。tests/cli_closed_pipe.rs はプログラムの開始前に読み取り側を閉じるため、最初の書き込みはどの実行でも失敗します。

セキュリティ#

配布ライブラリの依存関係の更新が1件（先頭の項目）、残りはクロスバリデーション用ツール（xval/）です。

• p256、p384、p521 を 0.13 から 0.14 へ（elliptic-curve 0.14.3、ecdsa 0.17.0、crypto-bigint 0.5.5 から 0.7.10 を伴う。直接の crypto-bigint 依存関係も 0.7 になりました）更新すると、crypto-bigint 0.5.5 のタイミング変動である RUSTSEC-2026-0387 が解消されます。Kshana がこれらのクレートを使うのは公開署名（Galileo OSNMA のルート鍵と RFC 3161 のタイムスタンプトークン）の検証のみで、署名を行うのは使い捨て鍵を用いたテストだけであるため、実際の露出はありませんでした。この更新により、無視エントリなしでアドバイザリーが解消されます。ライブラリと MCP のロックファイルはどちらも更新され、検証結果は変わりません（OSNMA とタイムスタンプのベクトルテストは変更なしで合格します）。
• サポートされる最小の Rust は 1.88 になりました（RUSTSEC-2026-0387 の修正に必要です）。
• ANISE クロスチェックのロック（xval/anise-lunar-od、xval/anise-mars-od）で memmap2 を 0.9.10 から 0.9.11 へ更新（RUSTSEC-2026-0186）。ロックは、リポジトリ内の kshana のパス依存関係も再同期します。
• オラクル環境のピン（xval/oracles/requirements.lock、requirements.frozen.txt）で、pillow を 12.3.0 から 13.0.0 へ、certifi を 2026.7.22 から 2026.10.19 へ更新：pillow の八件のアドバイザリーと certifi の一件のアドバイザリーに対する修正版です。

ドキュメント#

• docs/BENCH.md、README、およびこのファイルは、xval/bench/RESULTS-v2.md に記録されているとおり、NOT MET となっている kshana-bench の合格基準をすべて挙げています：A2（テスト分割で、agc_k_sigma の AUC は 0.766、合格基準は 0.80 以上）、D1（最大のギャップは 0.0301）、タスク (b) の R1（引き継ぎ、再実行なし）。緩めた合格基準はありません。
• README の網羅性の改善：目次、ファミリーごとに分類したシナリオ種別（それぞれに docs/kinds/by-kind/ 以下のページがあり、エンジンの説明とフィールド、サンプル実行の入力と結果、台帳の行とオラクル、実行のレポートが述べる制約、エンジンが書き出すグラフを掲載）、ファミリーごとのコンタクトシート（すべて docs/KINDS.md で索引化）、docs/COMMANDS.md のすべてのコマンド、docs/ALL-SURFACES.md のすべてのサーフェス、プラグインコマンド、スキル、Studio のページ、docs/CAPABILITY-DOMAINS.md のすべての機能領域、埋め込んだ Mermaid 図（システム概要、サーフェス、内部ループ、受信機の信頼性、ラボのラウンドトリップ、Studio、テストとリリースのフロー、モジュールマップ、配布）です。tools/gen_kinds_index.py、tools/gen_readme_blocks.py、tools/gen_figures_038.py が生成し、tools/readme_audit.py が監査し、tests/readme_completeness_doc_sync.rs が保護します。これは、すべてのエントリーの説明とフィールドをエンジンに固定する役割も持ちます。
• tools/render-diagram-chromium.sh：Linux で Mermaid 図を SVG と PNG にレンダリングし、レンダリング記録を更新します。
• README：宇宙ユーザーと月面の図が docs/ からの相対パスを使っていたため、README から読み込めませんでした。また、あるリンクが ../../docs/JAMMERTEST.md を指していました。
• どのページも使っておらず、エンジンの出力ともう一致していなかった、手作業でコピーした古いグラフファイル二つ（docs/assets/clock-ensemble-band.svg、sweep-clock-stability.svg）を削除しました。現在のグラフは docs/KINDS.md にあります。

[0.38.0] - 2026-10-19#

追加#

• コンステレーションを超えた GNSS（gnss-ssv）。GNSS 軌道の上、周辺、その先にある宇宙機のための新しいシナリオ種別です（docs/SSV.md）：GPS、GLONASS、Galileo、BDS、QZSS、NavIC について、シェル上、または LEO、MEO、GEO、HEO、月遷移の軌道に沿った、一つの信号と四つの信号の可用性、途絶時間、C/N0、DOP、およびメインローブ対サイドローブのリンク。ブックレット、パラメトリック、またはユーザー提供の送信パターン。リムレイの電離圏、プラズマ圏、大気のモデル。微弱信号向けの受信機設計。HEO と月遷移向けの機上 GNSS 拡張カルマンフィルター。編隊の相対航法。ICG の Space Service Volume ブックレットと、実行前にコミットした事前登録のもとで比較しました。最小放射電力の定数と月の合格基準は一致し、その他の合格基準は事前登録した読み方では満たされず（ほとんどがブックレットの GLONASS ビーム角の不整合によるもの）、パラメトリックなサイドローブの代用は、測定された GPS パネルのパターンを再現しません。すべて MODELLED のままです（xval/gnss-ssv/RESULTS.md）。
• 航法および測地インフラとしての月の軌道と表面（lunar-infrastructure）。study で選択する五つの研究を持つ新しいシナリオ種別です（docs/LUNAR-INFRASTRUCTURE.md）：近直線ハロー軌道での機上 Earth-GNSS 軌道決定の、独立した地上のレンジとレンジレートの決定に対する整合性。地表局と周回機の二重差搬送波位相を、LAMBDA による整数値の決定で結合したもの。軌道上から地表へのレンジあり・なしでの、七パラメーターの月測地系のフィッシャー情報。GNSS、VLBI、レーザー測距の技術間オフセットと局所タイとの比較。h2、k2、l2 および物理秤動に対する感度。MODELLED で、入力はILLUSTRATIVEなものです：数値は独立した numpy と scipy のプログラムと照合しており、月の量の測定とは何も比較していません。合格基準は xval/lunar-infra/PREREGISTRATION.md と、開示した二つの修正で固定しました。三つが NOT MET で、それぞれ不達成を表明するテストで固定してあります：C3（注入した力の誤差が、事前登録した率では検出されない）、Q3（ブートストラップした成功率が、LAMBDA の正規 CDF の近似に起因して、合格基準 1e-9 に対し numpy のオラクルと 1.7e-6 異なる）、および G3 のトレース側（測距ファミリーを加えても、擬似逆行列のトレースが常に下がるとは限らない）。残りは満たしています（xval/lunar-infra/RESULTS.md）。
• 研究表の六本目の論文。「Cislunar navigation is an observability problem: arc-length thresholds, Gramian conditioning, and the Doppler lever」（arXiv:2610.23871、eess.SP）は、レンジのみの地球・月間空間（シスルナー）追跡では精度低下率が定義できないことを示し、代わりに四つの平面の遠方逆行軌道に対する可観測性グラミアンを用いています：レンジのみではスナップショットでランク 2（最大 4）で、約 2.09 時間の弧が必要です。レンジレート（ドップラー）は即座にランク 4 を与え、局を衛星の状態とクロックと同時に推定すると、外部の干渉計観測量がない限り、ランク不足が一つ残ります。その数値は cislunar-observability 種別（kshana scenarios/cislunar-observability.toml）で再生成され、cislunar-arc-recovery は独立した推定器でしきい値を試験します。README の研究カード、crates、npm、PyPI の README、およびジェネレーターに掲載しています。
• 中立の審判を、測れるものに。 kshana jammertest import は、公表されている NPRA Jammertest のカタログと送信計画を、予定された真値として読み込み（カタログ ID は保持）、kshana jammertest score は受信機ログをテストごとに採点します（検出レイテンシ、見逃した警報、誤警報、回復までの時間）。署名付きエビデンスパックとして出力することもできます（docs/JAMMERTEST.md）。採点の合格基準は、採点した実行より前に事前登録しました（xval/jammertest-score/）。JammerTest 2024 のデータセット（取得し、同梱はしない）では、事前登録した最小データ規則が最初の実行でもデータの扱いを改めた版でも満たされなかったため、評価できる合格基準はなく、何も主張しません。どちらの実行も記録し、固定してあります。MODELLED：スケジュールはデータセットの記録済みウィンドウであり、実際の放送時刻の記録ではありません。2025 の SimulaMet NMEA セットは対応していません（そのページにライセンスの記載がないため）。
• 受信機自身のフラグを、Kshana のものと並べて。UBX-NAV-STATUS の spoofDetState と UBX-SEC-SIG をエポックごとに self_report に読み込み、結果の receiver_self_report の比較が、それらを Kshana のモニターと対比します（両方、受信機のみ、Kshana のみ、どちらでもない）。警報は出さず、スコアも変えません。Septentrio SBF リーダー（PVTGeodetic、MeasEpoch、RFStatus、読み取り専用で、MIT ライセンスの sbf-tools クレート上）と receiver-trust live --serial（シリアルまたは USB の NMEA フィード、読み取り専用で、受信機には書き込みません）がこれに加わります。
• タイミングとハードウェアの安全性（docs/TIMING-HIL.md、docs/HARDWARE-SAFETY.md）。holdover-test シナリオ種別は、測定した時刻誤差の記録から、タイミングシステムのホールドオーバー試験（運用者が GNSS を取り外し、ホールドオーバー、回復）を、公開されている表の ITU-T マスクに照らして採点します。clock_log は linuxptp（ptp4l、phc2sys、ts2phc）と chrony（tracking、statistics）のログを読み込みます。iq scene --format sdrx は ION の GNSS SDR メタデータを書き出し、iq monitor --follow は SigMF の記録を、それが増えている間も監視します（受信のみ）。compliance-report に NIST IR 8323r1 Foundational PNT Profile（言い換えた行が 15 件、〜の証拠を裏付ける（supports evidence for））が加わりました。エビデンスパックは、運用者の lab-attestation を署名付きマニフェストに記録できますが、検証はされません。ハードウェアのステージ 0 から 4 と法的な注記は HARDWARE-SAFETY.md にあります（法務レビュー待ち）。いかなる種類の送信経路もありません。
• kshana-bench v1（kshana bench、bench/SPEC.md、docs/BENCH.md）：受信機ログ（JammerTest 2024）と IQ に対する GNSS 干渉検出、タイミングのホールドオーバー予測（IGS クロック）、および分布外の楽観ギャップのための、固定されたタスク、分割、指標です。固定したハッシュ付きの分割マニフェストと取得スクリプト（データは同梱しない）、コミットと公開による封印したホールドアウト、結果ファイルのスキーマ、静的なリーダーボードページを備えます。xval/bench/PREREGISTRATION.md で事前登録した合格基準によるベースライン：スコアラーの合格基準は満たし、C1 から C3 は満たし、D2 は満たしました。A2 は NOT MET（テスト分割で、agc_k_sigma の AUC は 0.766、合格基準は 0.80 以上）、D1 は NOT MET（最大のギャップは 0.0301）、タスク (b) の R1 は NOT MET（引き継ぎ、再実行なし）で、それぞれ固定してあります（xval/bench/RESULTS-v2.md）。すべてのスコアは MODELLED です。Python は bench_score、bench_leaderboard、WebAssembly も同じ、MCP は score_benchmark、render_leaderboard です。
• 干渉オブザーバトリー（kshana interference-map daily、sensitivity、docs/observatory/METHOD.md）：再現可能な日次の GeoJSON、PNG、インシデントレポート JSON で、三つの状態（degraded、not degraded、not observed）、最小 24 時間の遅延、0.5 度以上のセル、原因の特定なし、OpenSky データは拒否。事前登録したパラメーターの感度研究。adsb.lol によるバルト海の 30 日分のバックカタログ。
• receiver-trust のためのマシンおよびセンサーの入力（docs/MACHINE-INPUTS.md）。新しい [log] format の値で、すべて読み取り専用、MODELLED で、フィクスチャーは自作、データは同梱しません：rtklib-pos（RTKLIB の .pos 解ファイル）、novatel（OEM7 の ASCII とバイナリの BESTPOS、RANGE の C/No、RXSTATUS。受信機のジャマーフラグはそのエポックの self_report になり、receiver-self-report の比較で Kshana の警報と対比される）、rtcm3（GPS、GLONASS、Galileo、SBAS、QZSS、BeiDou、NavIC の MSM4 と MSM7 の C/N0。レイアウトは RTCM 規格ではなく、BSD ライセンスの pyrtcm の表によるもので、その通知は NOTICE にある）、gnss-sdr（GNSS-SDR の Monitor と PVT モニターのメッセージを JSON 行にしたもので、integrations/gnss-sdr/relay.py が中継）。
• 二つ目のセンサーとしての IMU ログ。 [log.imu]（csv または euroc）は、ジャイロのヨーレートを heading-course モニターが読む方位に積分します。すべてのサーフェスでインラインで使え、エビデンスパックにも引き継がれます。kshana imu-fit（Python の imu_fit、WebAssembly の imu_fit、MCP の fit_imu_log、プラグインの /kshana-fit-imu、JetBrains のアクション）は、静止ログからアラン偏差によって hybrid と fusion のシナリオの加速度計とジャイロのパラメーターをフィットし、出所にそのログの SHA-256 を記した [accel_classical] の表を出力します。
• 統合：ROS 2 パッケージ（integrations/ros2/kshana_trust：NavSatFix と ublox_ubx_msgs を入力、信頼のトピックを出力。ROS を使わないブリッジは実際のエンジンに対して試験済みで、ノード自体は稼働中の ROS グラフでは実行していません）、gnss_lib_py ブリッジ（integrations/gnss_lib_py、MIT の依存関係、任意）、および GNSS-SDR のリレー。
• 信頼テレメトリ向けの Home Assistant MQTT エクスポーター：kshana trust-telemetry --print-mqtt と --mqtt-tcp <host:port>（ディスカバリーメッセージと JSON の状態ドキュメント。公開のみで、認証情報も TLS もなし）、および Python、WebAssembly、MCP でテキストとしての format = "mqtt"。
• 上記に対する、MODELLED の台帳の行が七件です。ここに VALIDATED のものはありません：実際の受信機、基準局、IMU、GNSS-SDR の実行、ROS グラフ、MQTT ブローカーからのキャプチャーは、一つも読んでいません。
• 時間に対する光リンクのマージン。optical-atmosphere 種別は、オプトインの [timeseries] テーブル（duration_h、step_s、seed）を受け付け、その場合は、サイトごとに、定めたサイトモデルのシード付きの実現を時間方向に一つ書き出します：雲のエピソード、エピソードごとの液体水の柱、ステップごとに一つのガンマ・ガンマシンチレーションのサンプル、そしてそれらから、リンクマージン、雲とシンチレーションのフェージング、リンクアップのフラグ、および実現した可用性、雲の割合、途絶の回数、最長の途絶です。MODELLED（モデルからの一回の抽出であり、気候ではありません。外部のオラクルはありません）。このテーブルがなければ、結果は 0.37 のドキュメントのままです。同梱の二つの光シナリオには、このテーブルがあります（336 時間、600 秒、シード 37）。合格基準は、最初の実行の前に xval/optical-atmosphere/PREREGISTRATION-timeseries.md で事前登録しました。
• 試験条件の仕様と、ラボのラウンドトリップ。 kshana.test-conditions/1 は JSON Schema とともに docs/spec/TEST-CONDITIONS.md として公開され、recording.kind = "receiver-log" が加わりました。kshana bench-export は <base>.conditions.json も書き出します。kshana evidence round-trip は、シナリオのハッシュ、記載した条件のハッシュ、受信機ログのハッシュ、および記載したイベントに対するスコアを結び付けた署名付きパックを作り、採点イベントと食い違う条件を拒否します。gps-sdr-sim でファイルのみを書き出す実例があり、再生は運用者の責任であり、自動化されることはありません。Python は evidence_round_trip、MCP は create_round_trip_pack、プラグインは /kshana-evidence-pack です。
• 標準パック（kshana standards-pack、standards/）：レベル 1 から 4 の DHS Resilient PNT フレームワークのテストプロファイル、IMO MSC.1/Circ.1575 の精度レベルとインテグリティ評価、ICAO Doc 9849 Appendix F の監視、評価、緩和で、それぞれ実行前に定めた合格基準に照らして採点するシナリオの集合であり、それらが証拠を裏付ける（supports evidence for）compliance-report の行を伴います。未達成は記録し、固定しています：DHS L4-T1 と、IMO の四つの精度テスト。Doc 9849 自体は読んでいません（有料）。ICAO のパックは ICAO 自身の RFI Mitigation Plan の発表資料に従っています。compliance-report に標準パックの節が加わりました。すべて MODELLED です。
• LunaNet Augmented Forward Signal（docs/LUNANET-AFS.md）：PRN 1 から 210 の AFS-I の Gold 符号と AFS-Q の Weil 符号、kshana iq の信号 lunanet-afs-i と lunanet-afs-q、SB1 の BCH 符号、CRC-24Q とインターリーバー、および kshana lunanet-afs-check（spec、symbols、generate）で、LNIS V5 Applicable Document 1 Volume A（LSIS-AFS V1.0、29 January 2025）に固定しています。符号は、文書に印刷された表（文書は TBC と記載）に対して VALIDATED です。印刷された三次符号の列のうち一つ（PRN 147）は誤植の可能性が高く、その不一致は固定してあります。サブフレーム 2 から 4 の LDPC 符号化は未実装です。
• コース用ノートブック（notebooks/course/）：ジャミング、スプーフィング、ホールドオーバー、インテグリティ、OSNMA、干渉マップで、それぞれに演習があります。
• EU-US WG-C ARAIM Milestone 3 の最大 URA の研究（xval/araim-m3/、src/bin/gen_araim_m3_study.rs）。撤回された「Table A-3」の計画に代わるものです。明示した逸脱のもとで MODELLED です。
• docs/drafts/ 以下のオーナー承認待ちのドラフト：JOSS の論文、TSC 憲章の修正、オラクル登録プロセス、および LICENSES/ の分割案。ここにあるものは、何も採用されていません。
• 0.38 の機能向けの Studio ビュー（kshana.dev/studio/）。ブリッジのリプレイ（同じクロック上の二つの合成実行：軌跡、信頼スコア、ログが聞き取る衛星、判定。受信機自身のフラグを Kshana の警報と並べて表示）。光 PNT（optical-atmosphere の二つのシナリオ。オプトインのシード付き [timeseries] の実現を含み、MODELLED）。ホールドオーバー試験（ITU-T マスクに照らして測定した holdover-test の結果。結果自身の record.series から描画）。あなたが生成したファイルを開き、自身では何も同梱しない干渉オブザーバトリーのビューア。ツールのページには、Jammertest スコアラー、IMU のフィット、およびテレメトリ形式としての MQTT。Trust には、ログ形式の選択（RTKLIB の .pos、NovAtel OEM7、RTCM 3、GNSS-SDR、Septentrio SBF）と、任意の IMU ファイル。すべてのビューはブラウザー内でファイルを読み、何もアップロードしません。すべての数値は台帳がそれに付けているラベルを保持し、それぞれが助言の文言を伴います。/benchmark のサイトページは kshana bench leaderboard のフラグメントを表示します。

修正#

• Issue #36：バイト単位で厳密なピンの層。バイト単位で厳密なピンの層は、ベースラインと宣言されたホスト（KSHANA_EXACT_PINS=1、scripts/gate.sh で設定）でのみ実行し、すべての Apple シリコンの Mac では実行しません。Apple の数学ライブラリは macOS のリリース間で異なるためです。ポータブルな層はどこでも実行され、tests/exact_pin_gate_guard.rs は、バイト単位で厳密な層がプラットフォームのみでゲートされることが再び起きるのを防ぎます。オラクルとの比較自体は macOS で合格します。リテラルの取り直しはなく、許容差の変更もありません。scripts/oracle-triage.sh と docs/LOCAL-ORACLE-TESTS.md が、差異の切り分け方を説明しています。.github/workflows/oracle-macos.yml は手動かつ週次の診断であり、ゲートではありません。
• CodeQL：Studio の trust-open ヘルパーにおけるアンカーのないパターンが、ヘッダー全体にマッチするようになりました（web/studio/lib/trust-open.mjs）。
• CI：ランナーのディスク。check ジョブは、dev と test のプロファイルをデバッグ情報なしでビルドするため、リンクでディスクがいっぱいになることはなくなりました。
• ソースのガード。ピンを持つテストフィクスチャーを保持するすべてのソースファイルは、そのピンの範囲を宣言し、一時ファイルを書き出すテストは、呼び出しごとに一意のパスを使うため、並列実行で衝突することはありません。
• docs/SCENARIOS.md は、optical-atmosphere の任意のフィールド timeseries に合わせて再生成されました。
• JetBrains プラグイン：非推奨または削除予定のプラットフォーム API を使っていません。IntelliJ IDEA のビルド 263（2026.3：263.6800.24 と 263.7031.23）に対する IntelliJ Plugin Verifier（verifyPlugin）は、Insert Example で非推奨の呼び出し FileEditorManager.openFile を一件見つけました。現在は OpenFileDescriptor で新しいファイルを開きます。プラグインは 2024.3（since-build、変更なし）と 263 の両方のビルドと互換性があり、問題はありません。CI は verifyPlugin を実行し、互換性の問題と、削除予定の API の使用があれば失敗します。

[0.37.0] - 2026-10-17#

追加#

• 大気を通した光 PNT（optical-atmosphere のシナリオ種別、docs/OPTICAL-ATMOSPHERE.md、設計メモ docs/design/optical-atmosphere-0.37.md）。光リンクと地上サイトの組について、波長と仰角に依存する晴天時の損失、Hufnagel-Valley の乱流状態（Rytov 分散、シンチレーション指数、ガンマ・ガンマのフェージング、開口平均化）、定めた雲の気候から求めたリンクマージンに対する可用性、目標の可用性に必要なマージンと、どのマージンでも超えられない上限、途絶時間の分布、クロックのホールドオーバーモデルによる途絶ごとのタイミングと測距の誤差、距離相関のあるサイトダイバーシティ、そして波長の変更、より大きな開口、補償光学によるシンチレーション低減、追加マージンについての what-if の利得を報告します。optical_linkbudget には大気を考慮したバジェットが加わり、それがなければ出力は 0.36 とビット単位で同一です（合格基準 A5）。同梱の二つのシナリオには、ILLUSTRATIVEな雲の気候があります。MODELLED：台帳の行は三つです。数値は、xval/optical-atmosphere/PREREGISTRATION.md で事前登録した合格基準 A1 から A6 を、独立した mpmath プログラムに対して満たします。これが確認するのは定めた式の実装であって、大気ではなく、測定された可用性の記録とは比較していないため、VALIDATED の行はありません。A4 の合格基準は、使用していた正規 CDF が 1.5e-7 の近似だったために、最初は 3e-9 だけ外れました。CDF を置き換え、合格基準は登録したままにしています。ネイティブ版と WebAssembly 版は、同梱の両方のシナリオについて、バイト単位で同一のドキュメントを返します（A7、0.37.0 の統合コミットで実行）。

[0.36.0] - 2026-10-16#

追加#

• IQ モニターの検出 ROC（PRO-32、docs/design/DETECTION-ROC.md）。モニター付きのキャンペーンは、各検定統計量の最大値を、定めたイベントのウィンドウ（陽性）と、イベントの外のタイル状のウィンドウ（陰性、roc_window_s）で保持します。レポートはそれらを警報の種類ごとに集計して ROC にし、その AUC と、設定されたしきい値での動作点を、roc.json とレポートの節として出力します。合成キャンペーンでは、偶然水準の確認を満たしました。C/N0 の AUC の合格基準（0.95）は満たされず（0.79）、これは、イベント直後の陰性ウィンドウが、検出から CUSUM の減衰を引き継ぐためで、記録しています。MODELLED です。

• ラボリプレイのキャンペーンにおける IQ モニター（PRO-31、docs/design/MONITORS-IN-CAMPAIGN.md）。キャンペーンファイルの任意の [monitors] テーブルは、ランナーの一回の処理で IQ モニターを実行します：各フロントエンドチェーンの後での電力とスペクトル、および追尾チャネルごとの C/N0、SQM、ロック。それらの警報を、定めたイベントに対して採点します：検出または見逃し、検出までの時間、露出一時間あたりの誤警報です。各テストの閉形式の誤警報の値を示し、これには SQM テストの両側ガウス分布の新しい値（2Q(k)）を含みます。テーブルがなければ何も変わりません。合成キャンペーンでは、電力と SQM の誤警報の合格基準と C/N0 の誤警報の合格基準を満たしており、18 件中 18 件の減衰が検出されますが、構成上、検出器の一つのサンプルより小さい検出時間の上限は満たされず、記録しています。MODELLED。台帳の行「ラボリプレイのキャンペーンで採点した IQ モニター」。

• IQ キャンペーンからのラボフィット、フォローアップ（tests/iq_labfit_followup.rs、CI ジョブ labfit-iq-followup）。docs/design/LABFIT-FROM-IQ.md の §13.6 が未解決のままにした二つの仮説を、1e532f84 で事前登録した合格基準に照らして試験します。二つの合成キャンペーンを加えます：段階的な J/S を持つ S（シード 2026_1014）と、新しいランプの R（シード 2026_1015）です。結果は docs/design/evidence/labfit-followup/RESULTS.md にあります。

  • S1 は満たしました：各 J/S レベルを保持した状態で、δ_eff は +0.185 dB 以内で復元されます。ランプのキャンペーンの −1.1 dB の誤差は、推定器の遅れです。
  • S2 は満たされず、不達成を表明するテストで固定しています：段階的なキャンペーンでの (d) は、記述どおりには追尾ループモデルでは成り立ちます（0.45 dB）が、経験的なモデルでは成り立ちません（6.42 dB）。
  • R1 は満たしました：新しいランプのキャンペーンで、フィットしたドロップの滞留時間に各イベントのランプレートを掛けて加えた (d) は、両方のモデルで 1 dB 以内です。
  • (a′) と (d) の不達成は R でも再現します。
  • キャンペーンは、テストハーネスで J/S を step のプロファイルとして記述できるようになりました。
  • §13 の判定は何も変わらず、台帳の行は MODELLED のままです。

• 上限付き FLL プルイン、オプトイン（DS-LOOP-05）：新しいループ設計キー [design.carrier] fll_pull_in_max_s（秒）、Rust では LoopConfig::fll_pull_in_max_s。fll_assist = "pull-in" のもとで、その時間が経過した後、PLI にかかわらず FLL から PLL への引き継ぎを強制します。デフォルトでは未設定で、その場合は設計ハッシュの対象外です。デフォルトの設計とそのハッシュは変わりません。

  • 注入した真値に対して、58789af0 で事前登録した合格基準に照らして確認しました。コントロールは満たしました：デフォルトは、33 dB-Hz では 10 個のシード中 9 個で引き継ぎません。
  • 満たされず：1.0 秒の上限では、33 dB-Hz で 20 回中 16 回、31 dB-Hz で 20 回中 8 回がロックを保持します。残りは、強制的な引き継ぎと FLL の戻りの間を循環します。位相ジッターは、33 dB-Hz で PLL のみの場合の 1.8 倍です。
  • 約 35 dB-Hz のプルイン下限は、デフォルトの文書化された限界のままです。
  • MODELLED。台帳の行「既定設計の FLL から PLL への引き継ぎの下限を下回る領域での、上限付き FLL プルイン（オプトイン）」。

• ジャミング種別における捕捉ヒステリシスとフロントエンドの量子化器（CAP-06c）：jamming シナリオ向けの二つの任意のセクションです。

  • [acquisition]：acquisition_threshold_dbhz（dB-Hz、追尾しきい値以上）と reacquisition_delay_s（秒、デフォルトは 0）。衛星は、遅延の間、未捕捉であった後に、捕捉しきい値以上で捕捉されます。追尾しきい値以上である間は保持されます。出力：epochs[].sats[].acquired（true/false）、epochs[].acquired（個数）、fom.availability_acquired（1）。
  • [front_end]：adc_bits（1 から 16）と bandwidth_mhz（MHz、デフォルトはチップレートの二倍）。front_end ブロックを出力します：agc_gain_reduction_db（dB、10·log10(1 + J/N)）、quantiser_loss_db（dB、すべてのリンクの実効 C/N0 から差し引く）、loss_model。損失はガウス入力のもので、CW、狭帯域、掃引ジャマーには有効でないと明示されます。
  • セクションがなければ、すべての出力はバイト単位で同一です。
  • 70c72fcc で事前登録した合格基準に照らして確認しました。量子化器損失は独立したモンテカルロと 0.0007 dB 以内、AGC の読みは IQ 層の AGC ループと 0.012 dB 以内です。
  • 登録したヒステリシスの実行は有益ではなく（すべてのリンクがロスト状態）、その合格基準は NOT MET です。37793290 で登録した補足の実行セットはこれを満たしています：すべてのフラグが独立した再計算と等しく、1824 件のリンクのうち 732 件でヒステリシスが現れました。
  • 所見：CW ジャマーでは、1 ビットの ADC はガウスの値より約 5 dB 余分に損失します。
  • MODELLED。台帳の行「ジャミング種別の捕捉ヒステリシスとフロントエンドの量子化器を、独立した再計算と照合」。

• ジャミング種別におけるジャマーの地形による遮蔽（CAP-06b）：ジャマーのある jamming シナリオにおける、任意の [terrain] セクションです。フィールド：

  • dem_hgt：SRTM の .hgt タイル（作業ディレクトリからの相対パス）。
  • samples_per_side、ll_lat_deg、ll_lon_deg（度）：タイルのサイズと隅。
  • geoid_undulation_m（m、デフォルトは 0）、k_factor（デフォルトは 4/3）、profile_step_m（m、デフォルトは 30）。

  エンジンは、ジャマーと受信機の間の大圏の地形プロファイルをサンプリングし、支配的なナイフエッジを見つけます。ジャマーの受信電力、したがってすべての J/S は、ITU-R P.526-15 §4.1 の単一ナイフエッジ損失の分だけ下がります。

  • 結果に jammer_terrain ブロックが加わります：nu_max（1）、diffraction_loss_db（dB）、obstacle_distance_m（m）、obstacle_terrain_m（m）、path_length_m（m）、profile_points（個数）。
  • セクションがなければ、すべての出力はバイト単位で同一です。
  • 92cd2bfd で事前登録した合格基準と十か所の配置に照らして、コミット済みの実際の Death Valley の SRTM タイルで、独立した numpy での再計算と照合して確認しました。すべて満たしました：ν と損失での最悪の差は 1.6e-10（合格基準は 1e-9）、損失はジャマーの高さに対して単調で、損失は J/S をちょうどその分だけ下げます。
  • MODELLED。台帳の行「ジャミング種別におけるジャマーの地形による遮蔽を、実際の SRTM タイルでの独立した numpy 再計算と照合」。

• ジャミング種別の CRPA アンテナ利得（CAP-06a）：jamming シナリオの任意の [crpa] セクションです。フィールド：elements_enu_m（局所の東・北・上でのアンテナ素子の位置、m）、weighting（"null-steering" または "mvdr"）、bandwidth_mhz（MVDR の雑音帯域幅、MHz、デフォルトはチップレートの二倍）。

  • 各チャネルは、自らの衛星に向けて歪みのないビームを形成します。リンクの雑音は ‖w‖² で、ジャマーは |wᴴa_j|² で、既存の耐ジャミング C/N0 の式の前にスケーリングされます。
  • 各リンクに crpa ブロックが加わります：array_noise_gain_db（dB）と jammer_gain_db（dB）。
  • セクションがなければ、すべての出力はバイト単位で同一です。
  • 無効なセクション（空の素子リスト、未知の重み付け、正でない帯域幅）は、jamming::run_jamming だけでなく kshana と api::run_toml を通してもエラーになります。
  • 08d83b4d で事前登録した合格基準に照らして確認しました。満たしたもの：加法性（修正後：最初のビルドでは、新しい単位をすべてのジャミング実行の単位表に追加していました）、一素子は配列なし、雑音利得と実効 C/N0 は独立した numpy での再計算と 1e-9 dB 以内、MVDR は高い JNR でヌルに近づきます。
  • 満たされなかったもの：0.36 のポータブル数学では 456 件のリンクのうち 194 件で MVDR のジャマー利得（ホスト数学では 202 件。docs/revisions/STUDIO15-batch4-rebaseline.md）（最悪 1.7e-6 dB）。−100 から −188 dB の残差は、その合格基準では float64 の分解能を下回っており、numpy 自身も同程度に食い違います。
  • MODELLED。台帳の行「ジャミング種別の CRPA アンテナ利得を、独立した numpy での再計算と照合」。

• IQ 追尾エンジンを GNSS-SDR 0.0.19 と照合（PRO-33）：kshana iq track と GNSS-SDR は、30 から 45 dB-Hz の GPS L1 C/A の同じ独立した numpy 記録データを追尾します。

  • 合格基準は 48edd4a5 で事前登録しました。登録した較正は GNSS-SDR の誤った引き継ぎ（F3）で失敗したため、修正 1（1e4288c4）で、プルイン時のみの FLL を両方の受信機に追加し、どの試験記録よりも前にコミットしました。
  • 満たしたもの：搬送波とコードのジッターとドップラーは、すべての C/N0 で 5 % 以内で一致します。
  • 満たされなかったもの：エンジンの NWPR C/N0 は GNSS-SDR の SNV より 2.3–7.1 dB 低く読めます（F4、既知の推定器の限界。M2M4 は真値から 0.06 dB 以内）。ロック指標は定義が異なります（F5）。30 dB-Hz でのスリップの不一致が一件あります（F6）。
  • MODELLED。台帳の行「IQ 追尾エンジンを、独立した記録データ上の GNSS-SDR 0.0.19 と照合」。

• IQ 層のコードについての、二つの VALIDATED の行（DS-GIQ-06b、PRO-39）。

  • BeiDou B1I。63 個すべての B1I 主コードが、GNSS-SDR v0.0.19 の独立した生成器とチップ単位で一致します（合格基準は 911106d1 で事前登録）。コミットしているのはそのプログラムの出力のみで、公開 ICD が定義する B1I の PRN コードを、先頭部分とハッシュで保持します。
  • GPS L1C。126 個すべての L1CP/L1CD コードと 63 個の L1CO オーバーレイが IS-GPS-800J の印刷するチェック列と一致し、計算したルジャンドル系列は Table 6.2-1 と一致します（合格基準は fe372e26 で事前登録）。
  • 行：「BeiDou B1I の主測距コードを、独立した生成器と照合」と「GPS L1C の測距コードとオーバーレイコードを、IS-GPS-800J に印刷されたチェック列と照合」。

• スペクトルモデルにおける GLONASS、BeiDou、Galileo E6 のバンド（CAP-12、信号）：新しいバンド名 glonass-l1of と glonass-l2of（任意の FDMA チャネルを glonass-l1of-k<K> として、K = −7 から 6）、beidou-b1i、beidou-b1c、beidou-b2a、beidou-b3i、galileo-e6。それぞれが ICD の搬送波、変調、最小受信電力を持ちます。名前によるオプトインで、デフォルトのバンドセットと既存の出力は変わりません。

  • 5806f28b で事前登録した合格基準に照らして確認しました：ICD の値、零点、B1C の合成、C/N0 の経路は満たしています。
  • 二つの合格基準は満たされませんでした。単位面積の基準は、記載のままでは達成不可能でした（F1）。IQ 層の B1I と B1C の波形がモデルと一致するのは、コードの線スペクトルが不均一なため、帯域平均した場合のみです（F2）。
  • MODELLED。台帳の行「スペクトルモデル：GLONASS、BeiDou、Galileo E6 の各バンド（オプトイン）」。

• IQ 捕捉におけるセル平均 CFAR オプション（PRO-37）：iq::acq::ca_cfar と ca_cfar_cells は、捕捉グリッド上で、各セルをそのドップラー行の参照セルの平均と比較して判定します。しきい値は、M 個の非コヒーレントブロックに対する閉形式の CA-CFAR 誤警報確率（ca_cfar_pfa、ca_cfar_alpha）から決まるため、判定はサンプル電力の正規化に依存しません。オプトインで、デフォルトの検出器と既存の出力は変わりません。

  • 3724aefa で事前登録した合格基準に照らして確認しました：閉形式をモンテカルロと照合（18 件中 18 件）。設計値 1 % は、ガウス雑音と 2 ビット量子化雑音で 0.97–1.01 % と測定されました。
  • 一つの合格基準は満たされませんでした：雑音のない 2 ビット信号では、ピーク以外のセルの 1.28 % が、コードの相関サイドローブでしきい値を超えます（所見 F1）。
  • MODELLED。台帳の行「IQ 捕捉におけるセル平均 CFAR オプション」。

• 実測データに対するシンチレーションモデル（PRO-34）：IQ チャネルの Cornell シンチレーションモデルを、赤道のシンチレーションの夜の実測の 50 Hz GPS L1 の強度と位相（Zenodo レコード 16941224、INGV、マリンディ、CC BY 4.0）と、b6ccb499 で事前登録した合格基準のもとで比較しました。満たしたもの：強度の分布と、S4 に結び付いた位相シンチレーション。満たされなかったもの：モデルは −10 dB を下回るフェージングが 2.4 倍の頻度で、3.5 倍の長さで起こります（所見 F1）。登録した処理はモデルのラップされた位相を読み取りますが（所見 F2）、位相の結果は、アンラップしても成り立ちます。scripts/fetch_scint_malindi.sh がデータを取得します。この行は MODELLED のままです：「IQ 電離圏シンチレーションチャネル（Cornell モデル）を、実測の 50 Hz の GPS L1 シンチレーションと照合」。

• 修正した LuGRE のサンプルリーダー（MR-09）：realdata::lugre::parse_iqs_sdrx は、I を上位ニブルに持つ LuGRE の IQ バッチを、ミッドライズのレベル 2v + 1（SdrLayout::mid_rise）で読み取ります。これにより、I と Q に素の二の補数の整数が持つ −½ の平均が除かれます。run_acq.py --corrected は GNSS-SDR にも同じ読み方を与えます。汎用の ION リーダーと既存の出力は変わりません：149 件のシナリオ結果と研究一件は、前後でバイト単位で同一で、固定した LuGRE の所見は登録したとおりに読めます（xval/lugre-reader/RESULTS.md）。台帳の行に変更はありません。

• オプトインの BOC(1,1) 追尾（CAP-07 (a)）：LoopConfig::boc は、サイン BOC(1,1) のメインピーク向けに DLL ディスクリミネーターを再スケーリングし、コード NCO をサイドピークから動かすバンプジャンプモニター（±0.5 チップの very-early と very-late の相関器、アップ／ダウンカウンター、N = 8）を加えます。Channel::bump_jumps がジャンプを一覧にします。デフォルトはオフで、既存の出力は変わりません。合成 BeiDou B1C 信号に対して 6b68f6cc で事前登録した合格基準に照らして確認しました：オプションなしでは 0.55 チップずれたままのサイドピークからの開始が、オプションありでは 0.08 秒での一回のジャンプでメインピークに引き込まれ、メインピークからの誤ったジャンプは見られませんでした。一つの合格基準は満たされませんでした：スケーリングの単体テストのグリッドが、ディスクリミネーターの線形範囲の外に及びます（docs/design/evidence/boc-bump-jump/RESULTS.md の所見 F1）。MODELLED。台帳の行「BOC(1,1) 追尾：DLL のスケーリングとバンプジャンプによるアンビギュイティ解決（オプトイン）」。

• IQ キャンペーンからのラボフィット（B7.1、docs/design/LABFIT-FROM-IQ.md）。labfit シナリオの [input] campaign = "<out-dir>" は、kshana iq campaign の出力フォルダーを、CLI（kshana iq labfit）、Python（kshana.iq_labfit）、MCP の labfit ツール（作業ディレクトリ内のフォルダーのみ）でフィットします。信号、ループ設計、フロントエンドチェーン、ジャマーの種類ごとに、一つのユニットをフィットします：

  • 打ち切りを伴う、定めた J/S に対する C/N0 モデル。
  • 追尾しきい値を、直接および閉形式で。
  • C/N0 モデルを介して結合した、追尾ループモデルと経験的ロックモデル、およびそれらの滞留時間。
  • 記録にわたるシード付きのクラスターブートストラップ、90 % 予測区間、および一記録除外のホールドアウト。
  • ハッシュ化した、事前登録済みの [validation] テーブルで、合格基準ごとに PASS/FAIL を示します。

  レポートは、kshana.labfit-iq/1 として JSON、CSV、Markdown で出力され、単位のブロックを伴います。Q_eff は、独立した電力測定がなければ C/N0 データからは同定できません。これは定めた値であり、フィットすることはなく、フィットされるパラメーターは delta_eff = delta - 10 log10 Q です（設計修正 2026-10-12）。未知のジャマーの種類には、定めた中で最も有害な Q（cw、1）を用います。Kshana 自身のシーンからの合成キャンペーンでは、ホールドアウトのカバレッジの合格基準 (c) は合格します。delta_eff の合格基準 (a') と (b')（50 件のキャンペーン中 0 件がカバーされた）と、閉形式のしきい値の合格基準 (d) は満たされず、値とともに記録しています。MODELLED。台帳の行「オープン受信機の C/N0 とロックのモデルを IQ キャンペーンの結果に較正し、予測誤差を明示」。受信機ログの labfit の経路とその出力は変わりません。

• JPL カーネル上の solar-system（CAP-31）：planetary_kernel_path は、SPK が保持する各天体（de440s では水星、金星、地球、月）をカーネルから取り、ラベルは KERNEL で、設定されたときのみ kernel ブロックを加えます。新しい行で、SPICE に対して VALIDATED（f8e946ea で事前登録。最悪 3.3e-5 m、1.0e-11 m/s）。デフォルトのレポートは変わりません。

• DE440 エフェメリス上のポークチョップ（CAP-20b）：maneuver::porkchop_kernel は、DE440 SPK の太陽中心状態に対して C3 と到着 V∞ を掃引します。新しい行で、SPICE の状態に対して VALIDATED

  • pykep 3.0.1（2d857fb1 で事前登録。2026-2028 の地球から火星、304 セル、最悪 2.6e-14、最小 C3 のセルは同じ）。

• LRO の非重力マクロモデル：NOT MET（DS-LRO-10、e82047e2 で事前登録）。lunar_od::LunarMacroModel（LunarForceModel::macro_model でオプトイン）：月の影を考慮した平板の直接太陽放射、太陽追尾アレイ、月のアルベドと熱赤外。LunarMacroModel::lro_generic は、公表されている事実に基づく、ラベル付きの一般的な LRO の近似です（バスの平板はなし：平板の表を入手できなかったため）。4 時間の LRO アークでは、簡略化力学の RMS は 6.668 m、力学の RMS は 11.94 m のままで、放射係数は現実的でなく（約 +21 / −22）、三つの合格基準はすべて外れました。この所見はテストで固定しており、デフォルトの出力は変わりません（docs/design/evidence/ds-lro-10-macro-model/RESULTS.md）。オプトインの月のキャノンボール SRP は、地球ではなく月の円錐影を使うようになりました（forces::conical_shadow_body）。

• 月の軌道決定：任意の k2 固体潮汐と月中心の相対論（DS-LRO-11）、デフォルトはオフ（LunarForceModel::lunar_tide、::relativity）。ANISE クロスバリデーション用の KSHANA_LRO_DEGREE スイッチ（DS-LRO-04）、24 時間の LRO アークのフィクスチャー、情報のみの長いアークのフィット（DS-LRO-09）。情報のための実行は docs/design/evidence/ds-lro-09-11-longer-arc/RESULTS.md に記録しており、公表した数値は何も変わりません。

• CAPSTONE に対する CR3BP 9:2 NRHO（CAP-29d）：エンジンの円制限三体問題の NRHO を CAPSTONE の実際に飛行した軌道（JPL Horizons、2023 年3月。4e868170 で事前登録）に対して測定する、新しい MODELLED の行です。CAPSTONE の平均値に対して、周期は 1.07 %、遠月点は 0.05 %、近月点は 4.1 % で、登録した 3 / 5 / 20 % の合格基準の内側です。測定であって、検証ではありません。

• CR3BP の回転座標系の状態から月中心 ICRF へ（RM-34、FUT-06）：cr3bp::to_moon_centred_icrf / from_moon_centred_icrf / to_moon_centred_icrf_de440 は、無次元の地球・月回転系の状態を、座標系の面外レートを含め、瞬時の DE440 の地球・月の線上に写像します。新しい行で、SPICE の二ベクトル座標系に対して VALIDATED（2313eb1b で事前登録、どの実行よりも前の d5ef79b3 で修正。72 件、最悪 1.8e-7 m と 1.2e-9 m/s）。

• JPL Three-Body Periodic Orbits API に対する CR3BP ファミリーのメンバー：NOT MET（RM-35、a9074f65 で事前登録）。cr3bp_family（ハロー、NRHO、DRO の補正、モノドロミー安定性指標、擬似弧長連続法）は、API の 58 個のメンバーのうち 54 個で、すべての合格基準に一致します（状態、周期、ヤコビ定数は、すべてで 1e-10 以内）。一つの L1 ハローの安定性指標（9.5e-2）と、三つの小さな DRO の閉じ（1e-8 に対して 1.5e-8 から 3.3e-8）が外れたため、このモジュールは #[doc(hidden)] となっており、これを主張する行はありません。結果：docs/design/evidence/cr3bp-families/RESULTS.md。

• オプトインの DE440 月の姿勢と環境（FUT-05、DS-LRO-08、デフォルトは変更なし）：lunar_frame::try_icrf_to_moon_pa_de440、lunar::try_mci_to_mcmf_de440 / try_mcmf_to_mci_de440（エポック固定、DE440 の主軸）、lunar_od::De440LunarEnvironment（組み込みの DE440 PA 姿勢と、ユーザー提供の DE440 SPK から得る地心の太陽と月）。ANISE との比較（ea537710 で事前登録）：姿勢は 3.5e-7 rad 以内、LRO のフィットは 1 mm 以内ですが、エフェメリスの部分は合格基準を外しました（太陽 30.7 m、月 1.1 m、ANISE 側に約 1 ms の時刻のオフセット）。そのため、独立した外部の参照と照合して確認済みの行ではありません。結果：docs/design/evidence/fut05-de440-lunar-env/RESULTS.md。

• 月座標系キャンペーンのデータム、条件数でスケーリングした NumPy の合格基準：NOT MET（b887eb05 で事前登録、MODELLED のまま）。ステップ 0 は、疑似逆行列のフォールバックが、0.30 の推定局数のギャップの原因であることを否定します。NumPy は八つのシナリオのうち六つで合格基準以内で一致しますが、stations_estimated はこれを外し（5.9e-7 に対して 6.8e-6）、新しい日付 2026-12-01 では、観測されない南極のビーコンがビーコン情報をランク不足にし、変更していないオラクルはそれを評価できません。結果：docs/design/evidence/mr05-lunar-datum-cond/RESULTS.md。

• 実際の観測キャンペーン（解析的な月）からの月座標系データムは、VALIDATED：新しい 2025 の EDC ノーマルポイントに対して（どれも取得する前の 31f5283 で事前登録）、変更していない SPICE と NumPy のオラクルは、記録管理、ランク、ゼロ結合で一致し、シグマで 1.11e-3 以内（合格基準は 1e-2）、条件数で 8.95e-4、横／縦の比で 1.79e-3（合格基準は 2e-2）で一致します。共分散計算のみについてのライブラリチェックであり、合格基準は月のモデルを区別しません。結果：docs/design/evidence/mr06-llr-analytic-fresh/RESULTS.md。

• 追加された十四個の太陽系天体の IAU 天体姿勢と GM。「あらゆる太陽系天体の物理定数」の行から、VALIDATED の行として分離しました（154bc54 で事前登録）：Body::iau_rotation_et は、元のエポックの 574 個の行列と、これまで比較したことのない 41 個の新しいエポックの 574 個で、pck00011 の SPICE の pxform と 1e-9 rad 以内で一致し（最悪は Phobos の 1.38e-10 rad）、Body::mu は十四個すべての天体で gm_de440 と等しくなります。元の行の残り（J2、平均半径、レポート）は MODELLED のままです。結果：docs/design/evidence/mr08-body-orientation/RESULTS.md。

• 複数周回の Lambert（maneuver::lambert_multirev）：最大三周回の、両方の分岐を含むすべての解。新しい台帳の行で、pykep 3.0.1 に対して VALIDATED（a75de851 で事前登録。382 件、1058 個の解、速度差の最悪値は 1e-8 に対して 1.6e-13）。内部のケプラー着地ガードは、e = 0.994 のアークで maneuver::kepler_universal の制約を一つ見つけました。これは docs/design/evidence/lambert-multirev/RESULTS.md に記録しています。

• ボックス・ウィングと ECOM2 の太陽放射圧（DS-PA-14）、オプトイン。 srp_boxwing：GSC の衛星メタデータにある Galileo FOC/IOV の表を用いた平板のボックス・ウィングモデルで、公称の GNSS ヨーステアリングのもと、放射係数とパネルごとの偏微分を持ち、また ECOM2 の経験モデルとその偏微分を持ちます。ForceModel::box_wing_srp / PreciseForceModel::box_wing_srp（フィールド srp_boxwing、デフォルトは None：キャノンボールの経路とすべての基準値は変更なし）で選択し、ボックス・ウィングの組を使う場合、cr はその放射係数です。事前登録（xval/srp-boxwing-orekit/）のもとで Orekit 12.2 と比較：すべての合格基準を満たし、相対で約 1e-15 です。モデル評価としては VALIDATED で、Galileo の SRP 予測は MODELLED のままです。

• 扁平な地球の SRP の影と太陽の周縁減光（FUT-09、RM-11）。新しい srp_shadow モジュール：oblate_conical_shadow（WGS-84 の掩蔽楕円体）、limb_darkened_shadow（エディントンの法則）、ShadowModel。ForceModel::srp_shadow で選択します（デフォルト：既存の球形の円錐影で、変更なし）。forces::srp_accel_with_lit_fraction。扁平な影は、2400 個の幾何で Orekit 12.2 の照明比と 7.4e-9 以内で一致します（VALIDATED、xval/srp-oblate-shadow-orekit/）。周縁減光には外部のオラクルがありません（MODELLED）。

• NRLMSISE-00 熱圏（FUT-08、RM-10、DS-PA-13）。 nrlmsise00：パブリックドメインの NRL Fortran の C 版から移植した gtd7 と gtd7d（スイッチ、日平均 Ap と 3 時間ごとの ap 配列のモード）です。その C 移植とビット単位で同一で、720 点のグリッドで pymsis 0.13.0（NRL Fortran、単精度）と相対で 1.9e-6 以内にあり、公開されている 17 個のテストケースを再現します（VALIDATED、xval/nrlmsise00-pymsis/）。これが検証するのは移植であって、実測の密度に対するモデルの精度ではありません。

• オプトインの NRLMSISE-00 抗力密度のティア。 forces::DensityModel::{Exponential, Nrlmsise00 { f107a, f107, ap }}、forces::drag_accel_with_density、density_at、propagator::ForceModel::drag_density。静的な指数モデルがビット単位でそのままデフォルトです。宇宙天気はモデルごとに一定です。軌道レベルで、Orekit 12.2 自身の NRLMSISE-00 の抗力に対して 24 時間にわたり VALIDATED（最悪 0.03 m、抗力による変位は最大 142 km。xval/drag-tier-orekit/）。

• コーウェル伝搬器でのオプトインの DE440 太陽と月（RM-33、FUT-10）。 propagator::ForceModel::with_ephemeris は、第三体と SRP の項のために、任意の EphemerisProvider（例：DE440 の KernelEphemeris）を受け取ります。そのエポックを提供できないプロバイダーは拒否し、解析級数へのフォールバックを数え、デフォルトではオフです。EphemerisProvider::relative_position_jd2 は二部構成の精度を保ちます。Orekit 12.2 自身の DE440 リーダーとの比較では、24 時間の軌道は 0.017 m まで一致します。事前登録した太陽／月の位置の合格基準は外れており（6.4 m / 0.24 m。SPICE も同じ差を示します）、そのため MODELLED です（xval/propagator-de440-orekit/）。

• オプトインの S1 大気潮汐（DS-PA-03）。 tides::atmospheric_tide_s1 と s1_air_tide_acceleration（Biancale & Bode 2006、GFZ STR06/01 Table 1 のモデル N1、次数 2–6）を、propagator::ForceModel と precise_od::PreciseForceModel の air_tide_s1() で有効にします。デフォルトはオフです。MODELLED（係数は公表されている表と再確認済み。力の効果についての外部のオラクルはありません）。

• 仰角マスク付きのレンジレートと方位角／仰角のバッチ軌道決定（RM-36、FUT-13）。 orbit_determination::determine_orbit_batch_tracking、simulate_tracking、predict_tracking、propagate_with_stm（解析的な二体と J2 の偏微分を持つ変分 STM）、is_visible、measurement_with_partials、batch_ls::gauss_newton_analytic。レンジのみの経路は変わりません。事前登録した 8 個のシナリオで Orekit 12.2 のバッチ最小二乗と比較：雑音なしの状態の一致（≤ 1 cm）を除くすべての合格基準を満たしました。この一致は 4 個のシナリオ中 2 個で 1.46 cm と 1.74 cm となり外れましたが、kshana は真値から 1e-8 m 以内です。記録しており、MODELLED です。

• SP3 の精度による重み付け（DS-PA-06）。 sp3::parse_sp3_accuracy と Sp3Accuracy::position_sigma_m は、ヘッダーとレコードごとの精度コードを観測のシグマに対応付けます。SP3 で重み付けした Galileo のフィットの変種（Tier-2 の 3D RMS は、重み付けなしの 0.070 m に対して 0.035 m）を、変更していない記録済みの実行の隣に加えています。MODELLED。

• .github/workflows/agency-od-validation.yml の Swarm-A の全アーク用ディスパッチジョブ（DS-PA-08）。

• PDS SHADR テーブルによる惑星重力（CAP-30、CAP-31 の一部）。 SphericalHarmonicField::from_shadr（src/gravity_pds.rs）は、Mars GMM-3（次数／位数 120）と GRAIL GL0660B（次数／位数 660）を読み込みます。Body::with_gravity_field は、読み込んだ任意のフィールドを取り付けます（デフォルトは変更なし）。次数 20 に切り出したものは同梱しており（NASA PDS、パブリックドメイン。tests/fixtures/planetary_gravity/NOTICE.md）、完全なファイルは xval/planetary-gravity-pyshtools/fetch_data.sh が取得します。pyshtools 4.14.1 に対して VALIDATED（次数／位数 120 で全球にわたり全重力の 4e-15 以内、次数／位数 660 では |lat| ≤ 60° で 5e-14）。座標系への結び付けは MODELLED のままです（各フィールドの固有の座標系は、使われる IAU 座標系ではありません）。

• 2190次までの高次重力場（RM-14、FUT-07）。 SphericalHarmonicField::acceleration_hf / potential_hf（Holmes–Featherstone 修正前方列法。アンダーフローも極での特異点もありません）、prepare_high_degree、ストリーミング方式の ICGEM ローダー from_gfc_file / from_gfc_reader（正規化と最大次数の検査を行い、潮汐系を記録し、時間変動項は拒否します）、および scripts/fetch_egm2008.sh（EGM2008 全体。SHA-256 で固定しており、同梱はしません。テストは KSHANA_EGM2008_GFC で有効化します）。propagator::FieldEvaluator は、オプトインの Geopotential でこれを選択します。2190次までの範囲で Orekit 12.2 と 7.3e-17 m/s² 以内で一致し、24 h の 200×200 軌道では 0.13 m 以内で一致します。MODELLED：pyshtools は事前登録した極付近の合格基準に届かず（原因は pyshtools にあると特定）、軌道の70次感度対照も届きませんでした（0.73 m < 1 m）。いずれも xval/ に記録しています。

• DOP853 積分器（FUT-11）。 integrator::integrate_dop853、integrate_dop853_checked、integrate_dop853_dense（7次の稠密出力）、dop853_step、dop853_initial_step。フェイルクローズ型のステップガードを備え、propagator::Integrator::Dop853、propagate_dop853、propagate_dop853_checked も追加しています。既定のドライバーは変更していません。SciPy 1.18.1 の solve_ivp(method="DOP853") と照合して VALIDATED：単一ステップは 5.6e-15 以内、ステップ列は一致、終端状態は 1.6e-12 以内です（xval/dop853-scipy/）。

• 堅牢なケプラー方程式ソルバー（FUT-12）。新しい kepler モジュール：solve_kepler_markley（Markley 1995 の初期値、桁落ちのない残差）が 0 ≤ e < 1 のすべてを扱い、propagator::solve_kepler_robust でラップされます。50桁の mpmath の根と照合して VALIDATED：e = 0.999999 まで 0.9 ε·|E| 以内（xval/kepler-mpmath/）。

• Cowell 伝搬器におけるオプトインのテッセラル地球重力（RM-09）。 propagator::ForceModel に geopotential: Option<Geopotential>（with_geopotential、with_egm2008(nmax)）が加わります。これは SphericalHarmonicField（次数・位数 70 までの同梱 EGM2008、または任意の ICGEM .gfc）を、地球自転角（EarthFixedFrame::Era）または CIO による GCRS から ITRS への変換連鎖（EarthFixedFrame::Cio）で得られる地球固定座標系で評価します。既定は None で、既存の出力は変わりません。Orekit 12.2 の Holmes–Featherstone 法と 24 h にわたり（6 ケース、最悪値 0.036 m）照合して VALIDATED。合格基準は xval/cowell-tesseral-orekit/PREREGISTRATION.md に事前登録しています。

• 軌道経路の地球自転計算における二要素ユリウス日：jd2::gmst82、cio::gcrs_to_itrs_matrix_jd2、frames::teme_to_itrf_jd2 / itrf_to_teme_jd2、orbit::Propagator::position_in_frame_jd2、own_jd2_utc、From による jd2::Jd2 と timescales::TwoPartJd の相互変換、および ephemeris シナリオ向けのオプトイン two_part_jd = true（ECEF、地上軌跡、地上局ビュー。既定はオフで変更なし。オフのときはこのキーをシナリオのハッシュから除外します）。新しい台帳（ledger）の行。pyerfa の gmst82/c2t06a と照合して VALIDATED（事前登録 b10475ee；40 個の日付：GMST はビット単位で一致、行列は 2.7e-14 以内、1 µs 刻みの回転は 1.1e-14 rad 以内。単一の f64 経路ではこれを満たせません）。Cowell 力モデルのエポックは単一の f64 のままです。理由はそのドキュメントに記載しています。

• テーブルを超える EOP 予測（EopSeries::with_ls_ar_prediction、EopSeries::last_mjd）：IERS 地球姿勢系列の最終行で発行された LS+AR 予測器により系列を延長するオプトインの機能で、これにより後のエポックの座標系引数は、最終行に固定されることなく予測に従います。テーブル内の答えはビット単位で同一です（テスト済み）。これを呼び出さない限り、系列は従来どおり最終行に固定されます。予測の精度は、Bulletin A と照合した既存の LS+AR の知見のままです（MODELLED）。

• CIO 連鎖における天球極オフセット dX、dY（cio::gcrs_to_cirs_matrix_with_offsets）、および precession_matrix、teme_to_gcrs_matrix と新しい関数に対する ERFA ベクトルの直接検査。新しい台帳（ledger）の行。pyerfa と照合して VALIDATED（事前登録 979c1e39；1950–2100 年の 40 エポック：歳差と CIO はビット単位で一致、TEME→GCRS は 1.1e-10 rad 以内。これは二項の分点方程式級数から予測された影響です）。既存の関数は変更していません。

• 二要素時刻経路における1972年以前の UTC（timescales::tai_minus_utc_on_date、および1960-01-01 以降の Jd2::from_utc_calendar、jd2::utc_to_tai、jd2::tai_to_utc）：レートが変動する（「ゴム秒」）時代で、SOFA のドリフト表、日末の端数ステップ、日の端数に対する UTC から SI への換算を含みます。新しい台帳（ledger）の行。pyerfa の dtf2d/utctai/taiutc と照合して VALIDATED（事前登録 23c40661；1960–1971 年の 117 時点、最悪値 2.9e-11 s、合格基準は 1 µs）。1972 年以降の結果はすべてビット単位で同一です（変更前にチェックサムを固定）。1960 年より前は、SOFA と同様に TAI − UTC は 0 です。単一の f64 の timescales::tai_minus_utc は変更していません。

• GLONASS 放送衛星クロック（GlonassEphemeris::sv_clock_bias_s）：RINEX レコードからの −τn + γn·(t − tb)。衛星クロック上で読み取った時刻で評価します（固定小数点反復を二回、RTKLIB の慣例）。解析済みの −τn と γn は、これまで使われていませんでした。新しい台帳（ledger）の行「GLONASS 放送衛星クロックと放送軌道の伝搬」。RTKLIB 2.4.2-p13 の geph2clk/geph2pos と照合して VALIDATED（事前登録 e099c42a；2013 年の実際の放送ファイルの 292 ケース：クロック差 0 s、位置の最悪値 1.1 mm、合格基準は 1 cm）。ライブラリ関数であり、シナリオの出力は変わりません。PZ-90.11 から ITRF への変換は適用しておらず、モジュールにもその旨を記しています。

• IGS 局クロックに対する PPP 時刻解（0.36、FUT-19）：WTZR のフロート PPP フィルターの受信機クロックは、収束後の二時間にわたり、同局の IGS 最終統合クロックと標準偏差 0.075 ns で一致し、定常オフセットは −0.66 ns でした。合格基準は xval/ppp-time/ に事前登録しています。VALIDATED（新しい台帳（ledger）の行）。新しいフィクスチャ igs_2025055_WTZR_05m_0006.clk は、衛星クロックにすでに使っている IGS 最終クロックファイルの局クロック記録です。

• gLAB との PPP 一致確認（0.36、WP-07、RM-31）：gLAB 6.0.0 を、同じ WTZR の入力で別個のツールとして実行しました（コアは Apache-2.0。ダウンロードのチェックサムは公開リストと照合済み）。実行前に、手続き上の修正のコマンドラインをコミットしています。最初の登録済み実行では、Kshana のフロート PPP と gLAB の結果は、240 エポック中 240 エポックで 0.05 m 以内で一致し、最終エポックでは 5.0 mm 以内でした。SPP の合格基準には届かず（中央値 1.187 m、基準 0.50 m）、所見として記録しています。gLAB と RTKLIB 自身の SPP 解も互いに 0.852 m 異なります。したがって登録済みの規則により、両ツールの脚は全体として基準を満たしていない扱いのままですが、PPP の一致は成立しています。

• RINEX 4 航法ファイルの読み取り（0.36、WP-07、PRO-41）：rinex::parse_nav は RINEX 4.00-4.02 の航法ファイルを読み取り（> EPH GPS LNAV、Galileo I/NAV と F/NAV、BeiDou D1/D2、QZSS LNAV。その他のレコードは次のレコードヘッダーまで読み飛ばします）、parse_nav_with はオプションを受け付けます。同日の IGS RINEX 3 統合ファイルと照合して VALIDATED：復号したすべてのフィールドが一致し、位置の差は 0 m でした。RINEX 2/3 の読み取りは変更していません。

• BeiDou GEO の放送位置（オプトイン）：NavParseOptions::include_beidou_geo と RinexEphemeris::sv_position_ecef_bds_geo（BDS ICD、−5 度の傾き）。parse_nav は引き続き GEO を読み飛ばします。MODELLED：精密軌道との事前登録済みの比較はデータ依存で、まだ実行していません。

• RINEX 4 観測ファイル：実際の RINEX 4.00 MGEX 観測ファイルをテストで読み込みます（MODELLED、フォーマット適合性）。

• 実際の RINEX による LAMBDA を用いた RTK（0.36、WP-07 ★）：rtk_real::run_rtk。二周波 GPS のコードと位相による短基線の二重差を、フロートカルマンフィルターと LAMBDA 整数固定（比検定）で処理します。IGS 局 WTZR と WTZZ（1.4 m 離れています）で、ITRF2020 の基線と照合し、事前登録した合格基準のもとで VALIDATED：最初の十分間以降のすべてのエポックで固定でき、基線誤差は中央値 4.5 mm、95パーセンタイル 5.5 mm でした。

• 実データ PPP の RTKLIB との一致確認（RM-31）：xval/ppp-parity/run.sh と tests/ppp_parity_glab_rtklib.rs、合格基準は事前登録済みです。同じ WTZR の入力による RTKLIB v2.4.2-p13 の PPP は、三回目の登録で、最後の二時間のすべてのエポックにおいて Kshana と 5 cm 以内で一致しています（終端で 9.7 mm）。最初の二回の実行は所見として記録しており、固体潮汐がオフで、受信機アンテナが RTKLIB の基準スロットに設定されていました。単独測位の一致の合格基準には届きませんでした（中央値 1.09 m、基準 0.5 m）。gLAB の脚は未実行です（データ依存）。

• LNAV 以外の航法メッセージエンコーダー（0.36、WP-07、PRO-40）：gnss_navmsg は、GPS CNAV（メッセージタイプ 10、11、30；CRC-24Q；連続のレート 1/2、K=7 符号化）、Galileo I/NAV（偶数・奇数の公称ページにおけるワードタイプ 1-5；30x8 インターリーバー；同期 0101100000）、Galileo F/NAV（ページタイプ 1-4；61x8 インターリーバー；同期 101101110000）を、テスト用デコーダーとともに符号化します。MODELLED：ラウンドトリップと ICD の既知解。放送 Galileo エフェメリスがエンコーダーの LSB グリッド上にあるという事前登録済みの検査は成立しました（最悪値 3.6e-3 LSB）が、衛星数の合格基準には届かず（20 機中 15 機）、その旨を記録しています。エンコーダーはライブラリ関数であり、シーンへの組み込みはこの変更に含まれません。

• IONEX ファイルリーダー（0.36、WP-07）：ionex::parse_ionex_file と IonexFile、IonexHeader、IonexEpoch、IonexFileMap、IonexTimeInterp：固定桁の厳密な IONEX 1.0 リーダーで、エポックは最初のマップの日から数え、9999 は欠測として読み、RMS マップに対応し、このフォーマットの最近傍補間、連続補間、回転マップによる時間補間を備えます。スラント TEC はヘッダーのシェル高度で求めます。コミット済みの合成マップで検査し、またデータ依存（テスト時に SHA-256 を固定して取得し、同梱はしません）で実際の CODE GIM の切り出しでも検査しました：すべてのノードが厳密に一致し、補間は数式による参照と 4e-13 TECU 以内で一致します。RTKLIB の iontec は 6885 点で 3.6e-13 TECU 以内で一致しました（事前登録 B6）。データ依存の証拠に基づき VALIDATED（所有者の決定、2026-10-13）：SHA 固定のマップ以外ではテストが失敗します。

• Hatch 搬送波平滑化（0.36、WP-07）：hatch::HatchFilter と pvt::assemble_epoch_precise_smoothed。精密単独測位の組み立てにおける、発散のない（電離圏フリーの）形式です。記録済みの所見つきで MODELLED：IGS 局 WTZR では、単独測位誤差の中央値を 1.55 m から 1.12 m に、95パーセンタイルを 3.47 m から 3.21 m に下げますが、事前登録した 40 % の低減には届きません（残る誤差はノイズではなくバイアス的です）。

• 実際の RINEX によるフロート PPP（0.36、WP-07）：ppp_real::run_ppp。IGS 最終プロダクト（アンテナオフセットと変動、固体地球潮汐、位相ウィンドアップ、シャピロ遅延、推定した湿潤遅延、サイクルスリップ検出）を用いて、実際の二周波 GPS のコードと位相を処理する静的フロート精密単独測位フィルターで、parse_antex_receiver を備えます。ホールドアウトの IGS 局 WTZR で、ITRF2020 座標と照合し、事前登録した合格基準のもとで VALIDATED：6 h 後の誤差は水平 1.5 mm、垂直 2.9 cm で、最後の二時間のすべてのエポックが 10 cm 以内です。

• SP3 精密クロック補間（0.36、WP-07）：Sp3File::clock_s と clock_nodes は、表形式の SP3 衛星クロックを、前後の有効な二つのノードの間で線形補間し（不良クロックの番兵値は読み飛ばします）、ClockRinex::from_sp3 がそれらを PreciseProducts に渡すため、精密処理の連鎖は SP3 だけで動作します。2025-02-24 の IGS 最終 30 s クロックと照合し、事前登録した合格基準のもとで VALIDATED：GPS 衛星 32 機、中間点の RMS は 0.121 ns（基準 0.15 ns）、95パーセンタイルは 0.265 ns（基準 0.30 ns）です。

• 時計ホールドオーバーの性能指標と並べた RAIM（CAP-05b）：クロック種別にオプトインの [integrity] セクションを置くと、別個の integrity_fom ブロックを報告します（指定した地点からプリセットの天空に対するスナップショット RAIM：エポックごとの判定と保護レベル、可用性。GNSS が拒否されている間は利用不可で、外挿はしません）。ホールドオーバーの数値は変わりません。セクションがなければ出力はバイト単位で同一です。MODELLED。

• JammerTest 2024 で較正した受信機信頼性のしきい値（CAP-13）：公開の JammerTest 2024 データセット（実行時に取得し、同梱はしません。examples/jammertest_trust_calibration.rs）で C/N0 低下、AGC、ジャミング指標の各モニターを事前登録のうえ較正したもので、オプトインの [monitors] profile = "jammertest-2024-calibrated"（1.5 dB、3.5 シグマ、29）としてのみ提供します。ホールドアウトでは、AGC、ジャミング指標、和集合の合格基準は通過しましたが、C/N0 の誤警報の合格基準は通過せず（0.02 に対し 0.023）、そのためこの行は MODELLED です（xval/jammertest-trust/RESULTS.md）。プロファイルを使わない場合の既定値と出力は変わりません。

• 複数衛星の ARAIM 故障仮説（CAP-05a）：ADD v4.2 のサブセット規則を二機組以上に一般化したもの（add_v42_subset_plan、add_v42_protection_levels_to_order；次数 2 は、既存の MAAST で検査済みの経路と完全に同一です）、およびそれらの仮説に対するオプトインの高度化 RAIM（araim_subset_raim）で、故障を検出した場合は最も分離の大きいサブセットを報告します。より深いサブセットを必要とする事前確率は、切り詰めずに拒否します。MODELLED。

• 受信機信頼性におけるスカイライン（FUT-01）：受信機信頼性セッションは [skyline] を指定できます。その背後にある衛星は天空から失われ（sky-blocked、behind_skyline、open_fraction）、その損失は geometry に分類され、environment には分類されません。指定がない場合、方位ギャップによるフォールバックとすべての出力は従来どおりです。乗員訓練ジェネレーターには natural-degradation イベント（干渉ではなく、遮られた天空）とシナリオ scenarios/training/fjord-natural-degradation.toml が加わります。UERE x DOP のモンテカルロには、設計メモにある二つのマスク付きスカイラインのジオメトリが加わり、単独で事前登録しました：26 件の検査がすべて通過しました。

• RFC 3161 タイムスタンプの検証（CAP-14）：kshana::evidence::tsa::verify_token は、タイムスタンプトークンの署名（RSA PKCS#1 v1.5、RSA-PSS、ECDSA P-256 と P-384）、その ESS 署名証明書の紐付け、署名者の timeStamping 用途、およびトークンの genTime 時点での信頼アンカーまでのチェーンを、オフラインで検査します。kshana evidence verify --tsa-ca <anchors.pem> は、これをパックの timestamp.tsr に適用します（オプトイン。指定しなければレポートは変わりません）。VALIDATED（限定的）：自己生成した 27 ケースのすべてで、判定と genTime が OpenSSL 3.0.13 と一致しました。この比較は、検証器を書く前に事前登録しています。失効の確認は行いません。

• 全種別の図ごとの検証ティア（RM-04）：すべてのシナリオ種別の結果の末尾に、figure_tiers ブロックが付きます。ここには主要な数値、それぞれを所管する検証マトリクスの行、その行から読み取ったティアが記され（どの行にも所管されない数値はティアなしとして列挙されます）。このブロックは実行後に追加され、取り除くと以前のドキュメントとバイト単位で一致します（api::without_figure_tiers）。lunar-station-coverage には、凍結された予測を新しい日付付きの予測が置き換えるまで figure_tiers がありません。leo-ppp、solar-system、sweep、sweep-nd にはスカラーの主要な数値がなく、lunar-attack-surface はコンパクトな JSON を書き出します。キャンペーンのメンバーは、ティアなしのドキュメントのままです。

• 量子プリセット quantum-cai-coast（CAP-08c）：同梱の慣性シナリオで、原子干渉計の物理で規定した冷却原子干渉計加速度計（[accel_quantum.cai]、プラットフォームの振動レベルを明示）が、110分間の GNSS 途絶のあいだ、航法グレードの水晶加速度計と並んで惰行します。MODELLED。

• Greenhall の厳密な等価自由度（CAP-03）：allan::edf_greenhall。Greenhall と Riley（2003）の完全なアルゴリズム（差分次数 1 から 3、雑音指数 +2 から -4、重複と非重複、修正と非修正、大きな J のテーブルを含む）に、ADEV、MDEV、HDEV のラッパーを備えます。allantools 2024.6 との事前登録済みの比較のもとで VALIDATED：4,876 個のグリッド点が相対 6.0e-13 以内で一致しました。allantools は、さらに 32 点で失敗し、それらはオラクルの値なしで記録しています。assurance::uncertainty の信頼区間はビット単位で変わりません。

• 冷却原子干渉計の誤差項（RM-26/27/28）：ラマンレーザー位相雑音（後方反射の遅延項を含む）、熱的原子雲の波面曲率バイアス（純粋なデフォーカス、検出半径つき）、フリンジのアンビギュイティ解決（古典補助と二つの干渉時間）を、src/inertial/cai_error_terms.rs のライブラリ関数として提供し、いずれの閉形式も求積法またはモンテカルロで検査しています。MODELLED。シナリオ種別からはまだ到達できません（docs/QUANTUM-MODELS.md）。

• クロックログのフォーマット（RM-03）：src/clock_log.rs は、RINEX クロックファイル、TimeLab 形式の ASCII 位相または周波数ログ、TAPR TICC カウンターログを読み込み、一つの正規化した位相系列にします（tau0 は指定または自動検出、ギャップは計数、ギャップ方針あり）。オプトイン：通信タイミング系列はログを指定でき（[series.clock_log]）、クロックシナリオの [clock_log] テーブルは measured ブロック（ADEV、TDEV、MTIE）を追加します。テーブルがなければ、両方の種別はバイト単位で同一です（docs/CLOCK-LOG-FORMATS.md）。三つの合成ログによる事前登録済みの比較では、位相と配線の合格基準を満たしました。推定器は、allantools が評価できる範囲では 2.5e-14 以内で一致し、レコード全体の MTIE 点は allantools では評価されません（記録済み）。MODELLED。

• 周波数同期ワンダーマスク（RM-01）：telecom-timing 種別に、定温の MTIE と TDEV のワンダー生成マスクが七種類加わります。ITU-T G.811 PRC、G.812 タイプ I から III、G.8262 EEC オプション 1 と 2、G.8262.1 eEEC で、表が記すべき乗則の区間を含みます。また参照シナリオ scenarios/telecom-synce-eec.toml（フリーランの OCXO を EEC マスクに対して評価：1,000 s で不合格となり、そこではループが働く必要があります）も加わります。すべての行は itu.int のテキストと再照合しました。G.812（06/2004）は、08/2026 版の事前公開版で置き換えられていますが、これは読めませんでした。MODELLED（転記）：既存のマスクと出力は変わりません。

• gnss-ins 種別のフィルター事前分布に関するガイダンス（0.36、WP-09、RM-21 の所見）：パックの既定のフィルター事前分布は、戦術級 IMU に適しています。航法級 IMU では、既定の設定により、融合した惰行がフリー INS より悪化することがあります：70 m/s の航空機プロファイルで 52 m に対し 11 m です。新しい海事、鉄道、航空のパックと同様に、[imu_*.filter_prior] をセンサーのグレードに合わせて設定してください。航法級 IMU を既定の事前分布と組み合わせる同梱シナリオはありません。既定を使うものはすべて、加速度計の残留バイアスが 0.015 m/s² 以上です。ドキュメントのみの変更で、出力は変わりません。

• シミュレーター自身のリーダーで検査したtest bench向けエクスポート（0.36、WP-09、CAP-16）：8 件の同梱シナリオの kshana bench-export モーションファイルを、gps-sdr-sim の NMEA、緯度・経度・高度、地球固定のモーションの各リーダーで読み戻しました（MIT、コミット 28ca29a6。xval/testbench-gpssdrsim/ 経由で別個のツールとして使用し、信号に関する関数は呼び出しません）。エクスポートした軌跡は、それぞれ 1.2 mm、0.15 mm、完全一致で再現されました。所見：このシミュレーターの地球固定リーダーは、フル幅の CSV を受け付けられません。100文字の行バッファが各行を分割してしまうためです。docs/TEST-BENCH.md には、使うべき列の区切りと、このシミュレーターの 300 s の上限を記載しました。VALIDATED（新しい台帳（ledger）の行）。エクスポートのバイト列は変わりません。

• KF-GINS データセットによる GNSS/INS（0.36、WP-09、FUT-17）：fusion::kfgins のローダーとランナー、および閉ループ EKF におけるレバーアーム測定モデル。KF-GINS のデモデータセット（テスト時に取得し、同梱はしません）では、参照軌跡に対する Kshana の水平 RMS は 1.09 cm で、KF-GINS 自身の 1.11 cm に対応し、事前登録した合格基準はすべて満たしました。データ依存の証拠に基づき VALIDATED（所有者の決定、2026-10-13）：データセットは SHA-256 で固定して取得し、再現手順は xval/kfgins/PREREGISTRATION.md にあります。

• fusion パックの結合 PNT フィルター（0.36、WP-09、FUT-16）：fusion 種別は任意の [coupled] テーブルを受け付け、擬似距離と加速度計バイアス状態に対する一つの積層フィルターを実行します（fusion::coupled::CoupledPntBiasFilter）。fusion::coupled::CoupledPnt3d は3次元の8状態版です。新しい同梱シナリオ fusion-pnt-coupled：加速度計にバイアスがある状況で、結合モードは量子スイートの位置を（95パーセンタイルで）18.7 m に保ち、インテグリティも完全です。分離型のフィルターは 430 m に達します。テーブルがなければ fusion と hybrid のどちらも変わりません（固定済み）。hybrid はこのテーブルを拒否します。MODELLED。

• 海事、鉄道、航空向けの GNSS/INS パック（0.36、WP-09、RM-21）：軌跡ライブラリに基づく同梱シナリオ gnss-ins-maritime、gnss-ins-rail、gnss-ins-aviation、および gnss-ins 種別向けの任意の [tight] テーブルで、SGP4 Walker コンステレーションの擬似距離を融合します（正常時はすべての衛星、劣化時は仰角の高い数機）。鉄道パックでは、密結合により、切通しとトンネルを通過しても航法グレードの解を 5.3 m に保ちますが、疎結合では 12.9 m です。[tight] がなければパックは変わりません（固定済み）。MODELLED。

• 搬送波位相の密結合（0.36、WP-09、RM-25 / FUT-17）：fusion::carrier_tc。明示的な二状態の受信機クロックとフロート搬送波アンビギュイティを持つ誤差状態 EKF で、測定ループ内に Klobuchar と Saastamoinen の補正を備えた SGP4 Walker コンステレーションで駆動し、時間差分搬送波によるスリップ検出とアンビギュイティの再初期化を行い、比較のため同じ測定値によるコードのみの実行も備えます。MODELLED：8の字走行では、搬送波による解は 2.5 cm、コードのみは 47 cm で、NIS/NEES はシード間で整合しています。

• GNSS/INS 軌跡ライブラリ（0.36、WP-09、RM-24）：gnss-ins 種別は、profile = "straight" | "figure8" | "stop_go" | "aircraft" | "uas" | "csv" を持つ任意の [trajectory] テーブルを受け付けます。プロファイルは、真値の状態からオイラー角速度と進行方向の加速度を指令し、剛体運動学（協調旋回、上昇、コリオリ）から真の IMU を導出します。csv は真値の軌跡（t, lat, lon, alt, vn, ve, vd, roll, pitch, yaw）を取り込み、それを再現する IMU を解きます。テーブルがなければ、パックは従来の走行をビット単位で同一に飛行します（固定済み）。MODELLED。

• 月の地平線向けの緯度・経度 DEM タイル：[terrain] dem_tile_path は、極ステレオ投影の dem_path の代わりに、realdata::lola_dem のテキストタイル（緯度・経度グリッド上の平均球面からの高さ）を読み込み、lunar-station-coverage と moonlight-service-volume の両方で使えます。レポートはそのタイル（terrain.dem_tile、SHA-256 つき）を記載します。realdata::lola_dem は、地平線のレイマーチングに組み込まれました。同梱の切り出しから再サンプリングしたタイルは、地上局に、切り出しの地平線を 0.22 度以内で与えます。MODELLED。

• サービスボリュームのエクスポート地点における地形：terrain セクションがあると、moonlight-service-volume の衛星ごとのジオメトリのエクスポートの各行に clears_terrain（衛星が平坦なマスクと、その方位におけるエクスポート地点の地平線を超えている）が加わり、レポートに地点の地平線（export_site_terrain）が載り、ランタイムの CSV にその列が加わります。地形がなければエクスポートは変わりません。MODELLED。

• エンジンからの主要フィールド（0.36、STUDIO-06）：kshana::api::HEADLINE_FIELDS、field_importance_json()、および WebAssembly の field_importance() は、十二種別について、シナリオのどのフィールドがその問いに答えるかを、重要な順にドット区切りのパスで示します（jammers[].eirp_dbw）。Studio は、独自の順位付けより先にこれを読みます。表示用のメタデータのみで、エンジンは読まず、必要とするシナリオファイルもなく、これに依存する結果もありません。tests/field_importance.rs は、種別がディスパッチ不能な場合、またはパスが当該種別の同梱シナリオのどれにも見つからない場合に失敗します（Studio の平坦化した ID が配列の括弧なしで綴っていた二つのパスを検出しました）。

• エンジンからの種別とモジュールの対応表（0.36、STUDIO-05）：kshana::api::KIND_MODULES、kind_modules_json()、および WebAssembly の kind_modules() は、検証マトリクスの行が自身以外のモジュールを挙げているシナリオ種別ごとに、そのモジュール名を返します。Studio の機能マップは独自に手書きした写しを使っていました。tests/kind_modules.rs は、表にある種別がディスパッチ不能な場合、またはどの行にも現れないモジュールがある場合に失敗します。出力の変更はありません。

• ブラウザービルドでの短い IQ 実行（0.36）：WebAssembly モジュールの iq_signals() と iq_run_short(fs_hz, duration_s, signal, ids, dopplers_hz, cn0_dbhz, seed) は、合成シーンを構築し、各衛星を捕捉して、捕捉できたものを追尾します。すべてメモリ内で行い、0.25 s、1,000,000 サンプル、8 機に制限しています。シーンビルダーと名前による信号の検索は、ネイティブ専用の iq::cli から（iq::scene::synthetic と iq::signals::by_name へ）移したため、両方のビルドで共有します。コマンドラインの出力は変わりません。ネイティブのテストと web/smoke.mjs は、同じリクエストを一つのゴールデンデータ（tests/fixtures/iq_short_golden.json）とバイト単位で比較します：移植可能な数学関数への変更（STUDIO-15、後述）以降、ブラウザービルドとネイティブビルドは同じビット列を返します。

• 型付きの Python と TypeScript の API（CAP-34）：kshana.pyi は、閉じた語彙（ScenarioKind、すべての種別名、ErrorKind、ProvenanceClass）と、KindMeta および FieldUnit の辞書に型を付けます。scenario_kinds() と error_kind() がそれらを返します。WebAssembly パッケージには run_typed（解析済みドキュメントを data として持つ、型付き RunOutput オブジェクトとしての一回の実行）と scenario_kinds（解析済みの KindMeta[]）が加わり、その kshana.d.ts も同じ語彙を持ちます。error_kind の型は ErrorKind | "" です。tests/typed_api_sync.rs は、両方のリストをエンジンのものと等しく保ちます。

• すべての sweep-nd 列の単位（FUT-28）：sweep-nd の結果は、掃引した各キーと記録した各メトリクスの単位である key_units と metric_units を持つようになり、掃引したパック自身の単位表から読み取ります。軸は、パックが返さないキーについて unit を宣言できます。パックの単位と矛盾する単位の宣言は拒否され、どちらも与えない単位は推測せず null になります。points[].coords[] と points[].metrics[] は記述済みであり、したがって 76 種別のすべてが、フィールド単位のゲートで完全にカバーされるようになりました（未カバー種別の上限 1 -> 0）。

• RunOutput からの NumPy 配列（FUT-26）：Python の RunOutput に array(path)、columns(path)、series() が加わり、数値のリスト、レコードのリストの数値列、またはドキュメント内のすべてのレコード系列に対して numpy.ndarray を返します。各配列は、data() から得た同じ値に対する numpy.asarray と等しくなります（dtype もビット列も）。NumPy は、これらのいずれかを呼び出したときにのみインポートされ、実行時要件には含まれません。kshana.pyi で型付けし、stubtest で検査しています。

• キャンペーン最適化（CAP-32）：campaign 種別に新しく加わったオプションの [optimize] セクションは、指定した範囲内で一つから三つのシナリオキーを探索し、一つのメトリクスの最良値（最小化、最大化、または目標値への到達）を求めます。グリッド上の網羅探索、または決定論的で範囲を限定した Nelder–Mead 単体のいずれかで探索します。すべての評価は指定した種別の実際の実行であり、結果の trace に列挙されます。例：scenarios/campaign-optimize-link-budget.toml。合格基準は事前登録しました（docs/design/evidence/cap32-optimize/）：

  • Rosenbrock 関数は基準を満たした（f* = 1.7e-20）。
  • 閉形式の 1-D の目標解は基準を満たした（相対 6e-15）。
  • グリッドは、独立した総当たり探索とビット単位で等しい。
  • 単体法は、177 回の実行で 41 × 41 のグリッドと同等以上の結果を出す。

  ラウンド 1 の 1-D の合格基準は NOT MET として記録しました。事前登録した探索範囲が解を除外していたためです。MODELLED。台帳（ledger）の行「キャンペーンパラメーターに対する一つのメトリクスの範囲限定最適化」。追加的な機能であり、このセクションがないキャンペーンは変わりません。

• 較正アンサンブル（CAP-10）：単一シードの三つの検査を、200 個の独立したシードで、事前登録した合格基準に対して再実行しました。詳細は docs/CALIBRATION-ENSEMBLES.md（gen_calibration_ensembles が生成。シードごとの値は docs/data/calibration-ensembles.csv）にあります。

  • キャンペーンのモンテカルロのブートストラップ 95 % 区間は、200 個のアンサンブルのうち 192 個で真の平均を含み、そのカイ二乗検査は 196 個で通過します。
  • 単一シードのパーセンタイル許容差が通過するのは 200 個中 183 個のみで、予測どおり NOT MET です。これは約 2-sigma の合格基準であり、緩和せずそのまま記録しています。
  • white-FM の ADEV 較正は、すべてのシードで通過し、最悪の誤差も許容差を大きく下回っています。

  MODELLED.

• Scenario トレイトによる組み込み種別（FUT-27、進行中）：BuiltinKind トレイト（api::BuiltinKind。図ごとのティアのフックと append_figure_tiers を備えます）と、それに移した最初の種別（inertial、spoof、passes、link-budget、jamming）。出力は変わりません：すべての出力の SHA-256 を集めたカタログ全体のマニフェストは、変更の前後で同一です（tests/scenario_output_manifest.rs）。

• プレイグラウンドのフェッチなしの検査（RM-07）：tests/playground_no_fetch.rs は三つの点を検査します：

  • Studio ライブラリのすべてのシナリオが、ブラウザーのバンドルに入っていること。
  • バンドルが scenarios/ とバイト単位で同一であること。
  • ブラウザーのすべてのシナリオが、空の作業ディレクトリから実行できること。

• Alt-PNT マップ：実際の重力場、地図誤差のモンテカルロ、フル解像度の SRTM（0.36、WP-10）。gravity-map 種別は任意の [reference] を受け付けます：同梱の EGM2008 係数から合成した重力異常（またはネイティブビルド限定で、gfc_path による ICGEM .gfc ファイル）です。この合成は、二つの地域の 794 ノードにわたり、ICGEM Calculation Service と約 1e-8 mGal で一致し、事前登録した合格基準（RMS 0.005 mGal、最大 0.02 mGal）を満たしました（VALIDATED。台帳（ledger）の行「球面調和モデルによる重力異常の合成」）。新しい同梱シナリオ gps-denied-gravity-nav-egm2008 は、この実際の70次の場で60分間のベンチマークを実行します。事前登録した結果：整合誤差は 3106 m で、< 500 m の合格基準は予測どおり NOT MET（70 次では滑らかすぎます）、ドリフトの十分の一への低減は MET です（MODELLED）。任意の [map_error_mc] は、シードを与えたガウス相関の地図誤差のもとでベンチマークを再実行し、整合誤差の分布を報告します（同梱シナリオ gravity-map-error-mc）。探索的で、事前登録はしていません：0.2 度にわたって相関する 2 mGal の地図誤差（マッチャー自身のシグマが見込む大きさ）では、20 回の実現のうち 1 回が 500 m 以内に収まり（中央値 2.9 km、p95 14.7 km）、地図が完全な場合は 144 m です。合成ベンチマークでの 500 m 未満の測位解は、地図が正確であることを前提としています。どちらのオプションもなければ、ドキュメントは以前のリリースとバイト単位で同一です。combined-altpnt は、EMAG2v3 形式の CSV から磁気チャンネルを読み取る任意の [magnetic_grid]（csv_path、column）を受け付けます。EMAG2 は、利用条件が明示されていないため同梱していません：tools/fetch_emag2_tile.py が SHA-256 を固定して取得し、領域を切り出します。実際の EMAG2 グリッドでの航法結果は主張していません。地図の同時推定（地形 SLAM、RM-18）：altpnt::sequential::run_sequential_trn_on_map は、真値と異なる保存済みの地図の上で逐次地形航法器を飛行させ、その地図を信頼するか、FastSLAM 型の Rao-Blackwell 化フィルターでセルごとの地図補正を推定します。15 m の相関地図誤差に対して、既知地図の SITAN と照合する事前登録を行い、20 個のシードで平均 1.5 % の改善、20 個中 10 個で改善となり、改善の合格基準はどちらも NOT MET（10 % と 20 個中 12 個）でした。完全な地図での悪化はありません（MET）。再訪のない単一の飛行では、地図を学習できません（xval/terrain-slam-rbpf/、MODELLED）。terrain-slam のドキュメントはバイト単位で同一です。実際の SRTM のテストは、コミット済みの二つのフル解像度の切り出しを使って CI で実行されるようになりました。事前登録した合格基準はすべて満たし、最近傍ノードは 8 点中 8 点で GDAL 3.8.4 と一致します（xval/srtm-ungate/）。

• 相互運用性、WP-08（0.36；各項目は、そのオラクル実行の前に単独で事前登録してコミットしており、テレメトリー項目が既存の行を広げているのを除き、いずれも新しい VALIDATED の台帳（ledger）の行です）：

  • CCSDS 軌道データメッセージ（src/odm.rs）：OPM 3.0/2.0、OMM 3.0/2.0、OCM 3.0（TRAJ、PHYS、COV、MAN、USER ブロック）を KVN と NDM/XML で書き出し・読み込みでき、SGP4 要素セットからのフル精度の OMM も扱います（OmmMessage::from_omm_file）。OmmFile::to_omm_kvn の出力は変わりません。Orekit 13.1.8 と双方向で照合：Kshana のメッセージ 30 件中 27 件が Orekit で解析でき、Orekit が書き出したものは Kshana がすべて読み取れます。値は相対 1e-14 以内、エポックは 1e-9 s 以内で一致します。四つの所見を固定しました（Orekit は ELEMENT_SET_NO を必要とし、XML のユーザー定義パラメーターでの COMMENT を拒否し、BSTAR なしでは BTERM を書き出さず、OCM の相対エポックを SI 秒の TDB で読みます）。従来の OMM ライターの META_START は Orekit に拒否されます（記録済み）。行「CCSDS 軌道データメッセージ（OPM、OMM、OCM）」。
  • CCSDS 姿勢データメッセージ（src/adm.rs、src/ndm_xml.rs）：AEM 2.0/1.0 と APM 2.0 を KVN と XML で Orekit 13.1.8 と照合し、すべての合格基準を満たしました。Orekit の APM ライターは、MAN_DELTA_MASS のない軌道変更を拒否します（固定済み）。行「CCSDS 姿勢データメッセージ（AEM、APM）」。
  • SPICE SPK エクスポート（src/spk_writer.rs）：SPK タイプ 9 と 13 のライターとリーダー、および OEM から SPK へのエクスポート。CSPICE N0067 と照合し、カーネルは SPICE のものとバイト単位で同一で、評価結果もビット単位で同一です。行「SPICE SPK エクスポート（タイプ 9 と 13）」。
  • SPICE SPK タイプ 3 と 21（src/spk_writer.rs）：タイプ 3（チェビシェフ）とタイプ 21（拡張差分線）のセグメントを、与えられたレコードから書き出し、SPICE と同じ方法で評価します。CSPICE N0067 と照合し、カーネルは SPICE のものとバイト単位で同一で、すべての評価が双方向でビット単位に一致します。行「SPICE SPK タイプ 3 と 21（チェビシェフ、拡張差分線）」。
  • Space Packet の拡張（src/space_packet.rs）：CUC/CDS 時刻コードを持つ二次ヘッダー、パケット誤り制御、セグメンテーションとストリームの検査を、ccsdspy 2.0.1、spacepackets-rs 0.18.0、spacepackets-py 0.32.0、CPython の crc_hqx と照合し、不一致はゼロでした。行「CCSDS Space Packet の二次ヘッダー、パケット誤り制御、セグメンテーション」。
  • 実際のコンシューマーを通したテレメトリースキーマ 1.3：スキーマ 1.3 の合成ストリームの Prometheus エクスポジションと OTLP/HTTP JSON（ジオメトリ系列と class ラベルを含む）は、prometheus_client と OTLP proto で正確に読み取れ、promtool 3.5.0 の check metrics でリントの問題なく受理され、OpenTelemetry Collector contrib 0.135.0 を変更なしで通過しました（データ依存：ツールは SHA-256 を固定して取得し、出力はコミット済み）。

• 火星の軌道決定、実行 2（0.36、WP-14、CAP-30）：mars_od::fit_damped は、法線行列を対角成分でスケーリングし、ステップを減衰させます（Levenberg-Marquardt）。これは、生の対角成分が八桁にわたる行列で、登録済みの Gauss-Newton フィットが失敗したためです。別途登録しています（xval/mro-od/PREREGISTRATION-RUN2.md、同じアーク、合格基準、編集）。採点対象の MRO パスでは、軌道は MRO 航法再構成から RMS で 0.36 km 以内（最大 0.53 km）で、合格基準を満たしました。フィット後のドップラーは 48.6 mHz で、合格基準の 30 mHz を満たしていません（所見を固定）。採点のみの修正 R2-A1 は docs/revisions に開示しています。この行は MODELLED のままです。

• 火星のランプ型 2-way ドップラーモデルと軌道決定（0.36、WP-14、CAP-30 の一部、ステージ 2）：mars_od は、ODF のランプテーブルから DSN のランプ型 X バンド 2-way ドップラーを予測し（光行時間、シャピロ、対流圏、局時刻、CIO 連鎖と IERS EOP による DSN 局）、火星周回機をフィットします（GMM-3、第三天体、SRP、大気抵抗）。naif_kernel は SPK タイプ 1 を読み取り（CSPICE と照合済み）、gravity_sh::from_shadr は PDS SHADR のフィールドを読み取ります。実際の MRO パスでの MRO 航法再構成に対して事前登録を行いました（データ依存、scripts/fetch_mro_od.sh、月次 CI）：予測したドップラーは観測と 12.5 mHz で一致し（合格基準 30 mHz、満たした）、登録済みの軌道フィットは採点対象のアークで失敗して軌道を生成しませんでした（所見を固定）。この行は MODELLED のままです。

• DSN 軌道データファイルリーダー（0.36、WP-14、CAP-30 の一部）：odf::parse_odf は TRK-2-18 の ODF を読み取ります。実際の Mars Reconnaissance Orbiter の ODF（NASA PDS、同梱）では、リーダーは PDS ラベルのレコード数、グループ位置、局、時刻と一致し、すべてのデータタイプが既知です。ラベルのファイル末尾のテーブルはファイルより一行少なく、ラベルの不整合として所見に記録しています。MODELLED。これらのデータでの軌道決定は、まだ行っていません。

• TWSTFT バジェットと時刻比較の安定度：time-transfer-budget 種別（0.36、WP-14、FUT-19）。

  • 双方向の式： twstft_budget は、これを局の装置遅延、Ku バンドの電離圏の上り下り非対称、トランスポンダー遅延差、Sagnac 項を加えて T_A − T_B について解き、順方向モデルを 1e-15 s で復元します。
  • 不確かさバジェット：二乗和平方根で合成し、リンクの TDEV を A タイプの項とします。
  • リンク雑音：双方向の系列に、フリッカー位相雑音の下限、日周の非相反性、定数の相反性残差が加わります。ホワイトジッターの timetransfer パックは変わりません。
  • 実系列：与えられた BIPM Circular T、MJD,ns CSV、または IGS 局クロック系列の安定度。

  MODELLED。新しい同梱シナリオ time-transfer-budget。PPP 時刻解は、GNSS 実データのブランチで IGS 局クロックと照合して、別途 VALIDATED です。

• 突入加熱、EO 放射計測、上昇時の損失（0.36、WP-14、CAP-28）：三つの新しい種別。

  • entry-heating：自転する地球または火星の上での3-DoF の質点による突入で、Sutton-Graves のよどみ点加熱を含みます。
  • eo-radiometry：撮像装置の SNR、ナイキスト周波数での MTF、相対エッジ応答、GIQE 4 の NIIRS。
  • ascent-losses：重力、抗力、操舵、背圧の損失を含む多段の重力ターン上昇で、理想 dv から損失を引く厳密な恒等式で検査します。

  突入時のピーク減速度は、事前登録した合格基準のもとで、公表されている Stardust の公称値と照合しました：35.44 g に対し 33.4 g（+6.1 %、合格基準 10 %）。この行は VALIDATED です。加熱、放射計測、上昇は MODELLED です。さらに新たに、reentry::us76_pressure、同梱シナリオ entry-heating-stardust、eo-radiometry、ascent-losses、および docs/ENTRY-EO-ASCENT.md があります。

• リアクションホイールによる姿勢制御：aocs 種別（0.36、WP-14、CAP-21）。MRP フィードバックのもとで、三つ以上の釣り合ったリアクションホイールを持つ剛体ハブの慣性指向スルーで、最小ノルムのホイールトルクを各モーターの上限でクリップします（aocs）。シミュレートしたジャイロとスタートラッカーから、乗法 EKF でループを閉じることもできます（aocs_mekf）。真値状態のループは、コードが存在する前に事前登録した三つのケース（直交する三つのホイール、四つのホイールのピラミッド、飽和するケース）で Basilisk 2.9.1 と比較しました。すべての MRP 成分、機体角速度、ホイール回転数、モータートルクが、すべてのサンプルで一致し、最悪値はシグマで 2.4e-14、ホイール回転数で 2.9e-11 rad/s でした。この行は VALIDATED で、MEKF は MODELLED です（NEES の整合性）。新しい同梱シナリオ aocs-slew と aocs-slew-mekf、および docs/AOCS.md。

• 地上局コンタクトのスケジューリングと DVB-S2 ACM（0.36、WP-14、CAP-22/23）：二つの新しいシナリオ種別。acm-link は、一機の衛星が一つの局の上を通過する場合について、各パスの Es/N0 と、その間に選ばれる DVB-S2 の MODCOD（ETSI EN 302 307-1 Table 13 のしきい値にマージンを加えたもの）を示します。また、ACM が一定符号化のベースラインに対して運べるデータ量も示します。contact-schedule は、複数の衛星が複数の局の上を通過する場合について同じことを行い、競合のないコンタクト計画（アンテナの切り返し、衛星ごとに一局、各バックログを上限とする優先度重み付きの配信）を作ります。限界価値に基づく貪欲法の計画、先着順のベースライン、小さな集合での厳密な最適解を報告し、貪欲法の最適性ギャップも示します。アクセスウィンドウは、VALIDATED の見かけのパス予測器から得ます。新しい同梱シナリオ acm-link と contact-schedule（例示用の入力）、および docs/CONTACT-SCHEDULING.md。MODELLED（新しい台帳（ledger）の行が二つ）。

• 公表された実験と照合する Starlink ドップラー測位（0.36、WP-14、CAP-11 の一部、MODELLED）。これは、leo-pvt のドップラーモードと starlink-sop プリセットを、「Unveiling Starlink for PNT」（NAVIGATION 72(1)、2025、doi:10.33012/navi.685）のデータセット3のパーセンタイルと比較する、事前登録した代理比較です。モデルは、3 機の衛星（固定の規則で選んだ 47 度のマスク）、高度補助なし、30 Hz のドップラーシグマを用い、200 個のシードで行いました。90パーセンタイルの 3-D 誤差は、20 s で 92.2 m、8 s で 870 m であり、公表値の 2 m と 10 m に対して、二倍の合格基準はどちらも NOT MET です。モデルは、予測とは逆に楽観的ではなく悲観的でした：固定された三つの衛星は、実験の 63 機の衛星を 10 分間、15 s ごとのチャンネル切り替えで使った場合と比べて、幾何学的な多様性がはるかに乏しいためです。どちらの未達も、アサートしています（tests/starlink_doppler_published_proxy.rs）。

• DE440 に基づくインパルス遷移の最適化器（0.36、WP-14、CAP-20c/d）：maneuver::optimise_transfer_kernel は、Type I または Type II の範囲で、出発 C3 または到着 V-infinity を最小にする、単一周回の弾道 二インパルス遷移の出発日と到着日を求めます。2日のグリッドで探索し、その後 2-D Nelder-Mead で精緻化します。DE440 カーネルによる太陽中心の状態を用い、porkchop_kernel を土台にしています。比較は、独立した SPICE + pykep 3.0.1 + SciPy 1.18.1 の最適化器に対して、2026 年の地球から火星への機会で事前登録しました（bf0439e8）：四つの最適化すべてが相対 8.7e-13 で一致し、日付は 1e-5 日以内でした（VALIDATED、新しい台帳（ledger）の行）。副次的な公表参照として、NASA/TM-2010-216764（2026-2045 年の地球から火星へのハンドブック）とは、Type II の最小 C3（9.182 対 9.144）と Type II の最小到着 V-infinity（2.564 対 2.565）が一致しました。Type I の最小 C3 は一致しません：10.535 対 11.11（-5.18 %）で、ライブラリのオラクルは Kshana と一致しています。この未達は記録し、アサートしています。

• 月面基準局の研究（0.36、計画されている月の南極基準局に関する公表資料を受けたもの。出典は docs/LUNAR-REFERENCE-STATION.md）：lunar-station-coverage 種別は、月の差分 PNT モデルを、南極域のユーザーグリッドと一日分のエポックにわたって行うモンテカルロ掃引で、各点と領域全体について、補正後と補正前の誤差のパーセンタイル、理由つきの可用性、指定したしきい値に対するカバレッジ、保護レベル、方位ごとのカバレッジ半径、補正リンクのバジェットを与えます。一点、一エポック、一試行では lunar-differential-pnt に厳密に帰着します。その演算は、事前登録した合格基準のもとで numpy により再計算しました（位置とパーセンタイルは満たし、局の補正は倍精度の丸めにより基準に届かず、記録済み）。MODELLED。台帳（ledger）の行「月面基準局のカバレッジと精度のマップ」。いかなる機関とも提携しておらず、その承認も受けていません。実在のいかなるシステムの性能についても、何も述べていません。

• 事前登録した予測：月面基準局のカバレッジ（検証ではありません。MODELLED）。docs/predictions/lunar-reference-station.md は、コミット c05dac1d で、公に示されている仮定のもとでの lunar-station-coverage の結果を、入力と結果の SHA-256 ハッシュとともに凍結し、採点プロトコルを今回固定します（精度と保護レベルは係数 2、可用性とカバレッジは 10 パーセントポイント。仮定が変わった場合は編集せず、日付を付けた新しい予測とします。外れた場合も、当たった場合と同じく目立つように公表します）。すべての数値は、四機のコンステレーションの非公開の要素セットに支配されており、これはILLUSTRATIVEであり、その旨を明記しています。tests/prediction_frozen.rs がこれを守り、docs/VALIDATION.md には「事前登録した予測」セクションが加わります。台帳（ledger）の行はありません。

• 月面基準局の拡張（0.36；局の研究の制約 2 と 3、および出典の解の方式）：それぞれ lunar-station-coverage でオプトインであり、既定では存在しないため、凍結した予測を含む既存のすべてのドキュメントは変わりません：[receiver]（ユーザーと局でのマルチパス a + b exp(-el / el0)、エポックにわたり局のものを任意でガウス・マルコフとする設定、C/N0 に由来する DLL コード雑音、チャンネル間バイアス。月での値はILLUSTRATIVE）、orbit_err_growth_m_per_s（補正の遅延にわたる放送軌道誤差の線形増加、ILLUSTRATIVE）、[solution]（高度拘束、それを使う場合の最小三機、エポックにわたる静止ユーザーのウィンドウ）。公表された主張との比較への二つの補遺は、それぞれの実行の前に単独で事前登録し、編集していない記録済みの実行の隣に置きます：成長を伴う K5 はすべてのレートで失敗し、出典の解の方式では K1 から K5 が失敗して K6 が通過し（6 件中 1 件）、R300 の補正後 p95 の 3-D 誤差は 280.6 m から 2.11 m に下がります。MODELLED。台帳（ledger）の行が三つ。

• 月面の地形による地平線マスク（0.36；月面基準局の研究の第一の制約）：lunar-station-coverage（局とすべてのユーザー点）および moonlight-service-volume（すべてのグリッド点）の任意の [terrain] セクションは、各地点に方位依存の地平線を、0.36 のスカイライン表形式で与えます。これは、出典を明記した指定のプロファイル（station_horizon、user_horizon）か、月の球面の大円に沿って厳密な曲率で極域 DEM（dem_path）上をレイマーチングした結果か、またはその両方によります。パブリックドメインの LRO LOLA LDEM_75S_240M 南極 DEM の 0.98 MB の切り出しを、5 x 5 のブロック平均で 1200 m に再サンプリングして同梱し（data/lunar-dem/、NOTICE、SHA-256、scripts/make_lola_south_polar_crop.py を含む）、リポジトリ限定のシナリオ scenarios/lunar-station-coverage-terrain.toml も同梱します。閉形式の地平線（裸の球、台地の中のクレーター、ラスタライズした円錐）と照合して検査しました。MODELLED、台帳（ledger）の行「指定したプロファイルまたは極域 DEM による月面の地形地平線マスク」。このセクションがなければ、単位ブロックを含むすべてのドキュメントがバイト単位で同一です。

• ジオメトリを考慮した信頼性（0.36 ジオメトリ設計ノート、セクション 4）。すべての receiver-trust エポックは、静止でも船舶でも、バッチでもライブでも、衛星ジオメトリを持ちます：good、degraded（理由は few-satellites、high-pdop、high-hdop、および情報としての sky-blocked）、またはログに衛星ジオメトリがない場合は unknown で、HDOP、PDOP、VDOP、使用した衛星を伴います。これは、受信機が報告する仰角と方位角（NMEA GSV、UBX NAV-SAT）から、既存の orbit::dop カーネルを通じて導出するか、NMEA GSA から取ります。すべてのエポックはまた、good、fair、poor のいずれかのラベルを持ち、これは常に報告されて採点されることはなく、HDOP、PDOP、VDOP、衛星数、信号喪失を言葉で述べた注記もあります。船舶のスコアには geometry モニターが加わり、ジオメトリが不良（HDOP が 4 を超える、PDOP が 6 を超える、または使用した衛星が 5 機未満）でない限り何も減点せず、その後 15 点の上限まで傾斜的に増えます。ジオメトリだけでは、最大でも degraded の帯域に達するにとどまり、untrusted の帯域には決して達しません（アラームなし）。すべての減点にはクラス geometry、environment、inconsistency が付くため、不良な天空が攻撃と読まれることはありません。loss-of-lock は、失われた衛星がすべて、最後の報告で 15 度未満だった場合に geometry となります。ジオメトリ不良による減点は、受信機が示す HDOP が、その示す天空と、max(1.0、導出した HDOP の 25 %) を超えて食い違う場合に inconsistency となるため、偽造した不良な天空でラベルを得ることはできません。新しい [geometry] テーブルは、すべてのしきい値を出所とともに示します（HDOP 4、PDOP 6、使用衛星が少なくとも 5 機、sigma_UERE 1.5 m、max(1.0、導出した HDOP の 25 %) の HDOP 許容差（この 25 % は、コンステレーションごとの時計またはサブセット解を持つ受信機に対する代表的な選択）、15 度。IEC 61108-1 と GPS SPS の数値は引用のとおりで、規格の本文に照らして確認する必要があります）。信号の全喪失は天空としてはラベル付けされません：視界にある衛星が追尾されておらず、視界にある衛星の DOP が良好で（かつ追尾されていないものが地平線の半分に偏っていない）場合、エポックは signal_loss を持ち、ジオメトリの減点は environment になります。示された HDOP または PDOP が 99 以上、GGA の品質が 0、GSA のモードが 1 の場合は、DOP ではなく測位不能として読みます。上限（cap_points 15）、傾斜の終端（full_ratio 1.5）、下限（floor、既定はスコアの degraded_min）は [geometry] にあり、ラベルの良好な水準（HDOP 2、PDOP 3、6 機の衛星、代表的）も同じです。有効な上限は min(cap_points, 100 - floor) であるため、degraded_min を引き上げる [score] テーブル（0.35 のものを含む）は、拒否されずに上限を下げ、degraded_min を下回る下限は拒否されます。MODELLED。助言用ソフトウェアであり、型式承認を受けた航法装置（IEC 61108、IEC 61162）ではありません。船舶の航行の責任は引き続き運用者にあります。

• ジオメトリは、あらゆる出力面に届きます：結果の JSON（epochs[].geometry、すべての減点の class、geometry_model、geometry_summary）、ライブの JSON 行（スキーマ 1.3）、Python と WebAssembly の receiver_trust、assess_vessel_log、receiver_trust_replay、MCP の assess_* ツール、エビデンスパック（epochs.json、config.json、サマリーページのジオメトリのレーン）、および trust-telemetry（Prometheus の kshana_trust_geometry* と kshana_trust_reason_active の class ラベル、OTLP の kshana.geometry.*、CEF のカスタムフィールド cs6（ジオメトリの状態とクラス）、cfp3（HDOP）、cfp4（PDOP）。CEF の二つのオラクルパーサーの両方で検査済みです。LEEF の geoStatus、geoHdop、geoClass）です。ジオメトリのラベルもエクスポートされ、それ以前のすべての系列とフィールドの後ろに追加され、ラベルを持つ入力に対してのみ出力されます：Prometheus の kshana_trust_geometry_label{label} と kshana_trust_geometry_vdop、OTLP の kshana.geometry.label と kshana.geometry.vdop、LEEF の geoLabel、geoPdop、geoVdop、geoUsed、そして CEF では三つ目の cs6 フィールド（ラベル）と cn1（使用した衛星）です。VDOP は CEF には含まれません（浮動小数点のカスタムフィールドはすでに使われているため）。CEF の二つのオラクルパーサーはどちらも、ラベルのケースを書いたとおりに読み戻せました（修正 5：176 行、pycef で 172 行、Logstash で 176 行を解析）。示された HDOP が示された天空では説明できない場合は、すべてのエポックにフラグが付けられて計数され（geometry_summary.hdop_mismatch、エビデンスのサマリーページの一行）、ジオメトリが不良の場合にのみ採点されます。信号喪失は、それが続く間ジオメトリの状態が degraded のままであるため、単独でエクスポートされます：Prometheus の kshana_trust_geometry_signal_loss、OTLP の kshana.geometry.signal_loss、LEEF の geoSignalLoss=1。CEF では、cs6 の environment クラスとして現れます。

• orbit::dop_cofactor：orbit::dop の背後にある共分散因子 (HᵀH)⁻¹ で、同じ演算でそこから切り出したものです。

• 台帳（ledger）の行「ジオメトリによる位置誤差：RMS 誤差 = sigma_UERE x DOP」（MODELLED、内部整合性）：gnss_lib_py と整合させた 8 個の DOP ジオメトリに対するエンジンの最小二乗解を、シードを与えたモンテカルロで、検証済み DOP カーネルの共分散因子と照合します。許容差は最初の実行より前に事前登録しており、必ず失敗する二つのネガティブコントロールも含みます。これに並べて、手で選んだ四つの天空に対する以前の検査を、カイ二乗信頼区間つきで、事前登録の前に行った実行として報告します。

• 方位依存のスカイラインマスク（src/skyline.rs、docs/SKYLINE.md、設計ノート項目 1）：方位に依存する仰角のカット、表の点ごとの最大値（それぞれを個別に補間し、360° で折り返す）、閉形式の街路の谷（端の開放は任意）、鋭いエッジを持つ扇形、地球の曲率を考慮した地形プロファイルで構成します。有効なカットは max(mask_deg, skyline) です。出所を明記した四つのREPRESENTATIVEなプリセット（city-street、harbour-approach、fjord、container-terminal）があり、フィールドごとに上書きできます。任意の [skyline] セクションは、gnss-sim、jamming、leo-pvt（極域掃引を含むすべてのモード）、leo-pass と nmea-scenario の訓練ファイル、さらに新しい地上局ユーザー user_site = { lat_deg, lon_deg, height_m } を通じて orbit と integrity で使えます（回転する地球上の測地的な視角で、ARAIM の水平・垂直の分割には測地的な上方向を用います。各サンプルは絶対時刻の一時点 epoch + t であり、要素セット、放送エフェメリス、SP3 ファイルは、それぞれのエポックからそこまで進められます。epoch の指定がない場合は、最も新しい衛星エポックから日付を付けます。周回する user はスカイラインを拒否します）。結果には skyline { source, open_fraction, provenance } とサンプルごとの masked_by_skyline が加わります。セクションがなければ、すべてのシナリオは 0.35.0 とバイト単位で同一で、これはリリースコミットのダイジェストと照合して確認しました。六つの同梱例：orbit-urban-canyon-skyline、integrity-harbour-approach、gnss-sim-container-terminal-skyline、jamming-harbour-approach-skyline、leo-pvt-fjord-skyline、およびキャンペーン leo-vertical-autonomous-vehicle-skyline（自律走行車の谷を、平坦なカットと街路の両方で扱います。既存のキャンペーンは変わりません）。MODELLED。

• 天空ジオメトリ関数（src/geometry.rs、設計ノート項目 2）：sky_geometry（地点、時刻、コンステレーションのプリセット、二行要素セット（tle、最大 4 MiB、エンジンの SGP4 で UTC の epoch まで伝搬）、または与えられた衛星から、可視と遮蔽された衛星を求めます。sky_source と sky_statement は、天空が代表的なものか、要素セットがそのエポックで与える天空であって測定ではないことを示します。tle_skipped は未使用のすべての行を理由つきで列挙します。入力の上限は、水平線より上の衛星が 2000 機（システムテーブルを構築する前に検査）、受信機クロックが 16 個です。五つの DOP、システムごとに一つのクロックまたは共通の一つのクロックを使った ENU の余因子と共分散、一シグマおよび指定した信頼度での水平誤差楕円を含みます）、sky_monte_carlo（シードを与えた最小二乗の誤差、最大 5000）、skyline_presets、skyline_profile、skyplot_svg。orbit::dop_cov は、今ではその縮約となった orbit::dop の背後にある共分散を公開します（検証済みのスカラーは変わりません）。出力面：kshana sky と kshana skyline、同名の Python と WASM の関数、MCP ツール sky_geometry（40 個のツール）、およびノートブック notebooks/geometry.ipynb（.md のミラー付き。tests/python/test_notebooks.py が実行）。すべての結果に、MODELLED のラベル、誤差モデルの記述、助言が付きます。

• 台帳：スカイラインと天空ジオメトリの五つの行。VALIDATED、いずれもオラクルを実行する前に事前登録した比較によります：方位依存のスカイラインマスク：可視集合、方位と仰角、マスク下の DOP は、Orekit 12.2（TopocentricFrame、ElevationMask）と gnss_lib_py 1.0.4（get_dop）に対して、視角とマスクの差の最悪値は 1e-9° に対し 1.1e-12°、可視集合は同一、DOP は相対 3.3e-13（xval/orekit-skyline/）。ジオメトリの共分散からの水平誤差楕円とシステムごとの余因子 は、numpy の linalg.inv と linalg.eigh（標準 P2）に対して、270 ケース、軸は相対 5.1e-13（xval/numpy-ellipse/）。MODELLED：谷、扇形、地形の縮約、プリセット、天空ジオメトリの合成（プリセット天空、モンテカルロの点群）。

• ジオメトリ信頼性、スカイライン、月面基準局の行を加えて、台帳は 274 行になりました：独立した参照と照合して確認済みが 134 行、モデルから計算が 136 行、パートナー担当が 4 行です。

• 月面基準局：局の時刻ラボ（MODELLED）。lunar-time-budget の任意の [time_lab] ブロック（src/lunar_time_lab.rs）。局のクロック（既定は miniRAFS クラス、名前を指定した任意のクラス、または指定した安定度の点に合わせた装置カード）を LTC に同期させ、その後フリーランまたは N 秒ごとに再同期するものとしてモデル化します。時刻誤差曲線 x(t)、1、10、100 ns に達するまでの時間（閉形式と並べた二分法）、各ホライズンでの支配的な項を、すべて単位つきで出力します。同期の残差はILLUSTRATIVEです。LTC のレートは再導出しておらず、独自の VALIDATED の行を保持します。公開された ICG WG-B 月面 PNT 資料（2024 年6月）のナノ秒レベルの目標は、主張ではなく出典の記述として引用します。クロックの順序 optical < PHM < RAFS < miniRAFS は 1 s から 7e5 s まで成り立ち、テストは PHM と RAFS の曲線が 7.5e5 s 付近で交差することを固定しています。この交差は、単一の雑音型のクロックモデル（純粋なフリッカー FM と純粋なホワイト FM）の性質であり、物理的な結果ではありません。ブロックがなければ、レポート、その表、そのサマリーは変わりません。例：scenarios/lunar-station-time-lab.toml。台帳（ledger）の行を一つ追加し、MODELLED と表示します。

• 月面基準局：局の測地（MODELLED）。lunar-llr-datum の任意の extra_reflectors と extra_beacons の入力が、station_geodesy ブロックを加えます。アーカイブされたレーザー測距の一部から得た五つの配列のデータム情報を、指定した地点に追加したレトロリフレクターと追加した VLBI ビーコンが寄与する分と組み合わせます。リフレクターは、見えるアーカイブ済みのエポックで、アーカイブ済みの重みを使って測距します。ビーコンは、局を固定したまま、lunar-frame-campaign のネットワークとスケジュールを使います。ブロックは、各 Helmert の 1-sigma を前後で示し、その比も示します。これらは、削減したパラメーター集合に対する Cramer-Rao 下界で、ILLUSTRATIVEのスケジュールと地点に基づきます。入力がないか空であれば、レポートはバイト単位で同一です。例：scenarios/lunar-station-geodesy-baseline.toml と -with-station.toml。台帳（ledger）の行を一つ追加し、MODELLED と表示します。

• 月面基準局：公表された主張との比較（MODELLED）。五つの公開資料にあるすべての数値の主張を、正確な文言、ページ、示された仮定とともに列挙し、比較可能、一部比較可能、比較不可能に分類しました（tests/fixtures/lunar_station_published/CLAIMS.md。出典の URL、取得日、SHA-256、ライセンスは tests/fixtures/lunar_station/SOURCES.md にあります）。一部比較可能な主張は、実行の前に事前登録した六つの片側の合格基準で採点しました（PREREGISTRATION.md、改訂 2、05bf9a19）：6 件の主張のうち 1 件が事前登録した合格基準の範囲内でした（事前登録 05bf9a19）。カバレッジは、南極側の両方の円で、0.95 以上に対して 0.00 であり、補正後の p95 は 1.5 m 以下に対して 280.6 m です。原因は、どの資料も公表していない衛星の軌道要素です。ILLUSTRATIVEの同梱要素では、8 % のエポックで四機の衛星が共通視野にあり、ジオメトリは特異点に近い状態です。この実行は、それらの要素ではこれらの主張を再現しておらず、主張が誤りであることの証拠でもありません。tests/lunar_station_published_oracle.rs で固定しています。台帳（ledger）の行は一つで、MODELLED と所見を表示します。

• 月面基準局：クロックファイルのデータ準備状況。realdata::clk::rinex_clock_series は、エポックの時刻系を明示するようになりました。これは TIME SYSTEM ID の値であり、宣言がない場合はヘッダーの衛星システムの既定です。結果には、その時刻系が宣言されていたかどうかも示されます。この関数は、未知の時刻系（たとえば月の時刻スケール）、宣言のない混合システムのファイル、食い違うファイルを、GPS 時刻として読まずに拒否します。合成の局クロックのフィクスチャを同梱します。補正ファイルのフォーマットは定義していません。公開されたものが存在しないためです。

変更#

• fusion::ukf、fusion::tightly_coupled、fusion::gnss_ins_ekf のモジュールドキュメントは、17状態の UKF 航法器、フル INS の密結合、明示的なクロック状態を、今後の課題とは呼ばなくなりました。代わりに hybrid_ukf、tightly_coupled17、carrier_tc を指しています。

• RINEX 4 はもう拒否されません（0.36、WP-07）：RINEX 4 の航法ファイルは、以前は意図的に拒否していましたが、現在は読み取れます（Added を参照）。バージョン 4 以降の観測ファイルでは、ヘッダーのラベルを 61-80 桁目のみで照合するため、新しい自由記述のレコードがラベルとして通ることはありません。

• ionex::parse_ionex が実際の IONEX ファイルを読み取ります（0.36、WP-07）：16値の完全なレコードは 61-80 桁目を埋め、リーダーはそれをラベルと誤認したため、すべての実際の IONEX ファイルで None を返していました。現在は、ラベル欄が数値であるレコードを値として読みます。出荷済みの出力でこれを使うものはありませんでした。

• Galileo E1 と E5a の受信電力を OS SIS ICD Issue 2.1 に合わせました（改訂、2026-10-14）。galileo-e1 と galileo-e5a のスペクトル帯域と、そこから電力を取る LEO 信号の GNSS 被害側は、Galileo OS SIS ICD Issue 2.1 の Table 12 の最小受信電力を使うようになりました：−157.25 dBW（従来は −157.0）と −155.25 dBW（従来は −155.0）。

  • 九件のシナリオ結果が変わります：スペクトルの例、スペクトルのキャンペーン、三つの LEO レジリエンス垂直領域、三つの LEO 信号設計です。これらの帯域では、実効 C/N0 が −0.25 dB、J/S が +0.25 dB 動きます。
  • 変わったすべての値（1766 個、旧 → 新）は、変更のあったドキュメントの表とともに、docs/revisions/CAP12-galileo-icd21-power-changes.md とその CSV に列挙しています。台帳（ledger）の行のステータスは変わりません。
  • 同日の第二部：LEO 信号の被害側 galileo-e5b（−155.0 → −155.25 dBW、Table 12 の E5b）と galileo-e5-altboc（−152.0 → −152.24 dBW）。ICD には E5 全帯域の行がないため、AltBOC の値は Table 12 の E5a と E5b の合計の電力和であり、従来の値と同じ方法で構成しています。三つの LEO 信号設計の結果が変わります（64 個の値：これらの受信電力と、二つの被害側での LEO から GNSS への C/N0 劣化）。同じ改訂（§5）と CSV に列挙しています。それ以外は何も変わりません。

• S2 大気潮汐の修正（tides::atmospheric_tide）。Ray（2001）の S2 気圧調和係数は、余弦位相遅れを伴う非正規化の P_nm の係数ですが、完全正規化として、遅れを IERS の正弦の進みとして使っていました。現在は、N_nm で割り、ε = 90° − ψ を使って入力されます。新しい tides::s2_air_waves は、GFZ STR06/01 Table 5 のモデル A2 を、21 個の波すべてについて再現します（最悪値 0.0005 cm、0.05°。VALIDATED）。潮汐を有効にした出力のみが変わります：Galileo の CI フィットは 0.132 → 0.133 m、Swarm-A の成分は 1–2 mm です（xval/s2-air-tide-fix/ に事前登録）。

• ドキュメントのみ：propagator::solve_kepler_checked、orbit::solve_kepler、ephem::solve_kepler は旧式のソルバーとして文書化され、数値は変わらず、kepler::solve_kepler_markley を指しています。

• D9 ラウンド 3（utck_bound）の状況。BIPM Circular T 465 は 2026-10-12 に公表されました。事前登録した前向きの採点は、まだ実行していません：号 465 には約 285 個のテスト値があり、停止規則は 1000 個を必要とするため、およそ号 465–468 になります。この実行には、アーカイブ済みの 2026-09-30 の研究所ごとのファイルも必要です。BIPM がその後、113 個のうち 87 個を書き換えたためです。台帳（ledger）の行とテストのヘッダーにその旨を記しており、テスト、その合格基準、その分割は変わりません。

• ドキュメントの正確性の見直し（0.36）。ロードマップ、機能の行、設計ドキュメントのステータス行、モジュールのコメントをコードに合わせました。出力の変更はありません。すでに実装済みなのに未完了として挙げられていた項目に、完了の印を付けました：ITU-T マスクの検査、24 h のホールドオーバーシナリオとクロックログの取り込み（通信タイミング）、最初の一分間のクイックスタート、Lense–Thirring と Orekit の伝搬器のクロスチェック、ITRF 精密の GCRS 連鎖、ゴールデンとクロスプラットフォームのハッシュ、出所、複数故障の ARAIM（ADD v4.2）、単一衛星の FDE、CRPA ライブラリ、CAI のフリンジアンビギュイティの限界、カバレッジのストリート型サイジングと 3-D 軌道ビュー、剛体の姿勢ダイナミクス、OMM ライターと NAIF カーネルリーダー、DE440 の月の秤動、プレイグラウンドの実行の意味を述べる文、PositioningFom、17状態の密結合航法器、重力マップ種別。また、まだ未完了の部分も正確に記しました（たとえば orbit::Propagator の二要素 JD、実際のプロダクトに対する src/ionex.rs リーダー、raim の複数衛星の除外）。欠けていた docs/design/evidence/cn0-m2m4/RESULTS.md は、テストを新たに実行した結果から書きました（M1–M4 は通過）。パートナー向けの IQ 検証ドラフトには、現在の台帳の件数が入っています。

• Galileo E1 のメモリコードは、同梱されなくなりました。 data/galileo-os-sis-icd/C7_E1B.txt と C8_E1C.txt（ICD の Annex C.7/C.8）は、リポジトリとパッケージから削除しました。ICD の条件（LICENSING.md に引用）では、出典を明記すればユーザーがコードを保存して製品で使うことができますが、再配布は非営利目的に限られており、Kshana は商用ライセンスでも提供されています。galileo::e1b_table / e1c_table は Result を返すようになり、ユーザー自身のコピーを KSHANA_GALILEO_E1B / KSHANA_GALILEO_E1C から読み込みます。ソースのチェックアウトでは data/galileo-os-sis-icd/ から読み込み、そこには新しい scripts/fetch_galileo_e1_codes.sh が ICD の PDF から（ハッシュ検査つきで）抽出します。galileo::E1B_TABLE_TEXT / E1C_TABLE_TEXT は削除しました。テーブルがなければ、Galileo E1 信号（galileo-e1b、galileo-e1c）は、その入手方法を示すエラーを返し、E1 のテストはメッセージを出してスキップします。テーブルがあれば、E1 の出力はすべて変わりません。コードテーブルを使うシナリオ、ゴールデン、スペクトルの出力はありません。E5a の Annex C.3/C.4 のテストフィクスチャ（tests/iq_signals.rs の LFSR オラクル）も同じ方法で扱います：同じスクリプトで取得し、git の管理対象外とし、それがなければテストはスキップします。

• あらゆる場所での移植可能な数学関数（0.36、STUDIO-15）：ライブラリ内のすべての f64 の超越関数と、rand_distr の正規分布、ガンマ分布、指数分布のサンプラーは、純 Rust の libm（portable_math::PortableFloat、portable_distr）で計算するようになり、ネイティブビルドと WebAssembly ビルドは、同梱の 141 個すべてのシナリオと短い IQ 実行で、バイト単位で同一の結果 JSON を返します。その代償として、ホストの数学ライブラリで計算していた結果の最下位ビットが動きました：同梱の 141 個のシナリオのうち 98 個が変わり、43 個は変わりませんでした。5 個は最大のフィールドで 1e-3 を超えて変わり、残りはそれより小さな変化です。動いたすべての値は、docs/revisions/STUDIO15-portable-math-rebaseline.md に旧 -> 新で列挙しています（動いたすべての 136,127 個の数値の CSV つき）。合格基準、許容差、しきい値は変わっていません。公表している数値で変わったもの：europa-surface-pnt の可用性は、地球の範囲で 0.719 -> 0.713、RMS 誤差は 86.147 -> 86.499 m です（可用性の境界にある一つのエポックは、今ではどこでも同じ判定になります。macOS arm64 では 0.725 / 85.800 m と出力されていました）。lunar-joint-od-clock の局誤差は、VLBI ありで 3.541350 -> 3.536885 m、なしで 2183.558 -> 2184.021 m です。paper/crossover/inertial.json は、八つの vibration_psd の値が最下位桁で 3 単位動きました（技術報告書の正誤表）。公開済みの cislunar-observability ドキュメントは、丸め誤差の下限程度の量で変わりました（有効数字六桁を超える八つの値が、最大で相対 6.8e-5。順位もしきい値も動いていません）。バイト同一性ガード（skyline_scenarios、geometry_corpus_identity、geometry_trust_no_change）の固定ハッシュは、「0.36 portable」と名付けたベースラインに更新し、0.35.0 の値は履歴の記録として残しています。凍結した月面基準局の予測には手を加えておらず、その移植可能な再実行をその隣に保存しています（docs/predictions/*.portable-0.36.json）。tests/lunar_joint_od_numpy_oracle.rs（検証済みの月面ジョイント OD の行）：フィクスチャを再エクスポートし、numpy の比較を numpy 2.4.6 で再実行しました。登録したバージョン、スクリプト、合格基準は変えておらず、六つのネットワークすべてが通過します（docs/revisions/STUDIO15-lunar-joint-od-oracle-rerecord.md）。STUDIO-15 の後にマージしたバッチ 2-3 の作業も移植可能な数学関数を使っています（62 個のファイルの 457 か所の呼び出し）。それによって動いたものは docs/revisions/STUDIO15-batch4-rebaseline.md にあります：同梱の 12 個のシナリオ（最大の相対変化は 5.2e-8。表示される数値は動きません）、再承認した 28 個のスカイラインのガード行、iq_campaign の M2M4 ダイジェスト、従来の gnss-ins の真値のハッシュ、観測されていないビーコンのデータム シグマ（632.3769 -> 632.3772 m）、そして記録した二つの所見（CR3BP の DRO の閉合、CRPA A3、456 本のリンクのうち 194 本）。Greenhall の厳密な edf は、カーネルに倍々精度の対数を使って、検証済みの合格基準を保っています（docs/revisions/STUDIO15-greenhall-edf-portable.md）。gps-sdr-sim のtest bench オラクルは、動いた NMEA エクスポートで再実行し、すべての合格基準が満たされました（docs/revisions/STUDIO15-testbench-gpssdrsim-rerun.md）。

• README：月面スイートの行は、各部分のエビデンスのティアを示すようになりました（以前はすべて MODELLED と書かれていました）。

• realdata::clk::rinex_clock_series は、(PhaseSeries, GriddingLog) のタプルの代わりに RinexClockSeries（系列、グリッド化ログ、時刻系、宣言されていたかどうか、レコードタイプ）を返します。現在は、衛星（AS）のレコードから、指定した名前の受信機・局（AR）のレコードへフォールバックします。

• ジオメトリが不良でない限り、スコアは変わりません。ラベルは常に報告されます。ジオメトリが良好または並（GPS のみの開けた天空で 8 機の場合を含む）か、ジオメトリが不明（モニターが動作しない）の場合、すべてのスコアは 0.35 と同じです：tests/geometry_trust_no_change.rs は二つの例のセッションの出力を、tests/geometry_corpus_identity.rs はコミット済みのすべての船舶の NMEA コーパス（GPS のみの開けた天空も）と乗員訓練シナリオを、追加したキーを取り除いたうえで 0.35.0 のバイト列に固定しています。ジオメトリを不良にするジャミングを含む二つの訓練シナリオでは、不良なエポックは、ジオメトリの減点のみが異なります。ジオメトリが不良のログは、0.35 では失わなかった最大 15 点を失います。それ以外の意図した変更はすべて追加です：結果の JSON とエビデンスパックの上記のキー（score_model.weights は変わりません）。ライブの JSON 行スキーマは 1.2 から 1.3 になります（geometry が追加され、各減点に class）。抜粋のサマリーには geometry が加わります。テレメトリーには、ジオメトリの系列、フィールド、class ラベルが、それらを持つ入力に対してのみ加わるため、0.35 のストリームや結果は、以前とバイト単位で同じように表示されます。geometry は17番目のモニター名で、判定した場合（ログがジオメトリを与える船舶）には monitors_run の末尾に列挙されます（0.35 のリストは順序を保ち、サマリーのモニター数は一つ増えます）。また [score.weights] のエントリはありません（設定しようとすると拒否されます：その減点は [geometry] で設定します）。

• tests/fixtures/dop/NOTICE は gnss_lib_py のライセンスを Apache-2.0 としていましたが、1.0.4 のリリースは MIT です。

• NMEA リーダーは GSA を読むようになり（短い GSA はスキップとして数えず無視します）、信号なしでリストされた衛星を含め、GSV の仰角と方位角を保持します。UBX リーダーは NAV-SAT の仰角と方位角を保持します。C/N0 はこれまでと全く同じように読みます。

• 結果の変更：広帯域とスイープ型のジャマーは Q = 2 を使うようになります。アンチジャム式は、これらのジャマーに対して、以前は 1 を使っていた箇所で、教科書的なスペクトラム拡散の補正 Q を使います。Q = 2 は、主ローブにわたる白色雑音で、帯域内の信号電力を正規化したものです。テストでは、navsignal からの閉形式に固定しています。

  • 変更なし：CW と狭帯域のジャマー（Q = 1）、認識されないジャマー型（Q = 1、最も損害の大きい値）、および q_override。
  • 影響：広帯域またはスイープ型のジャマーが作用する箇所では、実効 C/N0 が最大 3.0103 dB 上がり、導出した J/S のしきい値が 3.0103 dB 上がり、自由空間での拒否半径は 0.7071 倍に縮みます。
  • 変更した同梱シナリオ：144 個のうち 12 個が変わり、すべて事前登録のとおりです（xval/jammer-q/PREREGISTRATION.md、結果は xval/jammer-q/RESULTS.md）：
    • jamming-demo：C/N0 +3.01 dB。
    • jamming-harbour-approach-skyline: min_tracking 6 → 7;
    • lunar-jamming：失われた衛星 26 → 0、ロックロスのスタンドオフ中央値 27.4 → 19.4 km。
    • tracking-loop：ループダイナミクスの拒否半径 75.2 → 53.2 km。
    • およびこれらを含むキャンペーンとスペクトルのクロスチェック。
  • 影響を受ける利用側：jamming、lunar-jamming、tracking-loop、impairment-eval の各種別、スペクトル種別の jamming_kind_cross_check、IQ キャンペーンの MODELLED の参照曲線と labfit の既定の Q、およびインターオペラビリティのシーンエクスポート。

• JetBrains プラグイン：非推奨または削除予定のプラットフォーム API は使っていません。五つの選択ダイアログは、非推奨の Messages.showChooseDialog の代わりに、ドロップダウン付きの小さな DialogWrapper を使います。単一ファイルの選択は、非推奨の FileChooserDescriptorFactory.createSingleFileDescriptor() の代わりに FileChooserDescriptor のコンストラクターを使います。アニメーションは、2026.3 プラットフォームで削除予定の browse(File) の代わりに BrowserUtil.browse(Path) で開きます。Since-build は 243 のままです。IntelliJ Plugin Verifier は、2024.3（IC-243.21565.193）、2025.2（IC-252.23892.409）、2026.2.3（IU-262.10968.63）、2026.3 EAP（IU-263.6259.32）に対して、非推奨または削除予定の使用なしで Compatible と報告します。verifyPlugin は、既定で 2024.3 を検査し、KSHANA_VERIFY_IDES に与えたリストがあればそれも検査します。

• gnss_sim::run_gnss_sim と jamming::run_jamming は Result を返します：無効な [skyline] セクションは、api::run_toml 経由ではすでにそうだったように、直接呼び出した場合もエラーとなり、平坦なマスクへの暗黙のフォールバックはしません。これら二つの関数を呼ぶ Rust の呼び出し側にとっては破壊的変更です。

修正#

• キャンペーンのスコアラー：実際のトラッカーの偽ロックが計数されていませんでした（iq::campaign）。トラッカーの偽ロック検査は、作動するとチャンネルを LOCKED から LOST に移します。スコアラーは代わりにそのチャンネルの次の更新に印を付けていましたが、それはすでにロック解除されていたため、計数されませんでした。LOCKED から報告された false-lock イベントは、その時刻における一つのエピソードとして、実行内と、それを含むすべての指定イベントで計数されるようになりました。プルイン中に見つかったもの、またはすでに LOST のチャンネルが繰り返したものは、新しいエピソードではありません。新しいテストは、実際の偽ロックを起こします：ロック中の正当な GPS L1 C/A 搬送波を 1/(2T) だけステップさせます（tests/iq_campaign_false_lock.rs）。

  • tests/iq_campaign.rs の参照キャンペーンでは、ramp/agc-3bit の PRN 11 だけが変わります（偽ロックのエピソードは 0 → 1、ロック時間あたり 426 と 437）。
  • そのセルの DIGEST は固定し直しています。
  • 事前登録した採点結果の固定は有効なままで、引き続き厳密に再現されます：そのハッシュでは、登録後に行ったこの修正で変わった六つのフィールドだけを、修正前の値に戻して対応付けます。修正後の値は、それとは別に固定しています。
  • 合格基準は変えておらず、VALIDATED の行、図、ウェブ上の数値も動いていません。

• lunar-frame-campaign：観測のないビーコンが報告されるようになりました（MR-05 で発見）。レポートには、観測のないビーコンがある場合にのみ unobserved_beacons と warning が加わり、その場合は、観測のあるビーコンのシグマが、すべて null になる代わりにそれ自身の情報から得られます。データムは変わらず、既定、同梱、公開のいずれの出力も動きません（docs/revisions/BEACON-unobserved-cell-changes.md）。

• 月の主慣性軸座標系（lunar_frame::icrf_to_moon_pa。lunar_od と LRO フィットで使用）：moon_080317.tf の DE421 の平均地球軸から主慣性軸へのオフセットは、向きが誤っており、オイラー角の順序も誤って適用されていたため、解析的な PA 座標系は PA 上ではなく約 208″ ずれていました。現在は、SPICE の Frames Required Reading の定義どおりに転記し、SPICE の pxform('MOON_ME','MOON_PA') と 2.6e-16 rad で一致します。解析的な PA 座標系は、DE440 の PA から 6″ から 8″ の範囲にあります（事前登録 e1ead19b。最初に提案した変更が 1e-12 の合格基準に届かなかったため、be33382e で再登録。docs/design/evidence/fut05b-me-pa-offset-sign/）。動く公表数値：LRO フィット（tests/agency_lro.rs）の生のオーバーラップは 53.8 → 39.9 m、動力学は 12.6 → 12.05 m、縮約動力学は 6.65 → 6.67 m です（合格基準は変わりません）。解析スタックは、両方の階層で ANISE の DE グレードのクロスバリデーション（12.0 / 6.67 m）と一致するようになりました。以前の動力学階層での差は、この誤りによるものでした。

• MCP サーバーは [terrain] dem_hgt を拒否します（CAP-06b のフォローアップ）。ジャミング種別の地形タイルのパスは、inline_only::FILE_SOURCE_KEYS に入りました。インライン出力面は、これを指定するシナリオを拒否し、そのメッセージにはパスもオペレーティングシステムのエラーも含めません。ファイルソースのガードのテストは、_hgt で終わるフィールドにもフラグを立てるようになりました。

• 日の端数を持つ Jd2::from_parts は、UTC、TAI、UT1、地球自転の変換で端数を落としていました（日の端数が一時間だと、地球が 15° ずれる結果になっていました）。日の端数は整数に正規化されるようになりました。エンジンの呼び出し側に影響はありません：すべて整数の日を渡しており、出荷済みの出力はすべてビット単位で同一です。

予定#

• 指定したスカイラインからのジオメトリ（0.36 の項目 1。現在は src/skyline.rs としてエンジンに入っています）：入力にスカイラインがある場合はそこから sky-blocked と open_fraction（方位ギャップはフォールバック）、nmea-scenario での自然劣化（フィヨルドまたはターミナル）イベント、および sigma_UERE x DOP の行における設計ノートの二つのマスク付きジオメトリで、補遺として事前登録します。
• 航法つきの RINEX ログ（エンジン自身の測位解から）と、Android ログ（Status の行から）のジオメトリ。どちらも現在は unknown と読みます。$PKSHT（バージョン 1 は 0.36 で変更なし）、および Signal K と OpenCPN の統合でのジオメトリ。
• 既存の欠落で、0.36 で導入されたものではありません：すべての衛星の SNR フィールドが空になると、loss-of-lock や C/N0 の減点は作動せず、信号の全喪失は、ジオメトリモニターの signal_loss（environment に分類）を通じてのみ見えます。それに対する減点を計画しています。
• 外部のテレメトリーオラクル（Prometheus のテキスト形式パーサーと OTLP コレクター）でのスキーマ 1.3 のストリーム。これらは現在、1.2 のストリームのみを対象としています。
• 両側が遮られる障害物（谷または狭いフィヨルド）は、スカイラインが統合されるまでは、遮られた天空ではなく信号喪失と読まれます。

[0.35.0] - 2026-10-12#

サードパーティの AI クライアントに言及している一節は、ここでは省いています。GitHub の CHANGELOG.md にあります。

Galileo OSNMA 検証器#

• 新しいモジュール kshana::osnma と kshana osnma verify <input>：Galileo OSNMA のための、オープンで純 Rust の受信機側検証器。I/NAV ページを読み取り、衛星とエポックごとに、航法データが認証されているかどうかを、失敗または遅延のすべてに理由を付けて報告します：HKROOT と MACK の解析、DSM-KROOT と DSM-PKR の再構成、公開鍵の Merkle 検証、TESLA 鍵チェーンの検証、相互認証を含む ADKD 0、4、12 の MACSEQ とタグの検証、および受信機信頼性モニター向けの $PKSOS 形式の結果。出力には、そのステータスが航法インテグリティのサービスではないという助言が付きます。docs/OSNMA.md は、何が検証され何が検証されないか、時刻の要件、および Kshana が EU の OSNMA ICD の知的財産権に基づく権利を一切付与しないこと（ユーザーは ICD の Annex E の許諾に依拠します）を述べています。SIS ICD Issue 1.1 と Receiver Guidelines Issue 1.3 に対して実装しました。ページは CRC を検査し、u-blox UBX-RXM-SFRBX のバイトストリームは直接読み取れます（--format ubx）。既定のテストは合成データと公表されているプリミティブの既知解テストを使い、オプトインのテストは、公式ベクトルをローカルにダウンロードしたコピーを読み込みます。独立したレビューを経て、検証器は、時刻を検証済みの TESLA 鍵からのみ取り（偽装された遠い未来のサブフレームで失敗を消し去ることはできなくなりました）、認証を期限切れにして使用中の IODnav に従わせ、検証済みのアラートメッセージ（その Merkle リーフにランダムな NPK フィールドが含まれるようになりました）と NMA ステータス「don't use」を尊重し、ダミータグを衛星ステータスから除外し、チェーンを CID ごとに失効と更新つきで保持し、KROOT のパディングハッシュを検査し、UBX フレーム長と TESLA 検証の作業量に上限を設けます。衛星が認証済みと読まれるのは、それが送る最新のエフェメリスとクロックのデータが、ビット単位で、認証されたデータそのものである間（同じ IODnav の下というだけでは不十分）に限られます。認証されていない NMA ヘッダーからのステータスまたは失効は、二つの衛星が一致するか、検証済みの KROOT がそれを運ぶ場合にのみ有効となり、再生された古い KROOT はチェーンを置き換えられず、停滞した鍵ストリームは報告されます。

追加（MCP サーバーのチャンネル）#

サードパーティの AI クライアントに言及している一節は、ここでは省いています。GitHub の CHANGELOG.md にあります。

• kshana-mcp --http <addr>、ストリーミング可能な HTTP、セルフホスト。既定ではループバック。ループバック以外のアドレスには --allow-remote と KSHANA_MCP_HTTP_TOKEN のベアラートークンが必要です。パスを読み書きするツールはありません（IQ ファイルのツールはオフ）。リクエストのサイズ、時間、並行数の上限があり、CORS ヘッダーはなく、Host と Origin の検査を行います。Kshana はエンドポイントをホストしません（docs/deploy/mcp-http.md。Docker、Fly.io、Cloud Run のテンプレートつき）。

追加（出力面）#

• Python と WebAssembly 上の osnma_verify。kshana osnma verify の背後にある検証器を、メモリ上のバイト列に対して実行し、--json が出力する JSON を返します（助言は advisory フィールドに入り、認証ステータスのみで、航法インテグリティのサービスではありません）。拒否の挙動はコマンドラインと同じです。MCP にはありません：入力は長い生の受信機ストリームであり、CLI と Python のほうが適しているためです。docs/SURFACES.md と docs/OSNMA.md にその旨を記しています。

• WebAssembly、Python、MCP 上の trust_telemetry、およびプラグインコマンドと JetBrains アクション。信頼性ストリームまたは receiver-trust の結果を、Prometheus テキスト、CEF または LEEF の syslog 行、または OTLP JSON ペイロードとして出力します。使うエンコーダーは kshana trust-telemetry（kshana::surface::trust_telemetry）が使うものと同じで、ソケットもクロックも使いません。プラグイン：/kshana-trust-telemetry と trust-telemetry スキルです。JetBrains：Render Trust Telemetry。wasm と python の機能と MCP サーバーは、クレートを追加しない otlp も有効にするようになりました。

• パリティの一括確認。JetBrains のアクション Validate Scenario、List Scenario Kinds、Assess Receiver Stream。kshana --help は receiver-trust evidence、evidence、trust-telemetry、nmea-scenario も一覧するようになりました。ノートブック compliance-and-test-bench（compliance マッピングとtest bench向けエクスポート）。docs/SURFACES.md に残っていたすべての JetBrains の「CLI only」のセルは、理由つきの明示的な N/A になりました。

サードパーティの AI クライアントに言及している一節は、ここでは省いています。GitHub の CHANGELOG.md にあります。

追加（エビデンスパック）#

• kshana receiver-trust evidence と kshana evidence verify：GNSS 信頼性イベントのための、署名つきで検証可能なエビデンスパック。パックは、生ログの抜粋と全ログの SHA-256、すべてのしきい値を含む設定、エポックごとの結果と理由、エンジンのバージョン、ハッシュチェーンのマニフェスト、自己完結型の HTML サマリーをまとめ、Ed25519 で署名します（鍵は kshana evidence keygen から、またはご自身のファイルから。鍵はパックに保存されることはなく、*.evidence-key は git の管理対象外です）。verify はすべてのハッシュ、チェーン、署名を検査し、失敗した点を正確に示します。--pubkey を使うと署名者を固定します。RFC 3161 のトークンを添付でき、それは読み取られてマニフェストに結び付けられます（認証局自身の署名は、このビルドでは検査しません。openssl ts -verify がそれを扱います）。ログの抜粋は、リーダーがソースの範囲を報告する場合（NMEA、UBX、RINEX 3、Android）はウィンドウの厳密なバイト列で、それ以外は全ログであり、どちらかはマニフェストに記します。作成と検証は純粋な公開関数（kshana::evidence）で、wasm32 向けにビルドできます。パックは、技術的な記録であり、法的見解ではないと明記しています。新しい依存関係は、ed25519-dalek のツリー（BSD-3-Clause と Apache-2.0/MIT、最小限の機能）と、鍵素材を消去するための直接の zeroize（すでにそのツリーにあります）です。docs/EVIDENCE-PACKS.md を参照してください。

追加（信頼性テレメトリー）#

• kshana trust-telemetry：セキュリティテレメトリー源としての GNSS の信頼性。エポックごとの信頼性ストリーム（JSON 行：スコア 0-100、バンド、理由）またはバッチの receiver-trust の結果を読み、Prometheus の /metrics エンドポイント（既定は localhost）、RFC 5424 エンベロープ（UDP または TCP）内の CEF または LEEF の syslog イベント、そして既定でオフの otlp 機能のもとで OTLP/HTTP JSON のエクスポートに渡します。配信は、接続と書き込みの時間制限、上限つきの再接続バックオフ、kshana_trust_syslog_send_failures_total カウンターを備えたワーカースレッドで動くため、停止または滞留したコレクターがライブの評価を止めたり /metrics を固まらせたりすることはありません。理由ラベルは 64 系列に制限されます。新しい依存関係はありません。Grafana ダッシュボードのサンプルは deploy/grafana/ にあります。メトリクス名、ラベル、CEF/LEEF のフィールド対応は docs/TRUST-TELEMETRY.md にあります。ストリームのフォーマットは src/telemetry/sample.rs に隔離しています。

追加#

• 海事向けの信頼性：受信機がすでに出力している NMEA 0183 から、航行中の船舶の測位解に対するライブの 0-100 の信頼スコアを求め、オプトインのゲートを備えます。 kshana receiver-trust は [platform] テーブルを受け付けます（kind = "static" または "vessel"、船舶の最大速度、加速度、旋回率、喫水線からのアンテナ高、任意の方位センサー。すべての既定値は理由つきで文書化）。船舶では、較正平均からの距離を測るため航行中の船では誤りとなる静的な位置ジャンプのモニターは、因果的な移動プラットフォーム用のモニターに置き換えられます：報告された速度と針路、および船舶の限界に対する位置の運動学的整合性、対地針路に対するジャイロ方位、対地速度に対するスピードログ、指定した喫水線からの高さに対するアンテナ高度、較正ベースラインに対して C/N0 の広がりが縮小し同時に上昇すること、および時刻の整合性（ライブモードではこのコンピューターの時計に対しても）です。また、報告された認証ステータスも、全体または衛星ごとに読み取ります（報告されたステータスのみで、OSNMA の暗号処理は行いません）。すべてのしきい値は、実行の前に [maritime] テーブルで明示されます。その後、各エポックは、決定論的で事前登録した対応付け（学習はなく、イベントに合わせて調整したものもありません。重み、バンドの境界、エビデンスは [score] テーブルに保持）により 0 から 100 のスコアを得て、既存の信頼性の状態に対応付けられ、減点したモニターとその点数が付きます。静的シナリオは変わらず、以前と同じハッシュになります。kshana receiver-trust live <session.toml> は、標準入力、追記されるファイル、TCP または UDP を読み、エポックごとに一行の JSON と、独自の $PKSHT センテンスを書き出します。--gate を使うと、測位解が信頼できる間はストリームを変更せずに通し、信頼できない間は測位解を無効として印を付けます（GGA 品質 0、RMC と GLL のステータス V、GNS と VTG のモード N）。ゲートは、要求しない限りオフです。--listen tcp:<port> は、ゲートを通したストリームを任意の数の TCP クライアントに提供します（既定ではループバック。遅いクライアントは、他を妨げずに切断されます）。これは助言用ソフトウェアであり、型式承認を受けた航法装置（IEC 61108、IEC 61162）ではありません。運用者が引き続き責任を負います。examples/maritime-trust/ は、タリンからヘルシンキまでの合成ログで、テキストのみで書かれ、途中で位置のドラッグオフが入り、その間も受信機は有効な測位解を報告し続けます。期待される出力はテストで固定しています。ガイド：docs/MARITIME-TRUST.md。この検査は、バス上のあらゆるものと整合する測位解を持つスプーファーを見抜けません。ガイドにその旨を記しています。

干渉マップ#

• kshana interference-map と kshana route-exposure：航空機と船舶が劣化した航法データを報告した場所と、経路のどれだけがそれに触れるかを示す、公開の図。入力は、オープンライセンスの ADS-B（adsb.lol、ODbL 1.0）と AIS（NOAA MarineCadastre、NLOD 2.0 の Kystverket）のデータから作ったローカルの CSV ファイルです。各出力ファイルは、一つのソースと UTC の一日分の GeoJSON で、手法、そのしきい値、データのライセンス、帰属表示、ソースのカバレッジの偏りを含みます。ADS-B の手法は、NIC と NACp を固定グリッドに集計し、異なる航空機の割合からセルを劣化とみなし、精度を一切報告しない装置、低高度、広域の原因に対するガードを備えます。AIS の手法は五つの検出器を動かします：陸上の位置（ユーザーが与えた海岸線に対して）、円形の航跡、あり得ないジャンプ、あり得ない速度、一つの位置に多数の船舶。しきい値は、名前を付けた手法バージョンの、事前登録した定数です。集計のみ：識別子はメモリ内でハッシュ化されて書き出されず、異なる航空機または船舶が 5 未満のセルは公開しません。劣化したセルは、干渉があったという所見ではありません。既定のコマンドはネットワークを使いません。オプトインの fetch-land --allow-network ヘルパーは、コミットで固定したアドレスから Natural Earth の陸地ポリゴンをダウンロードし、SHA-256 が一致する場合にのみファイルを保持します。ADS-B の入力は、CSV か、adsb.lol の readsb 履歴ファイルを直接使えます（新しい依存関係：gzip 用の、純 Rust バックエンドの flate2）。どちらの手法もバージョン 2 です：劣化または異常の判定には、少なくとも 5 機または隻（公開の最小値）が必要で、5 未満のセルごとの件数はすべて null として伏せられ、背景を推定できない日はその判定を伏せます。出力ファイルは <source>-<dataset>-<date>.geojson と名付けられ、上書きされることはありません。入力は行ごとにストリーム処理し、経路の露出は日付変更線を扱います。テストは合成データのみを使います。docs/INTERFERENCE-MAP.md と、docs/data/INTERFERENCE-DATA-SOURCES.md のライセンスの見直しを参照してください。

追加（訓練ストリーム）#

• kshana nmea-scenario：GNSS のジャミングとスプーフィングの認識に関する乗員訓練のための、合成のブリッジ NMEA 0183。シナリオ TOML から、ファイルを書き出すか、TCP または UDP（ユニキャストまたはブロードキャスト。実時間、加速、または可能な限り高速）でストリーム出力し、旋回率、加速度、潮流の制限を持つ船舶の航跡について、エンジン自身の公称コンステレーションによる衛星ジオメトリとともに、ブリッジ向けの全セット GGA、RMC、VTG、GSV、GSA、GNS、ZDA、HDT、VBW を出力します。タイムライン上のスクリプト化したイベント：ジャミング、位置のドラッグオフ（遠ざかっていく有効な測位解）、時刻スプーフ、リプレイ遅延で、それぞれ開始と回復のランプを持ちます。教官ログ（JSON とテキスト）は、いつ何を注入したかを、真の航跡と報告された航跡とともに記録します。scenarios/training/ のライブラリ（外洋でのジャミング、沿岸でのドラッグオフ、入港時の時刻スプーフ、複合）には、トレーナー向けノートが付きます。出力はチェックサムが有効でシードごとに決定論的です。テストはシナリオごとにゴールデン抜粋を固定し、すべてのセンテンスを receiver-trust の NMEA リーダーで読みます。テキストのみ：RF、IQ、波形の出力はありません。ストリームは訓練と試験のためのものであり、船舶の実際の航法システムには決して入力してはなりません。docs/NMEA-TRAINING.md を参照してください。

海事向けの統合（0.35.0、ワークストリーム B）#

• Signal K プラグイン（integrations/signalk/、npm には公開していません）：kshana receiver-trust live を実行するか、それに接続します（サーバー自身の NMEA 入力、カスタム入力引数、JSON 行の TCP フィード、またはゲートストリームの $PKSHT センテンス）。信頼スコア、バンド、理由、アラーム、ゲートの状態を navigation.gnss.kshana.* の下に公開し（受信機が報告した位置もコンテキストとして含みますが、navigation.position には決して入れません）、Signal K の通知を出します（degraded では warn、untrusted では alarm、保持、解除、陳腐化のしきい値つきで、すべて設定スキーマにあります）。npm への依存関係はありません。記録した合成出力でテストしています。
• OpenCPN：ゲートモードの NMEA は kshana receiver-trust live --gate --listen tcp:10110 が直接提供します（推奨）。依存関係のない TCP リレー（integrations/opencpn/nmea-tcp-relay.mjs）は、任意の代替手段です。どちらの場合も、信頼性が崩れると OpenCPN は無効な測位解を認識し、NMEA デバッグウィンドウに $PKSHT が出ます。テストは、合成のゲート済みストリームを実際の TCP ソケット経由で再生し、コンシューマーが受け取るものを検査します。ネイティブのスコアパネルのプラグイン（integrations/opencpn/plugin/、プラグイン API 1.18、CMake）は、OpenCPN 自身の NMEA ストリームから $PKSHT を読み取り、untrusted のバンドで警告します。ビルドでき、そのロジックは単体テスト済みで、OpenCPN 5.8.4 の中で仮想ディスプレイのもとで動作させました（エビデンスと再現スクリプトは integrations/opencpn/evidence/）。プラグインマネージャー向けにはパッケージ化していません。
• リファレンスビルド（deploy/reference-build/）：汎用の部品リスト、OS のセットアップ、助言モニターとオプトインのゲート向けの systemd ユニット（check-units.sh が systemd-analyze verify で検査）、コンテナの選択肢、Signal K の配線。
• Signal K プラグインは、ライブ JSON スキーマ 1.2 を受け付けます（position のあとに advisory キーが追加されます。未知の追加キーは無視されます）。実際の 1.2 出力と、実際の signalk-server に対して検査済みです。
• レビューでの修正：systemd ユニットは常に再起動し、サンドボックス内で動作します（シェルなし、不要な場合はネットワークなし）。logrotate のスニペット。check-units.sh は、どんな所見でも失敗します。コンテナは、環境変数からヘルスチェックつきでゲートを実行し、ベースイメージはダイジェストで固定します。Signal K のスコアのメタデータ、データが再開すると古い通知は置き換えられ、子プロセスのエラーは保持され、kill は段階的にエスカレートし、安全でない inputArgs は拒否され、通知は notifications.navigation.gnss.kshana.trust に置かれます。リレーは保持している不完全な行に上限を設けます。$PKSHT のパーサーは、0 から 100 の範囲外のスコアを拒否します。ドキュメントのリンク検査。これらすべてを、実際のバイナリのエンドツーエンドを含めて実行する CI ワークフロー（marine-integrations.yml）。
• docs/MARINE-INTEGRATIONS.md。助言用ソフトウェアであり、型式承認を受けた機器ではありません。運用者が引き続き責任を負います。ソフトウェアのみ：何も送信せず、検出や誤警報の数値も主張しません。

追加：compliance マッピングとtest bench向けエクスポート#

• docs/compliance/ と kshana compliance-report。Kshana の出力から、五つのレジリエンスのフレームワークと規格（米国 DHS の Resilient PNT Conformance Framework v2.0、船舶向けの IMO ガイダンス、航空向けの EASA ガイダンス、NIS2 Article 21、EN 16803。後者は有料の規格で、パートごと、およびカタログのテキストに見える少数の条番号によって引用しています）への対応付けで、フレームワークごとに一つの表があります：参照、私たちの言い換えによる要求内容、それを裏付ける証拠となる出力（supports evidence for）、そしてギャップ。ソースのバージョン、URL、読んだものと読んでいないものを記録しています。kshana compliance-report <result.json>... は、与えた実行からこの対応付けを埋め、各行に evidenced、partly-evidenced、not-evidenced、out-of-scope のいずれかを付けて、Markdown と JSON で出力し、すべての行にギャップを残します。表現は「〜の証拠を裏付ける（supports evidence for）」であり、何も格付けも承認もしません。テストは合成の実行を使い、コミット済みの表がコードからずれると失敗します。
• kshana bench-export <scenario.toml>。gnss-ins、jamming、gnss-sim シナリオの車両の動きとイベントを、実験室の GNSS シミュレーター向けに書き出します：フレームを文書化したユーザーモーション CSV とメタデータのサイドカー、NMEA 0183 の GGA/RMC、ウェイポイントのテキスト、そしてイベントを CSV と receiver-trust の [[events]] ブロックとして（src/interop/testbench.rs）。動きとイベントのみで、信号は書き出しません。すべてのファイルは tests/interop_testbench.rs で読み戻し、指定した許容差の範囲で比較します。docs/TEST-BENCH.md は、エクスポートをシミュレーター経由で再生し、受信機のログを kshana receiver-trust で採点する方法を示します。
• 何が証拠として数えられるか。結果が機能の証拠として数えられるのは、その種別が書き出すフィールドを持つ場合のみで、種別のラベルだけでは何にも数えられません。未知の種別、兄弟シナリオと食い違う結果、十六進でないハッシュ、不正な形式の受信機信頼性カウントは、使わなかったものとして理由つきで列挙されます。レポートは Markdown のセルをエスケープし、非 ASCII のハッシュでパニックを起こしません。compliance::run_from_text と assess_texts は、パスではなくテキストを受け取ります。
• test bench向けエクスポート。 --epoch は範囲検査されます（UtcEpoch::parse_iso）。ウェイポイントファイルはすべての間隔を検査し、除外した場合はコマンドがその理由を示します。ドキュメントには、gnss-ins の方位は針路ではなく機体のヨーであること、GGA のプレースホルダーフィールド、およびシナリオ自身の高度変化を明記しました。bench-export と compliance-report は使用法のテキストに入っています。
• fusion::pack::truth_trajectory は、gnss-ins の走行プロファイルの真値の状態履歴（その種別自身の真値と同じステップ処理）を公開し、UtcEpoch には NMEA の日付と時刻のフィールドが加わります。

干渉マップの検証#

• 干渉マップのデコード意味論とジオメトリは、合成入力に対して独立した実装と照合して検査しています。NIC と NACp のコードの意味は合成 ADS-B フレームの pyModeS によるデコードと、AIS の利用不可の値は合成 AIVDM センテンスの pyais によるデコードと、グリッドセルへの割り当ては shapely と、セルごとの経路長は shapely と GeographicLib と、内陸のマスキングは shapely と pyproj と、それぞれ最初の比較の前に固定した許容差で照合しました（tests/fixtures/interference_map_ref/PREREGISTRATION.md）。これが検証するのは、コードとフィールド値の読み方とジオメトリであり、フラグの付いたセルが干渉であることではありません。陸地ポリゴンのリーダーは、最初の頂点を繰り返さないリングを閉じるようになりました（以前は最後の辺を欠いて読んでいました）。ドキュメントは、NACp と NIC の低精度のしきい値を、各コードが表す境界として明記しています（NACp 6 は 556 m の EPU の境界、NIC 5 は 1 NM の封じ込めの境界）。

追加（テレメトリー形式とエビデンスパックの検証）#

• エビデンスパックの暗号処理、パック検証器、テレメトリーのワイヤ形式の外部検査。RFC 8032 のセクション 7.1 の Ed25519 テストベクトル（1、2、3、1024）と FIPS 180-4 の SHA-256 の例を、パック自身の署名、検証、ハッシュの関数に通し、厳密な一致を確認しました。docs/EVIDENCE-PACKS.md の規範的なセクションのみから Python で書いた検証器（hashlib と cryptography）は、71 個の無傷のパックと改ざんしたパックで Rust の検証器と一致します：判定、失敗の集合、署名の判定、および両方のチェーンのヘッド。当方の Prometheus エクスポジションは公式の Python クライアントのパーサーで、当方の OTLP JSON は公式の opentelemetry-proto メッセージで、厳密に読み取られ、どちらも作成元の状態と一致します。CEF と LEEF には、独立したオープンな検証器がなく、モデルから計算した状態にとどまります。docs/EVIDENCE-PACKS.md には、クリーンルームの検証器を書く元になった、規範的なパック形式と検証手順が加わりました。VerifyReport には signature_valid が加わりました。オラクルとフィクスチャ：scripts/gen_ed25519_rfc8032_ref.py、scripts/gen_evidence_pack_ref.py と scripts/evidence_verify_cleanroom.py、scripts/gen_telemetry_formats_ref.py。テストは evidence_crypto_reference、evidence_pack_reference、telemetry_formats_reference。CI は Python を必要としません。

追加（CEF イベントの検証）#

• テレメトリーの CEF イベントは、独立した二つのオープンソースパーサーで正しく読み戻せます。 pycef 1.11 と Logstash の CEF コーデック（Logstash 8.15.3 上の logstash-codec-cef 6.2.7）が、157 行の CEF（コミット済みテレメトリーストリームのすべてのバンド変化とすべてのエポックに加え、=、バックスラッシュ、パイプ、改行、タブ、マルチバイト文字を含む敵対的なテキスト）を解析し、すべてのヘッダーフィールド、重大度、拡張キーの集合、およびすべての値を正確に復元します。Logstash コーデックは、ヘッダーのテキストにエスケープが必要な四行も読み取れますが、pycef には読み取れません。合格基準はどちらのパーサーを実行する前に登録されています（tests/cef_reference.rs）。フィクスチャーは tests/fixtures/cef/、オラクルのスクリプトは scripts/gen_cef_ref.py と scripts/gen_cef_logstash_ref.py にあり、CI には Python も Logstash も必要ありません。LEEF には保守されているオープンなパーサーがなく、モデルから計算された扱いのままです。CEF イベントは、トラストスコアとエポックオフセットを、整数フィールド cn1 と cn2 ではなく、CEF ディクショナリの浮動小数点カスタムフィールド（cfp1、cfp2）で伝えるようになりました。整数フィールドはどちらの値にも適していませんでした。CEF は今回のリリースで新規に追加されたため、出荷済みのものが変わることはありません。

変更#

• MCP：assess_receiver_log はログを text または base64 で受け付けます。ツールの入力は 4 MiB までに制限されています。
• ジャミングのグラフも、パレットから色を取得するようになりました。 src/jamming.rs は、ジャマー Q の作業が進む間も、Observatory パレット改訂で独自の色のまま残された唯一のモジュールでした。その *.chart.svg（jamming、maritime-strait-jamming、およびその他の jamming 種別のシナリオ）は src/palette.rs を読むようになり、tests/palette_sync.rs の許可リストは空になりました。変わったのは色とフォントだけです。jamming-demo と maritime-strait-jamming のグラフは、色、font-family、バージョンのフッターを正規化すると、以前に記録されたレンダリングと一致します。プロットされた値は動いていません。web/studio/recorded/ にある記録済みの Studio コピーは、0.33.0 と 0.34.0 の再移植時に再記録されました（バージョン表記のみ）。これらはジャミングのグラフの古い配色を保持しており、次回の再移植でパレットの配色になります。

修正#

• クロックアンサンブルの 3 シグマ境界がフリッカーフロアを含むようになり、フィルター健全性チェックもそれを検出します。flicker_floor がある場合、真値のクロックはフリッカー FM を持っていましたが、インテグリティ境界を与える 二状態フィルターは持っていなかったため、出荷済みの clock-ensemble シナリオの 3 シグマのカバレッジは 0.41（古典）と 0.33（量子）でした。また NIS/NEES チェックは、フィルター自身のモデルから真値を生成していたため、フロアの有無にかかわらず同一の値を報告していました。境界は、二状態の分散に、前回の同期以降に蓄積したフリッカー位相の厳密な分散を加えたものになり、真値のクロックと同じバンクから計算されます。NIS/NEES チェックは、そのバンクを用いた拡張モデルから真値を生成し、整合する拡張フィルターを実行します（また、フリッカーの真値に対する 二状態フィルターは consistent = false と報告します）。出力の変化は、flicker_floor がゼロでないクロックにのみ生じます。clock-ensemble における integrity は、0.40866 / 0.33026 から 0.99970 / 1.0（古典 / 量子）になり、filter_health の NIS/NEES にフリッカーが含まれるようになります。時刻誤差、holdover_s、timing_p95_ns は変わらず、フロアのないシナリオはバイト単位で同一です。scenarios/orbit-gnss-challenged.toml（軌道種別、シード 7、フロア 1e-16 / 2e-11）も変わります。fom.integrity は、古典が 0.7734 から 1.0、量子が 0.9796 から 1.0 になり、filter_health の NIS/NEES とその帯域も変わります。その量子の filter_health.consistent は true から false に反転します。これは 16 シード × 60 ステップのフリッカーアンサンブルにおけるサンプリング上の事象（NIS 0.8815、帯域 [0.9125, 1.0914] に対して）であり、欠陥ではありません。この帯域は 95 % の帯域なので、構造上、約 5 % のシードで整合するフィルターにフラグが立ちます（このシナリオの新しい 40 シードでは、量子で 1 件、古典で 2 件にフラグが立ちました）。64 × 200 では、同じシードが両方のクロックで帯域内に収まります（NIS 0.990 と 1.001）。既知の後続課題：フュージョン種別にも同じ欠落があります（フロアがある場合の古典のインテグリティは 0.80）。ハイブリッド種別は 0.99 を超えたままです。

[0.34.1] - 2026-10-10#

セキュリティ#

• MCP サーバーの入力を強化しました。MCP サーバーのシナリオツールは、インライン内容のみを受け付け、ファイルソースのフィールドは拒否するようになりました。入力サイズにも上限があります。アドバイザリー：GHSA-8wpf-hqg5-6xjr。

[0.34.0] - 2026-10-09#

ラボリプレイ：GNSS の IQ 録音のための、トラッキングエンジン、検出モニター、キャンペーンランナーと、それに付随するループ設計、C/N0 推定器、スコア。エビデンスクラス：以下はすべて MODELLED であるか、閉形式およびシード付きシミュレーションとの内部整合性を確認したものです。VALIDATED の行は追加されず、検証台帳（ledger）は変わりません（251 行：独立した外部の参照と照合して確認済みが 124、モデルから計算が 123、パートナーの担当部分が 4）。これはソフトウェアの解析層であり、ジャマーやスプーファーの波形を合成することはなく、何も送信しません。

追加#

• ラボリプレイ：試験条件、キャンペーンランナー、スコアリング（0.34.0）。 kshana iq campaign <campaign.toml> は、録音 × フロントエンドチェーン × ループ設計（kshana.loop-design/1）を再生し、すべてのセルを録音ごとの試験条件ファイル（kshana.test-conditions/1、TOML または JSON）に対してスコアリングします。このファイルには、ラボが録音について把握している内容が記されます。期待される衛星、および各イベントについて、種別ラベル、開始と終了、影響を受ける衛星、記載された J/S またはジャマー電力プロファイルです。これはメタデータのみです。衛星ごとに、実行全体とイベントごとに付けるスコアは次のとおりです。

  • 可用性、ロックロスまでの時間、およびロック喪失時に記載されていた J/S
  • 再捕捉時間（イベントの終了時点から、およびロック喪失時点から）
  • 記載された J/S ビンごとの C/N0 劣化の実測値
  • ロック時間あたりのフォールスロックの発生回数（トラッカーのフラグ、または真値サイドカーに対するドップラー）
  • PLL と DLL のディスクリミネーターのジッター

  実測した劣化曲線ごとに、解析的なスペクトル分離の参照（jamming::effective_cn0_dbhz、種別の Q を使用）が描かれ、表示されるあらゆる場所で MODELLED のラベルが付けられます。

  セルはトラッキングセッションのロック状態機械を通じて並列に実行され、それぞれがコンテンツハッシュのキーで不可分に書き込まれます。キーには、録音の SHA-256、条件、フロントエンド、設計、実行、スコアリングの各ハッシュ、必須の data_class（synthetic | client-confidential）、およびエンジンのバージョンが含まれます。run.epochs を設定すると、各セルの kshana.track-epoch/1 ストリームとロックイベントも保持され、セルキーで名前が付けられ、セルにハッシュとして取り込まれます。cell_key と report::digest は公開されているため、利用者はすべてのキーとダイジェストを再導出できます。したがって、再実行では完了済みのセルがスキップされ、出力はワーカー数に依存しません。実行では scorecard.csv/.json、自己完結した report.html、および DIGEST が書き出されます。合格/不合格の基準（[scoring.bars]、録音ごとに上書き可能）は、レポートの作成時に適用されます。

  • [scoring] cn0_estimator = "m2m4" | "nwpr"（既定は "m2m4"、スコアリングハッシュの一部）は、報告される C/N0 と劣化曲線の基となる C/N0 を選びます。両方の推定値が常にスコアリングされて報告され（実行全体とベースラインの中央値、および J/S ビンごと）、セルとスコアカードには推定器が記録されます。NWPR は、ループ自身のジッターのもとで約 8 dB × Bn·T だけ低く読みますが、M2M4 はそうなりません。

  その他の新機能：

  • kshana iq campaign report <dir> は、セルからスコアカード、レポート、ダイジェストを再構築します。
  • kshana iq conditions <file> は、試験条件ファイルをそのスキーマに照らして検査します。
  • events_from_sigmf = true は、SigMF 録音の kshana:test_event アノテーションをイベントとして取り込みます。
  • Python に iq_test_conditions、iq_campaign、iq_campaign_report が追加されます。
  • kshana-mcp に iq_campaign と iq_campaign_status が追加されます。これは、呼び出しごとのサンプル予算のもとで増分的に実行でき、再開可能で、すべてのファイルは作業ディレクトリに制限されます。

  テスト：tests/iq_campaign.rs は、3 録音 × 2 フロントエンド × 2 設計の合成キャンペーンを実行します。そのシーンには記載された C/N0 プロファイルがあり、次を対象とします。

  • すべての指標を、注入した真値に照らして検査
  • 破損したセルを含む単一ワーカーの途中実行の後の再開が、中断のない四ワーカー実行とバイト単位で一致すること
  • セルごとのエポックファイル
  • 20 秒、三衛星の再捕捉の回帰テスト：reacquire を有効にすると、2 秒のギャップの後、すべてのチャネルが 2 秒以内に復帰します。reacquire を無効にした場合の結果は固定されています。
  • 再実行せずに基準を再判定
  • CLI
  • 既定では無視されるリリースモードのスループットとメモリのチェック。4 GB の録音を含みます（実時間の 5.45 倍、ピークメモリは開始時の RSS より 2 MB 多い。一台のマシンでの測定であり、合格基準ではありません）。

  ソフトウェアのみ：何も送信せず、干渉やスプーフィングの波形も合成しません。設計と実装時のメモ：docs/design/LAB-CAMPAIGN.md。

• ラボリプレイ用のトラッキングエンジン（0.34.0：B3.1、B3.2、B3.3、B6.1）。

  • ループ設計ファイル：kshana.loop-design/1 TOML（docs/design/LOOP-DESIGN-TOML.md、パーサーは iq::track::design）。名前付きの設計を一つ以上定め、すべてのループのフィールドを設定します。

    • 搬送波の種別（PLL、FLL、または FLL 支援付き PLL）、次数、帯域幅
    • PLL/FLL/DLL のディスクリミネーターと搬送波アイディング
    • 間隔と積分
    • ロックのしきい値と C/N0 のウィンドウ、およびビット同期
    • ロック状態機械
    • 引き継ぎ時の捕捉（"auto" または明示指定）

    設計は互いを extends できます。未知のキーは拒否されます。解決済みの各設計には、正規化した JSON 形式（すべての階層でキーを整列し、数値の書式を固定）に対する SHA-256 ハッシュがあり、このためハッシュはフィールドの順序に依存せず、すべての出力がそれを記録します。利用できる場所：

    • kshana iq track --design <file> [--design-name]。明示したフラグは設計を上書きし、記録されます。
    • kshana iq sweep --design <file>。ファイル内のすべての設計を実行します。
    • Python の iq_track(design=, design_name=, reacquire=)、iq_loop_designs。
    • MCP の iq_track design/design_name。

  • M2M4 C/N0（EpochOutput.cn0_m2m4_dbhz、cn0_beaulieu_dbhz の後のトラックエポックの列 cn0_m2m4_dbhz、Python のエポック辞書）。NWPR と同じウィンドウに対する 二次・四次モーメント推定で、プロンプト電力のみを使います。NWPR はループ自身の搬送波ジッターのもとで低く読みます（約 8 dB × Bn_PLL·T）が、M2M4 はそうなりません。GPS L2C CM（20 ms、公称 40 dB-Hz、PLL 1 から 10 Hz）では、この推定値はどの帯域幅でも 39.93 dB-Hz と読む一方、NWPR は 39.55 から 38.22 に下がります。L1 C/A の 45 dB-Hz では 45.34 と読みます。NWPR とその他のすべての出力は変わりません（ビット単位の固定）。バイナリレコードは 184 バイトのままです（この値は、予約済みのフロートとフラグのビット 6 を使います）。

  • 追加の相関器タップ（マルチ相関器 / SQM）。 [design.integration] extra_taps_chips = [..]（プロンプトからのオフセット（チップ単位、正が早い側）。最大 16 個、それぞれ ±2 以内）は、E/P/L に加えて追加のレプリカを相関し、それを EpochOutput.extra（設計順の (offset, value)）として返します。ループがこれらを使うことはありません。空の場合はこのキーが正規化 JSON から省かれるため、既定の設計のハッシュとタップのないすべての出力は変わりません（kshana.track-epoch/1 は維持され、タップなしの CSV/JSONL/バイナリはビット単位で同一です）。タップがある場合は、CSV/JSONL の列が増え、バイナリレコードは 184 + 16 × taps バイトとなってそのヘッダーに extra_taps_chips を持つため、古いリーダーは誤って解釈せずにファイルを拒否します。--extra-taps（CLI）、extra_taps（Python）、extra_taps_chips（MCP の iq_track）。一回の実行内の設計は、タップについて一致している必要があります。

  • 並列チャネル（iq track / iq sweep --threads <N|auto>、Rust の TrackSession::with_threads）。各チャンクのチャネルは最大 N スレッドで実行されます（std::thread::scope、wasm32 は直列のままです）。チャネルの相関とロック状態機械はそのチャネルにしか触れず、そのエポックとイベントはバッファーされてチャネル順にシンクへ書き出されるため、どの N でも出力（CSV、JSONL、バイナリ、イベント、サマリー）は直列実行とバイト単位で同一です。既定は 1 スレッドのままです。12 チャネル、4 秒、4.092 MHz の録音を 4 コアで測定した結果：直列で 19.5 秒、2 スレッドで 11.5 秒、4 スレッドで 6.3 秒（3.1 倍。最初の捕捉は直列です）。

  • 捕捉サーフェスのエクスポート（kshana.acq-surface/1、iq::acq_surface、docs/design/ACQ-SURFACE.md）。iq acquire --surface <path>（一つの PRN、CSV、JSON またはバイナリ）、Python の iq_acq_surface、MCP の iq_acquire surface_out は、探索が計算するドップラー × コード位相の相関電力サーフェス全体（そのセルは acquire と、ビット単位で同一）を、ピークと 二つの微細ドップラー精密化（放物線推定と 1/16 ビンの微細探索。167 Hz のビンに対し、コヒーレント 4 ms で ≈5 Hz）とともに書き出します。acquire 自体とすべての既定値は変わりません。

  • ストリーミングのエポック出力（kshana.track-epoch/1、iq::track::sink）。ループの更新ごとに、次を含みます。

    • アーリー/プロンプト/レイトの相関器
    • 三つすべてのディスクリミネーターの出力
    • PLL/FLL/DLL の NCO 状態と搬送波位相
    • PLI とロックのフラグ
    • 両方の C/N0 推定値とビット
    • ロック状態

    発生と同時に、CSV、JSON Lines、またはバージョン付きのバイナリ形式で書き出され、Rust（BinaryEpochReader）と Python（iq_read_epochs）のリーダーがあります。

    • iq track に --epochs、--events、--summary（kshana.track-summary/1）が追加され、iq sweep に --epochs と --events が追加されます。MCP の iq_track に epochs_out/events_out が追加され、その応答はメモリ上限のあるサマリーから作られます。
    • 実行時のヒープは、録音の長さに応じて増えなくなりました。tests/iq_track_memory.rs がカウント型アロケーターで測定しています（長さが 6 倍でも、ピークは 64 KiB 以内で同じ）。メモリ内の経路は増加することを示す対照も併せて実施しています。
    • ストリーミング出力は、メモリ内のリプレイとビット単位で同一です。

  • ロック状態機械（iq::track::lock、TrackSession）：プルイン → ロック → 喪失 → 再捕捉 → プルイン。喪失が reacq_window_s（既定 30 秒）を超えて続いた場合は、退役します。失敗した探索は reacq_interval_s（0.1 秒）ごとに等間隔で再試行されるため、再試行のスケジュールが測定された再捕捉時間に加えるのは最大 0.1 秒です。任意のバックオフ（reacq_interval_s を超える reacq_max_interval_s）は既定で無効で、max_reacq_attempts は任意の上限です（既定は 0、上限なし）。4.092 MS/s で三つの PRN に 2 秒の途絶が生じた場合、すべてのチャネルが再捕捉されてロックした状態で終わるようになりました。試行予算を 3 回にした場合は、すべてのチャネルが喪失から 0.2 秒以内に退役しました。

    • しきい値（loss_dwell_s、pull_in_max_s、再捕捉のドップラーウィンドウ）は設計から取得されます。すべての遷移は、その理由とともにイベントになります。
    • フォールスロックの検査は、追跡中のドップラーを、その ±1/(2T) の FLL/PLL エイリアスに対して探索します。PR #38 で測定されたフォールスロック（追跡が 500 Hz ずれて −2400 Hz）を検出します。再捕捉を有効にすると、チャネルは注入したドップラーでロックした状態で終わります。
    • 0.8 秒の信号ギャップは喪失と判定され、信号が戻ってから 0.3 秒以内に再捕捉されます。
    • --summary final_state（および表の列）は最後の遷移後の状態であるため、最後のループ更新の後に退役したチャネルは RETIRED と読まれます。
    • FLL 支援はプルイン中のみ（[design.carrier] fll_assist = "pull-in"、既定。"always" は以前の動作をビット単位で維持します）。平滑化した PLI が fll_off_pli（0.8）以上で fll_gate_dwell_s（0.1 秒）の間保たれると、FLL は PLL に引き継がれ、fll_on_pli（0.6）を下回ると戻ります。有効のままにすると、10 Hz の FLL 経路は、クリーンな信号でも約 38 dB-Hz を下回ると位相ロックを失いました。35 dB-Hz では位相ロックの割合は 10～16 %、真の位相誤差は 38～41° でした。ゲートを設けると、既定では 35 dB-Hz で 100 %、4.5° を維持し、PLL 単独と同じです。100 Hz の引き継ぎ誤差からのプルインは変わりません。事前登録した合格基準を伴うエビデンス：docs/design/evidence/carrier-lock/。したがって、既定のループは、既定の設計による以前の実行とビット単位では一致しません。再現するには fll_assist = "always" を使ってください。既知の限界：35 dB-Hz では引き継ぎがトラック開始から 1.9～2.6 秒後に起こり、33 dB-Hz では 10 Hz の FLL によって PLI が引き継ぎのしきい値を下回ったままになるため、プルインは完了しません。
    • 新しいループ設計のキーと API を列挙します。
      • [design.carrier]: fll_assist, fll_off_pli, fll_on_pli, fll_gate_dwell_s;
      • [design.lock]：reacq_window_s、reacq_interval_s、reacq_max_interval_s。max_reacq_attempts は、既定値 3 から任意の上限（既定は 0）に変更されています。
      • Rust：LoopConfig.fll_assist（FllAssist、FllGate）、LoopCore::set_fll_enabled、EpochOutput.fll_active、ChannelSummary.final_state。
    • 設計ハッシュは正規化した JSON 形式に対するもので、組み込みの既定のハッシュは 33261cd171a53803a6c262686e878e01f37d902a93d5918c20a44297b8ef8e80 です（テストで固定）。
    • 出力の互換性に関する注記：
      • iq track の表の末尾に final_state の列が追加されました。
      • iq sweep の CSV の末尾に design_hash の列が追加され、その JSON に design_hash と warnings が追加されました。
      • スイープの mean_cn0_dbhz は、NWPR 推定値を持つすべての更新にわたる平均（メモリ上限のあるサマリー）になり、実行の後半に限った平均ではなくなりました。
    • 再捕捉は、組み込みの既定では無効です。この場合、状態機械は観測するだけで、ループは状態機械がない場合とビット単位で同じように動作します（ただし、既定のループ自体は変わりました。上記の FLL 支援を参照）。設計ごとに有効にする（[design.lock] reacquire = true）、--reacquire を指定する、または reacquire=True を指定します。
    • commensurate_sampling の警告：fs がチップレートの半分の整数倍（iq::track::commensurate_samples_per_chip）の 1e-6 以内にあるとき、iq track/iq sweep（出力、--summary、スイープの JSON）、MCP の iq_track の応答、Python の iq_track の結果が、コードループのジッターとバイアスが代表的でないことを警告します。根本原因は、事前登録した合格基準とともに docs/design/evidence/dll-jitter/ に記載されています。ちょうどチップあたり 2 サンプルで 0.5 チップ間隔の場合、DLL の S カーブは単一のステップになり、ループがディザリングします。45 dB-Hz で ≈0.09 チップ RMS のコード誤差（≈26 m）となり、通約不能なレートでの ≈0.004 チップと対照的です。そのレートで NWPR の C/N0 が約 2 dB 低くなるのも、同じ原因によります。コードドップラーがちょうど 0 Hz でチップあたり 4 サンプルの場合、コードは ±0.21 チップの不感帯を越えないため、最大で約 0.2 チップのコード位相バイアスがジッターに現れないまま残ることがあります（測定値：0.5 チップ間隔では、対照のコード誤差の 2.0 倍で、平均は +0.011 チップ。0.25 チップ間隔では +0.125 チップ）。警告はこのレートを対象とします。
    • 既知の限界：既定の設計は、約 35 dB-Hz を下回ると FLL→PLL に引き継がない（約 35 dB-Hz のプルインの下限。上記の FLL 支援と docs/design/evidence/carrier-lock/ を参照）。
    • 実行できないフォールスロックまたは再捕捉の探索（コード周期あたりのサンプル数が整数にならないレート）で、トラッキングが止まることはなくなりました。
    • テスト：tests/iq_track_engine.rs、tests/iq_cli.rs、iq::track::design::tests、tests/python、および MCP の IQ ラウンドトリップ。

• 合成シーンの C/N0 プロファイル（0.34.0）。 iq::channel::cn0_profile は、Kshana 自身のシーンで、衛星ごとに時間変化する C/N0 を、シーンの C/N0 に対する dB オフセットとしてスケジュールします。形状は、ステップ、ランプ、区分線形、および指定した S4 と非相関時間を持つ、シード付きのシンチレーション様ライスフェージングです。これらは既存のシーンチャネルフック（Cn0ProfileChannel。電離圏、対流圏、シンチレーション、マルチパスの効果と合成可能）を通じて適用され、シーンのコアには変更がありません。真値サイドカーの cn0_dbhz はプロファイルに従います。

  • 利用できる場所：kshana iq scene … --cn0-profile <toml> と kshana.iq_scene(…, cn0_profile="<toml>")。
  • 用途：既知の真値に対して、ループ、モニター、キャンペーンのスコアリングをストレステストできます。変えるのは、正規の信号の強度だけです。
  • 検査（tests/iq_cn0_profile.rs）。合格基準：フェージングの平均強度が 1 の 5 % 以内、S4 が目標の 8 % 以内（S4 = 0.3、0.7、1 で）、強度の相関が 0.05 τ で 0.9 超、5 τ で 0.05 未満、真値が記載された C/N0 にプロファイルを加えたものと厳密に一致すること、追跡した NWPR の C/N0 の低下が 6 dB のステップに対して 0.7 dB 以内であること。測定結果：S4 は目標の 1.3 % 以内、追跡した低下は 6.26 dB。

• IQ 経路の検出モニター（0.34.0 の「ラボリプレイ」）。新しい iq::monitor モジュール、kshana iq monitor コマンド、kshana.iq_monitor(path, ...) バインディングです。これらは録音を観測し、時系列とフラグ付きイベント（開始、警報、終了の時刻、ピーク、しきい値）を報告します。検出と測定のみを行い、信号を生成することはありません。

  • 全電力 / AGC：ブロックごとの電力と、理想的な AGC が適用するゲイン。上昇と低下にフラグを立てます。
  • 相関前スペクトル：学習したベースラインに対するブロックごとの Welch PSD。超過のしきい値は、誤警報の目標から求めます。また、複素尖度とパルス検出器も備えます。パルス検出器は、各ブロックでしきい値を超えるサンプルを数え、その数の厳密な二項上側確率が pulse_pfa（既定はブロックあたり 1e-4）を下回ったときにイベントを発生させます。z スコアが限界値を超えたときではありません。短いブロックのように期待される個数が小さいと、サンプル一つだけで既に数シグマに相当するためです。
  • チャネルごとの C/N0：独立した推定値（ストライドはループの C/N0 ウィンドウから設定）を入力とする、二つの片側 CUSUM 変化検出器（低下と上昇）。
  • 相関器からの SQM：デルタ (I_E − I_L)/I_P と比 (I_E + I_L)/(2 I_P)。チャネルが追加の相関器を供給する場合は、それによる非対称性の検定も行います。
  • ロック指標の系列：連続するプロンプトから得た PLI と周波数ロック指標を、生の信号として提供します。ロックとロック喪失の判定は、トラッキングエンジンのロック状態機械が行います。

  一回のストリーミングパス（iq::monitor::run::run_monitors）ですべてを実行し、TOML/JSON の設定ファイル（MonitorConfig）を使います。キャンペーンランナーも同じエントリポイントを使います。すべて MODELLED です。各統計量は、シード付きシミュレーションにより閉形式に照らして検査されます（tests/iq_monitor.rs）。

  • ガンマ分布の裾に対するブロック電力の超過
  • 尖度の平均 2 とそのばらつき 2/√N
  • パルスの割合 e^{−t}
  • Siegmund の近似に対する CUSUM のラン長（測定値 330 と 8.46 サンプルに対し、338 と 8.34）
  • ライス位相の平均に対する位相ロック指標
  • 追跡中の C/A 信号では、SQM のデルタと比のばらつきは、一次の閉形式から約 6 % の範囲にあります（測定値 5.97 %、テストの合格基準 12 %）。

  スペクトル超過の誤警報の式は近似であり、測定した発生率は式の 1.3 倍でした。エンドツーエンドでは、モニターは次をフラグします。

  • 6 dB の C/N0 ステップ（変化時刻は一回の推定の範囲内）
  • 録音の途中で現れる反射経路（比の検定）
  • 信号の途絶（その間に PLI は 0.999 から −0.3 に、FLI は 0.93 から 0.03 に低下）
  • 狭帯域のトーンと、まばらな高振幅サンプル（スペクトル、パルス、尖度の検定）。これらは汎用の DSP のテスト入力であり、干渉モデルではありません。

変更#

• iq track/iq sweep は、新しいセッションを通じてストリーミングします（追加項目を参照）。
  • --csv は 0.32 の列を維持しますが、ストリーミングされるようになったため、複数チャネルの行はチャネルごとにまとまらず、時間順に交互に並びます。--json は 0.32 の形を維持し、引き続きすべてのエポックをメモリに保持します。長い録音には --epochs を使ってください。
  • iq sweep は、実行時間の後半の更新にわたってジッターを測定するようになりました（以前は更新回数の後半）。また、その CSV/JSON に design_hash の列が追加されます。
  • トラックの表に final_state の列が追加されます。
  • 使い方のテキストは、iq track がフロントエンドのフラグを受け付けるとは述べなくなりました。それらを適用するのは iq acquire だけです。
  • Python の iq_track の acq_noncoherent と doppler_max は、既定で None（設計の値。組み込みの設計では 1 と 5000 Hz）になりました。そのエポックには、アーリー/レイトの相関器、carrier_phase_cycles、bit_edge、bit、state が追加され、結果には design と events が追加されます。

修正#

• 既定の捕捉ステップは、FLL が引き込めない残差を Galileo E1 のトラッキングに引き渡さなくなりました。ステップ 2 / (3 · N · T_code) は、引き継ぎ時に最大 1 / (3 · N · T_code) のドップラー誤差を残しますが、既定の二象限 FLL が引き込めるのは 1 / (4 T_track) だけです。コードが 4 ms 以上のすべて（N = 1）、すなわち Galileo E1-B と E1-C を含め、残差（4 ms で 83.3 Hz）は 62.5 Hz のプルインの範囲外にあり、トラッキングは +125 Hz でフォールスロックし、それを隠す位相ロック指標は 0.97 でした。既定のステップには 0.2 / T_track（kshana::iq::acq::default_step_hz）、つまりプルインの 0.8 という上限も設けられたため、隣のビンが勝った場合でも、引き継ぎはプルインの範囲内に収まります。（最初に 0.4 を試したところ、E1-B で 42 回の実行のうち 1 回がフォールスロックし、1 ms コヒーレントの GPS L1 C/A 探索は 350 Hz ずれたビンを選んで +500 Hz でロックしました。同じ実行で 0.25 と 0.2 ではどちらも発生しませんでした。）コスト：Galileo E1-B/E1-C のビンは 166.7 Hz から 50 Hz になり、±5 kHz にわたるビン数は 61 ではなく 201 になります。1 ms のコード（166.7 Hz、N = 4）は変わりません。ループ設計での "auto" はこれを意味します。明示した doppler_step_hz または --doppler-step は記載どおりに使われ、iq acquire（トラッキングへの引き継ぎなし）は教科書どおりのステップのままです。エポックのヘッダーと --summary には、各チャネルについて解決済みのステップとループ帯域幅が記録されるようになりました（resolved）。既定の設計ハッシュは変わりません。出力の変化：4 ms 以上のコードでの検出は、異なるドップラービンに入ることがあります。

• GPS L2C CM（20 ms のループ更新）は、既定の設計でロックを保持します。既定の 15 Hz PLL と 10 Hz FLL は、T = 20 ms で Bn · T がそれぞれ 0.3 と 0.2 となり、ループは完全な開始状態からでもロックを失いました（PLI −0.08、M2M4 15.8 dB-Hz）。新しい設計キー carrier.bn_t_max（既定 0.1）は、ループ更新時間が 4 ms より長い場合（Design::loop_config_for）に、PLL と FLL の雑音帯域幅を bn_t_max / T に制限します。20 ms では 5 Hz と 5 Hz、BeiDou B1C の 10 ms では 10 Hz と 10 Hz となり、1 ms と 4 ms のコードは 15 Hz と 10 Hz を維持します。これは明示した帯域幅にも適用され、bn_t_max = 0 で無効にできます。このキーは既定値のときは正規化形式から省かれるため、既定のハッシュは変わりません。他の値を設定した設計は、別のハッシュになります。45 dB-Hz では、L2C CM は PLI 0.996、ドップラー誤差 0.00 Hz、M2M4 42.71 dB-Hz になります。既知の未解決項目：そこでは NWPR の C/N0 が 1.76 dB 低く読まれ（B1C の 10 ms では 2.45 dB 低く）、このため、マトリクスの L2C の T5 は、無視される所見のままです。

• 再生成された docs/assets/clock-ensemble-band.svg：コミット済みの図は、自身のシナリオに対して古くなっていました（データの変更であり、再描画ではありません）。このグラフは 2026-06-02 に scenarios/clock-ensemble.toml から描画されました。その二日後に 67fed19e がそのシナリオにフリッカー FM のフロア（量子は flicker_floor = 1e-16、CSAC は flicker_floor = 2e-11）を設定しましたが、図は再描画されませんでした。図が示していたのはフロア設定前の実行です。y 軸は 0 から 47 ns、CSAC の実行ごとの途絶 p95 は 10.5 から 47.6 ns（平均 25.2 ns）、古典のホールドオーバーは平均 4050 秒。出荷されたとおりのシナリオ（チュートリアルと CLI のサマリーがすでに述べているとおり）では、y 軸は 0 から 407 ns、CSAC の実行ごとの p95 は 40.8 から 374.0 ns（平均 167.0 ns）、古典のホールドオーバーは 844 秒 [220 から 2130 秒] です。20 ns の仕様線は同じ 20 ns の位置にあり、軸の高さは約九倍になります。エンジンは変わっていません。六月のシナリオファイルに今日のエンジンを適用すると、古い図の軸が正確に再現されます。この図は README やドキュメントからは参照されていません。

既知の制限#

• NWPR の C/N0 は、プロンプトあたりの C/N0·T が高いと低く読まれ、5 MS/s の BOC(1,1) は約 1 dB を失います。NWPR は理想的なプロンプトでは不偏ですが、ループ自身の PLL ジッターにより、フィットした約 8 dB × Bn·T の損失が生じます（一つのシーン、四点：20 ms で 1/2.5/5/10 Hz のとき −0.24/−0.44/−0.77/−1.58 dB。既定の bn_t_max = 0.1 では約 −1 dB）。M2M4 は影響を受けません。5 MS/s の BeiDou B1C データも、帯域制限によりプロンプト電力が約 1 dB 失われます（10 MS/s 以上を使ってください）。どちらも推定器の欠陥ではありません。GPS L2C と BeiDou B1C の信号マトリクスの T5 の行は、これらを原因とする無視される所見のままです。

[0.33.1] - 2026-10-08#

セキュリティ#

• グラフのテキストと Studio のグラフ取り込みを強化しました。シナリオが生成グラフに持ち込むテキストは、共通の一つのルーチンで一貫してエスケープされるようになり、Studio はグラフから描画用のマークアップだけを取り込みます。Studio のアドレスパラメーター、種別をキーとする検索、シナリオの取得は、既知の値に制限されます。同梱のグラフ、記録済みの結果、公開済みの数値は変わりません。信頼できない出典のシナリオファイルを Studio で開く場合や、生成したグラフをウェブページに埋め込む場合は、アップグレードを推奨します。アドバイザリー：GHSA-h25h-cg9f-v2cg。

[0.33.0] - 2026-10-08#

ドキュメント#

• IQ 層の干渉とスプーフィングの範囲を、正確に記述しました。下記の 0.31.0 と 0.32.0 の項目には、IQ 層は「干渉やスプーフィングの波形合成を追加しない」と記されています。これは IQ 層自体（iq::scene は正規の GNSS 信号のみを生成します）には当てはまりますが、エンジン全体についての記述として読めてしまい、そうではありません。0.29.0 以降、spectrum 種別の [iq] セクションは、設定されたジャマー（雑音状のジャマーはビンごと、トーンとチャープは波形として）を含む解析モデルの SigMF スナップショットを書き出します。また spoof_capture は、ループのキャプチャを試験するために、正規の信号とスプーファーのレプリカ信号をメモリ内で合成します（合成結果は書き出されません）。エンジンは 0.20.0 以降、ソフトウェア GNSS 受信機も備えています（sdr：捕捉とトラッキング。0.31.0 以降は iq::acq と iq::track も）。Kshana には、送信を行うものも、無線ハードウェアを駆動するものもありません。README のステータス行、docs/POSITIONING.md、docs/SPECTRUM.md、IQ の設計ノートに、この点が明記されました。公開済みの項目は、公開時のまま残されています。動作の変更はありません。
• 既知の制限：通約サンプリング。サンプルレートがチップレートの整数倍または半整数倍のとき、サンプルはどのチップでも同じチップ位相に位置し、コードディスクリミネーターは階段状になります。45 dB-Hz の合成 GPS L1 C/A 信号で、0.5 チップ間隔の場合、2.046 MHz（2 サンプル/チップ）では ≈0.09 チップ（≈26 m）の RMS コード誤差と −0.09 チップのバイアスが生じ、通約不能なレートでの ≈0.003 チップと対照的です。NWPR の C/N0 は、そこで ≈2.4 dB 低く読まれます。4.092 MHz では、間隔とコードドップラーに依存します。0.5 チップでは、ドップラー 1500 Hz では無害ですが、0 Hz では 2 倍で、0.011 チップのバイアスがあり、0.25 または 0.1 チップでは、コード誤差が 8～10 倍になります。搬送波のトラッキングは影響を受けません。測定結果は docs/design/iq-notes/receiver.md にあります。

追加#

• MCP サーバー上の GNSS IQ 層（フェーズ B.1）。 kshana-mcp に、エージェントから kshana iq 層を操作する六つのツールが追加されます。iq_signals（受け付ける信号名と IQ のセットアップ）、iq_info（録音の説明）、iq_scene（記載されたプロファイルまたは放送エフェメリスのシーンを、任意の信号レベルのチャネル付きで生成）、iq_acquire（FFT 捕捉。任意でフロントエンド段を前置）、iq_track（捕捉の後、DLL/PLL/FLL のバンクを実行）、iq_frontend（バンドパス、ノッチ、ブランキング、エクサイズ、AGC、量子化器）です。IQ サンプルがプロトコルを通ることはありません。どのツールも、KSHANA_MCP_IQ_DIR で設定した一つの作業ディレクトリ内のファイルパスを受け取り（未設定の場合、IQ のファイルツールは無効になり、他のすべてのツールには影響しません）、その外に解決されるパスと、overwrite が設定されていない限り既に存在する出力を拒否し、作業の前に呼び出しごとのサンプル予算（KSHANA_MCP_IQ_MAX_SAMPLES、既定 50,000,000）を適用し、未知の引数を拒否し、簡潔な JSON サマリー（検出、C/N0、ロック状態、書き出した各ファイルとそのバイト数）を返します。エポックごとの出力は、呼び出し側が指定したファイルにのみ送られます。これらのツールは、新たな公開の接続点 kshana::iq::cli::execute を通じて CLI と同じコード経路を実行します。これは CLI のメッセージを印字せずに返します（標準出力は MCP の JSON-RPC チャネルであるため）。iq::cli::build_code と iq::cli::signal_names も公開されました。ソフトウェアのみで追加的な変更です。IQ 層は干渉やスプーファーの合成を追加せず、何も送信されず、新しい依存関係もありません。server.json は二つの環境変数を宣言します。mcp/kshana-mcp/tests/iq_round_trip.rs のラウンドトリップテストは、短い二衛星のシーンを生成し、捕捉をシーン自身の真値サイドカーに照らして検査するほか、トラッキングのロックと C/N0、フロントエンド、SigMF 出力、予算、パスの閉じ込め、無効状態も検査します。

• 検証台帳（ledger）における GNSS IQ 層。gps-sdr-sim（独立した GPS L1 C/A ベースバンド生成器、MIT、コミット 28ca29a6）に対する事前登録されたクロスチェックが、常時実行されるテストスイート（tests/iq_gpssdrsim_cross_generator.rs）に加わりました。コミット済みの参照出力（tests/fixtures/iq_gpssdrsim_cross_generator/：gps-sdr-sim 自身の 8 ビット I/Q の 20 ms、そのチャネル一覧、および同じビルドにリンクされたハーネスから得たその背後のチャネル状態）は、scripts/gen_iq_gpssdrsim_ref.sh で再生成されます。テスト時にネットワークや外部ツールは必要ありません。台帳の行が二行追加されます（251 行：独立した外部の参照と照合して確認済みが 124、モデルから計算が 123、パートナーの担当部分が 4）。

  • 独立したベースバンド生成器に対する GNSS IQ シーンの信号ジオメトリ：独立した外部の参照と照合して確認済み。放送エフェメリスのシーンの真値（可視衛星の集合、疑似距離、コード位相、ドップラー、見通し角）は、11 チャネルすべてで gps-sdr-sim のチャネル状態と一致します。最悪値は 1.6 mm、5.5e-6 チップ、7.4e-5 Hz、4e-9 度で、実行前に固定した合格基準 0.05 m、2e-4 チップ、0.02 Hz、1e-4 度に対するものです。
  • 独立に生成した I/Q サンプルに対する GNSS IQ の捕捉：モデルから計算、所見あり。iq::acq は、gps-sdr-sim のサンプルに含まれるすべてのシミュレート衛星を、登録した合格基準の範囲内で検出します（コード位相は 0.195 チップ以内、ドップラーは 72 Hz 以内）。ただし、登録した「他の PRN は検出されない」という基準は満たされません。gps-sdr-sim の雑音なしの出力では、ガウス雑音のしきい値が、存在しない 21 個の PRN すべてで、他の衛星との相互相関によって超えられます。厳密なテストは所見とともに無視された状態で残され、固定したテストがそれを記録しています。エンジンのコードや公開 API は変わりません。サンプル I/Q はサンプル単位では比較されません。gps-sdr-sim の整数の正弦テーブル、ゲイン、ゼロの初期搬送波位相、切り詰められた LNAV フィールドは、受信機が一致させるべき量ではないためです。比較は、受信機が測定する観測量で行われます。

変更#

• iq track は、既定で ≈4 ms の捕捉から引き継ぎます（動作の変更）。各トラッキングチャネルを初期化する捕捉は、一周期ではなく ceil(4 ms / T_code) のコード周期をコヒーレントに積分するようになりました。ここで T_code はコードの完全な周期です（階層コードでは、一次コード長と二次コード長の積で、捕捉が積分する単位）。階層のない 1 ms のコード（GPS L1 C/A、BeiDou B1I、GLONASS L1OF）は 4 周期（4 ms）を探索するようになったため、既定のドップラーステップ 2 / (3 · N · T_code) は ~667 Hz ではなく ~167 Hz になります。完全な周期が既に 4 ms 以上のコードは、すべて 1 周期のままです。Galileo E1-B（4 ms）、BeiDou B1C（10 ms）、階層コードの GPS L5-I/L5-Q、Galileo E5a-I/E5a-Q と E1-C（オーバーレイコードを含めて 10 から 100 ms）、および GPS L2C です。したがって、どの信号も少なくとも ~4 ms は積分します。一周期の探索では、チャネルを最大 ~333 Hz ずれた状態で引き継ぐことがあり、それは FLL のプルインの範囲外で、~500 Hz 離れたフォールスロックを追跡しながら、問題のない追跡であるかのように報告しました。180 本の GPS L1 C/A チャネルをシード付きでスイープした結果（ドップラーは ±5 kHz にわたり、38 から 47 dB-Hz、半数は航法データ付き。docs/design/evidence/iq-track-acq-default/、再実行可能）では、フォールスロックは 180 本中 27 本から 180 本中 1 本に、捕捉の失敗は 102 件から 11 件に減り、その代償は GPS L1 で PRN あたり ~40 ms の追加探索です（11 → 52 ms）。残った一件のフォールスロックは 38 dB-Hz で、36 Hz ずれていました。すべてのインターフェースが一致します。kshana iq track と kshana iq sweep（--acq-coherent）、Python の kshana.iq_track（acq_coherent=None は自動になりました。スタブも更新）、および MCP の iq_track ツールです。従来の既定に依存していた場合は、acq_coherent=1（--acq-coherent 1）を渡せます。kshana iq acquire 自身の --coherent の既定は 1 のままです。新しい公開項目 iq::acq::auto_coherent_periods と iq::acq::AUTO_COHERENT_S、回帰テスト tests/iq_cli.rs::track_default_handoff_does_not_false_lock_where_one_period_did。
• 生成されるすべてのグラフィックが、サイトの Observatory テーマに従うようになりました。すべてのグラフのバイト列が変わります。これは公開済みの図の意図的な改訂で、変わったのは色とフォントだけです。プロットされた値、座標、ラベルは動いていません。すべてのシナリオの *.chart.svg（したがって Studio のグラフのエクスポートと README のデモグラフも）、実行レポートの HTML（*.report.html）、タイムラインのアニメーション（--animate）、シナリオ結果と調査の HTML ページ、検証サマリー、ドキュメントの図とダイアグラムは、これまで暖色系ダークの 七月のパレット（#0c0b08 の地、#e0bd84 のゴールド）と、暖色系ペーパーのレポートテーマを使っていました。これらは今後、すべての色とフォントを一つのモジュール src/palette.rs から取得します。このモジュールは web/theme.css を反映しています。グラフは、Observatory の地（#060A14）の上に、Geist の書体スタックで計器風のダークで描画されます。レポート、アニメーションプレーヤー、結果ページは、Observatory のライトとダークのトークンで、閲覧者のライト/ダークの設定に従います。六つの障害領域には、それぞれ一色が割り当てられています（干渉はコーラル、スプーフィングはマゼンタ、タイミングはブルー、軌道はシアン、インテグリティはライム、航法はアンバー）。エビデンスのティアは、独立した外部の参照と照合して確認済みがライム、モデルから計算がアンバー、パートナーの担当部分がマゼンタで表されます。ウォーターフォールのランプは、知覚的な（inferno の）順序を維持したまま、新しい地に合わせて再アンカーされています。
  • tests/palette_sync.rs は、このモジュールを両方のテーマで web/theme.css に一致させ、docs/assets/palette.json と docs/diagrams/mermaid-config.json（どちらもこのモジュールから生成され、Python の図ツールと mermaid-cli 用）が最新であることを検査し、パレット以外の src/ に 十六進数の色リテラルが現れると失敗します。
  • tests/published_figures_still_reproduce.rs に三つ目の診断「色とフォントだけが動いた」が追加され、パレットの改訂と、プロットされた値の変動を区別できるようになりました。再レンダリングされた README のすべてのグラフは、その正規化のもとで、以前のものと一致することを確認しました。
  • tools/gen_validation_figures.py はパレットを読み込み、これまでコミット済みのジェネレーターがなかった README の三つの結果の図（domain-coverage-map、scenario-fom、sgp4-regime-bars）も、実際のテキスト要素を使って、web/capabilities.json、clock-holdover の結果、tests/fixtures/sgp4_comparison.md から生成するようになりました。tools/gen_readme_assets.py も同じパレットを読み込み、サイトとのライトテーマのずれが解消されます。sgp4-regime-bars の値は、そのフィクスチャーの kshana↔ref 最悪ケースの列（7.31e-9、8.05e-9、8.18e-9、4.12e-6 km）で、Matplotlib の図から変わっておらず、tests/figures_doc_sync.rs は、コミット済みの図とフィクスチャーが食い違うと失敗するようになりました。
• docs/assets/figures/domain-coverage-map を最新のデータに更新しました（データの変更であり、再描画ではありません）。この図は、8 領域にわたる 28 の機能（独立した外部の参照と照合して確認済みが 11、モデルから計算が 17）と述べていましたが、これは自身が示すソースに対して古くなっていました。新しいジェネレーターにより web/capabilities.json から描画し直した結果は、8 領域にわたる 46 の機能（独立した外部の参照と照合して確認済みが 17、モデルから計算が 29）です。

修正#

• CW/狭帯域ジャマーの Q は 1.5 ではなく 1.0 になりました。搬送波上のトーンに対する教科書の値は 1 です（トーンは信号のスペクトルのピークを保ちます。κ = T_c、Q = 1/(R_c κ)）。従来の 1.5 では、J/S が同じ場合に、トーンが広帯域雑音よりも損害が小さくなっていました。出力の変化：jamming、lunar-jamming、interop の各種別で、高 J/S の CW/狭帯域ジャマーのもとで、実効 C/N0 が約 −1.8 dB になります（同梱の spectrum の例のトーン：表からは 17.98 dB-Hz、従来は 19.74）。広帯域の Q は 1.0 のままです（保守的で、教科書の ~2 より約 3 dB 低い）。0.34 のレビューまで保留しています。従来の 1.5 を保つには q_override を設定してください。

• kshana iq scene の整数出力が、整数の範囲を使うようになりました。単位電力の雑音とライタースケール 1 では、ci8/ci16 のシーンは約 {-1、0、1} になり、2 ビットのシーンではしきい値が 2.8 シグマにありました。整数形式は、期待される成分ごとの RMS がフルスケールの四分の一（ci8 で 31.75 LSB、ci16 で 8191.75）、または 2 ビットで 2 LSB になるようにスケーリングされます。スケールとクリップされた要素の数は、印字され、サイドカーに書き込まれます。浮動小数点出力は変わりません。

• 七つのテストファイルにある八つのフィクスチャーのピンが、macOS で最下位ビットの差により失敗しなくなりました（issue #36 の一部）。エンジンがオラクルのコミット済みの入力（ヤコビアン、状態表、打ち上げ方位角）を今も構築できることを検査するピンは、ビット単位で比較しており、macOS arm64 では最後の桁の 2 から数千単位の差で失敗していました。現在は、フィクスチャーから取ったスケールの 1e-12 以内で比較します。整数、キー、長さは引き続き厳密に比較され、ミューテーションテストにより、1e-6 の相対変化では依然として失敗することが示されています。打ち上げ方位角のピンは、方位角そのものではなく sin az と昇交/降交の枝を比較します。軌道傾斜角が地点の余緯度に等しい場合、asin は引数の一 ulp を約 3e-9 rad に増幅するためです。オラクルの許容差や事前登録した合格基準は変わっていません。二つのテスト（月の同時 OD、月の可観測性）は対象外です。macOS では、それらの事前登録された比較自体が変動し、これは後続の対応に委ねられています。

• kshana iq track と kshana iq sweep がフロントエンドのフラグを適用するようになりました。使い方のテキストでは track に --bandpass/--notch/--blank/--excise/--agc/--bits があると示されていましたが、track と sweep はチェーンを構築せず、フラグは黙って無視され、--notch のような値のないフラグは、その後ろのフラグを飲み込んでいました。両方のコマンドが iq acquire と同じようにそれらを解析し、捕捉パスとトラッキングパスの前に新しいフロントエンドチェーンを置くようになりました。出力は、同じフラグで iq frontend が書き出すファイルに対してコマンドを実行した場合と一致します。

• IQ シーンのデータは、信号ごとに配置されます。 kshana iq scene --data（および NavData::Seeded）は、パイロットを含むすべての信号に 50 bit/s のビットを載せ、Galileo と BeiDou では GPS の LNAV のレートで載せていました。データは、新しい SpreadingCode::data_modulation()（DataModulation、iq::signals のすべてのコンストラクターが設定）で定められた、各信号自身のシンボルタイミングに従うようになりました。L5-I5 では 10 ms、E1-B では 4 ms、BeiDou B1I GEO（D2）では 2 ms、GLONASS L1OF では 10 ms のミアンダーを伴う 20 ms のビットです。データは、パイロット、一つの CM/CL ストリームである GPS L2C で拒否され、NavData::Lnav は L1 C/A 以外のすべてで拒否されます。カスタムコードは、既定で従来の 20 ms のタイミングを維持します。L1 C/A 以外のコードに NavData::Lnav を要求した、またはパイロットに NavData::Seeded を要求したプログラム上の Scene は、これまで黙って生成されていましたが、最初の読み取りでエラーを返すようになりました。

• GLONASS L1OF のチャネルは、それぞれの FDMA 搬送波で捕捉とトラッキングが行われます。 iq::acq::acquire とトラッキングチャネルは、すべてのコードを if_hz のみからダウンミックスしていました。そのため、マルチチャネルの GLONASS 録音でチャネル +3 を探索すると、チャネル 0 の信号が見つかり（すべてのチャネルが一つの測距コードを共有するため）、1.6875 MHz 高い位置は探索されませんでした。どちらも SampleSpec::baseband_hz(carrier) = if_hz + (carrier − center_hz) を使うようになりました。搬送波の項は、信号自身の搬送波を中心とするすべての録音ではゼロであり、中心が不明な場合は省かれるため、CDMA の処理は変わりません。carrier − center をサイドカーの if_hz に折り込むことで古い動作を回避していた場合は、その項を削除してください。オフセットは搬送波と中心から適用されるようになったため、残したままにすると二重に適用されます。ここで変わっていない既知の制限：GLONASS のシーンは各衛星を周波数チャネル k で識別し、u32 の衛星 ID は負のチャネルを折り返します。真値サイドカーは k = -7 を sat_id 4294967289 として書き出します（k + 2^32）。i32 のキャストで、k として読み戻してください。

[0.32.0] - 2026-10-05#

追加#

• CLI と Python 上の GNSS IQ 層（0.32.0 フェーズ A）。既存の iq モジュールは、Rust を書かなくても使えるようになりました。五つの新しい kshana iq コマンドがデータ処理のグループに加わります。scene は、真値サイドカー付きで、長い複数衛星の IQ シーンをファイルに生成します。acquire は、録音に対して一つ以上の PRN の FFT 捕捉を行い、各検出（PRN、ドップラー、コード位相、統計量、しきい値）を報告します。track は、捕捉の後に DLL/PLL/FLL のバンクを録音に対して実行し、ループ帯域幅、積分時間、相関器間隔を設定できるエポックごとのトラッキング出力（CSV/JSON）を出力します。sweep は、一つの録音を複数のループ設計で再生し、設計ごとの結果のジッターとロックの指標を報告します。labfit は、トラッキングループのロック喪失モデルを、受信機の信頼性のタイムラインに当てはめます。同じコアは Python（kshana.iq_scene、iq_acquire、iq_track、iq_labfit、iq_signals）にも公開されており、NumPy で扱いやすいリストと辞書を返します。ソフトウェアのみで追加的な変更です。新しい依存関係はなく、送信はなく、干渉やスプーフィングの波形合成もありません。エンジン、捕捉、トラッキング、ループ設計はクレート自身のものなので、CLI や Python の呼び出し側は、Rust のテストと同じビットを得ます。新しいモジュール iq::cli。シーン自身の真値サイドカーは、tests/iq_cli.rs における独立したオラクルです（捕捉は注入した各コード位相とドップラーを復元し、トラッキングは注入したドップラーに収束します）。公開済みのシナリオ種別の数や検証マトリクスの行に変更はありません。
• iq の CLI と Python における、GNSS IQ ライブラリの残りの機能（0.32.0 フェーズ A.2）。フェーズ A を基に、iq 層の残りを、Rust を書かなくても使えるようにします。
  • iq scene の伝搬チャネル（および Python の iq_scene）：一次の電離圏（--iono-stec/--iono-vtec または --iono-klobuchar）、Saastamoinen/Niell の対流圏（--tropo）、Cornell のシンチレーションモデル（--s4、--scint-tau0、--sigma-phi）、鏡面反射の地表マルチパス（--multipath-height/--multipath-ground）、三状態の陸上移動チャネル（--land-mobile）、見通し外のブロック（--nlos）が、新しいクレート内部のブリッジ（iq::channel::SceneChannelAdapter）を通じてすべての衛星に適用されます。このブリッジは、チャネルモデルの絶対経路を、シーンの幾何に対する超過分の形に変換します。
  • iq scene の SigMF 出力（--format sigmf）：サンプルを .sigmf-data/.sigmf-meta のペアとして、キャプチャと衛星ごとのアノテーション付きで書き出します。acquire/track は既に SigMF を読み込めるため、シーンはラウンドトリップします。
  • フロントエンド DSP：新しい iq frontend <in> <out> コマンドと、acquire/track の同じフラグ（--bandpass、--notch、--blank、--excise、--agc、--bits 1/2/3/8/14）が、iq::frontend の各段（バンドパス FIR、適応ノッチ、パルスブランキング、周波数領域エクサイズ、AGC、量子化器）を実行します。Python には iq_frontend として対応します。
  • 放送エフェメリスのシーン：iq scene --nav <rinex_nav> --rx-pos lat,lon,alt（--start/--window/--prn と併用）は、エンジンの RINEX リーダーを使って、健全な各 GPS 衛星を実際の放送ジオメトリの位置に配置するため、真値サイドカーには衛星ごとの実際の距離、ドップラー、コード位相が含まれます。Python には iq_scene_broadcast として対応します。ソフトウェアのみで追加的な変更です。新しい依存関係はなく、送信はなく、干渉やスプーフィングの波形合成もありません（チャネル伝搬の効果は、正規の信号にのみ作用します）。数値に関する各主張は、チャネルとフロントエンドの単体テストおよび tests/iq_cli.rs で、独立した参照（閉形式または注入した真値）に対して検査されています。

[0.31.0] - 2026-10-04#

追加#

• GNSS IQ 層：信号レベルのシミュレーションとソフトウェア受信機の処理。新しい iq モジュールにより、Kshana は単一衛星で短いブロックの L1 C/A フロントエンドから、完全な信号レベルの層へと拡張され、kshana iq コマンドグループから利用できます。この層は、エポックごとの真値サイドカー付きで、長い複数衛星の生の IQ シーンを生成し（iq::scene）、信号レベルで伝搬を適用します。コードと搬送波の発散を伴う電離圏、対流圏、振幅と位相のシンチレーション（Cornell モデル）、フレネルマルチパス、三状態の陸上移動チャネル、および見通し外（iq::channel）です。FFT 捕捉とマルチチャネルの DLL/PLL/FLL バンクで捕捉とトラッキングを行い、一つの録音を多数のループ設計で再生します（iq::acq、iq::track）。フロントエンドをモデル化し、FIR/IIR フィルタリング、1 から 14 ビットの量子化、AGC、ノッチ、パルスブランキング、周波数領域エクサイズを扱います（iq::frontend）。大規模な記録データセットを、メモリ上限のもとでストリーミングし、int8/int16/float32/パックされた 2 ビットおよび実数 IF の形式、複数ファイルの SigMF、リサンプリング、ファイルごとの SHA-256 を持つデータセットのインベントリ、バッチランナーを備えます（iq::io）。GPS L5/L2C、Galileo E1（CBOC、実際の ICD メモリコード）と E5a、BeiDou B1C/B1I、GLONASS L1OF の拡散コードを追加し、それぞれをインターフェース管理文書に照らして検査します（iq::signals）。さらに、トラッキングループのロック喪失モデルを、ラボ実行で観測された実際の受信機の挙動に当てはめ、一回分を除いたホールドアウト誤差と、予測と明記した外挿を提供します（iq::labfit）。数値に関する各主張は、独立した参照（ICD の表、閉形式、または注入した真値を復元する独立した受信機）に対して検査されます。物理的なチャネルとループのモデルは MODELLED のままです。これはソフトウェア層のみです。ソフトウェア受信機向けに IQ ファイルを書き出しますが、干渉やスプーフィングの波形は合成せず、無線ハードウェアも駆動しません。公開済みのシナリオ種別の数や検証マトリクスの行に変更はありません。設計：docs/design/GNSS-IQ-PLAN.md。
• 受信機の信頼性：実際の GNSS 受信機のログを評価します。 kshana receiver-trust <scenario.toml> は、u-blox UBX、RINEX 3（任意の放送航法ファイル付き）、Android GnssLogger、NMEA 0183 のいずれかのログを、時刻タグ付きの一つのタイムラインに読み込み、その上で信頼性モニターを実行します。モニターは、搬送波対雑音密度（C/N0）の低下、ロック喪失、自動ゲイン制御（AGC）、u-blox のジャミング指標、位置のジャンプ、そして RINEX と航法ファイルがある場合は、エンジン自身の単独測位解（パリティ受信機自律インテグリティ監視（RAIM）とクロック支援モニター付き）です。各エポックは、正常、劣化、または信頼不可のいずれかとなり、結果にはいつ、なぜそうなったかが示されます。シナリオに記載されたイベントと予測された C/N0 の低下は、同じファイルに記載された許容差に対してスコアリングされ、検出、遅延、見逃し、そして一致または不一致に分類されます。出力は、結果の JSON、エポックごとの CSV、グラフです。結果にはログの SHA-256 とすべてのしきい値が含まれます。Python（kshana.receiver_trust）、WebAssembly パッケージ（receiver_trust、ログはインライン）、および Model Context Protocol（MCP）サーバーの新しい assess_receiver_log ツールからも利用できます。ガイド：docs/RECEIVER-TRUST.md、例：examples/receiver-trust/。JammerTest 2024 のスプーフィングログでは、エンジンの経路が、事前登録したオラクルのパイプラインによる最初の警報を、公開されているすべての開始時点で再現します（tests/receiver_trust_jammertest.rs）。モニターは MODELLED のままで、検証マトリクスの行に変更はありません。

0.30.0 - 2026-10-03#

マイナーリリースです。検証ラウンド 2 とウェーブ 1 のパッケージにより、検証マトリクスは、0.29.3 の 223 行（VALIDATED が 93）から、249 行（VALIDATED が 123、MODELLED が 122、PARTNER が 4）になりました。すべての昇格は、実行前に固定した許容差で独立したオラクルに照らして確認され、食い違いはすべて所見として公開されています。新規：ネイティブの NAIF カーネルリーダーと DE440 経路、独立した外部の参照と照合して確認済みの SGP4 から ITRS への伝搬と時刻の経路、実測のクロックライブラリ、LunaNet AFS の参照ジェネレーター、拡張精度と平方根情報のソルバー、LuGRE データによる実際の月面 IQ 処理。変動した公開済みの数値は、下に改訂として列挙しています。

検証マトリクスの二十七行が、最初の比較の前に固定した許容差の範囲内で独立したオラクルと一致したため、VALIDATED になります（docs/VALIDATION.md の昇格規則）。内訳は、最初の検証ラウンドで十行、二回目で十七行です。最初のラウンドでは五十一行の MODELLED の行が外部のオラクルにかけられ、二回目では、残りの経路を設定できる行がかけられました。食い違いはすべて、調整で消すことなく、下に所見として記録しています。三行は、確認済みの部分が確認されていない残りを抱え込まないように分割され、これによりマトリクスは 223 行から 226 行になりました。その後に取り込んだ検証パッケージで 249 行になります。件数は、生成された docs/VERIFICATION-MATRIX.md から読み取っています。

この項目で使用する略語

略語	意味
ADD、ARAIM、MAAST	（ARAIM の）Airborne Design Document（航空機搭載設計文書）、高度な受信機自律インテグリティ監視、スタンフォード大学の Matlab Algorithm Availability Simulation Tool
ADEV、VRW、ARW	アラン偏差、速度ランダムウォーク、角度ランダムウォーク
ANISE、SPICE、NAIF、PCK	オープンソースの天体力学ツールキット（Nyx Space）、NASA の航法・補助情報機関（Navigation and Ancillary Information Facility）による Spacecraft, Planet, Instrument, C-matrix, Events ツールキット、惑星定数カーネル
BCRS、TDB、TT	太陽系重心座標系、太陽系力学時、地球時
BIPM、UTC(k)	国際度量衡局、各研究所が実現する協定世界時
CCSDS、OEM、LTC、TCL	宇宙データシステム諮問委員会、軌道エフェメリスメッセージ、メッセージの TIME_SYSTEM フィールドに書かれる月の時刻系
CRLB	クラメール・ラオの下限
CW	クローヒ・ウィルトシャー相対運動
DE440	ジェット推進研究所の Development Ephemeris 440
DOP、PDOP	精度低下率、位置精度低下率
EKF、UKF、INS、GNSS、IMU	拡張カルマンフィルター、無香料カルマンフィルター、慣性航法システム、全球測位衛星システム、慣性計測装置
EMT、VPL、HPL	有効モニターしきい値、鉛直および水平の保護レベル
EOP、IERS、PCC、MAE	地球姿勢パラメーター、国際地球回転・基準系事業、予測比較キャンペーン、平均絶対誤差
ERFA、SOFA	Essential Routines for Fundamental Astronomy、Standards of Fundamental Astronomy
GMAT	NASA の General Mission Analysis Tool
NTN、SSB	非地上系ネットワーク（3GPP）、同期信号ブロック
IGS、ILRS、ITRF2020	国際 GNSS 事業、国際レーザー測距事業、国際地球基準座標系 2020
ILS、LAMBDA	整数最小二乗法、Least-squares AMBiguity Decorrelation Adjustment
ISB	システム間バイアス
LEO	低軌道
MHSS、PL、TPL	多重仮説解分離、保護レベル、タイミング保護レベル
PSD、IQ、SigMF	パワースペクトル密度、同相成分と直交成分のサンプル、Signal Metadata Format
QPN	量子射影雑音
RAIM	受信機自律インテグリティ監視
SBAS、WAAS、DFMC、GEO	衛星型補強システム、米国の広域補強システム、二周波多衛星コンステレーション、静止軌道の SBAS 衛星
RMS、SISRE	二乗平均平方根、信号空間測距誤差
RTKLIB	オープンソースの GNSS 測位ライブラリ
TCXO	温度補償水晶発振器
VLBI	超長基線電波干渉計

外部の参照と照合して確認済み#

以下の各行には、オラクルの種別（ライブラリ：一意に定まる量を計算する独立したサードパーティのライブラリ、実測：実際に測定されたデータ、P2：コミット済みの入力に対して線形代数の量を再計算する独立した数値ライブラリ）、オラクル、実行前に固定した許容差、結果を記載しています。すべての昇格は、第二の査読者が再実行し、その査読者はフィクスチャーをバイト単位で再生成して、意図的なエンジンの変異によってテストが失敗することを示しました。

• GNSS/INS センサーフュージョン（ライブラリ）。対象は疎結合の 15 状態の誤差状態 EKF に限定：NaveGo v1.4（LGPL-3.0、GNU Octave 上で実行）を、その自身の実際の Ekinox IMU/GNSS 走行データで比較。Kshana の水平、鉛直、位置イノベーションの RMS は、NaveGo の 0.912、0.940、0.861 倍（合格基準 1.2）で、平均の正規化イノベーションは 0.395（合格基準 1.5）です。GNSS は走行の全期間で利用できるため、途絶は試験されていません。密結合の UKF と、結合したクロックフィルターは、主張の対象外です。
• 3-DOF の姿勢と指向誤差バジェット（ライブラリ）。重力傾斜トルクのピークに限定：Basilisk 2.9.1 の GravityGradientEffector、40 ケース、相対 1e-12 以内（最悪値 2.1e-15）。RSS の指向バジェットは、呼び出し側が与えた数値の和であり、対象外です。
• 月面での通信とナビゲーションの統合ジオメトリ（ライブラリ）。地点の配置、方位角、仰角、距離に限定：ANISE 0.10.2、768 サンプル、1e-6 度と 1 mm 以内（最悪値 2.2e-12 度と 5.6e-9 m）。測距精度のパラメーターは設計入力であり、主張の対象外です。
• トルクフリーの剛体姿勢ダイナミクス（ライブラリ）：Basilisk 2.9.1 の宇宙機ハブ、一般的な二つの慣性モーメントで 1e4 秒、クォータニオンと角速度は 1e-9 以内（最悪値 3.3e-11 と 3.4e-12 rad/s）。
• GNSS 搬送波位相の整数アンビギュイティ解決（LAMBDA）（ライブラリ）。ILS の解と、その上位二つのノルムに限定：RTKLIB v2.4.2-p13 の lambda()、300 の共分散、整数の不一致 0 件、ノルムは相対 1e-9 以内（最悪値 5.6e-13）。ブートストラップ成功率は、引き続き内部での検査にとどまります。
• 合成タイミング PL、スカラー MHSS（P2）：300 のコミット済み入力に対する numpy 2.3.5 と scipy 1.18.1。PL は相対 1e-9 以内（最悪値 1.2e-10）、支配的な部分集合は同一です。
• GLS の同相モードのホワイトニングとマハラノビスの恒等式（P2）：201 のコミット済み共分散に対する numpy 2.3.5 の LAPACK、相対 1e-12 以内（最悪値 7.9e-16）、条件数は最大 19.3。
• DE440 の月の主軸向き提供機能（ライブラリ）：2,000 のノード外エポックにおけるバイナリ PCK への SPICE の pxform、1.7e-5 rad 以内（最悪値 1.7e-6 rad、月面で約 3 m）。「修正」に列挙した修正の後の値です。
• SigMF の録音の入出力と Welch スペクトル（ライブラリ）。SigMF の読み書きと welch_psd に限定：scipy 1.18.1 の signal.welch と、ビンごとに相対 1e-12 以内（最悪値 6.0e-14）、sigmf-python 1.13.0 の録音はビット単位で同一にデコード、クレートのメタデータは SigMF v1.2.6 のスキーマに適合。IQ の合成とそのモデル比較は対象外です。
• LEO 放送エフェメリスのフィッターと、フィット区間に対する SISRE（実測）。16 パラメーターのケプラー軌道フィットと、その軌道のみの SISRE に限定：TU Graz の ITSG 精密軌道（四つの衛星）を Liu ら 2025 の統計と比較し、各成分は 1.5 倍以内（0.804 から 1.087）、SISRE は 1.5 倍以内（0.716 から 0.809）。

所見#

オラクルはこれらの行と食い違ったため、これらは MODELLED のままです。各所見は、その行のオラクルのテキスト（したがって docs/MODELLED-RATIONALE.md）にも書き込まれ、それを固定するテストが付いています。

• 搭載クロックの状態推定：11 機の GPS Block IIF 衛星の保持した IGS クロックでは、三状態フィルターは 一ステップ先では整合していますが、一時間後には 11 機中 9 機で自信過剰になります（周期項とフリッカー項はモデルに含まれていません）。
• スプーフィング検出：JammerTest 2024 では、公開されている 8 件の開始時点のどれに対しても、10 秒以内に警報を出した観測量レベルのモニターはなく、開始前の三つのウィンドウで誤警報がありました。
• スプーフィング下のタイミング保護レベル：検出された 8 件の開始時点のうち 3 件で、測定された未検出の時刻誤差が TPL を超えます（1.9 倍から 5.3 倍）。60 秒のクロック較正では、受信機の TCXO のワンダーをカバーできません。
• 打ち上げ窓と上昇のジオメトリ：Orekit 12.2 に対して、ジオメトリは丸め誤差の範囲で一致しますが、地球自転による地点速度は、緯度 62.9 度で相対 1e-6 を外れます（1.12e-6、球モデルが省略する極運動）。ラウンド 2：エポック付きの真の極の速度は一致しますが、エポックなしの既定の速度は依然として外れます（下を参照）。
• 弾道再突入回廊（Allen–Eggers）：Stardust の再突入について予測されたピーク減速は 61.8 g で、再構成された 32.89 g に対して +88 %（許容差 15 %）です。
• UT1 と極運動の合成誤差：178 号の IERS Bulletin A に印刷された精度の式に対して、極は 1.5 倍以内で一致しますが、UT1 は一致しません（10 日で 0.48、40 日で 1.59）。ラウンド 2 で置き換えられました。この行は現在 VALIDATED です（下を参照）。
• オフラインの既定の地球姿勢入力：astropy は行の集計を確認しますが、クレートが Bulletin A の予測と呼ぶ 12 行は、予測（P）ではなく、実測（I）のフラグが付いています。したがって、運用的な予測器の行の一致の数値は、実測の行に対するものでした。ラウンド 2 で置き換えられました。エンジンはフラグで行を分類するようになり、この行は VALIDATED です。
• 運用形式の地球姿勢予測誤差：予測器の UT1 誤差は、1 から 10 日で Bulletin A の 2.4 倍から 12.6 倍、10 日で 5.32 ms となり、第 2 回 EOP PCC の 0.36 から 3.13 ms の範囲外です。
• 月面の測地 VLBI：DE440 経由の ANISE の光行時間に対して、1 ps 以内の遅延はなく、最大の差は 24 µs で、大部分は解析的な月の中心（DE440 から約 200 km）によるものです。ラウンド 2：カーネル経路は独自の行で VALIDATED となり、この解析的な経路は MODELLED のままです。
• 月面の相互運用性エクスポート：Orekit 12.2 は LTC と TCL の時刻系を拒否するため、月面の OEM ファイルを別のリーダーとやり取りできることは確立されていません。
• クローヒ・ウィルトシャー相対運動：100 m での Orekit の非線形運動に対して、差は 1.2 から 6.3 mm で、1 mm を上回ります。これは省略した二次の項に比例するため、事前登録した許容差は線形化誤差を下回っていました。ラウンド 2 で置き換えられました。二次補正は、同じ合格基準に対して VALIDATED です。
• INS/TRN の慣性航法による誤差増大：NaveGo の自由慣性モンテカルロに対して、増大則は 600 秒まで 5 % 以内で成り立ち、それを超えると過大評価になります（一時間で 2.2 倍から 8 倍）。シューラーフィードバックを省略しているためです。ラウンド 2 で置き換えられました。シューラー誤差モデルは VALIDATED です。
• 実際のコンステレーションジオメトリによる月面サービスボリューム：公開されている 12 件の可用性統計のうち 4 件が、2 パーセントポイントを超えて異なります（最大 22.5）。
• 異種の UTC(k) トレーサビリティバイアスのオーバーバウンド：105,024 行の BIPM データで、50.8 % の行がオーバーバウンドを超えています。公表された不確かさが拘束するのは、オフセットの BIPM による測定であり、オフセットそのものではありません。
• 月面の測地基準系のヌル空間の分類：公表されている五つの反射器のジオメトリでは、相関は -0.97 ではなく -0.78 で、原点の CRLB は論文より 96 から 98 % 低くなります。
• 月レーザー測距の測地基準系ジオメトリの基盤：2024 の 192 点の ILRS 月面ノーマルポイントに対して、片道の残差 RMS は、以前の向きの補間では 96 m でしたが、下の修正の後は 22.7 m で、それでも 10 m の合格基準を上回ります（丸めた観測局座標、極運動なし）。向きの系列は、2024-2025 の外では黙ってクランプされます。ラウンド 2：測距値モデルは独自の行で VALIDATED となり（2.81 m）、系列は 2014-2030 を対象とし、その外ではエラーになります。
• 相対論的なクロックレートとフレームの結合：自己ポテンシャル項は、公表値を 3.18e-4 上回ります（許容差 1e-4）。論文は別のポテンシャルを評価しているため、この閉形式の公表値は存在しません。ラウンド 2 で置き換えられました。次数 2 の赤道ポテンシャルは、同じ論文に対して VALIDATED です。
• すべての太陽系天体の物理定数：追加された天体の 84 個の定数のうち 12 個が、NAIF の pck00011 と gm_de440 と異なります（火星の衛星の古い軌道要素、天王星、海王星、冥王星の別の GM 解）。ラウンド 2：定数は NAIF に従うようになり（転記であり、集計には含めません）、計算した向きは SPICE と一致します。この行は MODELLED のままです。
• 選択可能な LEO エフェメリスモデル：22 パラメーターのフィットは、20 分の弧で、公表されている along-track 誤差の 1.71 倍と 1.86 倍となり、1.5 倍を上回ります。ラウンド 2 で置き換えられました。22 パラメーターのモデルとフィットは、独自の行で VALIDATED です。
• GNSS と LEO の統合測位：システム間バイアスは RTKLIB と一致しますが、ITRF2020 の 3 m 以内にあるエポックは 93.2 % で、95 % に届きません。RTKLIB 自身もそのデータで 88.2 % に達します（ラウンド 2 のグループ遅延の修正後は 93.6 %）。
• 同相モードのインテグリティ盲点とカバレッジと DOP のマップ：どちらの比較も通りましたが、意図的に誤らせたエンジンも通るため、レビューで採用を見送りました（前者は内部の恒等式しか検査せず、後者の公表されたフロアは PDOP の二倍化を検出できません）。ラウンド 2：同相モードのインテグリティ盲点は、パリティを持つ入力で VALIDATED です。カバレッジのマップは所見のままです（下を参照）。

検証ラウンド 2#

二回目のラウンドでは、最初のラウンドで経路を設定できる状態で残された行をすべて対象としました。新しい事前登録を、フィクスチャーを取得する前、またはオラクルを実行する前にコミットし、敵対的な第二の査読者が各比較を再実行し、意図的なエンジンの変異が各テストを失敗させる必要がありました。所有者は、Omega 外の境界の行の修正された文言を、昇格の前の 2026-10-02 に承認しました（古い文言はコードと矛盾していたため）。

VALIDATED に昇格（17）。括弧内はオラクルの種別、許容差は実行前に固定しています。

• 相対論的なクロックレートとフレームの結合（参照）：Ashby と Patla 2024 の L_m は、論文が引用する二つの場の次数 2 の赤道ポテンシャルから 2.8e-6 以内（合格基準 1e-4）。動径方向の入力には pyshtools の 350 次の重力（8.3e-5）、DE441 の月の速度（2.5e-3）。
• オフラインの既定の地球姿勢入力（ライブラリ）：astropy 8.0.1 と IERS Bulletin A No. 039 が、再構成した抽出データの 30 の確定、54 の速報、90 の予測の行を確認しています。
• UT1 と極運動の合成誤差（ライブラリ）：astropy と pyerfa の完全な回転が合成表を再現します（UT1 と極は 6e-16 以内、その組み合わせは 1.9e-7 以内）。IERS Annual Report 2019 の実現誤差は、比が 1.001 から 1.100 になります。
• EO ペイロードのフットプリントとカバレッジ（ライブラリ）：Orekit 12.2 と GeographicLib 2.1 が、事前登録したすべての合格基準を満たし、J2 の昇交点の回帰が、ノード間隔に取り込まれるようになりました。
• クローヒ・ウィルトシャー相対運動（ライブラリ）：閉形式の二次補正を加えると、Orekit の非線形運動に対して 1.2e-7 m 以内で、これは 1e-3 m に対するものです。線形行列のみの場合は、特性評価にとどまります（1.2 から 6.3 mm）。
• B 平面ターゲティングとパッチトコニックの重力アシスト（ライブラリ）：GMAT R2026a の B 平面、漸近線、C3、日心軌道要素。ティスラン・パラメーターには sbpy 0.6.0 と Kasuga and Jewitt 2019。
• INS/TRN の慣性航法による誤差増大（ライブラリ）：九状態のシューラー誤差モデルが、補正した NaveGo の慣性航法実行の、48 点すべてで 5 % 以内（最悪値 3.70 %）。
• 同相モードのインテグリティ盲点（P2）：1464 のパリティを持つ入力に対する numpy の lstsq、1e-12 以内（最悪値 1.06e-14）。
• 月面の統合マルチ技術 OD とクロック（P2）：QR 解法の修正後、numpy は六つのネットワークのすべてのガウス・ニュートンのステップ、シグマ、観測局誤差を再計算します（2.4e-11 以内）。
• 月面 VLBI の観測局座標の共分散（ライブラリ）：SPICE で構築したヤコビアンが、スケジュール、スペクトル、シグマ、ヌル空間を 1 % と 0.1 度以内で再現し、numpy は 2e-13 まで一致します。
• Omega 外の残差に対する検出不能な同相モードの境界（P2、所有者の判断により文言を修正）：256 ケースに対する numpy の LAPACK、1e-12 以内、厳密な無限大が六つ。
• 基底不変なヌル空間の分類（P2）：72 の構成した行列に対する SciPy と NumPy の部分空間の交わり。整数は厳密、射影のノルムは 6.0e-15 以内。
• LEO の航法メッセージの単一周波の電離圏サービスと UTC サービス（ライブラリ）：Klobuchar、Az、UTC のドリフトには GNSSTk 15.3.1。三つのうるう秒のケースには ERFA。
• 5G の非地上系ネットワーク測位の限界（P1）：Bachl、Lei、Nabeel 2026 の単一 SSB の限界は、印刷された桁の半分以内。測位解の共分散には numpy。
• 月レーザー測距の測距値モデル（実測、月レーザー測距の測地基準系の基盤から分割した新しい行）：192 点の ILRS 月面ノーマルポイントで RMS 2.81 m、合格基準 10 m に対するもので、IERS 2010 の太陽系重心の光行時間を使用しています。合格基準を下回る各成分は一つずつには分解されておらず、行にもそのように記しています。
• 月面の測地 VLBI、カーネル経路（ライブラリ、月面 VLBI の行から分割した新しい行）：J2000 付近のエポックで、SPICE の収束した光行時間は 1 ps 以内、偏微分は 1e-6 以内。解析的な既定の経路は MODELLED のままです。
• Liu ら 2025 の 22 パラメーターの LEO エフェメリスモデルとそのフィット（実測、選択可能なモデルの行から分割した新しい行）：実際の精密軌道が、論文の日と保持した日の両方で、公表された統計の 1.5 倍以内（0.683 から 1.186）。n_dot のスケール規約は転記したもので、この比較では確認されておらず、停止規則は、論文の RMS 変化の規則ではなく、Kshana のパラメーター収束の規則です。ATOMIC の多項式と五つの高度の表は MODELLED のままです。

既存の VALIDATED の行の裏付けを付け替えました（件数に変更なし）。

• JPL Standish 軌道要素による惑星位置と太陽系天体間の光行時間：事後的に設定した公称の二倍の合格基準は、JPL Horizons DE441 との事前登録した比較に置き換えられました（RMS は Explanatory Supplement の表 8.10.1 の値以下で、最悪値は 0.778、地球の分割と ICRF の回転を含みます。光行時間は、DE441 の位置に対する Horizons との差が 1e-6 秒以内で、最悪値は 6.7e-9 秒）。「比較の後に設定した限界」というフラグは削除されました。
• インテグリティ（RAIM/ARAIM/SBAS）：この行は、もはや妥当性の検査に頼っていません。現在の内容は次のとおりです。ADD v4.2 の ARAIM の多重仮説解分離は、270 件の実ケースで ARAIM 2 について Stanford MAAST と一致します（VPL の最大差は 2.2e-3 m、合格基準は 0.05 m）。スナップショット RAIM の検出と除外は、2016 件中 2016 件の判定で RTKLIB の raim_fde と一致し、スロープ保護レベルは 2.7e-12 m 以内です。SBAS DO-229E の L1 保護レベルは、実際の WAAS 放送で Stanford MAAST と一致します（2868 組が 1.6e-5 m 以内）。一様シグマの関数 raim::araim_raim と raim::araim_dual_raim は ADD に適合して「いない」こと（入力を揃えた差は VPL/HPL で 0.75/4.04 m と 0.39/1.93 m、所見）、DFMC L5 SBAS の比較は所見であること（GEO が見えない 308 組は Kshana では保護され、MAAST では保護されない）、そして raim::solution_separation_raim には外部との比較がないことを明記しています。その行の自己フラグは削除されました。
• LEO 放送エフェメリスのフィッター：積分した真値軌道が、確認済みの部分に加わりました（Orekit 12.2 に対して 6 時間で 4.55 mm 以内、合格基準は 2 cm）。補正多項式、クロックのフィット、更新周期のトレードオフは、モデルから計算されたままです。

所見と保留中の行（MODELLED のまま）。各行のオラクルのテキストに、所見とそれを固定するテストが記されています。

• 航法信号の変調（Betz 2001、Hein 2006）：スペクトルと相関は一致しますが、24 MHz のサイドローブとすべてのマルチパスバイアス（11 から 15 % 低い）は一致せず、原因は未解明です。
• TDOA/FDOA の位置推定：限界は Ho と Chan、Ho と Xu、および著者らのコードと 3e-12 まで一致します。モンテカルロから印刷された Ottawa の係数は、1.3 % と 4.4 % 異なります。
• 月の距離での地球の GNSS：GENESIS の天頂方向の平均は、6 件中 5 件で Montenbruck ら 2023 と一致します。天底方向の平均は、衛星数で 1.0 から 2.4 多くなります。
• カバレッジと DOP のマップ：地球の設計は、すべての合格基準で Orekit、gnss_lib_py、numpy と一致します。月と火星の設計が 1e-9 を超えるのは、特異に近いセルだけです。
• GNSS の統合測位：二周波の 79.9 % と精密プロダクトの 94.2 % が 3 m 以内で、95 % に対するものです（RTKLIB は 67.9 % と 94.1 %）。精密プロダクトの ISB の差は、RTKLIB がアンテナオフセットを無視していることによります。
• トラッキングループ（GNSS-SDR 0.0.19）：35 から 45 dB-Hz では一致します。30 dB-Hz では、PLL は +21 %、DLL は -32 %、しきい値は +1.5 dB で、スリップ時間は 0.5 から 2 桁短くなります。
• 月面サービスボリューム（Orekit と Hipparchus）：160 個の値のうち 155 個が一致します。最悪サンプルの要件は、特異に近い LNCSS B のジオメトリで満たされません。
• 量子慣性センサー：QPN のみのフロアは、Gauguet 2009 の測定雑音より 21 から 31 % 低くなります（合格基準 30 %、0.5 ポイント届きませんでした）。
• 発振器のプリセット：実測のユニットは、ルビジウムのホールドオーバー、セシウムの短期、CSAC の最悪ユニットの各プリセットを上回ります。OCXO のプリセットには実測の記録がありません。
• 宇宙天気の密度：Jacchia 1971 は、太陽活動極大期の加速度計密度の 2 倍以内ですが、2008 年の極小期では約 1.7 倍の過大な密度になります。
• ジオメトリフリーの斜め TEC：36 本の弧のうち 33 本が CODE マップの 3 TECU 以内です（最悪値 6.84）。
• 公式の JammerTest 2024 のログに対するスプーフィング検出と TPL：10 件の開始時点のうち 4 件が間に合って検出されました。TPL は 10 件中 4 件で超過されます。
• 新しい IGS クロックに対するクロックフィルター：11 機のうち二機がイノベーション和の基準を満たしません。
• 最小二乗に自己回帰を組み合わせた EOP 予測器：UT1 は 2 から 10 日で、Bulletin A の 1.73 から 2.11 倍です。
• UTC(k) の実現オフセットのオーバーバウンド：プールした超過率は 0.0333 で、1e-2 に対するものです。
• キャンペーンによる月面座標系の測地基準：SPICE の経路は一致します。観測局を推定する P2 の経路は、条件数 2.1e8 の問題で 1e-9 を外れます。
• 実際の LLR による月面座標系の測地基準：16 個の値のうち 15 個が SPICE と一致します。z 並進のシグマは 1 % に対して 1.03 % 高くなります。
• 再突入（Allen-Eggers）：質点解は、機関による再構成と一致します（クロスチェックのみ）。加速度計との比較は、読み取れる Hayabusa2 のソースがないため保留されています。
• ITU-T のマスク：印刷された計算例の値は一致します。G.8273.2 のクラス限界には該当する値がありません（保留）。
• 打ち上げ窓のジオメトリ：エポック付きの真の極の地点速度は Orekit と一致します（4.9e-8）。エポックなしの既定の速度は依然として外れます（1.12e-6）。昇格していません。後続対応は保留中です。
• すべての天体の物理定数：NAIF との差があるのは 84 個中 0 個になり（転記）、計算した向きは SPICE と 1.4e-10 rad まで一致します。昇格していません。後続対応は保留中です。
• 所有者による範囲の決定待ちで保留されているもの（それぞれ、一致した比較はコミット済み）：月面の絶対観測局の可観測性、地表ビーコンの DOP、軸外のエクスポート、クロスモダリティの検出力、同相モードの整合性統計量、極軌道 LEO のカバレッジ。
• データ待ちで保留されているもの：時刻比較の誤差配分（実データの縮約が必要）、JammerTest の C/N0（アンテナ位置と電力分割が文書化されていない）。

改訂（変動した公開済みの数値、旧 -> 新）。

• snapshot_raim の保護レベルは、動径方向ではなく測地的な局所水平面で求めるようになりました。ABMF（北緯 16 度）で、HPL は最大 0.31 m、VPL は最大 0.14 m 変わります。ゴールデンは変わっていませんが、gnss-sim チュートリアルの記録済みサマリーは、平均 HPL 22.1 m / VPL 40.0 m から 22.2 m / 39.9 m に変わります（docs/tutorials/scenarios/gnss-sim.toml）。
• 月の回転系結合の既定値：d_alpha/d_scale 3.139807e-11 -> 3.138801e-11、d_alpha/d_radial 1.807187e-17 -> 1.806185e-17（メートルあたり）。
• オフラインの既定の EOP の実行（realtime-frame-eop、セルは docs/revisions/M035-default-eop-recut-cell-changes.md に列挙）：predicted_rows 12 -> 90、極のフロア 0.06776 -> 0.05550 mas、eop_term_m 14.01601 -> 14.01583、total_m 20.09759 -> 20.09746、total_time_ns 67.03834 -> 67.03790、tests/golden/realtime-frame-eop.csv の表 2 の行、運用的な予測器の一致 0.256/0.695/1.252/3.885 ms -> 0.133/0.421/0.839/2.786 ms。
• docs/LEO-NAVMSG.md の liu22 の SISRE（軌道/クロック込み）：60 秒 0.011/0.046 -> 0.014/0.046 cm、300 秒 0.068/0.139 -> 0.074/0.142 cm、600 秒 0.269/0.299 -> 0.258/0.290 cm。
• Liu の高度の表、Kshana（比）：GRACE-A 5.40（0.61）-> 4.25（0.48）、GRACE-C 4.12（0.66）-> 2.87（0.46）、Sentinel-2A 2.95（1.03）-> 2.20（0.77）、HY-2A 2.38（1.13）-> 1.25（0.59）、Sentinel-6A 0.70（0.94）-> 0.51（0.67）。
• LEO 航法メッセージの nDot のスケール 2^-60 -> 2^-58（事前登録なし、開示済み、フィットの比較の対象外）、liu22 のサンプルフレームの CRC 0x62373A -> 0xDED99C。
• docs/LEO-NAVMSG.md の検証表：Liu と ATOMIC の行が、VALIDATED の 22 パラメーターの行と、MODELLED の ATOMIC と五高度の行に分割されました。
• DE440 の月の主軸向きの行のテキスト：期間 2024-2025 / 731 行 -> 2014-2030 / 6,209 行、「黙ってクランプ」 -> 期間外ではエラー。
• eo-coverage シナリオ：equatorial_ground_track_spacing_km 2756.37 -> 2752.17 km、新しいフィールド inclination_deg（98.19）と nodal_period_min（98.893）。
• constellation-multi-gnss-coverage（TDOP/GDOP の基準クロックは、可視の最小番号のコンステレーションになりました）：全球 GDOP の最大 2.2236 -> 2.1205、平均 1.122 -> 1.131、中央値 1.115 -> 1.125、p90 1.255 -> 1.265、p95 1.305 -> 1.315、p99 1.41 -> 1.42、およびセルごとの GDOP マップ。mean_visible_by_constellation は整数として合計されるようになりました（相対で約 1e-12、小数 4 桁では見えません）。
• 放送群遅延の修正後の GNSS 単一周波の統合測位解：3 m 以内が 93.2 % -> 93.6 %、ISB の中央値 -0.351 -> -0.114 ns。
• tracking-loop の jitter_table log10_mean_time_to_cycle_slip_s（Costas ループの SNR rho/4）：25.47 dB-Hz のしきい値で 11.58 -> 2.10、25 dB-Hz で 9.55 -> 1.60、22 dB-Hz で 2.24 -> -0.14。
• ins-trn-coast：すべての出力が、シューラー誤差モデルとともに変わります。出荷されたシナリオの TRN ピークは 52.932679 -> 44.711834 m（tests/conflict_resilience_architecture_guard.rs）。
• lunar-vlbi のレポート：新しいキー geometry_path（既定の実行では "analytic"、数値は変わりません）。新しい任意のフィールド planetary_kernel_path、earth_orientation_kernel_path、moon_orientation_kernel_path。カーネル経路では epoch_partials も付きます。種別の説明は書き直されました。検証の行のカーネル経路のオラクルは SPICE（0.06 ps）で、ANISE（0.12 ps）はカーネル評価のクロスチェックになります。
• 天体定数：Phobos の GM 7.087e5 -> 7.087546066894452e5、Deimos 9.62e4 -> 9.615569648120313e4、天王星 5.7939506103e15 -> 5.793951256527211e15、海王星 6.83509997e15 -> 6.835103145462294e15、冥王星 8.69326e11 -> 8.696138177608748e11（m^3/s^2）、Phobos の赤道半径 13.1 -> 13.0 km、Phobos と Deimos の極と本初子午線は pck00011 から取得、太陽系の prime_meridian_deg は二次項と周期項を含むようになりました。
• europa-surface-pnt（Europa 上の body-pnt）：完全な pck00011 の Europa の向き（7cfd66b4。この向きは SPICE の pxform と 1.4e-10 rad まで一致）から求め、これにより着陸機が慣性空間で動きます。可用性は、リレーのみ / 地球との距離あり 0.485 / 0.725 -> 0.480 / 0.719（171 エポック中、リレーのみは 83 -> 82）、PDOP の中央値 5.266 -> 5.360、RMS の測位誤差 129.516 / 100.983 m -> 112.742 / 86.147 m、形式シグマの中央値 5.266 / 4.272 m -> 5.360 / 4.239 m。docs/SOLAR-SYSTEM.md の表と mcp/kshana-mcp/tests/round_trip.rs のピンもこれに従います。mars-orbit-pnt は変わりません。
• space-weather（f107 180、f107a 165、kp 4）、較正係数を Jacchia 1971 に置き換え：300/400/500/600/800 km での activity_density_kg_m3 は 2.602e-11 -> 3.608e-11、4.176e-12 -> 6.929e-12、8.136e-13 -> 1.618e-12、1.769e-13 -> 4.189e-13、1.544e-14 -> 3.781e-14。activity_factor は 1.076/1.121/1.168/1.216/1.320 -> 1.492/1.860/2.322/2.881/3.232。reference_exospheric_temperature_k は削除され、mean_exospheric_temperature_k が追加されました（1186.7 K）。tests/space_weather_reference.rs：800 km での太陽周期の変動幅は 10.4 倍になり（NRLMSISE-00 では 13.6 倍）、高度の検査は、NRLMSISE の 500 km までの上昇と 800 km での下降に従います。
• ntn-5g-positioning の toa_median_sigma_3d_m：NR 5 MHz 2.0903959 -> 2.0903962 m、NB 200 kHz 25.938613 -> 25.938839 m（サマリーのテキストは 2.09 / 25.94 m のまま変わりません）。
• lunar-joint-od-clock（QR 解法）：with_vlbi.station_pos_err_m 3.541344 -> 3.541350 m、without_vlbi.station_pos_err_m 2183.119 -> 2183.558 m。
• docs/field-units-schema.json は、上記の新規および削除されたフィールドに合わせて再出力されました。

検証パッケージ#

D12、拡張精度と平方根ソルバー（新しい VALIDATED の行が二行：226 -> 228 行、確認済みが 110 -> 112）。

パート 1、拡張精度のオラクル：

• 観測局を推定する月面座標系の測地基準：50 桁の mpmath 拡張精度のオラクル（事前登録 804662d5、事前の後退誤差の式による条件数でスケールした合格基準）は、新しいキャンペーン日（2026-03-18）と元の 2024-01-01 のシナリオで一致します。P2 のもとで新しい VALIDATED の行です。これにより、以前の倍精度をめぐる論争に決着がつきます。エンジンの測地基準のシグマは最大 9.7e-6 ずれ、NumPy の逆行列と固有値の経路は最大 6.2e-6、その Cholesky と QR の経路は約 1e-8 ずれています。エンジンは誤差の限界内にありますが、因数分解の経路より精度が約千倍低くなっています。
• オラクルの環境：mpmath 1.3.0 を追加。
• 改訂：なし。ゴールデンファイルや公開済みの図は変わりません。「観測キャンペーンによる月面座標系の測地基準」の行は MODELLED のままです（創設者の判断 2026-10-02、選択肢 A：別の行の状態を借りません）。そのテストのテキストは、新しいテストとその所見を引用しています。

パート 2、平方根情報の測地基準ソルバー：

• 新しい任意選択の平方根情報ソルバー（linalg_sr、lunar-frame-campaign シナリオでは solver = "srif"）：Householder QR、三角因子を通じた周辺化、スペクトルのための Jacobi SVD、そして正しく丸められた演算のみによる補償付きの積です。50 桁のオラクル（事前登録 b41908c9）に対して、そのデータムのシグマは、新しい日付（2026-06-09）で 3e-13 まで一致します。2026-03-18 と 2024-01-01 の入力では、既定のソルバーは最大 1e-5 ずれています。P2 のもとで新しい VALIDATED の行です。既定のソルバーとその出力は変わりません。事前登録した合格基準が保証できるのは、相対で約 2e-7 を超える誤差だけです。既定のソルバーは棄却しますが、反転した Householder の符号、補償のない内積、スペクトルの最終的な逆行列は棄却できず、行にもそのように記しています。
• 変更のない既定の隣にある、任意選択の平方根の経路：fim::crlb_srif、batch_ls::gauss_newton_srif、orbit_determination::determine_orbit_batch_srif、lunar_combination::formal_covariance_srif、precise_od::fit_srif、cislunar_srif::srif_cross_validation_sqrt。新しい linalg_sr::weighted_lstsq と covariance_from_sqrt_information の上にあります。それぞれ、両方が正確な場合には既定と一致します（内部検査であり、行はなく、それらに対する検証は主張しません）。precise_od::fit は共有ルーチンに委譲するようになりましたが、その出力とすべてのシナリオの既定の出力は変わりません。
• 月面座標系キャンペーンのランク判定：40 日分に対する事前登録した拡張精度の検査は、判定できるすべての観測局ブロックと、フルランクの Helmert の判定を確認します。事前の境界では、ランク不足の 20 日分の Helmert を保証できません。厳密な演算では、その欠陥は幾何学的なもので、1e-9 のしきい値は、キャンペーンの固有値比の自然な範囲の内側にあります。行はありません。
• 拡張精度のキャンペーンの行の主張は「最悪ケースの境界内」に絞られ、観測局を固定した場合の最弱方向の検査は、実際の角度を測るようになりました（6.6e-16 rad。比較器を acos から弦に変えましたが、合格基準は変えていません）。
• 改訂：なし。ゴールデンファイルや公開済みの図は変わりません。「観測キャンペーンによる月面座標系の測地基準」の行は変わらず、MODELLED のままです（創設者の判断 2026-10-02、選択肢 A）。

D4、JPL カーネルエフェメリスの基幹、フェーズ 1（新しい VALIDATED の行が四行：228 -> 232 行、確認済みが 112 -> 116）。

• NAIF カーネルリーダーには、独自の行があります。 naif_kernel（DAF コンテナ、SPK タイプ 2、バイナリ PCK タイプ 2）は、SPICE Toolkit（spiceypy 8.2.0 経由の CSPICE N0067）および ANISE 0.10.6 と、事前登録コミット自身のハッシュ（abcd9133）から導いたランダムな格子の、DE440 の 600 状態と月の向きの回転 200 件すべてで一致し、倍精度のチェビシェフ評価から事前に導いた合格基準の範囲内です（最悪値は合格基準の 0.6 %、1.95e-3 m）。この行が主張するのは、エンジンが JPL カーネルを正しく読み取ることであり、DE440 や解析的な級数が正確であることではありません（tests/naif_reader_spice_oracle.rs）。
• ephem_provider::KernelEphemeris：DE440（または任意のタイプ 2 の SPK）の位置を、エンジン自身のリーダー経由で取得します。二分割の TDB エポックを使い、カーネルの SHA-256 をレポート用に保持し、惑星の代わりに系の重心を使うことはありません。LunisolarSource により、ジオメトリの経路は、解析的な級数（既定）とカーネルのどちらかを選べます。
• lunar-llr-datum と lunar-vlbi-fim のための、任意選択のカーネル月：planetary_kernel_path のキーにより、地心の月の中心をカーネルから読み取ります。それ以外は変わらず、レポートにはカーネルとその SHA-256 を示す moon_ephemeris ブロックが追加されます。このキーがなければ、どちらのレポートも以前とバイト単位で同一です。
• カーネル経路での月面の点の共分散（新しい VALIDATED の行）：すべての観測局を固定し、ビーコンを DE440 の月に置いた場合、ビーコンの共分散は SPICE の光行時間ヤコビアン（最悪値 1.7e-3、合格基準 1 %）および NumPy の逆行列（4e-14、基準 1e-9）と一致します。事前登録 4a51256（tests/lunar_vlbi_surface_point_spice_oracle.rs）。解析的な経路の行は MODELLED のままです。解析的な月では、最小のビーコンのシグマがオラクルより 3.9 % 低くなります。
• 実際のキャンペーンによる月面座標系の測地基準、カーネルの月の中心（新しい VALIDATED の行）：未見の 2019-Q2 のノーマルポイント 447 点で、いずれかを取得する前に事前登録した 830d945a のもと、カーネル経路での測地基準の共分散は、変更のない SPICE と NumPy のオラクルと、1 % と 2 % の合格基準に対して 7.6e-5 以内で一致します（tests/validate_llr_datum_kernel_moon_fresh.rs）。創設者は、この行を新しい点でのみ昇格させると決定しました。既に見たデータでの診断（c51f8b2）は所見であり、エビデンスではありません。この合格基準は月のモデルを区別できません。解析的な月も同じ範囲で通り（最悪値 3.8e-3）、計画した変異（カーネルの月を一時間遅らせる）は検出されず、折り返し点では、月の中心が約 4,650 km 誤っていても（月を地球と月の重心まわりに取った場合）通りました。この行が主張するのはその経路での共分散であり、月の中心ではなく、行にもそのように記しています。
• UTC エポックでの DE440 による太陽、月、水星、金星の位置（新しい VALIDATED の行）：KernelEphemeris::relative_position_utc は、1973 年から 2026 年の間の 600 個の位置で Skyfield 1.54 と一致し、最悪値は 2.96 m で、二項の TDB − TT 級数（tests/kernel_ephemeris_skyfield_oracle.rs）で決まる、事前登録した合格基準（0bfafe6d）の範囲内です。惑星の位置は、この新しいカーネルの行で扱われるようになりました。Standish の行と惑星の衛星の行は変わらず、衛星は、それを必要とするシナリオを待ちます（創設者の判断）。
• 所見：LLR の測地基準の比較で唯一外れていたもの（z 並進のシグマ 1.025 % に対して 1 %）は、既に見たデータで月の中心のみを DE440 から読み取ると 0.049 % に下がります（tests/validate_llr_datum_kernel_moon.rs）。新しい 2019 の範囲では、解析的な月も通るため、2015 の外れは、その四半期のジオメトリにとっては際どいものでした。解析的な行「実際の観測キャンペーンによる月面座標系の測地基準」と「月面の点の座標の共分散 … 地球上の観測局のものとは別に保持」は、MODELLED のままです。それらのオラクルのテキストは、カーネル経路の行を指すようになりました。
• lunar_ephemeris は、エンジンにバイナリカーネルのリーダーがないとは述べなくなり、リーダーの行を指し示すとともに、宇宙機のカーネル（タイプ 13 と 21）が引き続き Horizons を経由する理由を説明します。
• 改訂：なし。ゴールデンファイル、公開済みの図、既存のテストの値は変わりません。解析的な lunar-llr-datum、lunar-vlbi-fim、およびすべての観測局を固定した lunar-vlbi-fim のレポートは、以前とバイト単位で同一です（結果の SHA-256 の接頭辞 9927aac2、cf1d2671、25c357e4）。

D9、実測のクロックライブラリ「Clock Atlas」（新しい行が三行、うち VALIDATED が一行：232 -> 235 行、確認済みが 116 -> 117）。

• 実測のクロックライブラリ（clock_library）。デバイスカード（ホワイト位相、ホワイト、フリッカー、ランダムウォークの各周波数変調、線形の周波数ドリフト、および任意で一回転あたり一回から四回の位相項）を、名前付きの実測クロック記録にフィットさせ、保持したデータで評価します。ギャップを考慮したアラン分散とアダマール分散、すべてのギャップ、位相の外れ値、位相ステップ、バースト、周波数ステップを記録し、ファイルや日の境界を一切知らない条件付け検出器、カードからスロットタイミング雑音モデル、拡張カルマンクロックモデル、スプーフィングモニターの雑音レベルへの変換を備えます。RINEX と IGS のクロックファイル、BIPM の研究所ごとのファイル、Circular T のセクション 1（realdata::clk）のリーダーと、UTC(k) のプールした階層的なエージング境界（utck_bound、まだスコアリングされていません）もあります。
• ラグ 1 の自己相関による雑音識別（allan::lag1_noise_id、Riley と Greenhall 2004）、新しい VALIDATED の行（ライブラリ）：140 ケースで allantools 2024.6 の autocorr_noise_id と一致し、整数は同一、最悪差は 9.6e-13 で、合格基準は 1e-9 です（事前登録 2ec76864、tests/clock_library_lag1_noise_id_allantools.rs）。
• 保持したデータで予測する実測のデバイスカード、新しい MODELLED の行（所見）：三分の一でフィットし、残りの三分の二のアラン偏差を 1.5 倍以内で予測します（事前登録 2ec76864）。新しい IGS の期間（2026-03-01 から 14）の GPS Block IIF：11 機中 10 機。G27 は二時間のスケールで楽観的です（最悪の係数 1.510）。セシウム（範囲内、1.070）、OCXO（範囲外、2.348）、ストロンチウム（範囲内）は報告されたもので、ブラインドではありません。JammerTest の受信機カード、Galileo のメーザーと Deep Space Atomic Clock のカードは保留です。12 局の静止した Wroclaw 観測局（Zenodo 6488497）での ZED-F9P 受信機 TCXO のモデルクラスは満たされません。開示した修正済みの再実行では、ブラインドの 11 局中 1 局です（tests/clock_library_device_cards_oracle.rs、tests/clock_library_f9p_cards_oracle.rs）。
• 一回転あたりの項を持つ GPS Block IIF のカード、新しい MODELLED の行（所見）：二つ目の新しい期間（2026-04-01 から 14）で、11 機中 9 機が合格基準の範囲内です。G03（1.947）と G25（1.581）は、保持した記録がフィットに使った三分の一より雑音が大きいため、楽観的です。周期項を外すと、11 機すべてが満たされません（事前登録 fb475550、tests/clock_library_periodic_cards_oracle.rs）。
• M002、搭載クロックの状態推定、ラウンド 3（所見、MODELLED のまま）：固定した条件付け検出器の後、ラウンド 2 の拡張フィルターは、調整と基準を変えないまま、11 機すべてで初めて (a) と (c) を満たします。(b) は G09（0.894）と G26（0.876）で満たされません（事前登録 fb475550、tests/clock_state_ext_igs_conditioned_oracle.rs）。
• M010、スプーフィング検出、ラウンド 3 から 4b（MODELLED のまま）：ラウンド 3 は保留です（3600 に対し、JammerTest ユニットの他のセッションからの学習エポックは 167）。ZED-F9P のモデルクラスのカード（ラウンド 4 と 4b）を使うと、クロックモニターは、記録された 10 件すべての開始時点で、開始前の誤警報がゼロになり（ラウンド 2：86）、10 件中 6 件の開始時点が 10 秒以内に検出されます（ラウンド 2：4）。同じ四件は遅れたままです（tests/clock_library_tcxo_card_jammertest_oracle.rs）。
• M083、UTC(k) のオーバーバウンド、ラウンド 3：465 以降の Circular T の号に対して、前向きに事前登録（fb475550）され、まだ実行されていません（tests/utck_bound_prospective_oracle.rs）。
• オラクルの環境：Wroclaw の ZED-F9P の記録は、$KSHANA_ORACLES/data/wroclaw_f9p のもとでデータが管理されています（CC BY 4.0、約 1.5 GB）。IGS クロックのフィクスチャーは同梱されています（IGS プロダクト、出典明記）。
• 改訂：なし。ゴールデンファイル、公開済みの図、既存のテストの値は変わりません。クロックのクラスが昇格しなかったため、M001（ホールドオーバーの再アンカー）は対応しません。

D8、独立した外部の参照と照合して確認済みの一つの伝搬、フレーム、時刻の経路（新しい VALIDATED の行が三行と、昇格した M131：235 -> 238 行、確認済み 117 -> 121）。

二体、永年 J2、または恒星時のみの独自モデルを持っていた地球軌道の種別は、一つの経路を共有するようになりました。二分割のユリウス日を使う SGP4/SDP4 の軌道要素セットを、IAU（国際天文学連合）2006/2000A の変換系列を通じて GCRS と ITRS（国際地球基準座標系）に引き渡し、任意で地球姿勢パラメーターを使います。

• 新規：sgp4::MeanElementSet、sgp4::SgpOrbit、sgp4::Eop、sgp4::teme_to_itrs_matrix[_eop]、sgp4::gcrs_to_itrs_matrix[_eop]。Sgp4::new_at と Sgp4::propagate_at は二つの部分からなるエポックを受け付けます。さらに新規：jd2::Jd2::from_utc_calendar（うるう秒のある日についての SOFA dtf2d の規約）、jd2::utc_to_tai、tai_to_utc、utc_to_ut1（SOFA の utcut1 と同様に TAI を経由）、tai_to_tt、および二つの部分からなる jd2::earth_rotation_angle。
• leo-pvt の極域モードは、IAU の変換系列に基づき、2026-01-01T00:00:00 UTC の SGP4 で伝搬します（leo_fusion::polar::latitude_sweep_at は任意のエポックを受け付けます）。SGP4 Walker ジェネレーターは、IAU の変換系列を経由して地球固定座標系へ回転させます。
• passes の種別は、新しい見かけの可視パス予測器（passes::predict_passes_apparent、apparent_look_angles）を実行します。IAU の変換系列上の SGP4、ITU-R P.834-9 の屈折、ダウンリンクの光伝搬時間（新しい refraction と light_time のスイッチで、既定はオン）、地球姿勢パラメーター（ut1_minus_utc_s、xp_arcsec、yp_arcsec、既定値 0）、1e-7 秒まで解いた交差時刻、および黄金分割探索による南中を含みます。幾何学的な passes::predict_passes は変更ありません。
• tests/no_private_models.rs は、パッケージの幾何、時刻、伝搬のカーネルが、独自のケプラー伝搬、J2 の永年変化率、あるいは恒星時のみによる回転を持たないようにします。名前のある高速ティアと、ある行の主題となっている物理は、理由を付した許容例外です。
• 新しい VALIDATED の行「地球周回軌道の時刻経路における二部構成のユリウス日とうるう秒」：pyerfa 2.0.1.5 の dtf2d/utctai/taiutc を、27 回すべてのうるう秒の前後にある 224 個の時刻で 1e-6 秒以内に照合（事前登録 e947e69d）。最大誤差は 1.9e-11 秒。
• 新しい VALIDATED の行「単一の地球周回軌道経路」：232 組の要素セットの TEME 位置を python-sgp4 2.24（Vallado の参照 SGP4）と 6.1e-8 m 以内（合格基準 1 cm）で照合し、GCRS から ITRS への回転と TEME から ITRS への回転を、地球姿勢パラメーターを用いて ERFA の c2t06a、pnm06a、ee06a とそれぞれ 2.9e-6 mas と 0.41 mas 以内（合格基準は 0.1 mas と 2 mas）で照合（事前登録 72ea9eb0）。開示事項：最初の実行は 2016-12-31T23:59:59.5 で、回転が一秒分ずれて失敗しました。うるう秒のある日では UT1 を UTC の準ユリウス日から取っていたためで、エンジンは現在 TAI を経由しており、二回目の実行は変更していない合格基準のもとで一致しています。
• M131「極域および北極圏のユーザー向けの、LEO のカバレッジと精度低下率（MEO GNSS との比較）」が VALIDATED になりました。Orekit 13.1.8 がエンジンの GCRS 状態を受け取って回転させ、可視性と DOP を計算します（複数クロックのグループには NumPy を使用）。位置は 6.8e-5 m 以内（合格基準 0.2 m）、可視数は 4040/4040 サンプルで一致、DOP の中央値は相対 2.3e-11 以内です。
• 新しい VALIDATED の行「屈折と光伝搬時間を含む、見かけの地上局パス予測」：同じ要素セットを、Orekit 13.1.8 が定められた定義どおりに構築した TEME で伝搬し、ITU-R P.834 の屈折とその光伝搬時間の測定モデルを用いて、海面高度の局での 60 ケースを照合。1210 パス、交差時刻は 3.4e-6 秒以内（合格基準 5 ms）、最大仰角は 5.5e-7 度以内、見かけの方向は 8.8e-7 度以内（合格基準 1e-4 度）。
• 所見（固定して保持）：Orekit に対する最初の全項目の端から端までの比較は、位置と方向の合格基準に届きませんでしたが、原因はエンジンではありません。Orekit 13.1.8 の SDP4 が、円軌道（e = 0）の深宇宙軌道で参照 SGP4 から外れ（最大 67 m）、また既定の TEME が IERS 1996（IAU 1980）の章動に基づいていて、IAU 2006/2000A の変換系列から約 72 ミリ秒角（LEO で 2.7 m）離れているためです。Orekit の ITU-R P.834 の h*theta0^2 の係数は 0.011380 ですが、勧告には 0.01380 と印刷されています。比較は、この項が消える海面高度で行っており、それより上での差は固定して保持しています。
• 「地上局パス予測（地上セグメント）」は、主張を幾何学的な passes::predict_passes に絞ったうえで、引き続き VALIDATED です。passes の種別は新しい行に属します。
• オラクルの環境：Orekit 13.1.8、Hipparchus 4.0.3、pyerfa 2.0.1.5、python-sgp4 2.24（xval/d8-orekit13/setup.sh）。
• 改訂：同梱の scenarios/passes.toml の総アクセス時間は 1675 秒から 1659 秒へ（パス数は従来どおり五、最大仰角の最良値は 73.25 度から 70.08 度へ）。また、すべての passes の出力が新しい経路に合わせて変わります（docs/examples/multi-tool-pipeline.md に印刷された行と docs/CAPABILITY.md の passes の項目も、その旨に更新）。同梱の polar-arctic-leo-coverage の GNSS VDOP は、赤道で 1.19669 から 1.19710 へ、89.9 度で 1.50645 から 1.50590 へ、融合 VDOP は 89.9 度で 1.14388 から 1.14250 へ（公表している小数第二位までの値 1.20、1.51、1.14 は変わりません）。ゴールデンファイルの変更はありません。
• まだ経由させていないもの：leo_pass、ドップラー、ジョイント、タイミングの leo-pvt モード、および leo_navmsg の真値軌道（そのモデルは leo_link::geometry と leo_fusion::geom にあります）、ならびに constellation-design の地球向け設計（名前付きの二体問題の高速ティア）。

D6、LunaNet AFS 参照ジェネレーター、LSIS V1.0（新しい行四件、うち VALIDATED は二件：238 行から 242 行へ、確認済みは 121 行から 123 行へ）。

• LunaNet Augmented Forward Signal（AFS）参照ジェネレーター（lunar_afs）。2025年1月29日付の LunaNet Signal-In-Space Recommended Standard（LSIS）V1.0 に固定し、すべての出力にそのバージョンを明記します。内容は次のとおりです：2492.028 MHz の搬送波、毎秒 500 シンボルで 2046 チップのゴールド符号を持つ AFS-I BPSK(1) データチャネル、10230 チップのワイル系列の一次符号、4 チップの二次符号、1500 チップの三次符号を持つ AFS-Q BPSK(5) パイロット、フレーム識別子 0 のフレーム（同期パターン、BCH (51, 8) のサブフレーム 1、CRC-24、符号化率二分の一の LDPC サブフレーム 2 から 4、60 行 98 列のブロックインターリーバー）、全探索によるサブフレーム 1 のデコーダーとパリティ検査行列のみから書いた min-sum LDPC デコーダー、そして真値ラベル付きのベースバンド IQ 合成（SigMF 記録として出力）。符号は、規格のシフトレジスターおよびルジャンドル／ワイル構成から生成します。規格から複製したものは再配布しません（規格には再利用条件がありません）。AFS-Q の一次符号のインデックスは IS-GPS-800J に由来し、規格の添付資料だけが定義するもの（AFS-I の G2 遅延、三次符号、LDPC の部分行列）は、xval/lunar-afs/fetch_lsis.sh が NASA ホストの PDF から取得してローカルキャッシュに保存したものを実行時に読み込み、すべてのファイルを固定した SHA-256（lunar_afs::lsis）で検査します。このモデルは適合性の参照であり、チャネル、伝搬、リンクバジェットのモデルではありません。
• sigmf::meta_to_json_with_extensions と sigmf::annotation_extension_fields：記録は、core:extensions で宣言した名前空間付きの拡張フィールドを持つことができます。
• 新しい VALIDATED の行「チャネル状態を与えた、独立したジェネレーターに対する LunaNet AFS ベースバンドのレンダリング」：LANS-AFS-SIM（BSD-2-Clause、コミット 480c6bf3、S バンドビルド）に対して、PRN 1 から 210 の符号でチップの不一致はゼロ、実行に含まれる三フレームでシンボルの不一致はゼロ、そのシミュレーター自身のサンプル 23.9 秒にわたる正規化複素相関は 0.999990（最悪の 2 ms ブロックで 0.999948）で、比較の前に固定した合格基準の範囲内です（事前登録 986ac280）。シミュレーター自身のチャネル状態でレンダラーを駆動しており、搬送波対雑音密度からの電力配分、および SigMF と 8 ビットの書き出しは対象外です。
• 新しい VALIDATED の行「LunaNet AFS のフレームのチャネル符号化、FID 0」：6000 シンボルのフレームは LANS-AFS-SIM のものとシンボル単位で一致します（事前登録 986ac280）。サブフレーム 1 の符号は LSIS の図 8 の計算例を再現し、CRC-24 は CRC-24/LTE-A のカタログのチェック値を再現します。
• 昇格した二つの行はどちらも、LSIS のキャッシュにデータが依存しています。xval/lunar-afs/fetch_lsis.sh を実行するまで、そのオラクルテストは通知を出してスキップされます。
• 所見（新しい MODELLED の行）「LunaNet AFS 拡散符号の生成」：生成した 2,937,232 個のチップとビットを規格の表および附属書 3 のファイルと比較したところ、一か所が異なります。三次符号 PRN 147 について表 E-5 が印刷している「最後の 24 チップ」で、これは PRN 151 のセルと重複しており、規格自身の附属書 3 のファイルはジェネレーターと一致しています。不一致ゼロの基準には届きませんでした。
• 所見（新しい MODELLED の行）「LunaNet AFS の閉ループでの復号可能性」：PocketSDR-AFS に対する事前登録済みの三回の実行。三回目は追跡と復号の合格基準を完全に満たしましたが、出力のみを加えた受信機ビルドが固定ビルドのログを再現するという保護条件は満たしませんでした。変更していない受信機の二回の実行でさえ、捕捉記録が異なるためです。
• 修正：lunar_service（export_antenna.carrier_hz）、lunar_jamming、attack_surface の既定の搬送波は丸めた 2.4 GHz でしたが、現在は LSIS-020 の AFS 搬送波 2492.028 MHz です。従来の既定では、自由空間損失が 0.327 dB 過小評価されていました。
• 改訂：なし。同梱のすべてのシナリオが搬送波を明記しており、138 個のシナリオファイルすべての結果は、以前の main とバイト単位で一致します。

D7、実際の月面 IQ と GPS LNAV（新しい行七件、VALIDATED はなし：242 行から 249 行へ、確認済みは 123 行のまま）。

• portable_math::FftPlan：混合基数の高速フーリエ変換（FFT）で、出力はどのプラットフォームでも同じビット列になります。8000 点と 24000 点の変換の SHA-256 固定値は、x86_64 と wasm32-wasip1 の両方で一致します（ランナーは xval/portable-fft-wasm/）。

• acquisition：サンプリングした IQ に対する並列コード位相探索（pcps_acquire、pcps_grid）で、コヒーレント折り畳み、非コヒーレント累積、探索全体の誤警報確率に対するカイ二乗しきい値、帯域制限雑音向けのセル平均統計を備えます。さらに refine、コードドップラーを含む prompt_series、および M2M4 とグリッドピークによる搬送波対雑音密度（C/N0）推定器も備えます。

• gps_lnav：サブフレーム 1 から 3 を対象とした IS-GPS-200 のレガシー航法メッセージ（LNAV）エンコーダーで、表 20-XIV のパリティとフィールドデコーダーを備えます。

• realdata::ion_sdr：ION GNSS SDR Metadata Standard（.sdrx）とそのサンプルファイルのリーダーで、二の補数のレベル向けに to_mid_rise を備えます。

• realdata::lugre：LuGRE（Lunar GNSS Receiver Experiment）の IQS バッチヘッダー、RAW、ACQ、NAV のテレメトリーおよび CLK ファイル、そして .sdrx のメタデータがバイナリヘッダーと矛盾する箇所を一覧にする検査。

• antenna::GainPattern2D、および earth_gnss_lunar における、ヨーステアリングの機体座標系、送信方位角とオフナディア角、そして測定パターンを用いた相対 C/N0 のための transmit_side_db。

• GPS LNAV 航法メッセージの符号化（新しい行。統合担当者による検証後も MODELLED のまま）：RTKLIB v2.4.2-p13 が解析・復号した 2025年3月2日の IGS 放送ファイルで、960 ワードすべてがパリティを通過し、96 サブフレームすべてが復号でき、608 個の放送整数すべてが Kshana のものと一致します（tests/gps_lnav_rtklib_integer_oracle.rs）。しかし、事前登録（d4d9eb9d）は、結果を含むコミットの二秒後に公開ブランチへ到達しており、「ファイルを取得する前に登録した」という順序を示すことができないため、この行は昇格させていません。

• realdata::ion_sdr は、ワードを最上位ビットから埋めます（LuGRE のバイトでは I が上位ニブル。以前の読み方では共役信号になっていました）。従来の読み方は SdrLayout::fill_lsb_first として残し、ワードより幅の広いサンプルも読み取れるようにしました。

• acquisition::refine_doppler_coherent：位相コヒーレントなドップラー精密化（シミュレーションで 30 dB-Hz、200 ms にわたり 0.2 Hz RMS）。

• gps-sdr-sim に対する GPS L1 C/A：チップとパリティビットはビット単位で一致。1152 個の LNAV フィールドのうち 230 個が一単位ずれています。gps-sdr-sim は、放送整数では丸めが必要なところを切り捨てるためです。

• RTKLIB で復号した LNAV：パリティとサブフレームはすべて通過し、すべてのパラメーターは量子化幅の半分以内です。41 個のスケール値は、RTKLIB の十進表記の 2^-43 定数により最終桁で数単位ずれ、登録した合格基準を超えています。

• GNSS-SDR 0.0.19 に対する LuGRE の捕捉：266 件中 266 件の判定が一致し、250 件が同じセルで検出されました。陽性の大半は、素の 4 ビットレベルにある −0.5 の平均値によるアーティファクトです。C/N0 の部分には同時期の飛行データがありませんでした。二つのバッチ（OP5、OP12）は誤って除外されました。メタデータはヘッダーと一致していますが、その時点ではリーダーがワードより幅の広いサンプルを読み取れなかったためです。

• 軌道予測したドップラーに対する LuGRE の捕捉：サンプル電力による判定では、すべての探索が帯域制限雑音の上で交差します。セル平均による判定では、最も強い組が大きさでは一致しつつ符号が逆になり、登録した I/Q の順序がデータの共役であることを示しています。

• 月面バッチでのブラインド捕捉：四つのバッチがそれぞれ一機の衛星を捕捉し（可視と予測され、1e-7 で誤警報なし）、二機を捕捉したバッチはないため、ドップラー差の合格基準は採点する組がありません。

• 月距離での相対 C/N0（M039 の再表明）：Block IIR/IIR-M のレコード 15 件と組が一つで、登録した合格基準には少なすぎます。

• 改訂：なし。公表した数値、ゴールデンファイル、ドキュメントの数値は変更していません。

• M039 の行「月距離での地球 GNSS」は、その主張を、ある時刻における衛星間の相対 C/N0 と可視性として月距離で再表明します（絶対 C/N0 は主張していません）。この行は MODELLED のままです。トップレベルの NOTICE には、LuGRE の CC BY 4.0 の帰属表示を記載しています。

修正#

• DE440 の月の主軸の姿勢は、日ごとのノード間を測地線に沿って補間するようになりました。従来の要素ごとの補間では、各日の四分の一点付近で最大 2.0e-4 rad（月面で 340 m）の誤差があり、行に記載していた「約 14 m」ではありませんでした。これを使うもの（月レーザー測距の幾何、月のデータム、月の断層の可観測性）は、修正後の姿勢を受け取ります。
• ラウンド 2 のエンジン修正。それぞれ、変更していない事前登録済みの許容差に対して再実行しました。EOP の行の IERS 版は、空白の Bulletin B ブロックではなく I/P フラグから読み取る。snapshot_raim は測地学的な局所水平を使う。月の回転速度フレームの結合は、赤道半径、J2、自転を使う。liu22 のフィットは、事前情報なしで補正量ゼロから始まり、論文の平均運動の変化率を使う。EO のノード間隔は J2 による昇交点の移動を含む。Costas のサイクルスリップ時間は rho/4 を使う。ジョイント解は、その組の放送群遅延を適用する。月のジョイント解は QR ステップを使う。NTN の限界は真の位置で評価する。コンステレーション設計のクロック基準は、視界内で最も低いコンステレーションとする。DE440 の姿勢系列は 2014-2030 にわたり、範囲外では打ち切らずにエラーとする。

追加#

• leo_navmsg::truth::TruthOrbit::from_ecef_states：表にした地球固定座標系の状態から構築した真値軌道で、実軌道のフィッター比較に使います。
• 上記の比較のテストファイルとフィクスチャー。それぞれにジェネレーターと、出典、ライセンス、取得日、SHA-256 を記した NOTICE.md が付きます。
• ラウンド 2：araim_reference::add_v42_protection_levels と _ecef（ADD v4.2 の故障検出。ARAIM 2 向けの Stanford MAAST に従い、ソースに BSD-3 の通知を記載）、raim::snapshot_raim_fde、cw_dynamics::second_order_correction と propagate_second_order、九状態の INS 誤差モデル inertial::coast::ErrorDynamics、lunar_vlbi::KernelGeometry の偏微分とカーネル経路の lunar-vlbi の入力、naif_kernel（SPK タイプ 2 とバイナリ PCK カーネルのリーダー）、ITRF2020 の局を伴う lunar_llr_geometry::llr_bcrs_one_way_m、Jacchia 1971 の密度、任意のエフェメリス提供元に対する solar_system::link_on、launch::site_rotation_speed_at、eo_payload::j2_nodal_period と ground_track_spacing_equator_j2、batch_ls::gauss_newton_qr、precise_products（RINEX クロック、ANTEX、DCB のリーダー）。

[0.29.3] - 2026-10-01#

0.29.2 に対するパッチリリースです。Kshana Studio は二つのビューを中心に作り直しました。先に答えを示し、平易な言葉で説明するシンプルビューと、フルダッシュボードを備えた詳細ビューです。kshana.dev の小さな修正が二件付きます。エンジンは変わりません。バージョン表示を除き、同梱のすべてのシナリオが 0.29.2 とバイト単位で同一の結果を出します。

変更#

• Kshana Studio にシンプルビューができました。Studio を開くと最初に表示されるのがこのビューです。
  • 答えが先に来ます。シナリオは結果の画面で開き、結果は平易な一文で示されます。同梱のすべてのシナリオに、そのシナリオが測定するものに合わせて書いた専用の文があります。
  • 表示される設定は多くても五つで、答えを最も大きく左右するものです。残りは「詳細設定」の中に折りたたまれており、開くまで表示されません。
  • 「計算方法」では手法を数行で説明し、「研究者向け」ではエンジン自身の数値、シナリオファイル、結果の裏付けとなるエビデンスを示します。
• フルダッシュボードは詳細ビューです。以前の Studio のすべてのパネル、グラフ、エクスポート、レポートがそこにあります。
• 切り替えスイッチで二つのビューを行き来でき、現在地は保たれます。シナリオ、表示していたビュー、編集した設定は引き継がれます。Studio は最後に使ったビューを記憶します。サイトやドキュメントからのリンクはシンプルビューで開きます。view=advanced を付けたリンクは詳細ビューで開き、以前の Studio のリンクも、これまでどおり同じシナリオとビューで開きます。
• 低速な接続でも最初の表示が速くなりました。シナリオの記録済みの答えは Studio の残りを読み込む前に描画されるため、低速なモバイル接続でも、答えが約九秒ではなく約二秒で表示されます。
• 検索が改善されました。検索では、領域またはタイトルが語に一致するシナリオが先に並び、ファイル名や本文にしか語が出てこないシナリオはその後になります。

修正#

• 視覚効果の軽減をオンにしても、ホームページの地球儀が空白にならなくなりました。システムの視覚効果の軽減の設定がオンのとき、ウィンドウのサイズを変えると、ページをスクロールするまでヒーローの地球儀が空になることがありました。地球儀はサイズ変更と同じフレームで再描画されるようになりました。
• ホームページの L バンドコンソールが、空の帯域について説明するようになりました。「ジャマーが帯域を奪う様子を見る」で、GPS L5 / Galileo E5a のパネルが一分間ずっと暗いままで、故障のように見えていました。このシナリオではその帯域で送信するジャマーはなく、衛星信号は雑音フロアより下にあるため、そこには雑音フロアを上回るものがありません。フロアを上回るものがないパネルの区間（L5 / E5a のパネルと、雑音ジャマーが始まる前の L2C のパネル）には、控えめなラベルでその旨を表示し、各帯域の C/N0 とロック状態を同じ実行から併記します。ラベルはフロアを上回るものがない場所にだけ置くため、ジャマーのエネルギーを覆うことはありません。

0.29.2 - 2026-10-01#

0.29.1 に対するパッチリリースです。LEO の航法メッセージ、融合、スペクトルの各モジュールで重複していたコードを削除し、kshana.dev にライトテーマを追加し、Kshana Studio を独自のアドレスに移し、サイトを検索エンジンと AI アシスタントが読めるようにし、Studio の小さな不具合をいくつか修正し、保存したトークンなしで npm リリースを公開できるようにします。エンジンの出力は変わりません。バージョン表示を除き、同梱のすべてのシナリオが 0.29.1 とバイト単位で同一の結果を出します。

追加#

• kshana.dev にライトテーマが加わりました。すべてのページをライトでもダークでも読めます。サイトは閲覧者のシステム設定に従い、切り替えスイッチも備えています。
• 検索エンジンと AI アシスタントがサイトを読めるようになりました。各ページに、固有のタイトル、説明、正規アドレス、ソーシャルカードのタグ、schema.org の構造化データが付き、スクリプトが描画するセクションにはプレーンテキストも付きます。サイトは robots.txt、各ページの最終更新日を載せた sitemap.xml、llms.txt と llms-full.txt（AI アシスタント向けの短いプレーンテキストガイドと完全版）、そしてデプロイ時に何が変わったかを検索エンジンに知らせるための IndexNow キーを公開します。
• npm リリースを、保存したトークンなしで公開できます。npm のジョブは Node 24 と npm 11.5.1 以降で動作するようになり、npm の信頼できる公開（trusted publishing）に対応します。npm は、リリースジョブの GitHub ID を短期間有効な認証情報と交換します。NPM_TOKEN シークレットは引き続き使え、設定されている間は使用されるため、npmjs.com でそのパッケージの信頼できる公開を有効にするまでは何も変わりません。手順は docs/RELEASING.md に記載しています。

変更#

• ホームページの見出しが、地球儀の上でも読みやすくなりました。見出しとその文字の後ろに柔らかな陰影を置き、アニメーションする地球儀の軌道線と衛星の点が見出しと交差する部分を薄くしています。

• Kshana Studio に独自のアドレスができました：https://kshana.dev/studio/。サイトとドキュメントのすべてのリンクがそこを指します。旧アドレスの /playground/ も引き続き使え、リンクに含まれるシナリオ、ビュー、その他の設定を保ったまま新しいアドレスに転送されます。

• Studio の修正。エンジンファイルのダウンロードは二回ではなく一回になりました。ダウンロード中は、空の画面の代わりに、シナリオの記録済みの結果を「記録済み」と表示してすぐに示します。スマートフォンでは、ヘッダーがコンパクトな一行になります。主要な数値は一行に二つずつ折り返されるため、画面の端に隠れるものはありません。フィールドのラベルはシナリオ自身の言葉を使い、その横にフィールド名を添えます。検索はどちらでもフィールドを見つけられます。

• 重複コードを減らしました。LEO の航法メッセージの単位表は、四つのフィット要約のために同じ十行の SISRE 統計を書いていました。現在はマクロが一回で書きます。二つのスペクトルウォーターフォールのグラフは、時間軸、カラーバー、C/N0 バーのパネルを共有します。メイングリッドのダウンサンプリングは downsample_grid を再利用し、シンプソン積分は navsignal::simpson を再利用します。LEO パス種別の二つのエントリーポイントは、一つの初期設定ステップを共有します。leo_link::geometry は、leo_fusion::geom のベクトルヘルパーをコピーせずにインポートします。詳細レポートは、API レポートの HTML エスケープをコピーせずにインポートします。scenarios/ にある 139 個のシナリオファイルすべてを 0.29.1 とこのコードで実行し、すべての出力ファイルがバイト単位で同一であることを確認しました。

• leo-navmsg と leo-pvt の単位表が、それぞれ専用のファイルになりました。ロジックも含むモジュールから、src/leo_navmsg/units.rs と src/leo_fusion/pvt_units.rs に移しました。PVT_UNITS は公開パスを維持します。宣言的なカタログに対するコピー＆ペースト検出の適用除外には、この二つの表ファイルだけが sonar-project.properties に加わり、tests/sonar_cpd_exclusions_are_justified.rs がそれを検査します。

修正#

• README の CI バッジが、main への push の結果を示すようになりました。このバッジは main 上のすべてのイベントの実行を数えていたため、push の実行がすべて成功していても「failing」と表示されることがありました。現在は push の実行だけを対象にします（event=push）。

0.29.1 - 2026-10-01#

0.29.0 に対するパッチリリースです。測定したカバレッジの数値、kshana.dev のプロジェクト名の行、より速いカバレッジジョブ、刷新した README を含みます。エンジンの出力は変わりません。すべてのシナリオが 0.29.0 と同じ結果を出します。

公表した数値の改訂#

• ラインカバレッジ：約 96 % → 約 95 %。カバレッジジョブが、リリース済みの 0.29.0 のコード（コミット db796dd、CI 実行 36809850252、2026-10-01）を再測定しました。結果は 95.35 %、src/ の 58,697 行中 55,970 行です。公表していた数値は 95.63 %（39,419 行中 37,697 行）で、0.28.0 より前の b1d350d で測定したもので、約 96 % に丸めていました。新しい数値は約 95 % に丸められるため、tests/coverage_figure_doc_sync.rs が固定しているすべての箇所が一斉に変わります。docs/COVERAGE.md、README のバッジ、Evidence の行と CI の表、crates.io、PyPI、npm のバッジ、テクニカルレポート、kshana.dev のカバレッジのページです。下限の 85 % は変わりません。

追加#

• kshana.dev のプロジェクト名の行。「Kshana · क्षण · the precise instant」が、ホームのヒーローの冒頭に表示され、すべてのページのフッターのブランドの下にも置かれるようになりました。kshana.dev は引き続き他のホストへのリクエストを一切行いません。デーヴァナーガリー文字は、क्षण の三文字を収めた、セルフホストの Noto Sans Devanagari のサブセットです（1,692 バイト、web/fonts/。SIL Open Font License の本文とその SHA-256 は web/fonts/FONTS.json にあります）。web/tools/fetch_third_party.py は、Google Fonts の text= のサブセットを、内容に基づくファイル名で保存できるようになりました。

変更#

• サイトのリンクは、整ったアドレスで、指し示す場所に正しく到達します。セクションへのリンクは、スマートフォンでもデスクトップでも、そのセクションをヘッダーの直下に表示するようになりました。ミッションの分野へのリンクは、その分野をパネルが最上部に来る状態で開きます。機能とエディションのリンクは、上にあるグラフが描画されている間も位置を保ちます。エディションは二重のヘッダーオフセットを加えなくなりました。ドキュメントページの折りたたまれた部分へのリンクは、その部分を開きます。すべてのページは整ったアドレス（/evidence#research、/docs/changelog、ホームは /）でリンクされ、正規リンク、サイトマップ、旧アドレスからのリダイレクトも同じアドレスを指します。.html のアドレスも引き続き使えます。研究は、ヘッダーのエビデンスと開発者の間、およびフッターに、独自のリンクを持つようになりました。ドキュメントはロードマップを表示しなくなりました（ROADMAP.md はリポジトリに残ります）。プロジェクトのグループは、変更履歴、ライセンス、セキュリティ、コントリビューション、ガバナンス、行動規範で、用語集は「はじめに」に移りました。
• カバレッジジョブが速くなりました。0.29.0 では 143 分かかり、健全な 91 から
  94. tests/property.rs のファザーが、前回の原因で、そのうち 4 を占めていました。同梱のコーパスは 74 個から 139 個のシナリオに増え、三つのテストバイナリがそのすべてを一ファイルずつ順に処理していました（determinism が二回、advanced_report と animation が一回ずつ）。カバレッジの計測を有効にした状態で合わせて 37 分となり、0.27.2 の 3 分と比べて大きくなっていました。現在は tests/support/corpus.rs を共有しており、シナリオごとの処理をすべてのコアで実行し、結果を並べ替えた順序で返します。すべてのシナリオとすべてのアサーションは維持されています。arm64 のノート PC のデバッグビルドでは、determinism は 14 コアで 143 秒かかり、KSHANA_CORPUS_THREADS=1（従来の逐次処理）では 612 秒でした。
• README を刷新しました。サイトと同じプロジェクト名の行で始まります。Studio のスクリーンショットは 0.29.1 の Studio で撮り直し、スマートフォン上の Studio と画面下部のステップバーを写した新しい一枚を加えました。新しい「サイト」の帯には、0.29.1 ビルドの kshana.dev の三つのページを表示します（tools/capture_site_shots.mjs、tools/readme_shots.py で合成し、docs/assets/readme/site/SHOTS.json に記録）。カバレッジの数値は約 95 % となり、アーキテクチャ図のものを繰り返していた研究図の代替テキストは、論文を説明する内容になりました。ヘッダーのバッジは小さく短くなり（高さ 18 px。「~95%」、「83/223」、「quality」、「AGPL-3.0」、「zenodo.20528627」）、十一個が二行に収まります。すべてのリンクと代替テキストは、意味を完全に保っています。
• コンテナイメージのジョブに 90 分を与えました。v0.29.0 では、kshana-mcp イメージのエミュレートされた linux/arm64 ビルドが、最後のクレートをコンパイルしている途中で従来の45分の制限に達し、イメージ、MCP レジストリのエントリー、チャンネルの確認が公開されませんでした。制限は 90 分になりました。イメージは変わりません。
• 八個の浮動小数点リテラルを再グループ化しました。対象は src/ephem.rs と src/sgp4.rs です（0.323_273_64 → 0.323_273_640）。SonarQube Cloud が、最後のグループの _64 または _32 を、f64 または f32 の接尾辞の欠落と解釈したためです（ルール S7454）。値は同じ数なので、すべての結果は変わりません。

0.29.0 - 2026-10-01#

新しいシナリオ種別が十二、実行を読み取る新しい方法が三つ加わりました。エンジンは、電波スペクトル、太陽系全体、任意の天体の周りのコンステレーション、シナリオを連鎖させて一つのミッションにするキャンペーン、そして低軌道（LEO）からの測位・航法・時刻（PNT）を、信号から測位解までカバーするようになりました。どの実行も、アニメーション、完全なレポート、他のツール向けの相互運用ファイル一式として書き出せます。

エンジン周辺の変更：再設計した kshana.dev（複数ページのサイトと、すべての機能をブラウザー内で実行する新しい Kshana Studio ダッシュボード）、書き直した README、Model Context Protocol（MCP）サーバーの十四個のツール、ネイティブ版と同じ数値を出すブラウザービルド、そして Kshana Pro の公開ページ。

増加の内訳：

LEO の機能は特定のシステムに依存しません。名前のあるシステムを必要とせず、一般的で明示したパラメーターで動作します。名前のあるシステムは任意のプリセットで、それぞれ公開されている出典とともに独自のファイルに置かれます。あるプリセット、Celeste IOD（in-orbit demonstration、軌道上実証）は、2026 年の ESA NAVISP LEO-PNT ワークショップで提示された数値を使います（ESA は欧州宇宙機関、NAVISP はその Navigation Innovation and Support Programme）。これは src/celeste_iod.rs という一つのファイルに、リポジトリ限定の五件のシナリオとともに置かれているため、ソースを編集せずに非公開にでき、そのワークショップの数値は、この変更履歴には一切繰り返していません。

アップグレードの前に「公表した数値の改訂」をお読みください。エンジンの出力が一つ変わります（ephemeris 種別の慣性系の列。章動行列の符号を修正したため）。また、ドキュメントの監査により、以前のドキュメントに印刷されていた数値を訂正しました。

この項目で使用する略語

ステータス：VALIDATED は、独立した外部のオラクル（公表された表、他のグループのソフトウェア、または測定データ）と照合して確認したことを意味します。MODELLED は、明示したモデルを内部整合性のみで検査したことを意味します。PARTNER は、その確認にパートナーのハードウェアまたはデータが必要であることを意味します。

略語	意味
3GPP, 5G, NTN	第三世代パートナーシッププロジェクト（3rd Generation Partnership Project）、第五世代移動通信ネットワーク、非地上系ネットワーク
AD, BC	暦の紀元（西暦、紀元前）
AIAA	American Institute of Aeronautics and Astronautics（米国航空宇宙学会）
AltBOC, BOC, BPSK, MBOC	代替バイナリオフセットキャリア、バイナリオフセットキャリア、バイナリ位相偏移変調、多重化バイナリオフセットキャリア（信号の変調方式）
ATOMIC	Autonomous Time and Orbit Determination for Microsatellite Constellations（公表されている LEO のエフェメリスモデル）
C/A, L1, L2, L2C, L5	粗捕捉符号（coarse/acquisition code）、および Global Positioning System の搬送波と民生信号の名称
C/N0	搬送波対雑音密度比
CIO	天球中間基準点（Celestial Intermediate Origin）
CLI	コマンドラインインターフェース
CRC-24Q	24 ビットの巡回冗長検査（Qualcomm 多項式）
CSAC	チップスケール原子時計
CSS, HTML, SVG, XML	Cascading Style Sheets、HyperText Markup Language、Scalable Vector Graphics、Extensible Markup Language
CSV, JSON, PDF, TOML, URL	コンマ区切り値、JavaScript Object Notation、Portable Document Format、Tom's Obvious Minimal Language、URL（uniform resource locator）
CW	連続波
CZML, KML, GeoJSON	Cesium Language、Keyhole Markup Language、Geographic JSON（地図と地球儀のフォーマット）
DE441	ジェット推進研究所の Development Ephemeris 441
DOI	デジタルオブジェクト識別子
DOP, GDOP, PDOP, HDOP, VDOP	精度低下率：幾何、位置、水平、垂直
E1, E5, E5a, E5b	Galileo の信号名
E3F	Global Positioning System のコンステレーション表にあるスロット名
ECEF	地球中心・地球固定
EE	分点方程式
EGM2008	Earth Gravitational Model 2008
EIRP	等価等方放射電力
ERFA、SOFA	Essential Routines for Fundamental Astronomy、Standards of Fundamental Astronomy（基礎天文学の参照ライブラリー）
ESA, NAVISP	欧州宇宙機関、その Navigation Innovation and Support Programme
FDMA	周波数分割多元接続
GCRF, GCRS	地心天球基準座標系（Geocentric Celestial Reference Frame）、地心天球基準系（Geocentric Celestial Reference System）
GLONASS	ロシアの全球測位衛星システム
GNSS, GPS	全球測位衛星システム、Global Positioning System
IAU	国際天文学連合
ICD, OS SIS ICD, OS SDD	インターフェース管理文書、Galileo Open Service Signal-In-Space Interface Control Document、Galileo Open Service Service Definition Document
ICRF	国際天球基準座標系
IMO	国際海事機関
INS, MEMS	慣性航法システム、微小電気機械システム
IOD	軌道上実証
IQ	同相成分と直交成分
IS-GPS-200	Global Positioning System のインターフェース仕様
ISS	国際宇宙ステーション
ITRF, ITRS, PEF, TEME	国際地球基準座標系、国際地球基準系、擬似地球固定、真赤道・平均春分点（座標系）
ITU, ITU-R	国際電気通信連合、その無線通信部門
J/S	ジャマー対信号比
J2〜J6, J2000	重力場の帯状調和項、2000-01-01 12:00 のエポック
JPL	ジェット推進研究所
LEO, MEO	低軌道、中軌道
MBSE	モデルベースシステムズエンジニアリング
NEES	正規化推定誤差二乗
NeQuick-G	Galileo の電離圏モデル
OEM, SP3, TLE	Orbit Ephemeris Message、Standard Product 3（精密軌道）、二行軌道要素
PNT, PPP	測位・航法・時刻、精密単独測位
PSD, SSC	パワースペクトル密度、スペクトル分離係数
RAIM, SQM	受信機自律インテグリティ監視、信号品質監視
RINEX, RTCM	Receiver Independent Exchange Format、Radio Technical Commission for Maritime Services
RMS	二乗平均平方根
RTKLIB	オープンソースの GNSS 測位ライブラリーで、ここではオラクルとして使用
SGP4	Simplified General Perturbations 4（二行軌道要素の軌道モデル）
SHA-256	Secure Hash Algorithm、256 ビット
SigMF	Signal Metadata Format
SISRE	信号空間の距離誤差
SPS PS	Standard Positioning Service Performance Standard
SRTM	Shuttle Radar Topography Mission
STK	Systems Tool Kit（その .e エフェメリスファイル形式）
STL	Satellite Time and Location
SVID	衛星識別子
T/P/F	Walker コンステレーションの総衛星数、軌道面数、位相
TEC	全電子数
UHF	極超短波
UTC	協定世界時
WGS 84	World Geodetic System 1984
X1, X5	Xona Pulsar システムの信号名

公表した数値の改訂#

公表した数値を変更した場合は改訂であり、記録します。黙って訂正することはしません。このリリースには、エンジン出力の改訂が一つと、ドキュメントに印刷されていた数値の改訂がいくつか含まれます。

エンジンの出力

• TEME→GCRS の変換が 2·Δψ だけ回っていました。章動行列で Δψ の符号が逆になっていたためです。 nutation::numat は、SOFA の iauNumat が Rx(−(ε̄+Δε))·Rz(−Δψ)·Rx(ε̄) を構築するところで Rx(−(ε̄+Δε))·Rz(Δψ)·Rx(ε̄) を構築していたため、nutation_matrix、nutation_matrix_2000a、teme_to_gcrs、gcrs_to_teme は、黄経章動の二倍、約 25 秒角だけ回転していました。この変換系列に対する検査はすべて性質テスト（正則な回転であること、往復で元に戻ること、章動の寄与が非ゼロであること）で、符号の取り違えがあっても通過します。端から端までの Vallado テストは TEME→PEF、TEME→ITRF、GCRS→ITRS を対象としていましたが、TEME→GCRS は対象外でした。Vallado の例（AIAA 2006-6753、2004-04-06）では、この変換系列は公表されている GCRF から 1,145 m ずれていましたが、現在は 0.11 m の位置に収まり、行列は ERFA の numat と 1e-14 まで一致します。tests/frame_reference_vectors.rs::teme_to_gcrs_matches_vallado_gcrf と nutation::tests::nutation_matrix_matches_erfa_numat はどちらも、旧い符号では失敗します。src/cio.rs の CIO（Celestial Intermediate Origin）整合性テストは、その結果生じていた約 130 m の不一致を「≈ 2·EE」によるものとしていましたが、残差は現在 5 cm となり、その上限は 250 m から 1 m に引き締めました。これは公表した数値を動かすため、改訂としてここに記録します。ephemeris 種別の gcrs_r_m と gcrs_v_m_s の列（同梱の ISS（International Space Station）シナリオで約 0.8〜1.0 km。その TEME、地球固定、地上軌跡、見通し角、ドップラーの列は変わりません）、および GCRS と ITRS の座標系に対する Propagator::position_in_frame / state_gcrs です。同梱のシナリオの要約行、グラフ、ゴールデンハッシュは、これらの列を読み取っていません。新しい相互運用エクスポートは、修正後の変換系列を使います。最初の orbit-sgp4-gps 衛星の CZML の位置は、同じ TLE を ERFA で変換したもの（sgp4 Python パッケージで伝搬）と 2.3 cm 以内で一致します。
• leo-navmsg 種別を、ネイティブとブラウザービルドの両方で修正しました。この種別は、すべての超越関数を一つのポータブルな数学ライブラリー経由で計算するようになり、そのフレームはすべてのプラットフォームとすべてのビルドで同じバイト列になります（「修正」の項）。すべての leo-navmsg の数値がこれに伴って変わり、leo-pnt-chain の navmsg ステージも変わります。この種別はこのリリースで新しいため、以前のリリースの数値は動きませんが、修正前に印刷されていた数値は変わります。docs/LEO-NAVMSG.md の、エンコードとデコードのシナリオのチェック値は 0x110315 でしたが 0x19105F になり、デコードしたメッセージの SISRE は 0.129 cm です。kshana.dev では、leo-navmsg-fit-interval-trade のミッションカードが、60 秒のフィットで最悪の距離誤差 1.6 mm、900 秒のフィットで 40.3 mm と表示していましたが、サイトはこのリリースのエンジンから構築し直され、1.8 mm と 46.6 mm を表示します。
• kshana.dev（ミッション）のジャミング影響範囲マップ。その 875 個のセルは、それぞれ受信機の位置だけを変えた maritime-strait-jamming の一回の実行です。セルは、そのセルの「この実行を開く」リンクが Kshana Studio に渡す小数点以下三桁の座標から計算するようになったため、セルが示すものは、そのリンクが再現するものと正確に一致します。30 個のセルの平均ジャマー対信号比（J/S）が、上下いずれかに 0.1 dB 動きます。追跡の可用性が変わるセルはありません。エンジンは、0.28.0 と 0.29.0 のすべてのセルで同一の結果を出します。
• WebAssembly（WASM）パッケージでのシード付きリサンプリング。ブラウザービルドは、同じシードから、ネイティブビルドとは異なるブートストラップとシャッフルのインデックスを引いていました（「修正」の項）。ブラウザーでの quantum-anomaly-detect の曲線下面積の区間は [0.9901265, 0.9938305] でしたが、現在はネイティブの [0.99035875, 0.993861] です。ネイティブの数値は動きません。

ドキュメントに印刷されていた数値

ドキュメントを、このリリースのエンジンの実行結果と一語ずつ突き合わせて監査しました。印刷されていた数値が実行結果と一致しなかった場合はドキュメントを訂正し、その訂正をすべて、旧 → 新の形でここに挙げています。以下のどの場合も、エンジンの出力は変わっていません。ドキュメントのほうが、読み違えたか、丸め誤りをしたか、すでに古くなっていました。

• スペクトル、コンステレーション、キャンペーン、アニメーション、レポート、相互運用の各ページのドキュメント監査と、新しい docs/SOLAR-SYSTEM.md。すべての数値をこのエンジンで再実行しました。公表した数値が二つ動きます。docs/CONSTELLATION-DESIGN.md は、5 000 機のコンステレーションのカバレッジテストを「デバッグビルドで約 0.13 秒」としていましたが、これは再現しませんでした（負荷のかかったノート PC で 1.24 秒）。そこでこのページは、テストが出力するプレフィルターの割合（19,440,000 組のペアテストの 9.9 %）と、同梱の leo-pnt-mega-shell についてのリリースバイナリの 0.14 秒を示すようになりました。同じページは E3F の交差を「0.050 度ずれ」としていましたが、この数値を出力するテストはないため、このページはテストが強制する 0.06 度の合格基準と、その背後にある 7.30 度と 7.36 度の導出だけを示すようになりました。エンジンの出力は変わりません。
• LEO-PNT のドキュメント：改訂した公表数値（このリリースのエンジンで再実行）。 docs/LEO-SIGNAL.md のバンドトレードオフ：generic-s の一次電離圏遅延は 3.24 m（印刷は 3.25 m でした）、generic-c-wide は 0.77 m（0.78 m でした）。docs/LEO-NAVMSG.md のエンコードとデコード：デコードしたメッセージの SISRE は、実行では 0.122 cm であるのに 0.119 cm と印刷されていました。このページは、後述の「修正」にあるプラットフォーム非依存化の修正後の数値、0.129 cm を示すようになりました。docs/LEO-PASS.md の LEO 対 GNSS のパス：パスのピークで自由空間損失が 32 dB 少ない（「26〜32 dB」でした）。信号とパスの数値について、エンジンの出力は変わっていません。ドキュメントが読み違えたか、丸め誤りをしていました。
• チュートリアル、実践的なパイプラインの例、/kshana-run コマンドを、このリリースのエンジンに対して監査しました。公表した数値の改訂、旧 → 新：<scenario>.table.csv を書き出す種別は四つではなく六つです（leo-navmsg と telecom-timing が抜けていました。docs/tutorials/README.md、commands/kshana-run.md）。チュートリアル 3 の冷却原子 ½bT² の交差は 18,440 秒ではなく 18,443 秒です。docs/examples/multi-tool-pipeline.md の oem-interop の往復誤差は、「~1e-7 km」ではなく、測定値の 4.88e-7 km です。チュートリアル 2 の CSAC のホールドオーバー帯域は、「~2600〜4400 秒」ではなく、テストが検証する 2000〜3200 秒です。チュートリアル 1 は、SP3 の行とジオメトリブロックを、エンジンが書き出す精度のまま引用しています。エンジンの出力は変わっていません。
• 検証、量子、SGP4、アニメーション、主張、インテグリティの各ページ。 docs/VALIDATION.md：白色周波数雑音クロックのシミュレーションによる一秒のアラン偏差に対して強制されるゲートは 20 % です（25 % と印刷されていました。25 % のゲートは、1 秒、10 秒、100 秒の曲線に対するものです）。速度ランダムウォークの行には、観測された約 12 % の隣に、強制される 20 % のゲートを明記しました。orbit-gnss-challenged におけるチップスケール原子時計の可用性は約 0.73 です（約 0.83 と印刷されていました）。docs/QUANTUM.md：このページの冷却原子の実践例における振動で制限されるショットごとの雑音は、ショット雑音の下限の約 46 倍です（「~45×」と印刷されていました。再計算すると 46.49）。また、ページ自身が挙げる機器と矛盾していた、実用機器の「1〜50 µg/√Hz」という範囲は、引用している二つの機器の公表値に置き換えました。docs/SGP4-VALIDATION.md：最悪の位置差は 4.12 mm です（「≈ 4 mm」と印刷されていました）。衛星名も併記しました。docs/ANIMATION.md：動画エンコーダーの例は、毎秒 24 フレームのフレームを 12 で読み取っていましたが、現在はフレームマニフェストが示すレートの 24 を使います。docs/CLAIMS-VS-REALITY.md：ジャミングモデルのテストは 10 件です（8 件でした）。また、結合フィルターの「48.8 m に対して 2.97 m」は、そのテストが検証する内容に置き換えました（結合した位置誤差が分離した場合の 0.6 倍未満で、100 回の試行のうち少なくとも 90 回で上回る）。docs/INTEGRITY.md：「Today」のスタンプは v0.22.0 でしたが、このリリースを示すようになり、その後に実装した二つの機能（コンステレーション全体の故障モードとインテグリティ支援メッセージ）は、ギャップの一覧から外れました。

追加#

スペクトル

• spectrum シナリオ種別：L バンドのスペクトルモデルとウォーターフォール（src/spectrum.rs、src/sigmf.rs、docs/SPECTRUM.md）。GNSS の L バンド全体を一つのパワースペクトル密度（PSD）として扱います。GPS L1 粗捕捉符号（C/A）と L2 民生信号（L2C）（BPSK(1)）、Galileo E1（多重化バイナリオフセットキャリア、MBOC(6,1,1/11)、または BOC(1,1)）、GPS L5 と Galileo E5a（BPSK(10)）、受信機の雑音指数を含む kT 雑音フロア、そして、スクリプトで指定したタイムライン上の連続波（CW）、狭帯域、チャープ、整合雑音のジャマーです。各ジャマーはバンドごとにスペクトル分離係数（SSC）で評価され、バンドごと、行ごとのジャマー対信号比（J/S）と実効的な搬送波対雑音密度（C/N0）が得られます。グラフは C/N0 のバー付きの SVG ウォーターフォールで、result.json は電力でブロック平均したグリッドを含みます。任意の [iq] は、モデルを IQ サンプルとして描画し、Signal Metadata Format（SigMF）の記録（cf32_le、ci16_le）を書き出して読み戻し、Welch 推定をモデルと比較します。任意の [recording] は、実際の SigMF ファイルを推定します。同梱の例 scenarios/l-band-waterfall-jamming.toml：チャープが 10 秒で L1 C/A と E1 を奪い、L1 搬送波上の CW トーンは、チャープが止まった後も C/A を 17.98 dB-Hz に抑えますが、そこにスペクトルのヌルがある E1 は回復します。L5 と E5a は影響を受けません。
  • 新しい VALIDATED の行：信号の PSD と SSC を、BPSK(n) の主ローブ 2n x 1.023 MHz、+/-1.023 MHz を中心とする BOC(1,1) のローブ、公表されている -61.8 / -64.8 / -67.8 dB/Hz の SSC の背後にあるパーセバルの閉形式、および教科書どおりの Q = 1（CW）と 1.5（整合）と照合。BOC(1,1) の PSD の最大値は、ローブの中心ではなく +/-0.759 MHz にあり、テストは両方を固定しています。
  • 新しい MODELLED の行が二つ：jamming 種別のチェーンに正確に帰着するウォーターフォールと C/N0 のタイムライン（すべてのレポートで相互検証）、および SigMF コーデックと Welch 推定器。第三者の記録はリポジトリに含まれていません。
  • navsignal：MBOC の変種と spectral_separation_coeff_offset。
  • レポートは、jamming 種別の代表的な Q 表から得られる C/N0 を、スペクトルから導いた値と並べて印刷します。C/A 搬送波上の CW トーンでは、両者は 1.8 dB 異なります。新しいマトリクスの行は三つで、一つは確認済み（信号スペクトルとスペクトル分離係数）、二つはモデル計算です。

太陽系

• 太陽系のエフェメリスと任意の天体の周りの測位。新しいシナリオ種別が二つ。
  • solar-system：太陽、八つの惑星、冥王星、月、フォボス、ダイモス、イオ、エウロパ、ガニメデ、カリスト、タイタンを、一つのエポックで扱います。国際天球基準座標系（ICRF）での太陽中心の位置と速度、重力パラメーター、半径、公表されている場合の J2（第二帯状調和項）、恒星時の自転、国際天文学連合（IAU）の極と本初子午線、一周回の軌道トラック、そして観測者の天体からの、また任意の追加リンクについての、光伝搬時間、片方向と往復の距離、太陽のシャピロ遅延、太陽との離角です。惑星は、Standish と Williams によるジェット推進研究所（JPL）のケプラー要素から得ています（表 1、1800 AD から 2050 AD、表 2a/2b、3000 BC から 3000 AD）。衛星は、IAU の同期自転率を用いた JPL の平均要素から、タイタンは IAU の自転モデルから得ています。例：scenarios/solar-system-tour.toml。
  • body-pnt：これらの天体のいずれかの周りの周回機または表面ランダー。その天体の周りの Walker コンステレーションからの疑似距離と、地球からのクロック不要の往復距離で航法を行います。精度低下率、形式的な不確かさ、地球リンクがある場合とない場合のシード付き最小二乗測位解を扱います。例：scenarios/mars-orbit-pnt.toml、scenarios/europa-surface-pnt.toml。
  • Body に、水星、金星、木星、土星、天王星、海王星、冥王星と七つの衛星、名前による検索、物理的なレコードが加わります。AnalyticSolarSystem は、既存の EphemerisProvider の継ぎ目を通して、任意の天体を他の任意の天体に対する相対で与えます。
  • JPL Horizons（Development Ephemeris DE441。フィクスチャーとクエリーは tests/fixtures/solar_system/）に対して VALIDATED：表 1 の水星から土星と地球は、明示した公称誤差の二倍以内（最悪で 1.87 倍）、表 2a/2b のすべての八つの惑星は最悪で 1.71 倍、そして地球から火星と木星への光伝搬時間。MODELLED：表 1 の天王星と海王星（DE441 に対して明示した誤差を超えます。2.0 倍と 5.2 倍）、冥王星、衛星、天体の定数、そして body-pnt の結果。
  • 所見：src/ephem.rs の Montenbruck & Gill の月の級数は、自身の歳差項によって、すでに J2000 の春分点に対して表されています（Horizons との差は 0.05 度）。そのため、追加の歳差回転なしで使用します。新しいマトリクスの行は六つで、二つは確認済み（惑星の位置、光伝搬時間）、四つはモデル計算です。

任意の天体の周りのコンステレーション

• 大規模なコンステレーション設計（constellation-design 種別、src/constellation.rs）。Walker デルタと Walker スターのパターン（T/P/F）、明示的な要素リスト、複数シェルの設計を、一回の実行で複数のコンステレーションについて、地球、月、火星、あるいは他の任意の惑星、冥王星や主要な衛星の周りに配置できます。天体の定数は solar-system 種別が追加したものを使います。公表された公称要素からのプリセット：Global Positioning System（GPS）のベースラインと拡張可能な 24 スロットのコンステレーション（Standard Positioning Service Performance Standard、SPS PS、2020）、Galileo Walker 24/3/1（Open Service Service Definition Document 第 1.1 版）、BeiDou の中軌道 Walker 24/3/1 に静止軌道と傾斜静止衛星同期軌道の衛星を加えたもの（Open Service Performance Standard 3.0）、GLONASS 24/3/1（Interface Control Document 5.1）。緯度・経度のグリッド上のカバレッジと精度低下率（DOP）：視界内の衛星数、GDOP、PDOP、HDOP、VDOP（幾何、位置、水平、垂直）、およびセルごとの可用性を、全球と最悪地点で、コンステレーションごとに受信機クロックを一つずつ持たせて評価します。可視性のプレフィルター（カバレッジの半角と、衛星直下点の緯度帯。球体では厳密）は、デバッグビルドで 10 度のグリッド上の 5,000 機の衛星を約 0.13 秒で処理します。
  • VALIDATED：Walker ジェネレーターは Galileo OS SDD の表 23 と GLONASS ICD のスロット式を再現します。GPS のプリセットは SPS PS の赤道通過の列を再現します（36 か所中 35 か所が 0.0108 度以内。E3F は 0.06 度以内で、表自身の行が矛盾しています）。GPS ベースラインの全球 HDOP 分布は SPS PS の附属書 B と一致します（中央値 0.940 対 0.94、95 % 点 1.255 対 1.25、平均 0.965 対 0.96。合格基準 0.03）。
  • MODELLED：任意の設計、他の天体、BeiDou の位相と傾斜静止衛星同期軌道のノード、オプションで J2 を含む二体問題の軌道、幾何のみ。
  • シナリオ：constellation-multi-gnss-coverage（102 機の衛星、可用性 100 %、PDOP の中央値 0.95、10 度より上で視界内に 31.0 機）、leo-pnt-mega-shell（5,000 機の衛星、20 度より上で PDOP が 3 以下となる可用性が 99.22 %、極冠では 0 %、プレフィルターはペアテストの 11.5 % を残す）、lunar-relay-constellation（月の周りの 14 機の衛星、全体の可用性 21.33 %、南極域上空で最も高い）。三つとも kshana example 用に同梱されています。注記：docs/CONSTELLATION-DESIGN.md。新しいマトリクスの行は三つで、二つは確認済み（Walker ジェネレーターと GNSS プリセット、GPS の全球 DOP）、一つはモデル計算です。
• スペクトルモデルで駆動するキャンペーンと、任意の天体の周りのコンステレーション。 scenarios/campaign-spectrum-holdover-integrity.toml は、spectrum 種別を、クロックのホールドオーバーとインテグリティモニターと連鎖させます（チャープが L1 C/A と E1 を奪い、その後 CW トーンが C/A を抑え続ける間に E1 が回復し、受信機は Galileo のみの空に切り替わります）。結果は、tests/campaign_composition_reference.rs のスタンドアロンのウォーターフォールの例に対して固定されています。constellation-design は、中心天体を Body::by_name 経由で解決するようになったため、solar-system 種別が使う定数を用いて、任意の惑星、冥王星、主要な衛星の周りにコンステレーションを配置できます。

キャンペーン

• キャンペーン：多数のシナリオを一つの実行に構成する。新しい campaign 種別（src/campaign.rs、docs/CAMPAIGNS.md に記載）は、既存の種別のメンバーを、コマンドラインと同じディスパッチで実行し、それらの結果から数値を読み戻します。四つのセクションを、任意の組み合わせで使えます。
  • [[phases]]：一つのタイムライン上の連鎖したミッション。種別ごとのプリセットは、クロック時刻誤差をそのガードに対して、実効搬送波対雑音密度比（C/N0）の平均を追跡フロアに対して、垂直保護レベルをアラート限界に対して、また位置誤差、追跡中の衛星、アラームフラグを読み取り、フェーズの境界とイベントとともに共通のグリッドに保持します。状態は carry、handoff、end_at で引き継がれます。
  • [sweep]：任意の種別のドット区切りキーを一つから三つまで。オプションで、各ノードにシード付きのアンサンブルを持たせられます。
  • [monte_carlo]：基準シード + k の実現 k、平均、ばらつき、パーセンタイル、固定シードのブートストラップによる 95% 信頼区間。
  • [compose]：複数のメンバーに結び付けた共有値と、最良値と最悪値を合わせた要約。すべての結果は、キャンペーンのハッシュと、すべてのメンバーの結果に対するダイジェストを持ちます。同梱のシナリオは四つ：campaign-jam-spoof-holdover-integrity（公称、ジャミング、クロックモニターが 370 秒で検出して終わるスプーフィング、慣性ユニットが惰行しながら 37.0 ns のスプーフィングによるオフセットを保持するホールドオーバー、インテグリティアラーム、回復）、campaign-sweep-jammer-power、campaign-shared-jammer-sea-road、campaign-monte-carlo-clock-holdover。tests/campaign_composition_reference.rs は構成の恒等性を固定します。単一フェーズのキャンペーンは三つの種別でスタンドアロンの実行をビット単位で再現し、固定シードのアンサンブルはバイト単位で安定し、白色周波数雑音クロックではアンサンブルの平均が報告された区間の内側にあり、ばらつきは sqrt(q_wf * tau) = 16.459 ns のカイ二乗区間の内側にあります。新しいモデル計算のマトリクスの行は三つです。

アニメーション

• アニメーションのエクスポート（--animate svg|html|frames|all、src/animation.rs、docs/ANIMATION.md）。結果に時系列を含む実行は、アニメーション付きの Scalable Vector Graphics（SVG）ファイル（Cascading Style Sheets のキーフレームを使い、スクリプトなし。移動する時刻カーソルの背後でトレースが描かれます）、自己完結した単一の HyperText Markup Language（HTML）プレーヤー（再生と一時停止、スクラブ、速度、一つの同期カーソルにすべてのパネル、クリックでシークするイベントマーカー。外部アセットなし）、またはビデオエンコーダー向けに、毎秒のフレーム数、長さ、フレーム時刻を記した manifest.json を伴う、番号付きの SVG フレーム列として書き出せるようになりました。キャンペーンはフェーズごとにアラームを示して再生され、スペクトルの実行はウォーターフォールを行ごとにアニメーションにします。プレーヤーは prefers-color-scheme に従い、prefers-reduced-motion のもとでは、SVG もプレーヤーも、動かさずに完成した絵を表示します。--animate-fps と --animate-duration は再生を設定します。kshana::api::animate_toml と kshana::animation::animate_result はライブラリーのエントリーポイントで、result.json に animation ブロックが加わるのは --animate を実行したときだけです。出力は結果とオプションだけで決まる純粋関数で、再実行してもバイト単位で同一であり、タイムスタンプを含みません。サンプリングされた時間軸のない種別は、「no time series to animate」というメッセージで拒否され、何も書き出されません。エクスポーターはその実行自身のサンプルを描画するだけで、数値を加えないため、MODELLED（内部整合性）であり、検証マトリクスの行は持ちません。公表した数値は変わりません。テスト：tests/animation.rs（決定性、フレーム数、外部アドレスがないこと、整形式の XML、視覚効果の軽減の経路、時系列を持つすべての同梱シナリオがアニメーションになること）。

レポート

• 高度な実行レポート（src/advanced_report.rs、docs/REPORTS.md）。すべてのコマンドラインインターフェース（CLI）の実行が、印刷可能な HyperText Markup Language（HTML）レポートの <scenario>.report.html と、同じ内容を機械可読な JavaScript Object Notation（JSON）文書にした <scenario>.report.json を書き出すようになりました。セクションは次のとおりです。エグゼクティブサマリー。すべてのシナリオ入力を、その単位とともに（フィールド単位スキーマ、つまり結果の units ブロックから読み取り、なければフィールド名の接尾辞から、それもなければ「記載なし」として）示すもの。その実行のグラフ、すべてのスカラー、すべての数値列の要約を含む結果。キャンペーンについては、スイープのノード表、モンテカルロの平均、標準偏差、5・50・95 パーセンタイルとブートストラップ信頼区間をメトリクスごとのヒストグラムとともに示すもの、連鎖のフェーズ表、または構成のメンバーと合算した要約（および sweep または sweep-nd の実行のグリッド）。イベントのタイムライン。その実行の種別が使う検証マトリクスのすべての行の VALIDATED / MODELLED / PARTNER のラベル、オラクル、テストのエビデンス（種別から行への対応表を通してマトリクスから読み取ります。一つの入力経路を評価する行、たとえば orbit の Simplified General Perturbations 4（SGP4）経路や slot-timing の測定記録経路は、その実行がその経路を通ったときだけ載せます。また、Shuttle Radar Topography Mission（SRTM）リーダーの行は、どのシナリオのフィールドも SRTM タイルを読まないため、どの種別にも載せません）。モデル化していないものの記述と前提を、それぞれ出典とともに引用したもの。再現性の記録（エンジンのバージョン、ビルドが KSHANA_GIT_COMMIT を設定したときのソースのコミット、シナリオファイルと結果文書の Secure Hash Algorithm 256 ビット（SHA-256）ダイジェスト、シード、プラットフォーム、正確なコマンド）。レポートは時計を読まないため、同じシナリオ、シード、エンジンビルドからはバイト単位で同一のレポートが得られ、表示され得る唯一のタイムスタンプは --study-name がすでに書き出すものです。印刷用スタイルシートは A4 と US Letter に収まり、表の見出しを繰り返し、行と図をページをまたいでも分割しません。Portable Document Format（PDF）ファイルは、ブラウザーの「PDF として保存」で作成します。--report pdf のオプションはありません。グラフを PDF に描画するには、重い新たな依存関係が必要になるためです。テスト：tests/advanced_report.rs はすべての同梱シナリオのレポートを作成し（空のセクションなし、プレースホルダーのテキストなし、ラベルがマトリクスと一致、シナリオのダイジェストがファイルのものと一致、再実行でバイト単位で同一）、tests/advanced_report_cli.rs は記録されたコマンドを新しいディレクトリで再実行し、バイト単位で同一の result.json を要求します。公表した数値は変わらず、種別、シナリオファイル、マトリクスの行の数も変わりません。
• レポート、アニメーション、エクスポートが連携します。高度なレポートに「アニメーションとエクスポート」のセクションが加わりました。その実行のアニメーションの描画を、動作しない画像として埋め込んだもの（ない場合はその理由）、隣に書き出したアニメーションとエクスポートのファイルへのリンク、そして、すべての相互運用フォーマットについて、適用できるか、できない場合はその理由、その仕様です。report.json も同じ companions ブロックを持ちます。HTML アニメーションプレーヤーは、隣に書き出したエクスポートファイルを一覧にします。コマンドラインインターフェース（CLI）は、レポートを書く前にエクスポートを生成するようになったため、両方がそれらのファイルを名指しできます。

相互運用エクスポート

• 相互運用エクスポートとインポート（--export、src/interop/、docs/INTEROP.md）。 kshana <scenario.toml> --export <format> は、シナリオのジオメトリを、CZML（Cesium Language）、KML（Keyhole Markup Language 2.2。Open Geospatial Consortium の標準で、gx:Track の時刻付きトラックを含む）、GeoJSON（Internet Engineering Task Force Request for Comments 7946）、Ansys STK（Systems Tool Kit）の .e エフェメリス（EphemerisTimePosVel、メートル単位、移動する物体ごとに一ファイル）として書き出し、また spectrum 種別の合成した IQ（同相成分と直交成分）スナップショットを、既存の src/sigmf.rs を通して SigMF（Signal Metadata Format）のペアとして書き出します。--export all は、適用できるすべてのフォーマットを書き出し、そうでないものについてはその理由を表示します。--export list は、実行せずに報告します。移動する物体は、Geocentric Celestial Reference System（CZML の INERTIAL、STK の ICRF）、および地球固定の WGS 84（World Geodetic System 1984）の経度、緯度、高さ（KML、GeoJSON）で書き出し、CZML の固定地点は FIXED です。jamming 種別は、自身のリンク方程式から二つのジャマーの影響範囲を追加します。--import-route <file.geojson> は、GeoJSON の LineString を、terrain-nav、terrain-slam、gravity-map、combined-altpnt のトラック入力に書き込みます。エクスポートはバイト単位で決定的で、タイムスタンプを含みません。tests/interop_formats.rs は、すべてのエクスポートを公表された仕様に対して検証し、エクスポートした衛星の状態をエンジン自身の状態と 1 mm まで比較し、すべての同梱シナリオをすべてのフォーマットに通して、それぞれがエクスポートされるか、されない理由を示すことを確認します（docs/INTEROP.md の表）。公表した数値は変わりません。spectrum 種別の IQ 合成は一つの共有関数に移りましたが、その結果文書はバイト単位で同一であり、PassesScenario は、自身の実行で使う propagator() と epoch_calendar() を得ます。種別、シナリオファイル、検証マトリクスの数は変わりません。epoch のない軌道またはインテグリティのシナリオは、その衛星自身のデータで日付が決まります。t = 0 は最も早い TLE（二行軌道要素）、放送エフェメリス、または SP3（Standard Product 3）のエポックで、そのような各衛星は、それぞれ自身の時刻で GCRS と地球固定座標系に回転されます。2000-01-01T00:00:00Z は、どの衛星もエポックを持たない場合にのみ使われます。SP3 と OEM（Orbit Ephemeris Message）のエクスポートは、2000-01-01 のラベルを維持します。これを支えるため、Sgp4::epoch_jd_utc、Sp3Interpolator::jd_ut1、Propagator::own_jd_utc を追加しました。既存のものでこれらを読むものはありません。

低軌道ナビゲーション：信号

• LEO-PNT の信号設計とマルチバンドスペクトル。新しい leo-signal 種別と、L バンドを超えて及ぶ spectrum 種別：種別は一つ、シナリオファイルは四つ（三つは同梱、Celeste IOD のファイルはリポジトリ限定）、マトリクスの行は四つ（VALIDATED が二つ、MODELLED が二つ）です。
  • leo-signal：任意のシステム向けの、パラメーター化した低軌道（LEO）の測位・航法・時刻（PNT）信号設計（バンド、送信帯域幅、ITU の割当。捕捉、データ、パイロットの各成分を、BPSK(n)、BOC(m,n)、MBOC、またはフラットなスペクトル、電力配分、FDMA サブキャリア、符号長、データレートで指定）。コンパイル済みの公開プリセットファイルが data/leo-signals/ にあり（Xona Pulsar X1/X5、Iridium STL、機会信号としての Starlink の信号、CentiSpace、代表的な C バンドの設計、代表的な UHF/L/S/C/広帯域 C の設計。それぞれ出典の URL を明記）、インラインで書くこともできます。信号ごとに次を扱います。帯域制限した PSD と帯域内の電力割合、Gabor 帯域幅、C/N0 と間隔に対する帯域制限した早遅コード追跡ジッター（Betz & Kolodziejski 2009）と測距精度、捕捉の探索空間、検出確率、逐次およびコード並列の平均捕捉時間、GPS L1 C/A、Galileo E1、GPS L5、Galileo E5a、E5b、AltBOC への、およびそれらからの SSC と C/N0 の損失、スペクトル種別の SSC コードによる CW、広帯域、整合の J/S 許容度、バンドのトレードオフ（電離圏遅延、自由空間損失、同じ C/N0 と同じ EIRP での測距、ジャマー許容度）、そして記述された測定に対する任意の形状検査です。例：scenarios/leo-band-trade.toml、scenarios/xona-pulsar-signals.toml、scenarios/celeste-iod-classical-pilot-signals.toml（2026 年の ESA NAVISP LEO-PNT ワークショップで提示された Celeste IOD のバンドと信号構成。Celeste IOD のプリセットとともに非公開にできます。後述の「LEO-PNT のエンドツーエンド」を参照）。注記は docs/LEO-SIGNAL.md にあります。
  • spectrum：バンドは、プリセットの信号設計（すべての成分を描画し、帯域制限し、C/N0 と J/S は追跡する成分を基準にする）、またはカスタムの搬送波と変調方式を使えるようになりました。[[panels]] は、一つのタイムライン上で他の周波数範囲のウォーターフォールを追加します。wideband（バラージ）ジャマーが、四つの波形に加わります。レポートには bands[].tracked_power_dbw、bands[].design、panels と、not_modelled の項目が一つ加わります。通常のバンドは、以前と同じ数値になります。例：scenarios/multi-band-jamming-waterfall.toml。
  • navsignal に、サイン積分、BPSK の帯域内電力と帯域制限した Gabor 帯域幅の閉形式、任意のスペクトルに対する帯域制限した早遅ジッターとその Gabor 限界、オフセット BPSK の SSC の閉形式、Galileo E5 AltBOC(15,10) のスペクトル、変調ラベルのパーサーが加わります。Modulation::label は BPSK(1/3) を分数で表示します。
  • マトリクスの行は四つ：VALIDATED の帯域制限した閉形式（BPSK の電力の 90.3 % が主ローブにあること、ジッターが Kaplan & Hegarty のコヒーレント形式に帰着すること（45 dB-Hz、B_L 1 Hz、d 1 チップ、T 20 ms で 0.0039564 チップ）とその Gabor 限界に帰着すること、そして BPSK の自己 SSC 2/(3 R_c)。Gabor の閉形式と、オフセット SSC をそのパーセバル形式に対して見たものは、内部の相互検査として明示）、VALIDATED の LEO の最大ドップラー（Xona X1 は 33.2 kHz で、公表されている 32 から 34 kHz の範囲内、Iridium は 36 kHz の 0.5 kHz 以内）、MODELLED の leo-signal、MODELLED のマルチバンドスペクトル。

低軌道ナビゲーション：リンク

• LEO-PNT のパスとバンドごとのリンクバジェット：leo-pass 種別。LEO-PNT とは、低軌道（LEO）の衛星による測位・航法・時刻です。ユーザー（地上、海上、空中、屋内のいずれも、静止または移動）と、一機以上の LEO 衛星を、設計したパス、明示的な要素、SGP4 を通した二行軌道要素（TLE）、または constellation-design のコードによる Walker コンステレーションから与えます。衛星、バンド、エポックごとに次を扱います。見通し角、距離、閉形式の距離変化率と距離加速度（実行のたびに中心差分で検査）、ドップラーとドップラーレート、自由空間損失、等方性フラックス、ガウスビーム、またはフラットな衛星パターンを使った EIRP（等価等方放射電力）、パッチのユーザーアンテナ、ITU-R P.676 の大気ガス減衰、ITU-R P.838/P.618 の降雨減衰、P.618 の対流圏シンチレーション、屋内ユーザーに対する ITU-R P.2109 の建物侵入損失、偏波不整合、システム雑音温度と C/N0（搬送波対雑音密度）、衛星直下の Klobuchar または垂直 TEC（全電子数）の斜め TEC から得るバンドごとの一次電離圏遅延、そして電離圏フリーのバンドの組とその雑音増幅です。Galileo または GPS の衛星は、インターフェース文書の受信電力を使い、同じ受信機で評価されるため、釣り鐘形の LEO のパスと平坦な MEO（中軌道）の搬送波は、一つのプロットを共有します。[iot] セクションは、デューティサイクルに対する、初回測位までの時間、一回の測位あたりのエネルギー、バッテリー寿命を示します（MODELLED）。
  • システム非依存：エンジンはプリセットを必要としません。任意のプリセットは、それぞれ独自のファイルに置かれ、PUBLIC（URL 付き）、REPRESENTATIVE、WORKSHOP のいずれかの印が付きます。汎用マルチバンド（UHF、L、S、C）、汎用 C バンド、Xona Pulsar X1/X5（arXiv 2509.19551）、Iridium STL、ドップラーのみの機会信号としての Starlink、CentiSpace、そして Celeste IOD（in-orbit demonstration、軌道上実証）です。Celeste IOD の信号パラメーターは 2026 年の ESA NAVISP LEO-PNT ワークショップで提示されたもので、非公開にできるよう src/celeste_iod.rs に置かれています（後述の「LEO-PNT のエンドツーエンド」を参照）。
  • 他のモジュールから呼び出せる、src/leo_link/（geometry、antenna、itu、iono、energy、presets）の公開ビルディングブロック。
  • シナリオ：leo-pass-vs-gnss-cn0、leo-indoor-uhf、leo-iot-energy、leo-pass-xona-pulsar、leo-pass-iridium、leo-pass-celeste-iod-multiband。
  • マトリクスの行は九つ。VALIDATED（6）：ITU-R P.838-3 の係数を、その表 5 に対して。P.618-14 の降雨減衰とシンチレーションを、ITU-R Study Group 3 の検証例に対して。P.2109 の建物侵入損失を、Study Group 3 のワークブックに対して。一次電離圏スケーリングを、自由空間損失とともに、IS-GPS-200 の群遅延比に対して。円軌道の静止ユーザーの最大ドップラーを、arXiv 2509.19551 の表 1 に対して。MODELLED（3）：パスとリンクバジェット、プリセット、低エネルギーの測位バジェット。種別は一つ、シナリオファイルは六つ。注記は docs/LEO-PASS.md にあります。

低軌道ナビゲーション：航法メッセージ

• LEO 航法メッセージ（leo-navmsg 種別、src/leo_navmsg/）。低軌道（LEO）の測位・航法・時刻（PNT）衛星の、放送エフェメリスとクロックのメッセージで、任意の軌道、搬送波、モデルに対応します。名前のあるプリセットは任意のデータで、すべての機能はそれなしで動作します。種別は一つ、シナリオファイルは五つ、マトリクスの行は九つ（VALIDATED が三つ、MODELLED が六つ）です。docs/LEO-NAVMSG.md を参照してください。
  • メッセージの内容：SVID、データの発行番号、バンドと信号の健全性、週、週内時刻と二次のクロック多項式、四つのモデルのいずれかによるエフェメリス（Galileo OS SIS ICD の 16 パラメーターのケプラー要素セット、そのセットに along-track、cross-track、radial の補正多項式を加えたもの、Liu et al. 2025 の 22 パラメーターモデル（doi 10.3390/rs17162894）、または ATOMIC のゼロクロック ECEF 多項式）、Klobuchar のセット、有効電離レベルを伴う NeQuick-G の係数、そして ICD のうるう秒のケースを含む、システム時刻から UTC へのパラメーターです。
  • フィッター：帯状 J2〜J6 または EGM2008 の重力と抵抗で積分した真値軌道、シード付きの自由または制御されたクロック、非特異な要素に対する Levenberg–Marquardt フィット、続いて線形最小二乗の補正多項式と、ユーザーの相対論的項を除いてフィットしたクロック。
  • 四つの解析とシナリオ：leo-navmsg-fit-interval-trade（信号空間の距離誤差（SISRE）対フィット区間と更新周期）、leo-navmsg-model-comparison（四つのモデル、ビット、そして Liu et al. の高度での Kshana の 22 パラメーターフィットを公表値と並べたもの。MODELLED）、leo-navmsg-midpass-update（パス中の各メッセージ切り替えでの連続性）、leo-navmsg-encode-decode（CRC-24Q と量子化バジェットを備えた Kshana 独自の文書化したバイナリフレーム、Kshana 拡張と表示した RINEX-4 形式のブロック、そして CSV の表）。
  • VALIDATED：全球平均の SISRE の重みを Montenbruck et al. 2018 が公表した中軌道と静止軌道の表に対して、Galileo ユーザーアルゴリズムを四つの実際の Galileo 放送エフェメリスに対して RTKLIB と比較（tests/leo_navmsg_reference.rs）、CRC-24Q をカタログのチェック値と RTCM 10403 1005 の例のフレームに対して。
  • プリセットは、それぞれ出典付きで一ファイルずつ：Xona Pulsar と Pulsar-0、Iridium、Starlink、CentiSpace、代表的な C バンドのシステム、ATOMIC、そして Celeste IOD（2026 年の ESA NAVISP LEO-PNT ワークショップで提示された資料を使う唯一のプリセットで、非公開にできるよう、そのシナリオとともに src/celeste_iod.rs に置かれています）。

低軌道ナビゲーション：融合

• MEO + LEO の融合による測位・航法・時刻：leo-pvt、leo-ppp、ntn-positioning。src/leo_fusion/ に新しいシナリオ種別が三つあり、いずれもシステム非依存です。すべてのコンステレーションは Walker シェル、要素セット、または GNSS プリセットで、すべての信号は搬送波、チップレート、搬送波対雑音密度（C/N0）の包絡線で、すべての誤差バジェットは明示的な一シグマで表します。名前のある低軌道（LEO）システムは任意のプリセットで、それぞれ一ファイルずつ、出典を public、workshop、derived のいずれかで明記します（Xona Pulsar X1/X5、Iridium Satellite Time and Location（STL）、機会信号としての Starlink の信号、CentiSpace、代表的な C バンドのシステム、ATOMIC のゼロクロックエフェメリスモデル、そしてワークショップから導出したパラメーターを非公開にできるよう src/celeste_iod.rs に置いた、ESA の Celeste 軌道上実証のプリセット一つ）。
  • leo-pvt には四つのモードがあります。ドップラー測位（距離変化率に対するバッチ最小二乗で、クロックドリフトと速度の状態を持つもの、ドップラーのみの機会信号モード、単一パスのアロングトラックとクロストラックの精度、そしてドップラー、ドップラーレート、ジャークの包絡線）、システムごとに一つのクロック（システム間バイアス）または既知のオフセットを持つ、GNSS + LEO の結合重み付き最小二乗（測定ごとのシグマを入力とし、LEO 衛星数に対する DOP）、緯度に対する極域と北極圏のカバレッジ、そして C/N0 と受信機の発振器に対する、協定世界時（UTC）への LEO 時刻比較（IS-GPS-200 のシステム時刻から UTC への式を使用）です。
  • leo-ppp：電離圏フリーのコードと位相に対するフロート精密単独測位（PPP）の拡張カルマンフィルターで、GNSS のみの場合と LEO で補強した場合を扱い、収束時間と、モンテカルロの NEES（正規化推定誤差二乗）整合性テストを備えます。同梱のシナリオでは、四つの MEO システムで 7.4 分、60、96、192、288 機の LEO 衛星でそれぞれ 4.8、3.2、2.7、2.3 分となり、傾向を比べる MODELLED の比較として、Li et al.（J. Geod. 93:749、2019）の 9.6、7.0、3.2、2.1、1.3 分と並べています。
  • ntn-positioning：到来時刻とドップラーに関するクラメール・ラオ限界から求める、3GPP の n256 移動衛星 S バンドにおける 5G 非地上系ネットワーク（NTN）の測位。
  • シナリオ：leo-doppler-positioning、starlink-sop-doppler-positioning、meo-leo-fused-pvt、leo-ppp-convergence、ntn-5g-positioning、polar-arctic-leo-coverage、leo-timing-utc（同梱）、および celeste-iod-fused-pvt（リポジトリ限定。Celeste IOD のプリセットとともに非公開）。
  • マトリクスの行は八つ：LEO のドップラー包絡線を、公表されている Iridium（±36 kHz：35.9 kHz、5% 以内）と Xona Pulsar X1（32 から 34 kHz：97 度のシェルで 33.6 kHz、拡がりなし）の数値に対して VALIDATED（tests/leo_doppler_reference.rs）、ドップラー測位、ジョイント疑似距離測位、PPP の収束、NTN の限界、LEO のタイミング、極域のカバレッジ、プリセットは MODELLED です。種別は三つ、シナリオファイルは八つ。ドキュメント：docs/LEO-PNT-FUSION.md。
• LEO-PNT のエンドツーエンド：leo-pnt-chain 種別と、つなぎ合わせた LEO の各段階。一つの低軌道（LEO）測位・航法・時刻（PNT）システムを、その信号設計からユーザーの位置まで追跡します。各段階は、それぞれのシナリオ表を持つエンジン自身の種別で、値はコードで受け渡されます（docs/LEO-PNT.md）：
  • leo-pass のバンドは leo-signal の設計（signal = "xona-x5"）を名指しできます。そのバンドは設計の中心、送信帯域幅、追跡する成分のチップレートを取り込み、EIRP（等価等方放射電力）を設計の各成分に分配し、各エポックの追跡成分の C/N0（搬送波対雑音密度）と帯域制限したコード追跡ジッター（測距誤差。iono_free の組の雑音もこれを使います）を報告します。設計のないバンドは、以前と同じ出力になります。
  • leo-pnt-chain は、信号 → パス → 航法メッセージ → 融合した leo-pvt のジョイント測位解 → 任意の leo-ppp の順に実行します。測位段階の LEO システムのうち、これらを未設定のものはすべて、パスに合わせた sin(仰角) の C/N0 の直線、メッセージの信号空間の距離誤差（SISRE：パス中の衛星の軌道での表現誤差に、明示した od_sisre_m の軌道決定項を二乗和平方根で合わせたもの）、設計の搬送波とチップレートを採用します。精密単独測位（PPP）のケースは SISRE を採用します。すべての受け渡しは、その値と単位とともに一覧にされ、tests/leo_pnt_chain.rs は、それぞれが上流の出力と等しいこと、および上流の変更が下流の数値を動かすことを検査します。LeoNavmsgScenario::broadcast_sisre は新しいメッセージのエントリーポイントです。
  • シナリオ：leo-pnt-end-to-end（一般的な 1080 km のコンステレーションと代表的な generic-l 信号）、xona-pulsar-end-to-end（公開の X5 信号）はどちらも同梱で、任意のリポジトリ限定の celeste-iod-end-to-end もあります。
  • パス、メッセージ、融合測位の各領域の Celeste IOD（in-orbit demonstration、軌道上実証）のプリセットは、src/celeste_iod.rs という一つのファイルに置かれるようになりました。build.rs は、このファイルが存在する場合にだけコンパイルに含めます（kshana_celeste 構成フラグ）。その五つのシナリオ（scenarios/*celeste-iod*.toml）はリポジトリ限定のため、このファイルとそれらのシナリオを削除すれば、2026 年の ESA NAVISP LEO-PNT ワークショップで提示されたすべての数値を、ソースを編集せずに非公開にできます。tests/workshop_preset_isolation.rs は、どのファイルがそのプリセットを名指しできるか、またはそのバンドプランの数値を持てるかを検査します。
  • 高度なレポートの対応表にあるすべての LEO 種別で、経路固有の行は、その実行がその経路を通ったとき（降雨率、建物、実行した解析やモード）にだけ載せます。leo-pvt のドップラーウィンドウは t_s を、leo-ppp のケースは t_min を得るため、どちらもアニメーションにできます。leo-pass と leo-pnt-chain は CZML、KML、GeoJSON、STK のエフェメリスをエクスポートし、他の LEO 種別は、フォーマットが適用できない理由を示します。

低軌道ナビゲーション：レジリエンス、重点領域、エンドユーザーのシナリオ

• LEO-PNT のレジリエンス。実験の重点領域ごとに一つ、エンドユーザーの業種ごとに一つのシナリオ、そしてすべての LEO 種別とシナリオの概要としての docs/LEO-PNT.md。すべてのシナリオは Celeste のデータなしで実行でき、同梱されています。
  • leo-pass に [spoofer] セクションが加わります。スプーファーは、真の位置から、開始後に飛ぶ、または押し出される（あるいはその両方の）主張位置の信号を、距離と距離変化率で自己整合するように偽造します（LEO のバンドごと、および MEO の GNSS 信号。電離圏の有無は問いません）。二つのモニターが、明示した誤警報確率で動作します。ドップラーとパス幾何の整合性（測定した距離変化率を、軌道と独立した事前の位置・速度から予測したものと比較。ウィンドウにわたる一般化最小二乗のカイ二乗を、GNSS、LEO、すべてのチャネルについて、C/N0 から求めた周波数ロックループ雑音で評価）、およびバンド間の整合性（各 LEO バンドの組の、モデルで補正した幾何フリー結合のステップ）です。結果は、エポックごとの統計量（そのためアニメーションにできます）、各バンドの組、そして各モニターがいつ検出するかを示します。構成要素は leo_link::spoof にあります。セクションがなければ、出力は変わりません。
  • すべての leo-pass バンドの組は、パスのピークでその幾何フリー結合が復元する斜め全電子数（TEC）と、その推定値のコード雑音シグマも報告します（電離圏の観測）。これにより、すべてのマルチバンド leo-pass の結果にフィールドが二つ加わります。既存の数値は変わりません。
  • leo-pvt のタイミングモードは trace = true を受け付けます。すると各行が、すべてのエポックで時刻誤差と予測シグマを、同じ乱数で報告するため、行の統計は変わらず、実行はアニメーションにでき、キャンペーンで連鎖できます。
  • キャンペーンは、ジオメトリを持つ各メンバーシナリオ（フェーズの実行、スイープとモンテカルロのベースシナリオ、共有値を結び付けた構成のメンバー）を、メンバーのラベルをファイル名に含めた独自のファイル一式としてエクスポートするようになりました。以前は、キャンペーンは何もエクスポートしませんでした。docs/INTEROP.md の相互運用の表は、それに合わせて変わります。
  • キャンペーンのスイープキーは、テーブルの配列を位置で指定できます（system.2.sisre_m）。
  • レジリエンスのシナリオ：leo-resilience-multiband-diversity（電力を掃引する 50 MHz の L5 バンドのバラージ。すべての L バンド信号が落ち、UHF、S バンド、C バンドの LEO 信号は C/N0 を保つ）、leo-resilience-js-margin（受信電力からの J/S マージン。GPS L5、Galileo E5a、Xona X5 は -105、-100、-95 dBW で失われ、-135 dBW の一般的な LEO 信号は -90 dBW でも追跡を続ける）、leo-resilience-spoof-doppler（30 m のジャンプを、GNSS のみのドップラーテストは見逃し、すべてのチャネルでのテストは開始の 105 秒後に検出）、leo-resilience-spoof-monitors（四つのスプーファーを両方のモニターに対して）、leo-resilience-gnss-jammed-leo-carries（GNSS はジャミングされ、S バンドと C バンドの LEO 層は追跡され、LEO 層だけでの受信機自律インテグリティ監視は 30 エポック中 2 エポックでアラーム）。
  • 重点領域のシナリオ：leo-focus-ppp-altitude、leo-focus-ntn-bandwidth、leo-focus-iot-eirp、leo-focus-science-iono-sounding、leo-focus-data-services、leo-focus-indoor-uhf、leo-focus-fused-pnt-sisre（L、S、C でのレジリエンスは leo-resilience-multiband-diversity）。
  • 業種別のキャンペーン。それぞれアニメーションを持ち、LEO のパスをエクスポートします：leo-vertical-autonomous-vehicle、leo-vertical-rail-maritime（同梱の海上と鉄道のシナリオに LEO を加えたもの）、leo-vertical-critical-infrastructure-timing、leo-vertical-polar-arctic、leo-vertical-5g-network-timing、leo-vertical-asset-tracking-iot。一行の結果は docs/LEO-PNT.md にあります。
  • MODELLED のマトリクスの行が三つ：ドップラーとパス幾何のスプーフィングモニター、バンド間のスプーフィングモニター、電離圏の観測。tests/leo_resilience_verticals.rs は、モニター（開始前は沈黙すること、ドップラー統計量がジャンプに対して二次であること、地上のスプーファーでは電離圏のステップが出て、電離圏を考慮したスプーファーでは出ないこと）、観測の恒等式、行の統計に対するタイミングのトレース、そしてキャンペーンのエクスポートが各メンバー自身のエクスポートと等しいことを検査します。
  • leo-pass のページは docs/LEO-PASS.md に移り、docs/LEO-PNT.md が概要になります。

海上、道路、鉄道のシナリオ

• 海上、道路、鉄道のシナリオ。既存の種別上の同梱の例が五つあり、船舶、道路車両、列車のそれぞれに実践例があります。すべての数値は MODELLED であり、測定データと照合して確認したものはありません。
  • scenarios/maritime-strait-jamming.toml（jamming）：船舶から開けた水面を挟んで 30 km 先の、高さ 30 m のマストにある 50 W の広帯域ジャマー。平均ジャマー対信号比（J/S）は約 48 dB で、可用性は 1.00 から 0.00 に落ちます。
  • scenarios/maritime-port-approach-coast.toml（ins-trn-coast）：12 ノットで航行する航法グレードの慣性航法システム（INS）で、GNSS を失い、補助なし。10 m には 281 秒後、100 m には 833 秒後に達します。これは国際海事機関（IMO）決議 A.1046(27) の、港湾進入と外洋の数値で、ここでは許容バジェットとして使います。
  • scenarios/maritime-spoof-position-push.toml（spoof-detect）：+2 dB の、搬送波に位相を合わせていないスプーファーが、四機の衛星を押して船を 500 m 引きずります。融合モニターは、受信機自律インテグリティ監視（RAIM）と信号品質監視（SQM）でこれを検出します（スコア 0.70、しきい値 0.50）。電力監視だけでは見逃します。
  • scenarios/automotive-urban-canyon.toml（gnss-ins）：15 秒のアンダーパスと 60 秒の路側ジャマーによる途絶を通過する自動車を、1.5 m の半車線バジェットに対して評価します。融合した途絶中の二乗平均平方根（RMS）誤差は、車載グレードの微小電気機械システム（MEMS）ユニットで 1.9 m、戦術グレードの比較対象で 0.7 m で、補正なしの場合、MEMS ユニットは 850.8 m までドリフトします。
  • scenarios/rail-tunnel-coast.toml（ins-trn-coast）：トンネル内を 160 km/h で走る列車の戦術グレードの INS。2 m（トラックの判別）には 35.8 秒後、約 1.6 km 進んだ地点で、20 m には 107.3 秒後に達します。これは INS のみの結果で、エンジンにはオドメーターのモデルがないため、悲観的な限界です。README のシナリオファイル数は 77 から 82 に変わります。五つとも kshana example 用に同梱され、ブラウザーのプレイグラウンドに一覧表示されます。

Model Context Protocol サーバー

• Model Context Protocol（MCP）サーバーは、すべての種別と、実行のすべてのビューに到達します。新しいツールが七つ加わり、合わせて十四個になりました。 run_scenario はすでにすべての種別をディスパッチしていました。エージェントに欠けていたのは、ある種別の有効なシナリオへの道筋と、コマンドラインが結果の隣に書き出す三つの出力でした。新しいツール：

  • list_example_scenarios と get_example_scenario は、同梱の参照シナリオ（kshana example の表）を、それぞれの種別と、そのヘッダーの最初の一文とともに提供し、内容は scenarios/ のファイルとバイト単位で一致します。リポジトリにあっても同梱されていないシナリオは、理由を添えて拒否されます。lunar-llr-datum（そのデータの一部はリポジトリにのみ含まれます）を除くすべての種別に、少なくとも一つの例があります。
  • report_scenario は、その実行のレポートを JSON（JavaScript Object Notation）、または印刷可能な HTML（HyperText Markup Language）ページ（docs/REPORTS.md）として返します。
  • animate_scenario は、その実行の時系列を、アニメーション付きの SVG（Scalable Vector Graphics）の描画、HTML プレーヤー、または番号付きのフレームとして、描画した内容の JSON 要約（docs/ANIMATION.md）に続けて返します。一つの応答に含まれるフレームは最大 120 です。コマンドラインは任意の長さを書き出します。
  • list_export_formats、export_interop、import_route は、相互運用エクスポートと GeoJSON のルートのインポート（docs/INTEROP.md）を提供します。対象は、CZML（Cesium Language）、KML（Keyhole Markup Language）、GeoJSON、STK（Systems Tool Kit）のエフェメリス .e、SigMF（Signal Metadata Format）で、ファイルの JSON インデックス（拡張子、サイズ、SHA-256、すなわち 256 ビットの Secure Hash Algorithm のダイジェスト）と、バイナリの SigMF サンプルファイルを base64 で添えます。

  ライブラリーに、既定でオフの bundled-scenarios 機能が加わり、参照シナリオの表を kshana::bundled_scenarios として公開します。これを有効にするのは MCP サーバーだけなので、Python ホイールと WebAssembly モジュールは、引き続きシナリオのテキストを含みません。スタディスイート（--study）は、スイートがディスク上のファイルを名指しするのに対しサーバーは何も読まないため、コマンドライン専用のままです。往復テストは、新しい各ツールを同梱のシナリオに対して実行し、エンジンの数値を検査します。対象は、スペクトル、太陽系、月とエウロパの周りのコンステレーション、キャンペーンのスイープ、そして低軌道（LEO）の信号、パス、航法メッセージ、融合測位、精密単独測位、非地上系ネットワーク、エンドツーエンドの各種別です。MCP のツール数を述べる、またはツールを列挙するすべての場所は、現在十四個と記載しています。ただし web/ 以下のプレイグラウンドのページは、サイトに置き換えられます。

kshana.dev、Kshana Studio、README

• 再設計した kshana.dev。単一のプレイグラウンドのページは、複数ページのサイトに置き換わりました。ホーム、ミッション、機能、エビデンス、開発者、エディション、ドキュメントで構成され、Kshana Studio へはワンクリックです。サイトのすべてのグラフ、マップ、数値は、このリリースのエンジンによる記録済みの実行で、シナリオと、同じ実行を Studio で開き直すリンクが付いています。サイトのビルドは、別のエンジンのコミットで作成された記録を拒否します。ドキュメントのページはリポジトリの docs/ から、インストールの選択肢はそのチャンネルから生成されます。フォントとスクリプトライブラリーは kshana.dev 自身から配信されるため、どのページもサードパーティのホストには何も要求しません。旧アドレス（/#playground、/#ledger、/#s=<scenario> の共有リンク、/?embed=1&… の埋め込みリンクなど）は新しい場所にリダイレクトされ、未知のアドレスは 404 ページになります。
• Kshana Studio：すべての機能のためのダッシュボード。Studio は、領域のタイルと最初に実行するのに適したものを並べたスタート画面で開き、実行を番号付きの五つのステップで進めます。シナリオを選ぶ、パラメーターを設定する、ブラウザー内でエンジンをローカルに実行する、結果を読む（主要な数値を先に、実行がしきい値を示す場合は各数値に PASS または FAIL のチップを付けて、その後にパネル）、共有またはエクスポートする、です。一つの検索ボックスで、シナリオ、領域、その中のフィールドを探し、コントロールへ移動できます。実行は固定して比較でき、パンくずリストが現在の場所を示し、スマートフォンではステップがステップバーになります。すべてのシナリオ種別に専用のビューがあります。スペクトルのウォーターフォール、太陽系、コンステレーションのカバレッジ、キャンペーン、アニメーション、実行レポート、相互運用エクスポート、低軌道のチェーンも含みます。ディープリンク（?scenario=…&tab=…）は、同じ実行を指定したパネルで開きます。
• 研究と引用。エビデンスのページには、arXiv にある五本の Kshana の論文（2606.22054、2606.24210、2607.02566、2607.05415、2607.06212）が、それぞれの要約、このエンジンで計算した図、それを再現するコマンド、Studio へのリンク、BibTeX とともに並び、さらにソフトウェアの引用方法も載っています。README にも、同じ研究のセクションが加わります。
• Kshana Pro の公開ページ。 docs/PRO.md とサイトのエディションのページは、プロプライエタリな Pro オーバーレイが、同じエンジンに何を加えるか（設計オプティマイザー、不確かさと感度、ミッションドシエ、キャンペーン監視、スペクトル共存、オンプレミスのジョブサービス、要求のトレーサビリティ）、それぞれが何を生み出すか、何をしないかを説明しています。サイトが示す Pro のすべての数値は、その公開ページに記載されています。Pro は物理モデルを追加せず、オープンなエンジンはそのまま、無償で提供され続けます。
• README を書き直しました。短いセクション、セクションごとに一枚の画像、Kshana のマーク、二行のバッジ、生成したアーキテクチャ、シナリオフロー、低軌道チェーン、検証の画像（古い画像で失敗する tools/gen_readme_assets.py）、そして tools/capture_studio_shots.mjs が実行中の Studio から撮影した Studio のスクリーンショットです。crates.io、PyPI、npm、MCP サーバーの README も同じデザインに従います。長い参考資料は、折りたたむか docs/ に移しています。

変更#

• <scenario>.report.html は、「追加」の項で説明した高度な実行レポートになりました。CLI の wrote … の行は、<scenario>.report.json も名指しします。置き換えられた一ページのスコアカードは、RunOutput::html_report() として変わらず、Python と WebAssembly のバインディングは引き続きこれを返します。OracleKind::modelled_reason() は、docs/MODELLED-RATIONALE.md が MODELLED の各行に対して表示する文を公開します。その文書は変わりません。
• README が、Kshana Pro が何の上に成り立っているかを説明するようになりました。「Support & professional services」の下のエディションのセクションと Kshana Pro の行が、Pro のモデルベースシステムズエンジニアリング（MBSE）とプログラムのツールが何をするか、オープンなエンジンの公表された出力のうち何を読み取るか（各実行の result.json と report.json、シナリオファイル、フィールド単位スキーマ、検証マトリクスのラベル）、そして時計のデジタルツイン、トレードスタディ、エビデンスパックが、オープンなエンジンの何に支えられているかを説明するようになりました。文言のみの変更で、エンジンの出力も公表した数値も変わりません。
• 互換性。公開の列挙型 navsignal::Modulation に Mboc のバリアントが加わります。これを網羅的にマッチさせている呼び出し側にとっては、破壊的変更です。ephemeris 種別の gcrs_r_m と gcrs_v_m_s の列が変わります（「公表した数値の改訂」を参照）。実行は、それを作ったエンジンのバージョンで引き続き再現されます。

修正#

• MCP サーバーの export_table_csv は、CSV（コンマ区切り値）の表を持つのは四つの種別だけとしていましたが、実際には六つが公開しています。このツールは、telecom-timing と leo-navmsg（kepler16 または kepler-rac のメッセージモデルでの encode-decode 解析）については常に表を返していましたが、その説明、拒否メッセージ、種別を列挙するドキュメントは、この二つを載せていなかったため、エージェントは求めないよう伝えられていました。現在は両方が明記され、往復テストが両方の表を取得します。

• 低軌道（LEO）の航法メッセージのフレームは、プラットフォームごとにバイト列が異なり、同じプラットフォームでもビルドごとに異なっていました。 scenarios/leo-navmsg-encode-decode.toml は、aarch64 macOS のリリースビルドではフレームを巡回冗長検査 0x110315 で符号化し、同じマシンの同じソースのデバッグビルドでは 0x898BD8、WebAssembly（WASM）ビルドでは 0x6A82D9 でした。leo-navmsg-celeste-iod.toml は、ネイティブで 0x6EDB2D、ブラウザーでは 0xC6E4F0 でした。原因は三つで、それぞれ、最初に食い違った値までたどりました。

  • プラットフォーム間。真値の軌道は両方でビット単位で同一でしたが、フィットの開始点は異なっていました。truth::state_to_elements は、接触軌道傾斜角を acos から、近地点引数を atan2 から求めますが、二つの数学ライブラリーは、これらを最終桁で異なる丸め方をします（20,000 個の引数のうち、サインで 781 個、コサインで 858 個、指数関数で 1,931 個、二引数アークタンジェントで 1,899 個が一致しません）。
  • ビルドプロファイル間。macOS の最適化ビルドは、一つの引数のサインとコサインを、システムの複合ルーチンへの一回の呼び出しにまとめ、そのサインは、200,000 個の引数のうち 379 個で、単独の sin のものと一致しません。最適化なしのビルドは、二回の呼び出しを行います。この種別は、サインとコサインを一緒に取る箇所が十三か所あります。
  • クロック内。rand_distr の正規分布サンプラーは、まれに通る二つの分岐で、ホストの exp と ln を呼び出します。シード付きの四百万回の乱数のうち、ネイティブビルドと WASM ビルドとで最終ビットが異なったのは三回でした。

  Levenberg–Marquardt のフィットは、この弧では最小値ではなく 80 回の反復の上限で止まるため、最終桁の一単位が、異なる量子化フィールドに持ち込まれます。この種別は現在、すべての超越関数を新しい src/portable_math.rs 経由で計算します。これは純粋な Rust の libm クレート（すでに依存関係ツリーにあり、現在は Cargo.toml に明記）を呼び出し、すべてのターゲットに対して一つのソースからコンパイルされ、オプティマイザーが書き換えるライブラリー呼び出しではありません。対象は leo_navmsg::{truth, fit, elements, codec, sisre, services} とシナリオのコードです。この経路の整数のべき乗は、f64::powi の精度が未規定のため、二乗と乗算の繰り返しとして書き下し、真値のクロックは、正規乱数を portable_math::standard_normal（ジェネレーターの生の出力に対する Marsaglia の極座標法）から引きます。真値の軌道が積分に使う共有ルーチン、すなわち球面調和関数の加速度、帯状項と抗力の加速度、J2 の永年変化率、Klobuchar の遅延は、数学ライブラリーに対してジェネリックに一度だけ書かれ、既存のエントリーポイントの隣に、クレート内部の _portable エントリーポイントを備えます。既存のエントリーポイントは最終ビットまで変わらないため、他の種別の数値は動きません。leo_navmsg::tests::the_encoded_frame_is_the_same_bytes_on_every_platform は、171 バイトのフレーム全体と、エフェメリスモデルごとに一つのチェック値を、通常の（最適化なしの）テストプロファイルで、すべてのプラットフォームで、基準ホストによるゲートなしに固定します。the_kind_never_calls_the_host_mathematics_library は、この種別のソースをディスクから読み、本質的な超越関数の呼び出し、rand_distr のサンプラー、またはレビューされていないモジュールへの呼び出しがあれば失敗します。この変更の後、デバッグビルド、リリースビルド、WASM ビルドは、五つの leo-navmsg シナリオすべてについて、バイト単位で同一の結果文書を生成します。これは数値を動かすため、改訂としてここに記録します。leo-navmsg 種別はこのリリースで新しいため、以前のリリースで公表した数値は動きませんが、leo-navmsg のすべての数値が、ネイティブと WASM ビルドの両方で変わり、leo-pnt-chain の navmsg ステージも変わります。軌道の数値は、フィットが移植可能な軌道要素から始まるようになったため、クロックの数値は、真値のクロックが同じ過程の別の実現になったためです。docs/LEO-NAVMSG.md は新しい結果から再生成されました。エンコードとデコードのシナリオについて公表していたチェック値は 0x110315 でしたが、0x19105F になります（位置は正確なメッセージから 1.126 mm 以内で、以前は 0.665 mm、クロックは 0.185 mm 以内で、以前は 0.451 mm）。ミリメートル未満の数値の変化の大きさは、フィットの感度であり、どちらの結果の誤りでもありません。フィットは変わっておらず、依然として反復の上限で止まります。

• シード付きリサンプリングは、32 ビットのターゲットでは異なるインデックスを引いていました。 usize に対する Rng::gen_range は、ジェネレーターから 64 ビットのホストでは 64 ビット、32 ビットのホストでは 32 ビットを取るため、同じシードでも別のインデックスになり、WASM ビルドでは他の場所のストリームの位置もずれていました。この引き方をしていたのは三か所です。eval_stats のパーセンタイルブートストラップ（bootstrap_ci、bootstrap_auc_ci）、impairment_ml の各学習パスの前のシャッフル、そして impairment_study の順列検定です。現在は portable_math::uniform_index を通して引き、これは常に u64 としてサンプリングします。64 ビットのホストがしていたことと正確に同じなので、ネイティブの数値は動きません。これは WASM パッケージの公表した数値を動かすため、改訂としてここに記録します。quantum-anomaly-detect の曲線下面積のブートストラップ区間（quantum_auc_ci、trade.foms[0].ci95）は、ブラウザーでは [0.9901265, 0.9938305] でしたが、現在はネイティブの [0.99035875, 0.993861] です。

• mover ID から作る STK エフェメリスのファイル名。/ またはスペースを含む mover ID（コンステレーションのシェルと衛星、Pulsar inclined/S1-0163）が、--export stk で CLI をパニックさせていました。現在、各 ID は安全なファイル名の部分（英字、数字、-、_）を通します。

• TEME→GCRS の章動の符号は、公表した出力を動かすため、上の「公表した数値の改訂」に記載しています。

0.28.0 - 2026-09-26#

追加#

• slot-timing シナリオ種別（src/slot_timing.rs）：自走する時計が、時刻に基づく経路設定またはタスク割り当てのスロットのガードから外れるまでの秒数、その時点で寄与しているすべての項（支配的な項を明記）、最後の測位からの残り時間、そして測位の遅延を差し引いたうえで時計をスロット内に保てる最大の測位間隔を求めます。時計は、クラスの既定値、通信タイミングのデータシートのプリセット、インラインのデータシート（アラン偏差の最大値、エージング、温度係数）、または実測の位相記録のいずれかから与えます。ソースが対応する最長の平均化時間を超える逸脱は、外挿として明示されます。同梱の例：slot-timing-ocxo-leo。docs/SLOT-TIMING.md を参照してください。
• 実測の赤色雑音フロア。位相記録の重なりアラン偏差を、ホワイト位相と IEEE Std 1139 の周波数変調基底（slot_timing::fit_weighted）で重み付き最小二乗法により当てはめます。各点には等価自由度に応じた重みを付けるため、ホールドオーバーの答えをクラスの仮定ではなく、その時計自身のフロアに基づかせることができます。重みなしの当てはめでは、ホワイトノイズの試験記録に偽のフリッカーフロアが生じ、2,000 秒の逸脱が 30 % 短くなりました。
• 実際の時計でのホールドオーバー逆算のホールドアウト検証（tests/slot_timing_cs5071a_holdout.rs）：5071A セシウム対水素メーザーの記録の最初の三分の一で当てはめたところ、0.5 ns から 2.5 ns までの六つのしきい値での一シグマ逸脱の予測は、残り三分の二で実測した逸脱の 0.84 倍から 1.03 倍の範囲に収まりました。基準は、試験の初回実行前に固定した 1.5 です。対照（一秒のアラン偏差をホワイトノイズとして読んだもの）は約 1,000 倍外れ、基準を満たしません。台帳に VALIDATED の行を新たに追加し、realdata-clock ワークフローがこれを実行するようになりました。
• 実際の水晶発振器での同じ予測（tests/slot_timing_ocxo_holdout.rs、scripts/fetch_ocxo.sh）：実測の恒温槽付き水晶発振器では、ホールドアウトの予測は保守的で、実測の逸脱の 0.59 倍から 0.70 倍となり、実測より遅くなることはありません。ただしその多くは 1.5 の基準の外にあります。この発振器のノイズフロアが5.5時間の記録中に半分になったためです。標本内で当てはめると 0.98 倍から 1.17 倍に収まります。水晶の場合は独立した外部の参照で確認されておらず、MODELLED のままです。この実行では、欠けていた項も見つかりました。水晶の周波数はふらつくため、モデルは測位時点で既知の周波数の不確かさ（fix_frequency_sigma）を持つようになりました。これがないと、予測は最大 2.5 倍まで楽観的でした。
• 軌道上の原子時計での同じ予測（tests/slot_timing_igs_holdout.rs、scripts/fetch_igs_clocks.sh）：GPS Block IIF 衛星について、国際 GNSS 事業（International GNSS Service）の最終クロック 14 日分を使い、データをダウンロードする前に手順を書き下ろしています。十機中八機は 1.5 の基準内に収まり、G25 と G30 は、実測より最大で約二倍遅い逸脱を予測しています。手順はすべての衛星が合格することを求めているため、軌道上の場合は独立した外部の参照で確認されておらず、MODELLED のままです。結果は固定されています。
• 温度補償水晶発振器（TCXO）、恒温槽付き水晶発振器（OCXO）、ルビジウム原子周波数標準（RAFS）の各時計クラス（ClockClass::Tcxo、Ocxo、Rafs）：商用の小型衛星バスや地上ゲートウェイが搭載する部品で、それぞれ公開データシート一点を出典としています（ClockClass::source）。ClockClass::ALL、id、from_id を追加しました。quantum-trade の baseline_clock_class は、三つの新しい id を受け付けます。公開 enum にバリアントを追加することは、それを網羅的にマッチさせている呼び出し側にとって破壊的変更です。
• 軌道上の受信機のタイミング保護レベル（src/orbital_timing.rs、slot-timing 種別の任意の spoofing セクション）：地上のスプーファーが低軌道衛星に一回の通過で到達できる時間、指定した最大ランプ速度のスプーファーが、衛星がその到達範囲を離れるか独立した確認が行われるまでに蓄積する引き込み量、そして各地上コンタクトまたはクロスリンクの確認がそのスプーファーから独立しているかどうかを求めます。フリッカー、ホワイト位相、ランダムランのいずれのノイズもない時計では、tpl::timing_protection_level_ns と完全に一致します。MODELLED。
• 三つのノート：docs/SLOT-TIMING.md（スロットをどの揺らぎ指標で受け入れるべきか、すなわち最大時間間隔誤差や時間偏差ではなく最大絶対時刻誤差である理由を含む）、docs/DECEIVED-TIME.md（欺かれた時刻に適用された署名付きコマンドは、依然として誤った経路に送られます）、docs/DEPLOYMENT-TARGETS.md（Kshana が動作する場所。no_std のフライトコアは提供しません）。

0.27.4 - 2026-09-26#

v0.27.3 リリースは crates.io（kshana と kshana-mcp）と PyPI には届きましたが、npm で止まったため、npm、ghcr.io の MCP イメージ、MCP レジストリ、JetBrains Marketplace、kshana.dev には届きませんでした。0.27.4 は同じエンジンに下記のリリース修正を加えて、すべてのチャネルに届けます。

修正#

• npm の公開ステップは、tarball を明示的なパスで指定するようになりました。npm は、接頭辞のない npm-dist/kshana-0.27.3.tgz を GitHub の短縮記法 owner/repo として読むため、v0.27.3 の npm ジョブは github.com/npm-dist/kshana-0.27.3.tgz をクローンしようとして、"Permission denied (publickey)" で失敗しました。tarball 自体は構築され、証明されていました。ステップは現在 ./npm-dist/*.tgz を公開します。リリース順で npm より後のすべて（MCP イメージ、JetBrains プラグイン、チャネル同等性チェック、サイト）は、設計どおりスキップされました。

変更#

• 通信タイミングと gnss-ins の単位カタログは、コピー＆ペースト検出の対象外です。他のカタログと同じ方針と正当性の検証に従っています。SonarCloud の品質ゲートは、新規コードの重複（3 % に対して 4.0 %）で赤になっており、重複していたブロックはすべて単位の行か ITU-T マスクのエントリーでした。

0.27.3 - 2026-09-25#

追加#

• scenarios/small-uas-jammed-nav.toml：GNSS がジャミングされた後、小型ドローンの航法がどれだけ持つか。フライトコントローラークラスの微小電気機械システム（MEMS）慣性ユニットである Bosch BMI088 を、戦術級ユニットと比較して実行します。GNSS（全球測位衛星システム）の信号は 100 秒間は正常で、その後 60 秒間は妨害されます（近くのジャマーがそうなる理由は jamming-demo.toml で示しています）。BMI088 のバイアスは、起動時のキャリブレーション後に残る残差で、データシート（BST-BMI088-DS000-19 rev 1.9）の温度係数から求めています。ジャイロは 0.015 °/s 毎 K、加速度計は < 0.2 mg 毎 K です。ファイルには2つの仮定が明記されています。キャリブレーション後の 10 K のウォームアップと、飛行中の毎分 1 K の継続的な昇温です。飛行中のドリフトは、ジャミング開始前にフィルターが学習できない誤差であり、これが慣性航法による惰行を終わらせます。数値はすべてモデルによるものです。これを検証するには、ジャミング環境での飛行ログが必要です。kshana example small-uas-jammed-nav で表示できます。

• 各 gnss-ins センサーは、独自のフィルター事前分布を設定できます（[imu_quantum.filter_prior] または [imu_classical.filter_prior]、sigma_accel_bias と sigma_gyro_bias を指定）。既定値は変わらないため、既存のシナリオはすべて同じ結果になります。民生用ユニットの残留ジャイロバイアスは、戦術級の既定値の外側約 26 シグマにあり、フィルターはこれを学習できません。有限かつ正でない事前分布は拒否され、事前分布が設定されている場合、結果にはそれがそのまま出力されます。

• kshana example [<name>] は、レジストリのユーザーに実行できるシナリオを渡します。cargo install kshana のユーザーは実行ファイルだけを持ち、scenarios/ ディレクトリは持たないため、どのクイックスタートでも最初のコマンドが失敗していました。コマンドラインインターフェース（CLI）は現在、単独で実行できる 75 件の参照シナリオを、バイト単位で同一のまま scenarios/（src/bundled_scenarios.rs）からコンパイルして組み込んでいます。表は CLI バイナリ内にあるため、Python ホイールと WebAssembly モジュールは大きくなりません。kshana example でそれらを一覧し、kshana example clock-holdover > clock-holdover.toml で一件を書き出せます。残りの二つのファイルはリポジトリ専用です。lunar-llr-datum はリポジトリにのみ同梱されるアーカイブ済みの月レーザー測距データを読み込み、quantum-pnt-demonstrator.suite は --study で三つの兄弟ファイルを実行するスタディマニフェストです。どちらかを指定すると、単独では実行できないものを出力する代わりに、理由を示して 2 で終了します。tests/cli_first_run.rs は、この表をディレクトリと双方向で突き合わせて保持するため、組み込まれてもおらずリポジトリ専用とも指定されていない新しいシナリオファイルは失敗します。

• 時計、軌道、ハイブリッド、フュージョンの結果にある性能指標のすべてが、VALIDATED か MODELLED かを、結果そのものの中で示すようになりました。結果ドキュメントには figure_tiers ブロックが加わり、常に最後のキーになります。ここには、報告される各数値（例：quantum.fom.timing_p95_ns）とそのティア、およびティアの読み取り元である検証マトリクスの行が列挙されます。VALIDATED は独立した外部のオラクルと照合して確認済みであること、MODELLED は内部でテストされた第一原理モデルであることを意味します。ティアは src/verification.rs から src/fom_label.rs を通じて得られるため、ずれていく第二の表はありません。これ以前は、時計ホールドオーバーの結果に「検証済み」や「モデル」という語が一度も現れず、生の JSON（JavaScript Object Notation）を読む人には両者を区別する手段がありませんでした。hybrid と fusion の位置の数値には担当するマトリクスの行がないため、ティアを付けずに untiered の下に列挙されます。このブロックに数値は含まれません。これは仮定ではなく、加算的であることが証明されています。ブロックを取り除くと、五つの種別すべてで変更前のドキュメントがバイト単位で復元され（エンジンテスト）、二つのゴールデンハーネス（tests/registry_golden.rs、tests/cross_platform_golden.rs）は、このキーだけを、それが最後のキーである場合に限って取り除き、残りを変更されていない固定済みの定数に対してハッシュ照合します。どのシナリオがこのブロックを持つべきかは各ハーネスのリストで固定されているため、除外が気づかれないうちに広がることはありません。

• telecom-timing 種別は、タイミング技術者が使う単位（時刻誤差、最大時間間隔誤差（MTIE）、時間偏差（TDEV））で答えを返し、それぞれについて国際電気通信連合 電気通信標準化部門（ITU-T）のマスクに対する PASS または FAIL と余裕を示します。マスクは、現行版から転記しています。プライマリ基準時刻クロック（PRTC）クラス A と B には G.8272（07/2025）、ロックモードとホールドオーバーでの拡張 PRTC には G.8272.1（2024）Amd. 1（07/2025）（クロックがロックされていた時間で決まるホールドオーバー期間にわたって 30 ns から 100 ns に上昇する時刻誤差エンベロープを含みます）、通信用バウンダリークロックとタイムスレーブクロックのクラス A から D には G.8273.2（2023）Amd. 2（11/2025）、基準点 C でのネットワーク限界には G.8271.1（2022）Amd. 3（05/2025）を使います。これらの勧告が「今後の検討課題」としている項目はすべて、推定せずに除外してあり、docs/TELECOM-TIMING.md は各数値をその表または項とともに列挙し、除外した項目も挙げています。レポートには、各時刻誤差バジェットを超えるまでの時間も示します。既定では、100 ns の ePRTC ホールドオーバー既定値、400 ns のネットワークホールドオーバー割り当て、1,100 ns の基準点 C 限界、1.5 マイクロ秒のクラス 4 エンドツーエンド要件です。

  入力は、合成のホールドオーバーか、ご自身の系列のいずれかです。合成のものは、恒温槽付き水晶発振器、ルビジウム標準、セシウム標準、チップスケール原子時計の四つの発振器プリセットから一つを使い、各プリセットは Microchip の特定のデータシートにある安定度、エージング、温度の数値を持ちます。これらの数値がどのようにホワイト、フリッカー、ランダムウォークの周波数雑音、エージング、温度項になるかは、すべてのレポートに明記され、MODELLED と表示されます。ご自身の系列は [time_s, time_error_ns] のペアで、インラインで与える（ブラウザーではこの方法で実行されます）か、ネイティブビルドではカンマ区切り値ファイルから読み込みます。選択した各マスクの限界値を並べた MTIE/TDEV の表は、実行の CSV 成果物として書き出されます。

  scenarios/telecom-prtc-holdover-24h.toml は、エージング、フリッカー、日周の温度変化を含む24時間のルビジウムホールドオーバーです。最大の時刻誤差は 603.2 ns で、喪失から 8,206 秒後に 100 ns を超え、終日 1.5 マイクロ秒以内にとどまり、セシウムクラスではない時計の当然の結果として、拡張 PRTC のホールドオーバーエンベロープには適合しません。scenarios/telecom-tie-ingest.toml はインライン入力を示します。この種別が報告する MTIE と TDEV は、コミット済みの 2 048 標本のホールドオーバー系列で allantools パッケージと照合しており、MTIE は完全一致、TDEV は 1.1e-15 の範囲で一致します。このためマトリクスには VALIDATED の行が一つと MODELLED の行が二つ（マスクの転記とプリセット）増え、現在は171 行（65 が VALIDATED、102 が MODELLED、4 が PARTNER）です。フィールド単位の網羅率は、61 種別中 60 種別から 62 種別中 61 種別になり、記述済みフィールドは 1,742 から 1,788 になりました。この種別は新規かつ加算的であり、既存のシナリオ、固定値、公表済みの数値は動きません。

• プレイグラウンドは、エンジンをバックグラウンドの Web Worker で実行するため、処理の遅いシナリオでもページが固まらなくなりました。 web/engine-worker.mjs が WebAssembly エンジンをホストし、web/engine.mjs が、実行、パラメーター掃引、SP3 / OMM / OEM / CSV のエクスポートといったすべてのシナリオ実行をそこへ転送します。150 ms を超える実行では、ビジー状態（Run を無効化し、「実行中… N 秒」と表示）と、ワーカーを終了して再起動する「キャンセル」ボタンが表示されます。モジュールワーカーを起動できないブラウザーは、従来のメインスレッド方式に切り替わります。cislunar-arc-recovery は、ページが固まるためカタログから外していましたが、低速と明記したうえで戻しました。Chrome では約 13 秒かかり（約 3 秒のエンジン呼び出し四回）、その間もページは応答し続けます。

• cislunar-observability が報告するすべての量に、単位、出所クラス、定義が付くようになりました。クレート全体の除外リストに残っていた最後から二番目の種別です。公開済みドキュメントの 41 個の数値フィールドをすべて記述したため、フィールド単位の網羅率は 61 種別中 59 種別から 61 種別中 60 種別になり、記述済みフィールドは 1,698 から 1,742 になりました。定義のないバックログは 239 のまま変わりません。

  これまでは、公開済みドキュメントを固定するピンが妨げていました。そのピンは units を、ドキュメントが決して持ってはならないキーとして指定していたのです。追加するには、そのアサーションを削除し、三つのファイルにある三つのハッシュを再基準化することになり、回帰の隠蔽と区別がつかない形になります。そこで、このドキュメントを測定する二つのピンは、追加が加算的であることを証明するようになりました。それぞれが units ブロックを取り除いて、ブロックが存在する前に固定された定数に対して再ハッシュし、両方の定数は変更されていません。ミューテーションにより、この保証が本物であることを確認しています。公開済みの値を動かし、不注意な修正のようにドキュメント全体のハッシュを再基準化しても、取り除いて再ハッシュする検証は失敗します。汎用レジストリゴールデンハーネスにある三つ目のピンは、まったく同じ理由で再基準化された六つの兄弟に合わせて再基準化され、値を持つ expect_summary リテラルは動きません。

• realtime-frame-eop は、各地球姿勢の行をどの真値に対して採点したか、およびフォールバックが何回働いたかを報告します。 table3_joint_eop[].{ut1, polar_motion,combined} は truth_source と truth_fallback_rows を備えるようになりました。final フロアは Bulletin B の確定値に対して採点され、それを公表しているエポックしか使えません。すべての dN の行は truth_pm()/truth_ut1() に対して採点され、これらは Bulletin A の速報値にフォールバックします。同梱の 2026 年の抜粋では、一日先で 31 標本中 12 標本がそれに当たり、フロアでは 0 です。つまり、フロアの行とその隣の予測の行は、測定可能なほど異なる真値に基づいており、入れ子の予測期間ではあり得ないほど増えていく標本数から推測させるのではなく、レポートが明示するようになりました。

• moonlight-service-volume は、数を合わせたケプラーのベースラインを出力します。 ephemeris_comparison.keplerian_matched は、例示用コンステレーションを、取得済み（RETRIEVED）セットの衛星数で再実行します。これは、数が異なる場合にのみ現れます。衛星数はその設計の幾何の一部であり、RAAN と平均近点角はどちらも 360k/n として分散されます。そのため、これがなければ、五機の取得セットが八機の例示用セットに対して採点され、設計と規模が混同されていました。五機の LANS 参照セットでは、14.24 ポイントのカバレッジ差のうち、8.68 が不足する三機によるもので、設計によるものは 5.56 ポイントにすぎないことが分かりました。実際に月軌道にある四機の宇宙機では、専用に作った四機のセットは 4.86 % に達しますが、実機は 0 % です。テストにより、数を合わせた行は、設定済みのものを名前だけ付け替えたものではなく、再構築されたコンステレーションであることを固定しています。これは当初の書き方であり、その実行結果が報告していたことでもありました。

• 公開サイトに九枚の機能カードを追加し、製品レベルのカードがないまま出荷されていた 22 件の検証マトリクス行を網羅しました。エンジンには、公表済みの Working Group C 参照ベクトルに対する ARAIM チェック、実際に取得した月コンステレーションの幾何、測定した C/N₀ 帯域を伴う月の妨害コンター、VLBI スケジュールから局共分散への段階、クロスモダリティの故障注入を伴う光と RF のハンドオーバー、アーカイブ済みの Bulletin A に対するリアルタイム地球姿勢予測、航法と通信のアパーチャ共有、INS/TRN の惰行、単位と出所の網羅という機能群が育っていました。いずれもマトリクスの行と同梱シナリオを持ちながら、kshana.dev では一切名前が挙がっていませんでした。カードと行の対応は、168 行中 72 行から 94 行になりました。

• プレイグラウンドのカタログに八つのシナリオを追加しました。機能カードの Run ボタンは、web/app.js にもそのファイルがある場合にだけ表示されます。六枚のカードは、そこにないシナリオを指していたため、実行する手段がないまま表示されていました。そのうち一枚（実際のレーザー測距の基準点）は、出荷時からその状態でした。tests/scenario_examples_doc_sync.rs は、この不変条件を両面で検証するようになりました。カードの run の対象は、scenarios/ の下に同梱されていて、かつカタログで提供されている必要があります。両方の失敗モードに対してミューテーションテストを行っています。

• moonlight-service-volume は、エクスポート地点が設定されている場合、衛星ごとの幾何を <scenario>.table.csv として出力します（G11）。公開される配列としてはクレート内で最大で、公開済みの通信・航法統合表では 2304 行あり、これまでは JSON の中でしか利用者に届いていませんでした。その形式は、兄弟シナリオの57点の曲線を、すべての点を含むと称する列の下で 23 点に切り詰めたものと同じです。リンクごとに一行、ヘッダー行に行数を記し、アンテナの列はアンテナが設定されている場合にのみ含まれます。エクスポート地点なしの実行はバイト単位で変わらず、ファイルも書き出しません。

• SBOM は、出荷されるものを正しく記述するようになり、60 個だったコンポーネントは 66 個になりました。 scripts/gen-sbom.sh は、開発依存関係を含め、既定機能の解決結果にあるすべてのパッケージを列挙していました。このため、sgp4 と chrono（テスト専用で、どの成果物にもコンパイルされないクレート）が部品表に入り、PyPI ホイールがリンクする --features python のチェーン（pyo3、pyo3-ffi、pyo3-macros、pyo3-macros-backend、pyo3-build-config、portable-atomic、target-lexicon、heck）が抜けていました。これはそのホイールの外部関数境界にあたります。スクリプトは現在、kshana パッケージから通常エッジとビルドエッジだけをたどって解決グラフを歩き、既定、python、wasm の機能セットの和集合に対して、すべてのターゲットプラットフォームで実行します（npm パッケージにも同じ SBOM が入っています）。固定されている CycloneDX 適合判定は、コミット済みのジェネレーターを通じて再基準化されています。コンポーネントは 60 → 66、複合ライセンス式は 53 → 60 となり、これらを標準の expression 形式に置けば、スキーマエラーは引き続きゼロです。

• CSV 再現性テーブルは、CLI と Python ホイールだけでなく、すべての入口に届くようになりました。MCP サーバーには七番目のツール export_table_csv が加わりました。シナリオを実行し、CLI が <scenario>.table.csv として書き出すバイト単位で安定したテーブルを返します。テーブルを公開しない種別の場合は、公開する種別（realtime-frame-eop、lunar-time-budget、lunar-jamming、および export_site_lat_deg + export_site_lon_deg が設定されている場合のみ moonlight-service-volume）を示すエラーを返します。WebAssembly モジュールには table_csv が加わり、同じテキストか undefined を返します。MCP のラウンドトリップテストと Python バインディングのテストは、返された CSV を tests/golden/realtime-frame-eop.csv に対してバイト単位で固定するようになり、RunOutput.write_csv が書き込んだバイト数を返すこと、およびテーブルのない種別ではファイルを作らずに 0 を返すことも固定します。MCP ツールの数を述べる、またはツールを列挙するすべての面で、現在は七と記載しています。

• WebAssembly モジュールの run_all：一回のエンジン実行ですべての出力を得ます。 run、chart_svg、summary、table_csv は、それぞれシナリオを最初から実行するため、プレイグラウンドはクリックごとに四回分の完全な実行コストを払っていました。ブラウザーでの cislunar-arc-recovery では、3 秒ではなく約 12 秒です。run_all は一回の実行から {json, svg, summary, csv} を返し、プレイグラウンドはこれを使うようになりました。四つの個別の呼び出しとバイト単位で一致します。

修正#

• 改訂：GNSS/INS フィルターのジャイロバイアス結合の符号が誤っていたため、gnss-ins の途絶時の数値が変わります。誤差状態の拡張カルマンフィルター（EKF）は、両方の慣性バイアスを残差（真値から現在の推定値を引いたもの。加算でフィードバックされます）として保持します。加速度計の列は速度誤差を +C_b^n b_a で駆動していましたが、ジャイロの列は姿勢誤差を −C_b^n b_g で駆動していました。ジャイロバイアスの残差は、実際には計算上の姿勢を +C_b^n b_g だけ回転させるため、ジャイロバイアスの推定値はすべて誤った向きに押していました。パックが安定していたのは、既定のジャイロバイアス事前分布（1e-4 rad/s、1シグマ）が、それらの状態を動かさないほど狭かったからにすぎません。事前分布を広げると、真のジャイロバイアスがゼロであってもフィルターは発散しました。融合後の途絶誤差 93 m が 4.3 km になったのです。scenarios/gnss-ins.toml の公表済みの数値は次のように変わります。

  gnss-ins.toml	変更前（≤ 0.27.2）	変更後
  コールドアトム IMU、融合後の途絶 RMS	96.1 m	1.9 m
  コールドアトム IMU、仕様内の惰行（50 m）	30 秒	60 秒（途絶の全期間）
  戦術級 IMU、融合後の途絶 RMS	62.5 m	3.1 m
  戦術級 IMU、仕様内の惰行（50 m）	37 秒	60 秒（途絶の全期間）

  自走の数値（130.7 m と 314.3 m）は変わりません。これらはフィルターを使っていなかったためです。融合後の惰行は引き継ぎ時の姿勢フロアに制限され、より良いセンサーでも改善しない、というパックの以前の解釈は、このバグによる見かけ上のものであり、撤回します。バイアスが一定でノイズがない場合、GNSS が使える間にフィルターがそれらを学習するため、融合後の惰行は最良の場合の値です。外部の filterpy 参照（tests/gnss_ins_sensor_fusion_reference.rs）は測定更新しか確認しないため、伝播を見つけられませんでした。現在は二つのテストが符号を直接確認しており、どちらも旧版では失敗します。一つ目は closed_loop.rs にあり、既知の残留ジャイロバイアスをストラップダウンに通し、フィルターが結果として生じる姿勢誤差を 2 % 以内で予測することを求めます。二つ目は、広い事前分布が 1e-3 rad/s のジャイロバイアスを学習し、6 m 以内にとどまることを求めます。gnss-ins のクロスプラットフォームのゴールデンは、この理由のためだけに再固定されています。

• レジストリのクイックスタートはすべて、クリーンなマシンで記載どおりに動くようになりました。この変更の前に測定したところ、crates.io と PyPI（Python Package Index）の例は、レジストリからのインストールにはない scenarios/clock-holdover.toml を読み込んでおり、npm の例は、パッケージの init() が WebAssembly バイナリを fetch で取得するのに対し、Node の fetch はローカルファイルを読めないため、Node.js 上で TypeError: fetch failed によりクラッシュしました。現在は次のとおりです。

  • README.crates.md と README.pypi.md は、README.npm.md がすでにそうしていたように、そのシナリオをインラインで持ちます。Rust のコードフェンスは、独自の main を持つプログラム全体です。これまでは末尾の rustdoc で隠された # Ok::<…> の行が crates.io に表示され、貼り付けるとコンパイルできなかったためです。tests/readme_code_fences_doc_sync.rs は引き続きこれをバイト単位でコンパイルし、現在はフェンス内の隠し行も拒否します。
  • README.npm.md は、ブラウザーと Node.js を分けて、ディスクからバイナリを読み込んで initSync に渡す Node 用のレシピを示します。doc-sync テストは、wasm-bindgen が生成するローダーとして initSync を受け付けます。
  • 三つとも、出所を示す文字列を省略せずにシナリオを埋め込んでいるため、シナリオのハッシュはどの面でも 5ba83a232b94 になります。npm の例はこれまで文字列を省略しており、CLI とは異なるハッシュになっていました。
  • このツリーのローカルビルドで再現しました。パッケージ化されたクレートへのパス依存を持つ新規の cargo new プロジェクトは、Rust の例をビルドして実行しました。パッケージ化されたソースから maturin でビルドしたホイールを新しい仮想環境にインストールすると、Python の例が動きました。wasm-pack --target web パッケージは、npm でパックしてインストールし、Node のレシピを実行しました。三つとも同じ要約行を出力しました。

• cargo run -- <scenario.toml> は、クローンからそのまま動作します。 Cargo.toml が default-run = "kshana" を設定します。これがないと、cargo は「could not determine which binary to run」と言って実行を拒否し、ドキュメント中のすべての cargo run -- の行がこれに当たっていました。

• CLI の最初の一分間のエラーは、次に何をすべきかを示すようになりました。存在しないシナリオのパスには、kshana example を指すヒントが加わり、二番目の位置引数では、その引数名に加えて使い方のテキストも出力されます。--help、--version、不明なオプションのエラー（終了コード 2）、および成功時の --validate の一行 ok: は、すでに main にありました。これらのどれについても、これまでバイナリを実行するテストがなかったため、tests/cli_first_run.rs がそのすべてを対象とするようになりました。

• Python の list_kinds() は、リストではなく一つの JSON 文字列を返すものとして文書化されました。これは scenario_kinds() と同じメタデータをシリアライズして返すため、反復すると文字を一つずつたどることになります。既存の呼び出し側が壊れないよう、文字列を返す仕様は維持されます。kshana.pyi、バインディングのドキュメントコメント、docs/PYTHON_API.md、README.pypi.md にその旨を記載し、scenario_kinds() を案内しています。

• 三つのレジストリ README は、すべての略語を初出で展開するようになりました。PNT は最初に現れるタグラインで展開され、CLI、TOML、JSON、SVG、CSV、CSAC、HTML、URL、API はそれらを使うファイルで展開されています。オラクル表の見出しは、CI を定義する前に「CI-gated」と書かなくなりました。

• 公表済みの数値を訂正しました。同梱した Celestrak の GPS + Galileo の TLE における、二つのコンステレーションを用いた ARAIM の可用性です。 docs/CAPABILITY.md は、Galileo を併用すると、12 m の VAL で可用性が 0.21 から 0.67 に上がること、そしてコンステレーション故障に頑健なモードは二つのコンステレーションだけでは制限されることを述べていました。これは tests/araim_dual_real_data.rs が各衛星をそれぞれの TLE エポックから伝播させていたためで（parse_propagators はエポックを捨てます）、これらのファイルのエポックは 70.6 時間（GPS）と 335.7 時間（Galileo）にわたっており、衛星同士が互いに矛盾する時刻にありました。テストは現在、各エポックを保持し（parse_tle）、すべての衛星を、セット内で最新の TLE エポックである共通の UTC 時刻（2026-06-07T07:21:04）で評価します。同じ 24 時間、289 標本のグリッドで測定した可用性は、GPS のみで 0.993（以前は 0.208）、併用で 1.000（以前は 0.671）、コンステレーション故障に頑健な二系統で 0.990（以前は 0.031）となり、APV-I の限界では、二系統モードが 0.180 から 1.000 になります。結論は逆転します。整合した空であれば、二つのコンステレーションは 12 m の VAL でコンステレーション故障の仮説を支えられます。最も早い TLE エポックを基準にしても同じ数値になります。テスト内の自己チェックは、その可用性ループを標本ごとに araim_dual_constellation_availability に固定しているため、唯一の違いは時刻の揃え方です。docs/CAPABILITY.md と docs/REAL_TLE_GUIDE.md の §3 に新しい数値を記載しています。下の 0.13.0 の項目は、リリース時のままにしています。

• 公開面では、RINEX 4 を検証済みとして掲げなくなりました。エンジンは現在、RINEX 4 の航法ファイルを、誤ってデコードするのではなく名前を示して拒否しますが、規格のグリッドには、航法パーサーの RINEX-3 のエビデンスに結び付けられた「RINEX 3 / 4」のカードと確認済みのラベルが残っていました。カードは現在「RINEX 3」となり、README、docs/CAPABILITY.md、docs/STANDARDS.md、ROADMAP.md、機能の要約は、事実を述べています。RINEX 3.0x の観測ファイルは解析でき、4.00 の観測レイアウトも解析できると見込まれますが、4.00 のファイルをコードで読み込んだことはなく、RINEX 4 の航法ファイルは拒否されます。

• --validate は、「ok」が確認対象が何もなかったことを意味する場合にそれを示します。カタログのおよそ三分の二は必須フィールドを公開しておらず、それらのパックは空の本体から参照設定を実行するため、リントは、六つのフィールドを確認した後と同じ表現で「ok」を出力することしかできませんでした。成功の行には、存在を確認した必須フィールドの数、またはその種別が必須フィールドを持たないことが示されるようになりました。

• scripts/gate.sh は、数値でない REPEAT または TEST_THREADS を拒否します。bash 3.2 では、REPEAT=no は数値比較をエラーにして偽と評価したため、ゲートは 0 でない値に対して「repeatability loop SKIPPED (REPEAT=0)」と表示し、それでもレシートを書き出していました。現在は両方の設定値が、単なる整数でなければ 2 で終了します。

• MSRV は、人が読むすべての場所で 1.85 と記載されるようになりました。 Cargo.toml は前回のリリースで 1.85 に上がりましたが、README のバッジ、インストールとトラブルシューティングの文章、codemeta.json、MCP クレート自身の根拠説明は、まだ 1.75 と書いていました。

• Python バインディングの RunOutput.__repr__ は、「chars」ではなくバイト数を報告します。これまでは UTF-8 文字列の len() を表示しており、これはバイト数です。708 文字の表に対して「chars」が 710 と出ていました。

• README は、--study --study-name を併記するように記載することをやめました。 --study-name は単一シナリオ用のフラグで、--study と併用すると無視されます（バイナリが警告を出します）。README.md と README.crates.md にあった二つのコピー＆ペースト用の例は、スタディのコマンドのみを示すようになりました。

• サイトの時計安定度のエビデンスは、観測された二つの許容差の両方を示すようになりました。5071A セシウム系列は ≤ 3e-5、PHASE.DAT は ≤ 5e-5 で再現されます。段落ではどちらも 3e-5 としていました。

• エンジンが出力した二つのファイルは、追跡対象から外れました。 scenarios/quantum-pnt-demonstrator.study.{json,html} は、エンジン 0.20.0 がすべての性能指標を空のままスタンプしたもので、README 自身のスタディコマンドがそれらを上書きしてツリーを汚し、プッシュゲートを塞いでいました。*.study.json / *.study.html は、他の四つのエンジン出力と同様に無視されるようになりました。

• プレイグラウンドでのシードの掃引が、毎回失敗することはなくなりました。掃引は整数の seed ノブを線形に刻んでおり（1、10.9、20.8、…）、エンジンは u64 として読むため、小数の値をすべて拒否していました。整数のノブは、現在は異なる整数を掃引します。

• プレイグラウンドのダウンロードはすべて、どのエンジンとどの入力で作られたかを示します。一部の種別（例：realtime-frame-eop）は engine_version も scenario_hash も出力しないため、そのダウンロードは単に kshana-csv.csv という名前でした。名前は現在、読み込まれたエンジンのバージョンと、シナリオテキストの 12 桁の十六進数による FNV-1a-64 フィンガープリントにフォールバックします。

変更#

• 公開されるクレートは以前の半分未満の大きさになり、cargo install kshana は CLI だけをビルドします。パッケージにはこれまで、論文、その投稿用パッケージ、論文の図の成果物、ノートブック、docs/、メンテナー用スクリプト、サンプルプログラムが含まれていました。ライブラリも CLI も、これらのいずれもコンパイルしません。また、src/bin/ 配下の三つの内部ジェネレーター（crossover_study、gen_validation_artifacts、validation_report）も含まれていたため、レジストリからのインストールでは四つの実行ファイルがコンパイルされてインストールされ、そのうち三つはチェックアウト内でしか役に立ちませんでした。これらのツリーと三つのジェネレーターのソースは、現在は除外されています。Cargo はパッケージのバイナリを、含まれるファイルから一覧するため、公開されるマニフェストには kshana だけが載ります。クローンでは、ジェネレーターは引き続き自動的に見つかるため、cargo run --bin <name> と validation_report を実行するリリースジョブは変わりません。cargo package で測定した結果は、変更前が 763 ファイル、16.7 MiB、圧縮後 6.8 MiB、変更後が 591 ファイル、10.5 MiB、圧縮後 3.0 MiB です。パッケージ化されたファイルだけをコンパイルする検証ビルドは通ります。パッケージ化されたクレートへの cargo install --path では、実行ファイルは kshana の一つだけがインストールされました。

• タイミング技術者が読める出力：p95 0.0ns はもう出ず、攻撃がない場合の security 0.000 もなく、サイトの件数は README と一致します。これは表示の改訂です。公表済みの数値は変わらず、JSON の値は同一であり、上のゴールデンハッシュがそれを証明しています。

  • 一行の要約は、光学時計の95パーセンタイル（p95）の時刻誤差を 0.0ns と表示していましたが、隣の表には 1.20e-4 ns と表示されていました。ゼロではないが小数一桁には小さすぎる時刻の数値は、有効数字三桁（p95 1.20e-4ns）で表示されるようになりました。厳密なゼロは、これまでどおり 0.0 と表示されます。HTML（HyperText Markup Language）レポート、スタディの比較表、プレイグラウンドでダウンロードできるレポートも同じ規則を使うため、ゼロでない数値が 0.000 と表示されることもなくなります。
  • security は、スプーフィングの検出可能性についての解析的な限界で、設定された攻撃に対してのみ意味を持ちます。clock、orbit、hybrid、fusion の各種別は攻撃を設定しないため、その要約は、失敗した検出のように読める 0.000 のような数値ではなく、security n/a (no attack) と表示するようになりました。値は fom.security に残り、applicable: false と印を付け、理由を figure_tiers に記し、レポートの表には「該当なし」と表示されます。spoof 種別は、これまでどおり検出を採点します。
  • tests/registry_golden.rs の二つの要約ピンは、まさにこの二つの理由で動き、他の理由では動きませんでした。golden_clock（量子の p95 と、両方の security の値）と golden_orbit（両方の security の値。p95 の値は厳密にゼロです）です。ドキュメント全体のハッシュは動いていません。README、三つのチュートリアル、およびそれらの教材用シナリオにある期待される要約は、それに合わせて更新され、tests/tutorials.rs が教材用のコピーをエンジンと照合します。
  • プレイグラウンドのガイドツアーは、初回の読み込みで開かなくなりました。そのモーダルが最初のクリックを奪い、スポットライトが、訪問者が着いた位置からページをスクロールさせていたためです。ツアーは、「60秒ツアーを見る」ボタン、または浮かぶ Tour ボタンから始まります。
  • ページは、スマートフォンで横にスクロールしなくなりました。390 px では、ブランド行と GitHub ボタンの内容が約 410 px になり、4 px のはみ出しが生じていました。ヘッダーは 320 px 以上で収まるようになり、性能指標の表は、ページを広げる代わりに自身のボックス内でスクロールします。
  • 機能エクスプローラーは、独自のカード数（「機能カード 46 枚 … うち 17 枚が外部のオラクルの裏付けあり」）を先頭に掲げており、隣の README は 168 行中 64 行と述べていました。現在は、生成された web/data/verification-matrix.json（README の件数が固定されているのと同じマトリクス）から読み取った検証マトリクスを先頭に置き、カードはその要約層であるものとして後から名前を挙げます。継続的インテグレーション（CI）ワークフローの新しいステップである web/counts.test.mjs は、算術を確認し、README.md とページの説明を相互にチェックします。tests/web_validation_counts_doc_sync.rs は、配線を Rust 側から固定します。

• 公開向けの説明は、最も検証が進んだ領域であるタイミングとホールドオーバーを先頭に置くようになりました。README の冒頭と docs/POSITIONING.md は、Kshana を、オープンで再現可能な、出所を明示した PNT レジリエンスのエビデンスエンジンとして示します。重要インフラのタイミングとホールドオーバーが最初（アラン、修正アラン、時間偏差、最大時間間隔誤差の各推定量と、ホールドオーバーの惰行分散の逆算が、それを支える VALIDATED の行です）、量子は中立的な量子対古典のトレード手法で、その結果には MODELLED と表示し、月・地球・月間空間および深宇宙の航法は、看板ではなく維持される機能として位置づけます。どちらのページも、Kshana が何でないかを明記しています。無線周波数の信号シミュレーターでもハードウェアインザループの装置でもなく、MATLAB/Simulink、STK、Orekit の代替でもありません。そして、新しい telecom-timing 種別と docs/TELECOM-TIMING.md を案内しています。「良いオープンツールがない」という古い一文は削除しました。何も見つからない検索は、何も存在しないことの証拠ではありません。ROADMAP.md には、日付のない優先順位（タイミングが最初、量子のトレードが二番目、月は維持）が加わり、古くなった三つの項目（コリオリと光シフトの系統誤差、NRHO の初期条件と月のシナリオ。いずれも出荷済み）が削除されます。README の「Coriolis and light-shift remain roadmap」の行も同様に訂正されました。

• docs/CAPABILITY.md は、過小に主張することをやめました。地球固定座標系の行は「none」となっていましたが、マトリクスは GCRS→ITRS を VALIDATED と評価しています。現在は「full」になり、コア座標系の行では ANISE との相互チェックが提供済みと記録されています。ガイドモードはロードマップに載っていましたが、プレイグラウンドはガイド付きスライダーとガイドツアーを出荷済みです。src/verification.rs との突き合わせにより、検証より前に書かれていたさらに五つの行を訂正しました。Orekit 12.2 と照合したカウエル力モデルとバッチ・逐次の軌道決定、Orekit の仰角検出器と照合した地上局パス、gnss_lib_py と照合した DOP カーネル、独立した oem パーサーと照合した OEM のインポートです。検証と妥当性確認の行は、引用されたすべてのテストが存在することを確認するガードを明記するようになりました。

• 用語集は、結果ファイルが何を述べているかを説明します。 docs/GLOSSARY.md には、出力用語（ホールドオーバー、p95、インテグリティ、セキュリティスコア、PDOP、sigma_y、q_wf）、通信タイミング用語（時刻誤差、max|TE|、cTE、dTE、MTIE、TDEV、PRTC、ePRTC、T-BC、T-TSC、OCXO、CSAC）、および三つのエビデンスのティア（VALIDATED、MODELLED、PARTNER）について、平易な言葉による項目が加わりました。

• 略語は、手書きの公開ドキュメントのすべてで、初出時に展開されるようになりました。README と docs/ 配下の 24 ファイルでは、数百の略語が、展開される前や展開されないまま使われていました。現在はそれぞれ、そのファイルで最初に現れる箇所で展開されています。生成された三つのファイル（docs/VERIFICATION-MATRIX.md、docs/MODELLED-RATIONALE.md、docs/SCENARIOS.md）はそのままにしています。これらは src/verification.rs と api::list_scenario_kinds() から書き出されるため、表現の変更はその元で行う必要があります。

• 行カバレッジに、記録としての測定値が加わりました。 docs/COVERAGE.md は、b1d350d 上の CI の coverage ジョブから 95.63 %（39,419 行中 37,697 行）を記録し、tests/coverage_figure_doc_sync.rs は、五つの公開面にある「~96%」をそれに固定します。これは手作業で維持されていた唯一の見出しの数値で、すでに一度、気づかれないまま動いていました。

• これまで何も読んでいなかった面に、新しいドキュメント同期ゲートを追加しました。 tests/readme_code_fences_doc_sync.rs は、JavaScript フェンス内のすべての import { … } from "kshana" を WebAssembly のエクスポートと照合し、README.crates.md の Rust の例を、テストバイナリがコンパイルするコピーとバイト単位で固定します。tests/security_md_doc_sync.rs は、src/lib.rs が #![forbid(unsafe_code)] を失うか、SECURITY.md がそれを述べなくなると失敗します。tests/no_overclaims.rs は、web/README.md と三つのレジストリ README もスキャンするようになり、サイト上のすべての規格は proof を明示する必要があります。

• 実機の時計に関する二つのチェックは、ランナー上で実行されます。 realdata-clock.yml（月次および手動ディスパッチ）は、5071A と PHASE.DAT の系列を取得し、KSHANA_REQUIRE_REALDATA=1 で両方のテストを実行するため、入力がないとスキップされずに失敗します。取得用スクリプトは二つとも、一つの allantools のコミットに固定され、SHA-256 を検証します。

• Python の型スタブは、ビルドしたホイールと照合されます（bindings ジョブの mypy.stubtest）。csv/write_csv がスタブなしで出荷されたのは、これが理由でした。

• 用語集は URE、EOP、FoM、CTI、TIB を定義します。README と台帳では、これらが略さず展開されないまま使われていました。

• すべての種別が公開するフィールド契約は、現在は事実どおりで、テストがそれを保ちます。61 の種別のうち五つが変わりました。空でない required_fields を持つ種別は 21 から 22 になります。ephemeris は tle|orbit+epoch を必須とするようになり（裸の kind = "ephemeris" は --validate を通過してから実行で失敗していました）、quantum-trade は、その実行がすでに要求していた candidate_adev_taus+candidate_adev_values|candidate_clock_class を加えます。必須のエントリーには |（これらのうち一つ）と +（これらすべて）を使えます。--validate は両方を理解します。lunar-joint-od-clock、pvt、earth-gnss-lunar は、漏れていた 9 個の実際の任意フィールドを公開します。docs/SCENARIOS.md は、clock を除くすべての種別で kind が必須であると記載するようになりました。tests/required_fields_are_true.rs は、すべての種別を同梱のシナリオと照合します。必須のエントリーを一つでも取り除けば実行が失敗し、必須フィールドだけを持つドキュメントは実行できなければなりません。

• JetBrains Marketplace のノートがゲートされるようになりました。 scripts/check-version-sync.sh は、plugin.xml の最新の <change-notes> エントリーが出荷するバージョンを名指ししていない限り失敗するようになりました。公開された七つのバージョンが、0.22.0 のノートをそのまま表示していたためです。

• 技術レポートのカバレッジの数値は、測定されたものになりました。 paper/kshana-technical-report.md は「near 97 %」と書いていましたが、現在は 96 % 付近（測定値 95.63 %、docs/COVERAGE.md）と述べており、カバレッジテストが固定する六番目の面です。

• メインスレッド外のエンジンクライアントがテストされます（web/engine.test.mjs、CI 内）。ディスパッチの許可リスト、キャンセルと再起動、三つのメインスレッドへのフォールバック経路、クラッシュからの復旧を、偽のワーカーに対して確認します。

• タグ付けされたコミットがテストに合格するまで何も公開されず、すべてのレジストリが配信するまでリリースは完了しません。順序は現在、タグ、検証、公開、同等性、サイトであり、release.yml の一回の実行の中で行われます（docs/RELEASING.md）。

  • 公開は、判定を待ちます。 publish.yml、mcp-publish.yml、jetbrains-plugin.yml は、タグのプッシュで開始されなくなり、release.yml が needs: verify のジョブから呼び出します。以前は、これらがその実行と競合していました。v0.27.2 では、タグから 4.5 分以内に crates.io、npm、Python Package Index（PyPI）がすべて公開を終えており、verify が戻ったのはタグから 84 分後でした。v0.27.0 では、crates.io のジョブが失敗している間に npm と PyPI が公開されました。タグに対する手動の再試行は、新しい scripts/check-release-verdict.sh が止めます。これは、その正確なコミットに対する Actions インターフェース上の緑の verify を要求し、それ以外の場合は安全側に倒して失敗します。
  • 何かをアップロードする前に、すべてをビルドします。リリースの途中で失敗したのはパッケージング手順だった crates.io が、最初に公開されます。
  • レジストリのトークンがなければ、ジョブは失敗します。アップロードをスキップして成功を報告することはありません。
  • 公開後の同等性チェック。 scripts/check_channel_parity.py は、crates.io（kshana と kshana-mcp）、npm、PyPI（ソース配布物と六つのプラットフォームのホイールすべて）、ghcr.io が、それぞれそのバージョンを配信するまでポーリングし、配信されなければ実行を失敗させます。docs.rs と Model Context Protocol（MCP）レジストリは報告のみで、必須ではありません。過去のリリースに対して実行すると、0.22.0 が npm と PyPI に、0.23.0 が PyPI に、0.27.0 が crates.io にないことが分かります。
  • macOS（Apple silicon と Intel）と Windows x86-64 向けのビルド済みコマンドラインバイナリが、ターゲット名（kshana-aarch64-apple-darwin など）を付けて、名前が変わらない Linux の kshana と並んで提供されます。SHA256SUMS ファイルがすべてのアセットを対象とし、verify-release がそれを確認して、macOS と Windows のバイナリをそれぞれのシステム上で実行します。
  • kshana.dev はリリースを表示し、main は表示しません。これまでは main へのプッシュのたびに再デプロイされていたのに、ページは最後のリリースを名指ししていました。pages.yml は現在、リリースタグだけをビルドします。すべてのチャネルがそのバージョンを配信するようになった時点で、リリースがそれを一度ディスパッチし、手動のディスパッチでは最新のリリース（または名前を指定したもの）が再デプロイされます。
  • ホイールの供給元は一つです。 publish.yml の手作業でコピーした六ターゲットのマトリクスは廃止され、wheels.yml を呼び出すようになりました。これにより、auditwheel のタグゲートとバイト再現性チェックは、PyPI が受け取るホイールを評価し、どちらかで失敗すればリリースが止まります。
  • ビルドツールを固定しました。すべてのワークフローが Rust 1.93.0 を要求します（msrv ジョブは自身のバージョン）。publish.yml と pages.yml は @stable を要求しており、v0.27.2 のログでは、rustup が 1.98.1 をインストールし、rust-toolchain.toml のほうが優先されるおかげで 1.93.0 でコンパイルしていたにすぎないことが分かります。wasm-pack は 0.13.1（v0.27.2 をビルドしたバージョンで、固定されていないインストーラースクリプトが選んだもの）に、チェックサム検証付きで固定され、mcp-publisher は 1.8.1 に、公開されている SHA-256 付きで固定されます。scripts/check-toolchain.sh は、ワークフローが別のコンパイラーを要求した場合や、ダウンロードしたスクリプトをシェルにパイプした場合に、失敗するようになりました。検証ジョブ、ゴールデンピン、ローカルのゲートスクリプトは、削除も緩和もされていません。

セキュリティ#

• サードパーティの GitHub Action はすべて、コミット SHA で固定されました。15 のワークフローにわたる 93 件の参照で、そのうち 92 件が新規です。タグは、Dependabot が更新できるように末尾のコメントとして残しています。例外は dtolnay/rust-toolchain で、そのタグはツールチェーンの選択子です。

• MCP サーバーイメージのベースレイヤーは、マルチアーキテクチャのダイジェストで固定され、Dependabot は mcp/kshana-mcp の Dockerfile を監視するようになったため、OS のレイヤーは、レビューを経た PR を通じて、引き続きセキュリティ更新を受け取ります。

• タグとマニフェストの照合チェックは、タグのバージョンを出荷する二つの公開ワークフローで実行されます。 mcp-publish.yml（ghcr イメージ、MCP レジストリ）と jetbrains-plugin.yml（Marketplace）は、publish.yml を待たずに競合するため、誤って切られたタグは兄弟のワークフローでしかゲートされていませんでした。どちらも、ビルドの前に scripts/check-version-sync.sh を実行するようになりました。

• Dependabot のアラートが有効になった日に挙がった四件のアドバイザリーを修正しました。MCP サーバーは rmcp を 1.7 から 2.2 に移行します。rmcp < 2.1 に対する三件のアドバイザリー（Streamable-HTTP のセッションテーブルのリーク、OAuth の保護リソース検証の欠落、クロスオリジンのリダイレクトに追従するカスタムヘッダー）です。サーバーは stdio のみで通信するため、いずれもここでは到達できませんが、公開されるクレートは脆弱な SDK を固定すべきではありません。rmcp 2 のマクロは Rust 1.88 を必要とするため、kshana-mcp だけが rust-version = "1.88" を宣言するようになり、kshana ライブラリは 1.85 のままです。唯一の API 変更（Content → ContentBlock）は適用済みで、ラウンドトリップテストは通ります。SonarQube のスキャンアクションは v5 から v6 に移行し、引数インジェクションのアドバイザリー（≥ 4.0、< 6.0）が解消されます。

0.27.2 - 2026-09-22#

追加#

• 検証マトリクスの行が引用するすべての Rust 項目が、クレートに対して解決されるようになりました。既存のガードは、ファイルパスの形をした引用を確認していました。164 件のパートナー以外の行のうち 63 件は、エビデンスをクレート内の項目として示しており（navsignal::code_tests、integrity::tpl_scalar::tests、api::tests::tracking_loop_kind_round_trips_through_the_dispatch）、.rs の接尾辞を持たないトークンは、パスのスキャナーからは見えませんでした。これらの行は、名前が変わったモジュール、空にされたテストモジュール、存在しなかった関数を指していても、すべてのゲートは緑のままだったはずです。

  tests/verification_rows_name_a_test_that_exists.rs は、こうした引用 339 件すべてをモジュールツリーを通じて解決し、パートナー以外のすべての行に、#[test] を実際に持つテストを少なくとも一つ挙げることを要求し、パートナーの行には何も挙げないことを要求します。評価のために四つのミューテーションを使いました。引用されたモジュール名の変更、行の唯一のテスト引用を非テスト関数に向けること、実在する mod tests の名前の変更、そこから #[test] 属性を取り除くことで、いずれもそれを担当するアサーションで赤になります。

  一つの行は、すでに誤っていました。Alternative / complementary PNT は、引用ではないグロブ tests/* を挙げていました。現在は tests/alternative_complementary_pnt_reference.rs と、その背後にある三つのクレート内テストモジュールを挙げています。

• 公表済みの数値は、ビルドのたびにエンジンと再照合されます（tests/published_figures_still_reproduce.rs）。README の三つのデモ用チャートはエンジン自身の chart.svg 出力ですが、シナリオを再実行するものは何もありませんでした。論文の二つのクロスオーバー研究は一度だけ生成されてコミットされたもので、README は scenario-fom.png の隣で四つの性能指標を文章で述べています。この三つはすべて、現在はエンジンのライブ出力に固定されています。

  これらを突き合わせた結果、有用なことが分かりました。デモ用チャートはエンジン 0.22.0 で、論文のクロスオーバー JSON は 0.20.0 で描かれたものでしたが、0.27.1 では五つの成果物すべてで、プロットされたすべての値が同一です。三つのチャート SVG が新たに実行した結果と異なるのは、フッターのバージョンスタンプのちょうど二文字ずつだけです。フッターが事実と合うよう、チャートは再描画しました。論文の JSON は意図的に 0.20.0 のスタンプのままにしています。これは、公表済みの論文が埋め込んでいる図の実行記録であり、スタンプを付け直すと、PDF にない出所を主張することになるためです。ガードは代わりに、より強い性質、すなわち現在のエンジンが公表済みのすべての値を再現できることを検証します。

修正#

• SonarCloud の解析が VERSION=not provided として記録されていたため、previous_version の新規コード期間が進まず、2026-07-02 の解析に固定されたままでした。このため八十二日分の作業が一つの差分として評価され、3 % のしきい値に対して 7877 行の「新規」重複行が測定されていました。スキャンは現在、クレートのバージョンを渡します。根本にある重複は実在し、これで隠されることはありません。それは、ensemble、hybrid、fusion、inertial、report にまたがって繰り返される宣言的な FieldUnit レジストリと、168 行の検証表に集中しており、測定から除外するのではなく、ここで作業として明記しています。

• scripts/gate.sh には単一ライターのロックがなく、すべての実行が同じログに書き込んでいました。これは整頓の問題ではありません。レシートの integration_binaries、tests_passed、tests_ignored は、そのログの中から読み戻されており、プッシュ前フックはそのレシートを信頼します。強制終了されたが、そのテストバイナリがまだ動いていたゲートは、次の実行がちょうど切り詰めたファイルに書き込み続けたため、ある実行の件数が別の実行の件数として証明されてしまい、プッシュされるツリー上では一度も実行されていないスイートを根拠にプッシュが許可されかねませんでした。現在はチェックアウトごとにゲートは一つ（稼働中のものがあれば終了コード 75 で拒否し、pid が消えた古いロックは解除）、実行ごとにログは一つで、終了時に target/gate-run.log が終了した実行から更新されます。両方向をテストしています。稼働中の pid は拒否され、終了した pid は解除されます。

• src/verification.rs は、そのテストが「名指しされたテスト/オラクルの文字列が実在するコードに解決されることを証明しない」と主張していました。現在は二つのガードがまさにそれを行うため、モジュールのドキュメントは事実と逆のことを述べていました。現在は、機械的に確認されることと、人間の判断に委ねられることを記載しています。verification::gen への古い参照（モジュールは artifacts です）は、兄弟のガード自身のドキュメントで訂正されました。

変更#

• main は 2026-09-22 に書き換えられ、強制プッシュされました。十件のコミットが四件になりました。書き換えでは、ゲートを赤にしたコミットを、それを解消したコミットに統合したため、main のすべてのコミットが、通過するツリーを持つようになりました。また、ブランチ全体の並行実行グループが、置き換えられたすべてのコミットに残していたキャンセル済みの実行も取り除きました。

  何も捨てていません。書き換え前のコミットは、それを指すタグを通じて引き続き到達でき、最終的なツリーは、書き換えの開始時のツリーとバイト単位で同一です。古い先端と新しい先端の間の git diff は、このリリースが変更する三つのワークフローファイルを除いて空です。

  置き換えられた SHA（いずれかを参照している方のために）：

  旧	件名
  9733177	docs(changelog): disclose the authorship rewrite and the two dangling crate sha1s
  5d16ea8	fix(docs): the engine-flow diagram said 6 figures of merit; the engine scores 7
  148d31d	fix(test): two more cross-platform pins, and two wrong assumptions of my own
  a3a2667	feat(web): surface the lunar cluster on the site — seven capability cards
  1e8bec6	docs(lunar): document 42 public fields and ratchet the ceiling down to 985
  7bba514	chore(release): v0.27.0
  3154548	test(docs): guard the distribution diagram, the last unguarded one
  7864142	chore(release): v0.27.1

  v0.27.0 と v0.27.1 のタグは、意図的に移動していません。これらは引き続き 7bba514 と 7864142 を指しており、これは現在 crates.io、npm、PyPI、ghcr.io、MCP レジストリで公開されている成果物のツリーを生んだ、まさにそのコミットです。クレートの .cargo_vcs_info.json は、パッケージ化の元になった sha1 を記録しており、レジストリは不変で、v0.27.1 のリリースアセットにある SLSA ビルド来歴の証明は、そのコミットに結び付けられています。タグを移動していたら、公開済みのそれらすべての成果物が、もう存在しないコミットを指したままになっていたでしょう。タグを残すことで、古いコミットには到達でき、公開済みのすべての来歴の連鎖が解決され続けますが、その代償として、二つのタグは main の祖先ではなくなります。これがこのリリースが存在する理由です。v0.27.2 は、main に独自のタグを与え、そのタグは、その上にあるコミットからパッケージ化されます。

  これは、この履歴で開示される二度目の書き換えです。一度目は 2026-09-21 に作成者情報を正規化したもので、0.27.0 のノートに、二つの宙に浮いたクレートの sha1 とともに記録されています。書き換えは毎回ここで開示します。検証可能な来歴を売りにするリポジトリが、公開済みの成果物の足元を黙って動かしてはならないからです。

0.27.1 - 2026-09-22#

修正#

• 公開されたクレートは、コンパイルできませんでした。 src/lunar_orientation.rs は、tests/fixtures/llr_geometry/de440_moon_pa.csv の最上位の include_str! を持ちますが、マニフェストは /tests/fixtures をパッケージから除外しているため、crates.io が受け取る tarball には、ライブラリ自身が埋め込むファイルが欠けていました。v0.27.0 の公開は、この理由で検証ビルドに失敗し、0.27.0 は crates.io に届きませんでした。それに依存しないジョブを持つ npm と PyPI は、通常どおり公開されました。除外には現在、そのカタログ一つについての例外が加わっています。

  src/ 内にある、フィクスチャーのその他の include_str! はすべて #[cfg(test)] モジュールの内側にあり、パッケージ化されたライブラリには届きません。最上位にあるものだけが届きます。

• CI のどこも cargo package を実行していませんでした。そのため、コンパイルできない tarball は、他の二つのレジストリがすでに出荷した後で、ようやく公開ジョブで発見されました。現在は package ジョブが、プッシュのたびにその tarball をそのままビルドしてコンパイルします。

変更#

• lunar-frame-realisation の出力ピンは、バージョンを上げても動かなくなりました。SVG のフッターにはエンジンのバージョンが入るため、リリースのたびに三つのハッシュを再基準化することになり、一日に二度行ったこともあって、慣例的に取り直されるピンは読まれなくなります。バージョン文字列は、ハッシュの前にプレースホルダーへ正規化され、出力が実行中のバージョンを述べていることは別に検証されるため、その事実は、ハッシュがかつて確認していたよりも正確に確認されます。

0.27.0 - 2026-09-22#

追加#

• lunar-llr-datum：実際の観測キャンペーンから得た月の座標系データム。 lunar-frame-campaign は、注入したヘルマート変換をシミュレーションのキャンペーンに置き換え、その旨を明記していました。観測局のネットワーク、スケジュール、観測ごとのシグマは例示用の入力です。このシナリオは、スケジュールと誤差モデルが答えに入り込む二か所から、シミュレーションを取り除きます。エポックは、アーカイブされた ILRS の月レーザー測距ノーマルポイント 337 個（2015-04-08 .. 2015-06-27、Grasse MeO 7845 と Matera MLRO 7941、五つの反射器アレイすべて）の送信時刻で、各観測の重みは、そのノーマルポイント自身のアーカイブされた精度（bin_rms / sqrt(n_raw)）です。片道距離の中央値は 5.13 mm で、ここで選んだ値ではなくファイルから得た値です。観測局の座標は IERS ITRF2020 から、反射器の座標は JPL DE430 の Table 7 から取得しており、各フィクスチャーは URL、取得日、SHA-256 を記録し、ソースを検証して、数値を出すくらいなら中止するコミット済みのジェネレーターによって、ソースから再生成されます。レポートは、どのリンクが測定済みで、どれがモデルから計算されたままかを明記しており、モデルから計算された方のものが測定されています。実データでの片道距離の観測値マイナス計算値は RMS で 156,494 m で、同じテスト群が同じ期間について JPL Horizons と照合して確認しています（ベクトル RMS 195,655 m、最悪のエポックは 0.054°。組み込みの解析的な月の級数が自ら主張する ~0.3° の範囲内です）。加算的な変更です。新しい種別、新しいリーダー（realdata::llr_crd）、新しいモジュール（lunar_llr）が加わり、既存の月の座標系パックはビット単位で固定されています。

• sigma_ure_m をシナリオパラメーターに：lunar-integrity と moonlight-service-volume です。信号空間の測距精度はコンパイル時の定数（LUNAR_SIGMA_URE_M）だったため、サービスボリュームの掃引は、一つの固定値での合否にしか答えられませんでした。保護レベルはこれに対して厳密に線形なので、これを公開することで、掃引はボリューム全体にわたる測距精度の要件になります。既定値は、従来の動作をビット単位で再現します。

• moonlight-service-volume の衛星ごとの幾何のエクスポート：export_site_lat_deg + export_site_lon_deg は、per_sat_geometry 配列を加え、名前を指定した一つの月面地点に対する、すべてのエポックでのすべての衛星の方位角、仰角、スラントレンジと、可視フラグを与えます。集計したカバレッジの要約は意図的に衛星ごとの幾何を畳み込んでいますが、スラントレンジはまさにリンクバジェットが使う量であるため、通信・航法統合の解析は、要約だけでは行えませんでした。両方の座標が指定されない限りオフで、純粋に加算的です。

• lunar_service::topocentric：エクスポートの背後にある、公開された見込み角ヘルパー。

• 新しい幾何機能のための検証マトリクスの行。

• 幾何エクスポートでの実際のアンテナパターン。エンジンは P1 以降、一様照射の円形開口パターン（antenna::pattern_gain_dbi、エアリーの [2·J₁(x)/x]² の形）を備えていましたが、antenna.rs の外では何も使っていませんでした。代わりに、ボアサイト利得と、利得とビーム幅の経験則の組み合わせが働いていました。moonlight-service-volume の任意の export_antenna テーブル（エクスポート地点が設定されている場合のみ読み込まれます）は、現在、エクスポートされるすべての行に衛星での軸外角とそのパターンからの地点方向への送信利得を与え、antenna_pattern ブロックを加えます。これは、実際のパターンにおけるビーム内の数と、対称近似におけるビーム内の数（θ₃dB[deg] = √(31000/G_lin)）を並べて報告し、その差を名前付きの補正として示します。両方の数値が出力され、どちらも他方を置き換えません。エンジン自身の代表的な月面の開口（1 m のディッシュ、2.4 GHz、η = 0.60）で、南極付近の地点と例示用の LCNS クラスのシェルに対して測定すると、この二つは一機を超えて食い違います。実際のパターンでは、見えている 76 本のリンクのうち半値ビーム内に入るのは 0 本ですが、近似では 28 本としており、エポックあたり −2.33 機の補正で、最悪の単一エポックは 3 です。近似は、それ自身の開口効率を持っています（通常引用される 70·λ/D 度の経験則に対して 0.641、一様円形開口に対して 0.920）。そのため、η = 0.60 のディッシュでは、ビームが 1.238 倍広すぎる値を返します。ブロックは、両方の暗黙の効率を、推定に任せずに出力します。純粋に加算的です。文書化された動作点で測定したところ、既存の 597 個のリーフのうち、0 個が変更、0 個が削除、494 個が追加でした。

• antenna::symmetric_beamwidth_rad、antenna::symmetric_relation_implied_efficiency、antenna::within_half_power_beam、antenna::HALF_POWER_DROP_DB、antenna::SYMMETRIC_GAIN_BEAMWIDTH_CONST_DEG2、antenna::UNIFORM_APERTURE_HPBW_COEFF、lunar_service::nadir_off_boresight_rad：その背後にある公開部品です。パターンは、それ自身だけでなく、公表されているエアリーの定数に対しても固定されるようになりました。半値の交点は二分法で求めて x = 1.61634 と比較しており、これにより厳密な半値幅は 1.02899·λ/D となり、慣例的な 1.02 の係数では pattern_gain_dbi が −2.955 dB であって、−3.010 dB ではないことが正直に記録されます。

• lunar-time-budget の縦長形式の再現性テーブル。このシナリオの配列値の出力（平均化時間のグリッド、七つの項ごとの x(τ) 曲線と、それらの二乗和平方根の合計）は、利用者に JSON 配列としてしか届いていませんでした。公開済みのあるテーブルは 400 文字で切り詰められ、すべてを含むと称する列の下に、57 個の平均化時間のうち 23 個しか公開されておらず、原稿は、エンジンがそれらを出力しなかったため、項ごとの曲線を閉じた式から再構築していました。通常の実行は現在、（グリッドのインデックス、平均化時間、項）ごとに一行を持つ <scenario>.table.csv も書き出し、切り詰められて、それでも全体に見える状態になることはありません。グリッドのインデックスは厳密な結合キーです。τ は 13 桁の有効数字で、各 x は 7 桁で書き出されるため、同じソースの別ビルドでもバイトは分岐しません。純粋に加算的です。レポートの JSON はバイト単位で同一です。

• hybrid-optical-rf レポートが、自らを記述するようになりました。link_configuration ブロックは、既定値を適用した解決後のリンク入力（搬送波の波長、送信と受信の開口、距離、パルス幅、積分時間、効率と損失）をそのまま出力するため、論文はソースから読み取った既定値を引用するのではなく、実行した設定を述べることができます。units ブロックは、論文が引用しそうなすべての量について、単位と出所のクラスを与えます。引き継ぎの共分散のトレースが、これが存在する理由です。それらは単なる variance として出力され、原稿は内部整合性チェックから平方メートルだと推定していました。その推定は正しく、まさにそれが欠陥だった理由です。誤っていても、何もそれを捕まえなかったでしょう。純粋に加算的です。四つの構成にわたって測定したところ、既存の 456 個のフィールドのうち、0 個が変更、0 個が削除、196 個が追加でした。

• 時間バジェットの再現性テーブルのための検証マトリクスの行は、正直に InternalConsistency / MODELLED としています。合計は、同じファイル内の各項の二乗和平方根と照合されますが、それはエンジン自身の項の定義を共有しているため、独立したオラクルではありません。これらを合わせて三つの行が加わります。この未公開セクションでの累計は、168 行（64 が VALIDATED、100 が MODELLED、4 が PARTNER）です。

変更#

• 履歴全体のコミットの作成者情報は、現在一つの識別情報に統一され、公開された二つのクレートは、もう存在しないコミットを指しています。2026-09-21 に git の履歴を書き換え、すべての人間によるコミットが ashfordeOU <236818772+ashfordeOU@users.noreply.github.com> によって作成およびコミットされたものになりました。それ以前は、一人の人物について三通りの表記があり、ashfordeOU <contact@ashforde.org> としてのコミットが 688 件、Chakshu Baweja <contact@ashforde.org> としてが 34 件、すでに正規のものが 94 件でした。dependabot[bot] のコミット一件は、意図的にそれ自身の作成者のまま残しました。ボットの依存関係の更新に付け替えをすると、ここの誰も行っていない作業の作成者を名乗ることになるためです。

  内容は何も変わっていません。書き換えが触れたのは、作成者とコミッターのヘッダーだけで、これは主張ではなく確認可能です。すべてのタグとすべてのブランチのツリーは、以前とビット単位で同一です。v0.26.0 は、これまでどおり、ツリー 92284e9420605568f1bfabb78cd95d383b40f3e2 に解決されます。

  その代償。コミットの名前は、そのツリー、親、作成者ヘッダーに対するハッシュであるため、祖先を変更すると、すべての子孫の名前が変わります。v0.26.0 のリリースコミットは dce2dbf7700788cf6de46260c14673c0e5347360 でしたが、現在は d4921f3025569e00e425e1747d0acfc261e96e18 です。二つの成果物は、公開時に古い名前を記録しており、公開済みのレジストリのバージョンは設計上不変であるため、訂正できません。

  • crates.io の kshana 0.26.0：.cargo_vcs_info.json は dce2dbf… を記録しています
  • crates.io の kshana-mcp 0.26.0：同じ sha1、path_in_vcs: mcp/kshana-mcp

  それ以外に影響はありません。npm パッケージは gitHead を記録せず、PyPI の配布物はコミットをまったく記録しません。どちらも仮定ではなく、確認しました。

  dce2dbf… が書き換え後のコミットを指すようにする修復手段はありません。その文字列は古い祖先そのものであり、それが解決される唯一の方法は、書き換え前の履歴を公開したままにすることですが、それでは書き換えが取り除いた作成者情報が復活します。したがって 0.26.0 の来歴は、記録された sha1 ではなくタグを通じて辿ることになり、そのタグは、クレートがビルドされた元のバイトとまったく同じものを届けます。次のリリースは、有効なコミットを記録するため、対応は不要です。

修正#

• realtime-frame-eop は、予測行のない EOP ファイルを既定にしていました（G12）。このシナリオは、オフラインの既定として、五行の確定値のみの finals2000A 抜粋を埋め込んでいたため、素の実行は predicted_rows.n = 0 と報告し、予測期間ごとの表は 5、4、3、2 のペアに基づいていました。エンジンは予測行を常に読めましたが、入力にそれがなかっただけです。既定は現在、IERS 2026 の抜粋そのまま（tools/finals2000A_2026.txt、MJD 61173–61204）で、Bulletin B の確定値 20 行と、Bulletin A の予測のみの行 12 行を含みます。このため、ファイル引数もネットワークもない素の実行は predicted_rows.n = 12 と報告し、予測期間ごとの表は n = 20 / 31 / 30 / 29 となり、運用上の予測器との比較と、製品自身の公表予測との一致も反映されます。代替として測定した 45 行の長期間の抜粋は、これも確定値のみのため predicted_rows.n が 0 のままになることから、採用しませんでした。これにより、公表済みの数値が動きます。規則 R4 に基づき、創業者の承認を得ています。公開済みの p4_frame_eop.csv の 22 個のセルのうち十個、tests/golden/realtime-frame-eop.csv の値が入っている 42 個のセルのうち 24 個です。測定された速報値マイナス確定値の極フロアは 0.0678 mas（以前は 0.0769 mas）になり、これは論文 P4 自身の極運動の表が n = 20 ですでに公表している値です。両者は 13.5 % 食い違うことなく、一致するようになりました。この表から P4 が示すその他の数値は、示している精度では変わりません。動かなかったフィールドを含む、旧から新への完全な一覧は、docs/revisions/G12-default-eop-cell-changes.md にあります。確定値のみの抜粋は、引き続き同梱され、バイト単位で固定され、実行されます。それについて予測行数がゼロになるのはファイルの性質であり、テストは今もそれを証明します。

• moonlight-service-volume の古い衛星数のクランプ。このシナリオは、自身のコンステレーションビルダーが 24 に対応し、テストも 24 を検証しているにもかかわらず、n_sats を 12 にクランプしていたため、12 を超えて要求されたすべての数は黙って減らされ、衛星数の掃引は 12 を超えると同一の値を返していました。これは、真の幾何的な飽和と区別がつきません。現在はビルダーの上限でクランプしています。これは n_sats > 12 のみの動作変更です。

• lunar-differential-pnt にあった、同じ古いクランプ。 lunar_dpnt は n_sats を 12 にクランプして同じ結果を招き、こちらは公開済みの表に届きました。dpnt_nsats_sweep.csv は、n = 16 の行を、n = 12 の行とバイト単位で同一のものとして持っていました。エンジンが、十六機のラベルの下で十二機の答えを返していたためです。現在はビルダーの上限 24 でクランプし、新しいテストがこれを固定します。より大きな各コンステレーションは、それ自身の数を報告し、かつ保護レベルを厳密に改善しなければならないため、クランプが気づかれずに戻ることはありません。これにより、公表済みの数値が動きます。n = 16 の保護レベルは 16.92 m → 14.57 m になります。24 まで掃引すると、曲線は厳密に単調で（24 機で 11.94 m、12 機と比べて 29.5 % 良好）、12 での飽和はありません。見かけの頭打ちはクランプによるものでした。n_sats > 12 のみの動作変更です。

0.26.0 - 2026-09-18#

ドキュメント、透明性、プレイグラウンドのリリースです。エンジンの動作は変わりません。検証マトリクスは 102 行（56 が VALIDATED、42 が MODELLED、4 が PARTNER）で、0.25.0 から変わりません。

追加#

• クレートレベルの rustdoc（lib.rs の //!）が、エントリーポイント、誠実さとティアのモデル、再現性を扱うため、docs.rs は、素のモジュールの壁ではなく、きちんとしたランディングページで開きます。
• docs/SCENARIOS.md：50 のシナリオ種別すべてを対象とする種別ごとのリファレンスで、api::list_scenario_kinds()（唯一の情報源）から gen_validation_artifacts によって生成され、tests/scenarios_reference_doc_sync.rs が守っているため、ディスパッチャーからずれることはありません。
• これまでドキュメントのなかった 11 個の公開モジュールのモジュールドキュメント（allan、estimator、fom、hybrid、inertial、models、report、run、scenario、timetransfer、types）。
• 式を述べていながら参照先を挙げていなかった、五つの数式モジュールの文献出典：batch_ls（Tapley/Schutz/Born、Bjorck）、cr3bp（Szebehely、Koon et al.）、detection（Kay）、attitude_budget（Wertz、Sidi）、reentry（Allen-Eggers、NACA TR-1381）。
• 協調的な開示のために、kshana.dev に公開された security.txt。
• プレイグラウンドでの実行ごとの検証ティア。単一実行の性能指標の表は、図ごとの VALIDATED/MODELLED のラベルを持つようになりました。これは、ダウンロード可能なレポートが使うのと同じ fomTier() の参照（検証マトリクスから導かれる src/fom_label.rs に対応）から読み取られるため、ライブの数値の隣に表示されるティアが、台帳と食い違うことはありません。
• プレイグラウンドのメニューに lunar-attack-surface：ディスパッチ可能な 50 種別すべてが、ワンクリックで開けるようになりました（以前は 49/50）。
• 実行可能な機能カードを、さらに五つ（宇宙天気、RF 障害の評価、レジリエンス、CCSDS OEM の相互運用、KIF）追加し、実行可能なカードは 11 から 16 になりました。API とライブラリ専用のカードは、偽の実行ボタンではなく、正直なドキュメントへのリンクを保ちます。

変更#

• ドキュメントのカバレッジは、CI でラチェットされるようになりました。 check-doc-coverage.sh は、ライブラリを missing_docs でコンパイルして警告を数え、件数が固定された上限（986）を超えた場合にのみ失敗します。-D warnings のもとでの厳格な #![warn(missing_docs)] は、現在ドキュメントのない公開項目 ~1000 件を、一夜にしてビルドの破壊に変えてしまいます。この方式では、ドキュメントのない新しい公開項目はビルドを失敗させ、既存の積み残しは意図的に減らしていきます。

修正#

• MCP の list_scenario_kinds ツールの行は、「~17 built-in scenario kinds」と表示していましたが、api::list_scenario_kinds() はしばらく前から 50 を公開していました。エージェント向けのドキュメントが、実際の機能を約三倍も過小に述べていたことになります。真の数に固定しました。
• 更新した依存関係グラフ（60 コンポーネント）に対して、CycloneDX SBOM の適合オラクルを再生成しました。適合判定は変わりません。正規化したスキーマエラーはゼロで、すべてのアトミックなライセンス id は、引き続き公式の SPDX 列挙に含まれています。

0.25.0 - 2026-07-15#

追加#

• 五つの機能が、外部で VALIDATED に昇格しました。いずれも現在、一意に定義された同じ量について、独立したサードパーティの実装と照合されています（循環のない形で、オフラインで再生成できるフィクスチャーを使用）。
  • IEEE-1139 のべき乗則からアラン偏差への変換を、五種類のノイズすべてについて、allantools の閉形式と照合（tests/powerlaw_oadev_reference.rs）。
  • CRPA の MVDR / 最小ノルムのヌルステアリングビームフォーマーの重みを、numpy/scipy の LAPACK と照合（tests/crpa_reference.rs）。
  • Wahba / TRIAD / QUEST による姿勢決定を、ノイズのない観測について、SciPy の SVD Rotation.align_vectors と照合（tests/wahba_reference.rs）。
  • CCSDS 502.0 OEM の共分散ブロックの交換を、独立した oem ライブラリのパーサーでラウンドトリップ（tests/ccsds_oem_covariance_reference.rs）。
  • 二乗則の捕捉の検出統計カーネル（一般化 Marcum-Q / P_d / P_fa / しきい値）を、SciPy の ncx2/chi2 と照合（tests/acquisition_reference.rs）。機械で検証される検証マトリクスは、102 行にわたり56 VALIDATED · 42 MODELLED · 4 PARTNER になります（以前は 51 · 47 · 4）。正直な範囲の注意書きは保たれています。たとえば、捕捉の昇格が対象とするのは検出統計カーネルのみで、CFAR/straddling loss は MODELLED のままです。
• 位置領域の性能指標（fom::positioning_performance）：航法解の3次元 ENU 位置共分散と水平保護レベルから、厳密な CEP、SEP、2DRMS を求めます。CEP/SEP は厳密な中央値の半径誤差であり（0.589·(σ₁+σ₂) の線形則ではありません）、scipy.stats の rayleigh/maxwell の分位点と、独立した NumPy のモンテカルロ中央値（tests/positioning_fom_reference.rs）で相互確認されています。以前の、未実装であることを正直に示すスタブを置き換えます。関数シグネチャが変わりました。エラーを返す () から、PositioningFom を返す (cov_enu, hpl_m) になります。
• 信頼区間の等価自由度（EDF）を、アラン系のすべての推定量について完成させました（assurance::uncertainty::edf）：修正アラン、アダマール、全分散の EDF は、Greenhall & Riley の合成 EDF アルゴリズムと NIST SP 1065 の Table-7 の TOTVAR 形式を使うようになりました（以前は重なりアラン偏差の EDF のみが実装されており、他は黙ってそれを流用していました）。allantools の edf_greenhall/edf_totdev と相互確認しています（tests/uncertainty_edf_reference.rs）。
• 月面 PNT の幾何、DOP、EOP、DRO、RF 測距の各機能に対する、独立した外部の相互確認（tests/validate_p*.rs。フィクスチャーとオラクルのジェネレーターは tests/fixtures/{p1_footprint,lunar_service,eop_prediction,rf_ranging_precision,dro_family_jpl,p2_independent_dop}/ 配下）。各確認は、すでに出荷済みのモデルから計算された機能を、異なる実装が生成したオラクルと突き合わせるため、一致は循環的ではありません。軌道上の送信・捕捉フットプリントは scipy.special.j1（Cephes：本質的に異なるベッセル J1）と、地表ビーコンの幾何 DOP は独立した NumPy の (HᵀH)⁻¹ の解と、UT1/EOP の持続予測の誤差増大は、同じ IERS finals2000A の行をそのまま別の NumPy で再解析したものと、平面の遠方逆行軌道の族は NASA/JPL の Three-Body Periodic Orbit Database と、RF 測距精度のバジェットは第一原理の参照と照合します。これらは既存モジュールの追加の回帰エビデンスであり、これらの相互確認テストを加えること自体は、どの機能のラベルも付け替えません（上の五つの昇格は、src/verification.rs における、オラクルに裏付けられた別個のステータス変更です）。
• lunar-attack-surface シナリオ（src/attack_surface.rs、kind = "lunar-attack-surface"）：run_toml を介して CLI / Python / MCP / wasm から到達できる、合成された P1 の月面信号セキュリティの実行で、リンクバジェットの電力不足とその 12–18 dB の感度帯、スタンドオフに対して必要なジャム/スプーフの送信電力、実際のアンテナパターンのもとでの軌道上の捕捉フットプリント、追尾ループのスプーフ捕捉の引き込み結果、大気のない天体の水平線到達距離、OSNMA/TESLA の認証バジェットをつなぎ合わせます。空の本体は、P1 のベースラインを再現します。
• 電力不足の感度帯（linkbudget::deficit_sensitivity_band、deficit_power_factor）：sweep::SweepAxis の上に構築し、received_signal_power_dbw を通じて評価する、本物の多軸掃引（基準 × EIRP × スラントレンジ）で、P1 の 12–18 dB の帯を再現し、線形係数の 32×（丸め後）/ 36×（丸め前）という数値の食い違いを調整します。
• 三次元のスプーフ捕捉キューブ（spoof_capture::capture_cube）：捕捉マップに搬送波/ドップラーオフセットの軸を加えます（J/S × コードオフセット × 搬送波オフセット、セルごとのロック時間）。搬送波ゼロのスライスは、2 次元の capture_map に厳密に一致します。

変更#

• 疎なモニターネットワークの検出（monitor_network）は、自由パラメーターや場当たり的な大円の重なりではなく、物理的な spoof_monitors の AGC 統計と lunar_service の月面座標の可視性グリッドを組み合わせて、各局の検出統計と幾何を導くようになりました。モニターごとの検出確率とネットワークの検出確率は、これまでどおり detection のカイ二乗/Marcum-Q の閉形式です。SurfaceMonitor / SpoofEvent のフィールドは、物理的な（緯度/経度/高度/電力の）量に変わりました。

修正#

• OSNMA/TESLA の認証オーバーヘッドの見積もり（nma_budget）：ページごとの OSNMA フィールドの部分（2 秒ページあたり 8 ビットの HKROOT + 32 ビットの MACK）が、サブフレームごとの合計と誤ってラベル付けされており、オーバーヘッドが 15 倍（1.33 bit/s）過小に見積もられていました。公開されている SIS-ICD の 30 秒サブフレームあたりの合計（HKROOT 120 + MACK 480 ビット ⇒ 20 bit/s）に訂正しました。その帰結は、現在は正直に述べられています。50 bit/s の AFS の航法レートでは、認証オーバーヘッドは無視できる数パーセントではなく、一次の ≈40 % のコストです。auth_latency フィールドは、鍵開示の遅延（認証済みの初回測位までの端から端までの時間の下限）として文書化されています。

0.24.0 - 2026-07-09#

幅広い機能のリリースです。完全に外部で確認済みの二つの解析スイート（完全な多基準意思決定分析（MCDA）の族と、アラン揺らぎ / 長 τ の時計安定度の推定量）を取り込み、基盤の上に、新しい実行可能な月の時間バジェット、リアルタイムのフレーム/EOP、光/RF ハイブリッド、シスルナー観測可能性、階層型 PNT の紛争耐性のシナリオ層を開き、さらに月面ビーコンと信号セキュリティの機能基盤を加えます。機械で検証される検証マトリクスは、102 行にわたり 51 VALIDATED · 47 MODELLED · 4 PARTNER に増えます（以前は 91 行にわたり 40 · 47 · 4）。新しい十一の行はすべて、意思決定分析とタイミング推定量の外部オラクルによる検証で、独立したライブラリ（SciPy、pymcdm、pyDecision、allantools）と厳しい許容差で照合しており、新しい PNT の機能面は、正直に MODELLED として示されます。これまでどおり、外部データセットの裏付けなしに数値モデルの主張を格上げすることはありません。

追加#

実行可能なシナリオ：それぞれが登録済みのシナリオ kind で、エンジンを通じてディスパッチされ、tests/determinism.rs（同梱のすべての scenarios/*.toml を実行し、実行できないフィクスチャーがあれば強制的に失敗する）によって CI で端から端まで確認されます。

• 階層型 PNT の紛争耐性（conflict-resilience、src/conflict_resilience.rs）：多層 PNT アーキテクチャのための、シード付きのモンテカルロ・レジリエンスエンジンで、§4.2 のベクトルごとの段階的劣化の生存モデル（名前付きの四つの脅威ベクトル、層ごとのモンテカルロが収束する、使える PNT の生存の閉形式を結果の JSON に出力）と、文書化され、ドリフトを防ぐ脅威パラメーターの出所（src/conflict_threat_params.rs）を備えます。アーキテクチャは MODELLED で、生存のモンテカルロから閉形式への収束が、確認済みの中核です。
• シスルナー観測可能性（cislunar-observability、src/cislunar_observability.rs）：アーク上の可観測性グラミアンの固有スペクトル、微分補正した遠方逆行軌道（DRO）のシーダー、事後共分散がフルの可観測ランクでちょうど有限になる独立した平方根情報フィルターによる相互確認です。コンステレーションは MODELLED で、ランク/グラミアン/STM/SRIF の不変量が、確認済みの中核です。
• 異種の光/RF ハイブリッドの連続性とインテグリティ（hybrid-optical-rf、src/hybrid_integrity.rs、src/optical_availability.rs、src/optical_linkbudget.rs、src/cross_raim.rs）：光と RF の PNT を組み合わせたときの、領域をまたぐ可用性とインテグリティです。MODELLED。
• 内生的な月の時間バジェット（lunar-time-budget、src/lunar_time_budget.rs）とリアルタイムのフレーム / EOP バジェット（realtime-frame-eop、src/realtime_frame_eop.rs、src/frame_eop.rs）：P3/P4 の月の時刻と地球姿勢のバジェットを、主張するのではなく、タイミングの連鎖から内生的に導きます。MODELLED。

外部で確認済みの解析スイート：ライブラリ機能で、それぞれが、自己チェックではなく独立した外部オラクルと照合して確認され、新しい VALIDATED の行としてマトリクスに入ります。

• 完全な多基準意思決定分析（MCDA）スイート（src/mcda/）：四つの手法の族、すなわち価値の集約（WSM、WPM、WASPAS）、比率システム（MOORA）と比例（COPRAS）、理想点までの距離（TOPSIS）、妥協計画法（VIKOR）、アウトランキング（六つの一般化基準の形を持つ PROMETHEE II、ELECTRE I の一致/不一致）に加え、Saaty の整合比（CR < 0.10）のゲートを持つ AHP のペロン固有ベクトルによる優先度の重み、MAUT の効用、パレートフロントの抽出、重みの感度分析を含みます。九つの集約器は pymcdm / pyDecision を再現し、AHP の固有ベクトルは SciPy/LAPACK と一致し、いずれも < 1e-9 です（tests/mcda_*_reference.rs）。感度のトルネードは、紛争耐性シナリオの中にも現れます。
• アラン揺らぎと長 τ の時計安定度の推定量（src/allan.rs）：MTIE（同期マスクが基づく ITU-T G.810/G.823/G.8261 のピークツーピークの時刻誤差の揺らぎ統計）、MDEV と TDEV の時間領域の揺らぎ、Theo1 / TOTVAR の拡張範囲の推定量です。NIST SP 1065 の系列で allantools と照合して VALIDATED です。TOTVAR に基づくバイアス除去済みの ThéoH ハイブリッドは、正直に MODELLED のままです。
• 保証 / 外部オラクルのハーネス（src/assurance/）：CI の誠実性ゲートに直接つながれたオラクルハーネス、決定論的な Merkle ルートを持つ W3C-PROV の出所記録、安定度推定量に対する Greenhall の等価自由度とカイ二乗の信頼区間です。
• PackRegistry / ExternalPack の拡張シーム（src/registry.rs、src/api.rs）：機能パックが一つのレジストリを通じて経路設定されるようにするディスパッチのシームです（組み込みのディスパッチは CLI のホットパスにあり、ツリー外のパックは、既定付きの ExternalPack::register_into の背後に接続されます）。ゴールデンのバイト同一性適合スイートと、スタンドアロン / wasm32 の CI ゲートで守られています。

モデルから計算された機能の基盤：上のシナリオと今後のシナリオに供給する新しいライブラリモジュール（まだ単独のシナリオ kind ではありません）。

• 月面ビーコンの DOP（src/lunar_beacon.rs）：達成精度のバジェット、N 衛星の掃引、GDOP マップを備え、加えて摂動付きの月のエフェメリス（src/lunar_perturbed.rs）と、大気のない水平線の幾何 / スプーフ電力の逆算 / AFS の不足帯域（src/jamming.rs、src/linkbudget.rs）を含みます。gnss_lib_py で確認済みの DOP カーネルを再利用します。
• LOLA 形式の DEM 取り込みと地形の見通し線（src/realdata/lola_dem.rs）。
• 信号セキュリティの三層防御：スプーフ捕捉、センサー間のインテグリティ、モニターネットワークの規模設計（src/spoof_capture.rs、src/cross_sensor_integrity.rs、src/monitor_network.rs）に、軌道ビームのアンテナフットプリントと OSNMA の認証バジェット（src/antenna.rs、src/nma_budget.rs）を加えます。MODELLED。

変更#

• 検証マトリクスと、そこから導かれるすべての成果物は、唯一の情報源（src/verification.rs）から再生成されました。サイト上の台帳、モジュールマップと検証の出所の図、README と各面の件数の文字列は、現在 102 中 51 / 47 / 4 と表示されています（以前は 91 中 40 / 47 / 4）。件数の誠実性ガードは、現在は git の全履歴をスキャンし、README の図はダークなブランドパレットに統一されました。
• 共有の適応的な積分ドライバーが、integrate と integrate_dopri の両方（src/integrator.rs）を支えるようになり、重複していたステッパーを取り除きました。
• SonarQube Cloud の静的解析を CI に追加しました（Rust + 取り込んだカバレッジ）。README には、セキュリティ / 保守性 / 信頼性のレーティングバッジが付きます。

サードパーティの AI クライアントに言及している一節は、ここでは省いています。GitHub の CHANGELOG.md にあります。

• リリース / パッケージングの規律：CI は、パッケージ/レジストリの公開ごとにデプロイ環境を登録し、焦点を絞った公開スタンドアロンのジョブは、遅い検証バイナリの対象から外されました。
• 帰属表示なしの衛生ガードは、作成者を示すマーカーだけを対象とするようになったため、統合先のホストや製品に言及してもビルドが失敗することはなくなりました。
• ドキュメント：README の引用セクションは、公開済みの四つの arXiv プレプリントを一覧するようになり、月面ビーコンの DOP 機能は、月の行に記載されました。

修正#

• 浮動小数点で駆動されるループの整数ループカウンター（Sonar S2193）。
• 保証の信頼区間の経路で、ニュートン法による改良を通じて、低い自由度でのカイ二乗の逆関数を正確にしました。
• kshana.dev：規格セクションは既定で開くようになり、台帳の件数のフォールバックが訂正されました。観測可能性の層まわりの古い README / サイトの文字列も同期しました。

0.23.0 - 2026-06-29#

一般的なフィッシャー情報 / クラメール・ラオの可観測性と最適実験計画の層を加える機能リリースであり、月面 PNT の可観測性に関する論文が基づくリリースです。機械で検証される検証マトリクスは、91 行にわたり 40 VALIDATED · 47 MODELLED · 4 PARTNER に増えます（以前は 89 行にわたり 39 · 46 · 4）。新しい推定エンジンは外部オラクルと照合され、VALIDATED です。その月面への適用は、正直に MODELLED です。これまでどおり、外部データセットの裏付けなしに数値モデルの主張を格上げすることはありません。

追加#

• src/fim.rs：フィッシャー情報、クラメール・ラオの下限、最適実験計画。汎用で再利用できる推定理論のエンジンです。測定ヤコビアンと重みからのフィッシャー情報行列 M = HᵀWH、対称固有値ソルバー（巡回ヤコビ法）、逆行列、または情報がランク不足の場合（自由網/データム欠損の場合）にはムーア・ペンローズの擬似逆行列と零空間基底によるクラメール・ラオの下限、そして候補の幾何に対する best_design セレクターを持つ D、A、E、T 最適の実験計画の指標を備えます。NumPy（eigh/inv）と、Kay（1993）の公表されている閉形式の下限に対して 1e-9 まで VALIDATED です（tests/fim_observability_reference.rs）。このため、自己チェックではなく、外部オラクルの行としてマトリクスに入ります。
• 月面の統合軌道決定の可観測性（src/lunar_combination.rs の lunar_observability、月面の統合レポートに表示）：FIM/CRLB のエンジンを、軌道と時計の統合解に適用し、絶対的な観測局のデータム欠損、地球基線の観測局を加えるにつれてのそのランクの回復、達成される観測局位置の CRLB、E 最適の条件数を明らかにします。正直に MODELLED です。推定エンジンは外部で確認済みですが、それを適用する月面ネットワークは代表的なシミュレーションであり、現在のどのデータセットも、その幾何を測定に変えることはできません。
• 月面統合シナリオのための、代表的な楕円月面凍結軌道（ELFO）の幾何（orbit_ecc、orbit_inc_deg、orbit_argp_deg、orbit_planes。円形配置は引き続き既定）と、VLBI なしの可観測性フィールドをレポートに追加し、データム欠損の結果が幾何に依存しないことを示せるようにしました。同じ 3→1→0 の段階と三局のしきい値は、Moonlight/LCNS 系の ELFO でも成り立ち、三本の地球 VLBI 基線があれば、絶対的な観測局位置はサブメートルの限界で観測可能です。これは elfo_geometry_confirms_the_observability_structure で固定されています。引き続き MODELLED です。

変更#

• 検証マトリクスと、生成されたすべてのエビデンス成果物は、唯一の情報源（src/verification.rs）から再生成されました。台帳（web/data/verification-matrix.json）、docs/VERIFICATION-MATRIX.md、docs/MODELLED-RATIONALE.md、検証内訳とオラクル種別の図、およびすべての配布面にある README の件数の文字列は、現在 91 中 40 / 47 / 4 と表示されています。

0.22.1 - 2026-06-29#

パッケージングのみのパッチリリースです。エンジン、シナリオ、結果に変更はなく、検証マトリクスは 89 行にわたり 39 VALIDATED · 46 MODELLED · 4 PARTNER のまま変わりません。

修正#

• npm の公開：クレートのマニフェストから導かれたパッケージの repository.url が、大文字小文字の誤った GitHub のオーナー（AshfordeOU）を使っていたため、npm の sigstore による来歴検証（オーナーを大文字小文字を区別して照合します）に失敗していました。マニフェストの repository は正規の小文字の ashfordeOU になったため、生成される package.json は来歴の主体と一致し、npm のリリースが公開されます。

変更#

• ホイールのビルドは codegen-units = 1 を固定し、manylinux のホイールが再ビルドしてもバイト単位で再現できるようにします（再ビルドして差分を取る再現性チェック）。

0.22.0 - 2026-06-29#

エビデンス、来歴、配布の規律に重点を置いた統合リリースです。機械で検証される検証マトリクスは、89 行にわたり 39 VALIDATED · 46 MODELLED · 4 PARTNER に増えます（以前は 61 行にわたり 15 · 42 · 4）。これは、モデルから計算された機能を、独立した外部オラクルと相互検証したことによるものです。配布されるすべての成果物は、暗号学的な SLSA ビルド来歴の証明を持ち、CycloneDX SBOM を同梱し、すべての面で歩調を合わせて公開されます。外部データセットの裏付けなしに数値モデルの主張を格上げすることはなく、新しい機能は正直に MODELLED のままです。

追加#

• 姿勢力学（src/attitude_dynamics.rs、MODELLED）：トルクフリーの剛体オイラー方程式とクォータニオン運動学（RK4）に、保存則の自己テスト（クォータニオンのノルム、運動エネルギー、|Iω|、対称コマの歳差）を備えます。
• モデルから計算された機能の相互検証を独立した外部オラクルに対して行い、検証マトリクスを 39 件の VALIDATED の行にしました。いずれも外部データセットの裏付けがあります（CI の誠実性ゲートは、それがない VALIDATED のステータスを禁止します）。最新の外部オラクルによる検証は次のとおりです。光時計の実測安定度曲線（quantum_trade の ADEV 曲線の当てはめは、Norcia らが公表した ⁸⁸Sr 光格子時計の σ_y(τ) を再現します。Science 366:93（2019）、Zenodo 10.5281/zenodo.3382347、CC-BY-4.0、tests/fixtures/optical_clock_adev/ に同梱）。GPS L1 C/A の拡散コード生成（src/sdr.rs の G1/G2 LFSR は、PRN 1–9 について IS-GPS-200 の Table 3-Ia のコード位相の八進数を再現します）。実際の地形での SRTM 数値標高リーダー（src/altpnt/terrain.rs は、同梱されたパブリックドメインの NASA/USGS SRTM v3 のタイル N36W117 / デスバレーを読み込み、Badwater Basin を文書化された測量の範囲内に置きます）。
• 新しい MODELLED の機能。それぞれ、閉形式または兄弟のコード経路に対して内部で相互確認されています。Clohessy–Wiltshire / Hill の相対運動力学、TDOA/FDOA の受動的な発信源位置推定、Wahba/TRIAD/QUEST による姿勢決定、GNSS の搬送波位相の整数アンビギュイティ解決（LAMBDA）、B 平面ターゲティングとパッチドコニックによる重力アシスト、CRPA 耐ジャムのアレイビームフォーミング、GNSS の二乗則による捕捉統計、量子慣性センサーの縞のアンビギュイティ / ダイナミックレンジ、IEEE-1139 のべき乗則の時計ノイズとフリッカー FM のフロア、CCSDS-OEM の共分散ブロックの交換です。
• 単一の情報源によるエビデンス台帳に、生成された検証ドキュメントとドリフトガードを備え、kshana.dev には、カードごとのエビデンスへのディープリンクを持つ、閲覧できる検証台帳があります。
• 機械可読な引用メタデータ：codemeta.json（CodeMeta 2.0）と .zenodo.json で、tests/citation_metadata_doc_sync.rs により Cargo マニフェストに固定されています。
• サプライチェーンの来歴：クレートの tarball、ホイール、sdist、npm の tarball に対する SLSA ビルド来歴の証明、PyPI の OIDC Trusted Publishing、ホイールと npm パッケージに同梱した CycloneDX SBOM、再現可能ビルドの差分とリリース後の検証です。
• 発見されやすさ：kshana.dev の robots.txt、sitemap.xml、Open Graph / JSON-LD のメタデータ、マトリクスから導かれる、生成された validation-breakdown の図です。
• crates.io / PyPI / npm 向けの面ごとの READMEと、件数の誠実性ガードです。

変更#

• Sagnac 時刻伝送オラクルを ExternalDataset に格上げしました。赤道周回のサニャック補正は、Ashby の公表値 207.4 ns（Living Reviews in Relativity 6:1、2003、Eq. 1.29。< 0.05 ns まで再現）と照合されるようになりました。複合的な時刻伝送機能は、正直に MODELLED のままです。
• ドキュメント、図、グラフを最新のマトリクス（39/46/4/89）に更新しました：検証の出所の図、oracle-kind-stacked の図（マトリクスから生成され、CI のドリフトガード付き）、VALIDATION/PROVENANCE/CAPABILITY/QUANTUM-MODELS/WHEEL_TAGS、アーキテクチャとチュートリアルのドキュメント、kshana.dev の台帳の合計です。
• ソースツリーを、固定された rustfmt（ツールチェーン 1.93.0）で再整形しました。純粋にスタイルのみで、動作は変わりません。
• 歩調を合わせたバージョニング。すべての配布面（クレート、PyPI、npm、MCP クレートと OCI イメージ、JetBrains プラグイン）は、エンジンと歩調を合わせてバージョン付けされ、CI の scripts/check-version-sync.sh で強制されるようになりました。
• JetBrains プラグインは AGPL-3.0-only に再ライセンスされ（公開済みの 0.1.1 は、なお Apache-2.0 と表示していました）、Marketplace のバージョンをリリースタグから導くようになりました。
• 堅牢性の強化：テスト以外の unwrap を除去または正当化し、clippy::unwrap_used をテスト以外のコードに対してゲートしました。
• kshana.dev の、証明を最優先にした刷新：目立つヒーロー、アーキテクチャ図と結果のグラフ、i18n、折りたたみ可能でレスポンシブな台帳と規格のセクションです。

修正#

• SP3 精密エフェメリス：補間の際に IGS の地球自転ノード補正を適用します。
• レジストリの画像：PyPI/crates.io/npm の README は絶対 URL の画像を使います。メインの README の相対画像パスは、PyPI の 0.21.0 のページで壊れた画像として表示されていました。CI のガード（tests/surface_readme_image_urls_doc_sync.rs）が、その再発を防ぎます。
• CI：fmt と clippy が緑になりました。git で無視される実データに対するコンパイルをやめました。

テスト#

• カルマン時計共分散は、半正定値かつ対称のまま保たれます（プロパティテスト、tests/property.rs）。
• ドキュメント同期のガード：公開されているすべての検証件数の文字列、引用メタデータ、生成された図、各面の README の画像 URL は、すべて唯一の情報源に固定されます。

0.21.0 - 2026-06-26#

このリリースは、オープンなエンジンに、MODELLED の二つのアプリケーションスイートを加えます。量子対応 PNT のデモンストレーター（信頼できる量子時刻伝送、GNSS を使わない量子航法、量子の故障/異常検出）と、月 / シスルナー PNT スイート（月の座標時、月の VLBI、統合 OD+クロック、座標系の実現、サービスボリューム、差分 PNT、相互運用エクスポート）で、それぞれが一つの kind から実行でき、それぞれが正直な TradeEvidence の記録と、代表性 / 飛行までのギャップの台帳を出力します。さらに、六つの新しい外部オラクルによる検証も加わり、機械で検証される検証マトリクスは、61 行にわたり 15 VALIDATED · 42 MODELLED · 4 PARTNER になります。新しいアプリケーションの数値は、例示用の公開情報源のパラメーターから MODELLED とされたものであり、TRL、飛行実績、認証、機関による推薦はありません。それらが再利用する確認済みのカーネルも、その旨をラベル付けしています。

追加#

• 量子対応 PNT のデモンストレータースイート（quantum-time-transfer、quantum-gnss-free-nav、quantum-anomaly-detect）。エンジンの背後で実行できる三つの MODELLED のアプリケーション領域で、それぞれが TradeEvidence と、代表性 / 飛行までのギャップの記録を出力します。
  • 信頼できる量子時刻伝送（src/timetransfer_chain.rs）：光格子時計 + フォトニックリンク対 CSAC + RF の双方向バジェットで、タイミング保護レベルを再利用し、遅延/リプレイ攻撃のセキュリティ FoM（1 − P_md）と、時計の異常検出 + CUSUM の遅延を備えます。
  • GNSS を使わない量子航法（src/quantum_nav_od.rs）：GNSS の途絶にわたる、冷却原子干渉計による慣性の惰行と、航法級の INS との比較です。外部の測位がなければ、加速度計のバイアスは観測不能のままで、誤差は依然として増え続けることを正直に示します。
  • 量子の故障 / 異常検出（src/quantum_faults.rs）：ラベル付きの故障カタログに、ブートストラップ信頼区間付きの ROC AUC と、固定した誤警報率での最小検出可能故障を備えます。
  • 共有の量子デバイス誤差モデルライブラリ（src/quantum_devices.rs）と、統一された量子対古典のトレードハーネス（src/qtrade.rs）が、三つすべてを支えます。
• 月 / シスルナー PNT スイート。CR3BP コアの上に重ねた、七つの実行可能な MODELLED の kind です。月の座標時（LTC/TCL − TT の永年レート、src/lunar_time.rs）、測地的な月の VLBI 遅延観測量（src/lunar_vlbi.rs）、複数手法を統合した OD + クロックのバッチ推定器（src/lunar_combination.rs）、座標系の実現（7 パラメーターのヘルマート変換 + IAU 2015 WGCCRE との結び付け、src/lunar_frame_realise.rs）、Moonlight / LCNS クラスのサービスボリュームの解析（src/lunar_service.rs）、月の差分 PNT（src/lunar_dpnt.rs）、LunaNet / IOAG に整合した相互運用エクスポート（KIF エンベロープ内の CCSDS-OEM と月の時刻系、src/lunar_interop.rs）です。すべて、例示用の公開情報源のパラメーターから MODELLED とされたものであり、実際の VLBI / Gateway の追跡に対しては確認されておらず、機関との関係や推薦はありません。
• 外部オラクルによる新たな検証六件（検証マトリクスは現在、15件が独立した外部の参照と照合して確認済みです）：
  • 実機の 5071A セシウム時計での ADEV / HDEV — Stable32 の十年点の参照値と照合して確認済み（tests/cs5071a_reference.rs）。
  • Stable32 の PHASE.DAT 参照での OADEV / MDEV / TDEV — Stable32 が公表している表と照合して確認済み（tests/phasedat_reference.rs）。
  • ESA OPS-SAT の実テレメトリでの異常検出 ROC AUC — scikit-learn と照合して確認済み（tests/opssat_ad_reference.rs）。
  • ICGEM 重力汎関数の合成 — GRS80 正規重力の標準と照合して確認済み（Somigliana の γ で 3.5e-12 まで。EGM2008 の擾乱マップ、tests/icgem_gravity_reference.rs）。
  • Klobuchar 放送電離圏モデル — RTKLIB と照合して確認済み（tests/klobuchar_reference.rs）。
  • RAIM 検出カーネル（171ケース、tests/raim_reference.rs）と、実際の EGNOS データでの SBAS DO-229E 保護レベル（RTKLIB SBAS-PL フォーク、tests/sbas_reference.rs）— いずれも外部オラクルと照合して確認済みです。
• 代表性とフライトまでのギャップの台帳（ledger）（src/representativeness.rs）。すべてのデモンストレーターが出力する構造化記録で、何が代表的か、何が簡略化されているか、モデルとフライトの間に何が残っているかを示します。あらゆる MODELLED のトレードに添えられる、率直な補足資料です。
• スタディ集計と CLI の使い勝手。シナリオスイートのマニフェストによるワンコマンドのスタディ集計、ハッシュが安定したスタディメタデータ + --study-name、--validate によるシナリオの lint、スタディレポートでの FoM ごとの検証ティアの表示。

変更#

• kshana.dev を共通のドメインスパインを軸に再設計 — 機能と検証を共通の語彙を持つ単一のドメインエクスプローラーに統合し、新たに確認済みとなった領域を表示し、陸地に忠実なアニメーション付きの地球インストゥルメントとスタディ依頼の CTA を加え、Ashforde OÜ のブランド表記とリンクを反映しました。
• README と ARCHITECTURE を網羅性と誠実さの観点で監査 — 古くなっていた確認済みの件数を修正し（現在は外部オラクル15件）、図を拡充し、Conditional Timing Protection Level（arXiv:2606.24210）と RF 障害の楽観ギャップ（arXiv:2606.22054）のプレプリントを引用しました。
• paper/ のソースと JOSS 原稿のパイプラインは、公開リポジトリで管理しています。

0.20.0 - 2026-06-22#

本リリースでは、オープンなエンジンに四つのスタディ機能を追加しました。条件付きタイミング保護レベル、フレームワークに沿った PNT レジリエンスのスコアリング、RF 障害の楽観ギャップ評価、ソフトウェア無線受信機・実データのフロントエンドです。いずれも一つのコマンドで再現でき、バイト単位で決定的な成果物を書き出します。すべてのスタディは MODELLED（合成データまたは公開データセットによる較正）であり、出所（エンジンのバージョン、シード、設定のハッシュ）と検証ラベルを率直に明記しており、認証ではありません。

追加#

• 条件付きタイミング保護レベル（tpl）。GNSS スプーフィング下で未検出の時刻誤差に対する、ホールドオーバーで制限された上界です。k シグマのモニター下限、検出遅延にわたる van Loan のコースト分散、CUSUM のアラーム発報時間を備えます。実際に記録された攻撃（JammerTest 2024、シナリオ 2.1.1）で較正しており、cargo run --release --example tpl_jammertest により、公開されている記録から復元したスカラー値から参照表を再現します（生のデータセットは再配布しません）。
• フレームワークに沿った PNT レジリエンスのスコアリングと意思決定の不安定性スタディ（resilience）。アーキテクチャモデル、RPCF に沿ったスコアリング、ディリクレ重みの単体、Kendall の tau と top-1 反転率による不安定性、共通モードの多様性の崩壊（Hill-N2）を扱い、cargo run --release --example resilience_report -- paper-artifacts/resilience-study.json を伴います。クロスウォークは docs/RESILIENCE-CROSSWALK.md にあります。
• RF 障害の楽観ギャップスタディ（impairment_study、impairment_ml、eval_stats）。パラメーターに基づく合成コーパス上の13検出器パネル、分布内と分布外の楽観ギャップ、順列ヌルを伴うスケーリング則の傾向、leave-one-out の劣化予測器を、cargo run --release --example optimism_study -- paper-artifacts/optimism-study.json により実行します。
• ソフトウェア無線受信機のフロントエンド（sdr）と実データアダプター（realdata/）。生の IQ/IF から相関器タップと SQM まで、さらに取り込みアダプター（RINEX、u-blox UBX、GnssLogger、JammerTest、Yunnan、SatGrid）とプローブ用のサンプルを備えます。これらはユーザーがローカルに用意した記録を読み込むもので、記録はコミットされていません。
• コミット済みのスタディ成果物。バイト単位で決定的な optimism-study.json と resilience-study.json を paper-artifacts/ 配下で管理するようになり、再ビルドせずにスタディの数値を確認できます。上記のジェネレーターから再生成することも引き続き可能です。生のデータセットはリポジトリに含めません（/realdata-cache/）。

変更#

• バージョンを Cargo.toml、CITATION.cff、README で 0.20.0 に更新しました。クロスオーバースタディの成果物は、スタンプがリリース版と一致するよう再生成しています。

0.19.0 - 2026-06-18#

変更#

• ライセンスを Apache-2.0 から GNU AGPL-3.0-only に変更しました。Ashforde OÜ から商用ライセンスも選択できます（デュアルライセンス）。オープンなエンジンは引き続き完全にオープンで、公開のまま検証できます。AGPL のネットワーク・コピーレフト（§13）により、クローズドまたはホスト型の派生物はオープンソースに戻すか、商用ライセンスを取得する必要があります。これにより、公開され、実行でき、監査できるエンジンという信頼性を保ちつつ、確認済みのコアをフォークしてクローズドにされることから守ります。LICENSE（AGPL）と、新設の LICENSING.md（各ライセンスの対象範囲と適用される場面）を参照してください。
  • LICENSE は AGPL-3.0 の全文を含むようになりました。全ソースの SPDX ヘッダーは AGPL-3.0-only に更新し、NOTICE、README、GOVERNANCE、GLOSSARY、ウェブサイト、クレート・パッケージのメタデータ（Cargo.toml、pyproject.toml、CITATION.cff、MCP クレートとイメージ）もこれに合わせて更新しています。
  • コントリビューター規約（CONTRIBUTING.md）は、AGPL でのインバウンドライセンスに加えて、商用ライセンス版に貢献物を含める権利を Ashforde OÜ に付与するものとなり、デュアルライセンスが引き続き機能します。
  • 依存関係のポリシーは変更なしですが、根拠を改めて示しました（deny.toml、GOVERNANCE）：依存関係は引き続き寛容なライセンス（Apache/MIT/BSD/ISC）に限ります。AGPL を認めるのは kshana 自身のクレートだけです。コピーレフトの依存関係は商用版を汚染し、デュアルライセンスを成り立たなくします。
  • 下流の利用者への注記：今回はコピーレフトへのライセンス変更です。Apache-2.0 の寛容な条件を前提にしていた利用者は、公開済みの最後の Apache-2.0 リリース（v0.18.0 以前）を引き続き使用できます。v0.19.0 以降は AGPL-3.0 / 商用です。

セキュリティ#

• pyo3 を 0.24 から 0.29 に更新し、外部の OSV・依存関係スキャンで検出されていた RUSTSEC-2026-0176 / RUSTSEC-2026-0177（GHSA-36hh-v3qg-5jq4 / GHSA-chgr-c6px-7xpp）を解消しました。どちらも関数レベルのアドバイザリーで、対象の関数（BoundList/TupleIterator::nth/nth_back、PyCFunction::new_closure）を Kshana は一切呼び出さず、pyo3 もオプション（python 機能）の依存関係であるため、実際の影響はありませんでした。ただし、下流の監査担当者向けにスキャン結果をクリーンに保つため更新しています。src/python.rs を pyo3 0.29 の API に移行しました（scenario_kinds の戻り値の型を Bound に変更。RunOutput の pyclass に skip_from_py_object を明示）。Python バインディングのテスト11件はすべて、再ビルドした拡張に対して成功しています。

0.18.0 - 2026-06-17#

追加#

• 実行可能な新しいシナリオ種別十一件 — 二テンダーのデモンストレーター、CCSDS 相互運用ブリッジ、一次近似のミッション解析・環境スイート（すべて MODELLED、追加のみ。既存の再現性ゴールデンは変更なし）。いずれも CLI / Python / WASM / MCP から呼び出すことができ、scenarios/<kind>.toml を同梱し、結果の JSON と一行サマリーに MODELLED ラベルを明示しています（tests/dominance_demonstrators.rs の種別ごとのテストで、ラベルが存在すること、および出力に文字列 VALIDATED が決して含まれないことを検証しています）：

  • impairment-eval（src/impairment_eval.rs）— 機械学習による RF 障害検出の評価テストベッド：ラベル付きの合成コーパス + 検出器に依存しない ROC/AUC ハーネス + 分布内・分布外の楽観ギャップレポート（動作特性のみ。フィールドデータや IQ データは一切使いません）。
  • quantum-trade（src/quantum_trade.rs）— 実測 ADEV の取り込みと GNSS 拒否下のレジリエンス包絡線を備えた、量子と古典の PNT トレードです。
  • space-weather（src/space_weather.rs）— 太陽・地磁気指数（Kp↔ap の IAGA 表、日別 Ap、中心化した81日 F10.7a）、Jacchia-71 外圏温度、静的な大気の上に重ねた活動駆動の熱圏密度カップリング（NRLMSISE の絶対密度モデルではありません）。
  • oem-interop（src/oem.rs）— GMAT / Orekit / STK のエフェメリス向けの CCSDS 502.0 OEM のインポートと往復変換ブリッジ（parse_oem リーダーは、ライターの厳密な逆変換です）。
  • launch-window（src/launch.rs）— 二体問題の打ち上げ方位角（sin Az = cos i/cos lat）、軌道面変更の Δv、射場の自転による増速効果、毎日の打ち上げ機会のジオメトリ。
  • reentry（src/reentry.rs）— Allen-Eggers 弾道再突入コリドー：最大減速度、最大 g と最大加熱の速度、最大 g の高度。
  • eo-coverage（src/eo_payload.rs）— EO のスワス / GSD / アクセス / 再訪ジオメトリ（SMAD の space-triangle）。
  • space-packet（src/space_packet.rs）— CCSDS 133.0-B Space Packet のプライマリヘッダーのエンコード・デコード（ビット単位で一致する往復変換）。
  • attitude-budget（src/attitude_budget.rs）— 3自由度の重力傾斜トルク + RSS ポインティング誤差バジェット（ハードウェア以前のスカラーバジェットであり、制御ループではありません）。
  • passes（src/passes.rs）— 地上局の可視・不可視パス予測（AOS/TCA/LOS、最大仰角、アクセス）。
  • link-budget（src/linkbudget.rs）— 片方向の CCSDS-401 / DSN-810-005 リンク方程式（C/N₀ = EIRP − FSPL − L_other + G/T − k、FSPL / Eb·N₀ / マージン / クロージャ）。

• 17状態のハイブリッド量子 + 古典の密結合 UKF — 実行可能なシナリオとして公開（MODELLED）。新しい hybrid-ukf シナリオ種別（src/fusion/hybrid_ukf.rs、scenarios/hybrid-ukf.toml）で、これまで API からしか使えなかった17状態の密結合 GNSS/INS アンセンテッドフィルター（src/fusion/tightly_coupled17.rs）を、CLI/Python/WASM/MCP のバインディングから呼び出せるシナリオにしました。17状態の誤差ベクトルは、15個の INS 誤差状態（位置、速度、姿勢のずれ、加速度計とジャイロのバイアス）に、CAI 由来の加速度計バイアス補正を加えたものです。冷却原子干渉計（src/inertial/quantum_imu.rs）が速度ランダムウォークの下限 q_va を決めるため、長期のコースト・ドリフトは量子センサーが限界を決めるものになります。さらに位相と周波数の2状態クロックを持ち、そのプロセスノイズは q パラメーターのクロックエンジン（clock_state::q_from_allan。クロックのアラン偏差プロファイルを q_wf/q_rw の PSD に対応づけ、距離の単位にスケーリング）から得ます。プラットフォームは、助走区間では GNSS の支援を受け（フィルターがバイアス、速度、クロックを学習します）、その後は CAI IMU とクロックだけで GNSS 途絶をコーストするため、この実行は古典 IMU の短期 + 量子の長期というハイブリッド化を示します。性能指標はフィルターの自己整合性です。モンテカルロのアンサンブルにわたってプールした NEES（Normalised Estimation Error Squared。推定可能な位置・速度・クロックの部分集合について）とイノベーションの白色性の NIS（Normalised Innovation Squared）を、95% の χ² 帯域（Bar-Shalom §5.4）と照合します。整合したフィルターは帯域内に収まり、意図的に調整を外したフィルター（q_factor / r_factor のノブ）は検出されます。客観的に確認でき、判別力のある判定基準であり、形だけの承認ではありません。NEES・イノベーション白色性の検査は「統計的オラクル」です。これは自己整合性の主張（想定したノイズの下で、フィルターが報告する共分散が、自身の誤差の広がりと正直に一致していること）であり、実世界の精度を保証するものでは「ありません」。適用範囲についての率直な注記：すべてモデル・シミュレーションです。CAI とクロックの入力は、文献に基づく代表的な値の範囲であって実測のハードウェアではありません。CAI のハードウェアとそのキーパーソンはパートナーの管理下にあり、TRL > 3、フライト実績、外部での検証を示唆するものは何もありません（結果の JSON と一行サマリーにこれらのラベルを明示しています）。等速・水平の単一軌道では、姿勢と IMU バイアスの状態は弱くしか可観測にならないため、NEES は推定可能な8状態について評価します。17状態すべてを可観測にする機動軌道は、ロードマップ上の項目です。あわせて、Ukf::update_stats（更新ごとの NIS を返します）と TightlyCoupled17::{update_gnss_nis, nees, nees_subset} の整合性計測も追加しました。既存のシナリオはすべて影響を受けません（追加のみ。再現性ゴールデンは変更なし）。

• 逐次（再帰）地形参照航法 — 実行中のフィルターとしての SITAN。新しい terrain-slam シナリオ種別（src/altpnt/sequential.rs、scenarios/terrain-slam.toml）は、既存の高度計と DEM の測定モデルを、terrain-nav が単一の一定 INS オフセットを復元するために使うバッチの粗から細への探索ではなく、particle_filter の SIR エンジンでエポックごとに実行します。各ウェイポイントで、粒子群は INS が報告した増分（それ自体がステップごとのドリフト増大で劣化しています）で伝播され、地形の一致度で重み付けし直され、縮退時にはリサンプリングされます。そのため、一定オフセットの当てはめでは原理的にできない、時間変化する INS ドリフトを軌跡に沿って追跡できます。合成 DEM 上では、再帰推定は有界のまま再収束し（最終値は約 70 m）、補助なしの慣性解は際限なく発散して約 5 km に達します。エポックごとの誤差は地形の特徴の出方に従い（平坦な鞍部ではバイアスのある INS でコーストし、特徴的な起伏で再ロックします）、有効サンプル数のモニターは粒子群が健全であることを裏付けます。適用範囲についての率直な注記：地図は既知で固定です。格納済みの DEM に対する再帰的な位置推定（地形 SLAM の位置推定の半分）であって、地図の同時推定ではありません。構成上、循環論法にはなりません（注入したドリフトのランプが独立した真値です）。既存のシナリオはすべて影響を受けません（追加のみ。再現性ゴールデンは変更なし）。

• GNSS 拒否下のレジリエンススパイン + FutureNAV デモンストレーターのスライス（src/holdover.rs、および src/impairment_eval.rs、src/quantum_trade.rs、src/navsignal.rs、src/inertial/quantum_imu.rs 配下のレジリエンス包絡線の基礎、src/verification.rs の FutureNAV 検証スライス）。クロックのホールドオーバー、信号トラッキング、慣性コースト、地形といった代替 PNT の構成要素を組み合わせ、GNSS 途絶時のレジリエンスを一つの筋書きとして示します。MODELLED。追加のみ。

• Kshana Interchange Format（KIF）— バージョン付きで自己記述的な成果物エンベロープ（src/interchange.rs）。シナリオ結果をスキーマタグ付きのラッパーで包み、保存した成果物が自身の種別、スキーマバージョン、MODELLED/VALIDATED ラベルを持ち運べるようにします。古いエンベロープも前方互換で読めます。追加のみ。既存の結果 JSON は変更なし。

• 航法信号の変調・トラッキングと CR3BP ハロー/NRHO の微分補正器（src/navsignal.rs、src/cr3bp.rs）。一次近似の航法信号の変調・トラッキングモデルと、ハロー軌道・準直線ハロー軌道のための円制限三体問題の微分補正器を、既存の深宇宙の機能軸に追加しました。MODELLED。

• impairment-eval の分布シフト評価モードとコーパスの重大度スケールのノブ（src/impairment_eval.rs）。ROC/AUC の楽観ギャップのハーネスに、分布内・分布外の明示的な分割と、調整可能なコーパスの重大度スケールを追加しました（動作特性のみ。フィールドデータや IQ データは一切使いません）。

• カバレッジあたりコストの ROI と検出見逃しのインテグリティ影響のマッピング（src/frugal.rs、src/integrity_impact.rs）。フルーガル・エンジニアリングの ROI の視点（単位カバレッジあたりのコスト）と、検出見逃し率からインテグリティへの影響への対応づけです。MODELLED。追加のみ。

• 出典付きの冷却原子干渉計（CAI）誤差モデルのパラメーターシート（src/inertial/quantum_imu.rs）。CAI 慣性モデルのための、文献を参照した範囲付きのパラメーターシートです。入力は出典のある値であり、実測のハードウェアではありません（TRL やフライトに関する主張はありません）。hybrid-ukf の速度ランダムウォークの下限に入力されます。

• プロジェクトのガバナンス。 GOVERNANCE.md に意思決定モデルとオープンとクローズドの境界を記載しました。これを反映して、機能マップのコミュニティ/ガバナンスの行は none → partial に変わります。

修正#

• ARAIM インテグリティ保護レベル — 公称バイアス（b_nom）と σ_URA を適用しました。MHSS 保護レベルは、故障モードごとに片側の公称バイアス射影 b_k = Σ_i |s_i|·b_nom を差し引くようになり、Integrity Support Message に含まれるインテグリティ用の σ_URA（精度用の σ_URE とは別のもの）を使います。これにより保護レベルはより保守的で、規格に即したものになり、その結果、既存のインテグリティシナリオが報告する PL の値が変わります。ISM・シナリオには #[serde(default)] の sigma_ura_m / b_nom_m フィールドが加わるため、これらを未設定にした入力は従来の動作を維持します。復元した b_k の式と実装上の率直な注記は docs/ARAIM_REFERENCE.md を参照してください。

• スプーフィングモニターの χ² 整合性。 parity_raim_test は共有の raim::chi2_quantile 逆 χ² 経路を使うようになりました。これにより、χ² の実装が食い違って二つ存在する状態をなくし、RAIM とパリティのスプーフィングモニターで閾値が一致します。

• gravity-map-nav を CLI のディスパッチャーに接続しました。このシナリオはこれまで API 経由でしか使えませんでしたが、ほかのシナリオと同様に kind= として呼び出せます。

• ドキュメントと件数の正確さ。README のシナリオ種別の件数を scenario_count_doc_sync テストで api::list_scenario_kinds().len() に固定したため、記載された件数がディスパッチャーとずれることはなくなりました。

0.17.0 - 2026-06-14#

追加#

• 深宇宙・火星 PNT — オープンな電波航法エンジン + GSE シミュレーション。地球で確認済みのコアの上に載る、完全に追加のみの新しい機能軸です（既存の地球向けシナリオはすべてバイト単位で同一で、再現性ゴールデンは再生成なしでそのまま通ります）。追加内容：多天体の力学コア（Body{mu, re, zonals, gravity, rotation, IAU-pole}。火星 GMM-3 のテッセラル重力、IAU の火星固定座標系、差し替え可能な EphemerisProvider の接続部、マイクロ秒未満の精度の二部構成ユリウス日、TT↔TDB を含みます）、電波観測量（反復的な光行時間 + シャピロ遅延、Moyer の二区間解による二方向・一方向・三方向のドップラーと距離、コヒーレントなトランスポンダーのターンアラウンド、CCSDS 414 に沿った再生・PN レンジング、CCSDS 506 に沿った Δ-DOR、太陽プラズマ・対流圏・電離圏の媒質）、CCSDS-TDM（503）の解析と出力、RTN の経験的加速度と三状態の搭載クロックと火星の大気抵抗モデルを備えた縮約力学の平方根情報フィルター、一方向と二方向を統合した推定器、CLI・Python・WASM・MCP・プレイグラウンドにわたる mars-pnt シナリオの面（中継コンステレーション + LMO/遷移/地表）、そしてエンドツーエンドの GSE 性能シミュレーター（ジオメトリ → リンクバジェット → 観測量 → SRIF → 共分散）です。検証ティア — シミュレーションで確認：合成の閉ループ OD（火星 LMO で約 0.2 m）と解析的な自己整合性に加え、太陽中心の火星力学は JPL DE440 と独立に照合しています（xval/anise-mars-od、カーネル依存：1日アークで 137 m。モデル化していない n 体の残差をそのまま示した値です）。報告している深宇宙の精度はシミュレーション・共分散上の性能指標であり、実ミッションの結果ではありません。実際の DSN/ESTRACK の追跡データによる検証はロードマップ上の項目です。ANISE（MPL-2.0、edition-2024）はワークスペースから除外した照合用クレートに隔離しているため、cargo deny のライセンスゲートと MSRV-1.75 のジョブには影響しません。
• 実際の IERS 地球姿勢パラメーターによる、機関水準の地上軌跡。ephemeris シナリオは、実際の IERS finals2000A ファイルの本文をインライン化した、任意の eop_finals2000a フィールドを受け付け、そこから補間したエポックごとの UT1−UTC と極運動で地上軌跡を換算し、公称の dut1_s/xp_arcsec/yp_arcsec のスカラー値を上書きします（EopSeries は precise_od が使うものと同じです）。データはシナリオに同梱されるため、実行は再現可能なまま、ファイルシステムを必要としません（WASM プレイグラウンドでも動作します）。kshana --eop <finals2000A> フラグを使うと、CLI から実際のファイルをシナリオに取り込めます。これにより、実際の地球姿勢データを使えるのが precise_od だけだった非対称が解消されます。

修正#

• 距離変化率の座標系の整合。地上局は、衛星の換算の厳密な逆変換（frames::itrf_to_teme。極運動と恒星時の回転を戻します）で慣性系に写像されるようになり、極運動を考慮しない GMST の回転は使いません。これで両端点が同じ座標系を共有します。報告されるドップラーへの影響は検証の下限より小さいものですが、実際の座標系の不一致と、ソース中の「厳密」という過大な記述を解消します。
• carrier_hz は検証されるようになりました。搬送波周波数がゼロまたは有限でない場合、ドップラーをゼロとして黙って出力するのではなく（λ = c/carrier が無限大になっていました）エラーを返すようになり、既存の step_s のガードと揃いました。

0.16.0 - 2026-06-11#

追加#

• エフェメリスのフィッティングによる力モデルの検証、実際の機関プロダクトとのクロスバリデーション。変分状態遷移行列と外れ値編集を備えた新しいバッチ最小二乗推定器（src/precise_od.rs）を、完全な力モデル（PreciseForceModel：EGM2008 ジオポテンシャル、第三体、固体・海洋・大気の潮汐、経験的な CPR/2-per-rev 加速度）で駆動し、実際の IERS finals2000A 地球姿勢パーサーで入力します。公表されている参照軌道と照合して確認済みです：Galileo MEO はポストフィットで 13 cm、ESA の Swarm-A LEO、LRO 月周回（月中心、GRAIL 重力、IAU-2015 の天体固定座標系 — 縮約力学で 6.6 m。オープンな経路では目標の 5 m を率直に上回っています。これに到達する DE 水準の ANISE/DE440 経路は、ワークスペースから除外したクレートです）。
• spoof-detect シナリオ — エポックごとの RAIM パリティ、AGC、信号品質（SQM）のモニターと、それらを統合した判定を組み合わせた、多層のスプーフィング検出器です。公表されている TEXBAT のシナリオパラメーター（Humphreys ら、ION GNSS 2012）と照合して確認済みで、搬送波が整列した困難なケースも含みます。
• ephemeris シナリオ — 状態、座標系、地上軌跡、ドップラー。一機の衛星（TLE→SGP4 または解析軌道）を伝播し、ステップごとに、慣性系の TEME と GCRS の状態（位置と速度）、地球固定の ITRF/ECEF 位置、WGS-84 の衛星直下点の地上軌跡（緯度 / 経度 / 高度）、そして地上局から見た地平座標の方位角 / 仰角 / 距離と、距離変化率およびドップラーを出力します。CLI、Python、WASM、MCP サーバーから利用でき、ウェブプレイグラウンドでは「Ground track」プリセットとして提供しています。そこでは軌跡を実際の世界地図の上に描画します（Natural Earth 1:110m の海岸線を埋め込み済みで、ネットワークも外部依存も不要です）。
• CCSDS OEM エクスポート（--export-oem / export_oem = true）— GMAT / Orekit / STK が読み込む、速度を含む Orbit Ephemeris Message で、既存の SP3 および OMM エクスポーターと同等です。
• ジオポテンシャルに対する固体、海洋（FES2004）、大気（Ray 2001 S2）の地球潮汐（IERS Conventions 第6章）を力モデルに組み込みました。
• ARM64 ホイール — PyPI のビルドで、Linux aarch64（manylinux_2_28）、macOS arm64、Windows arm64 のホイールも生成するようになりました。
• 拡張技術レポート（プレプリント）を README からリンクし、JOSS の論文を投稿可能な状態にしました（著者の ORCID を追加し、変更のたびに CI で PDF にコンパイルします）。

変更#

• 座標系を、公表されている Vallado のベクトルとミリメートル単位で照合して確認済み。TEME→PEF/ITRF の換算、CIO IAU 2006/2000A の GCRS→ITRS の全連鎖、ECEF→測地系 WGS-84 の変換を、内部の自己整合性だけでなく、Vallado ら（AIAA 2006-6753）の計算例とその IERS EOP に固定しました。
• 独立した時間尺度のクロスチェック。ERA と UTC/TAI/TT の時間尺度は hifitime と < 1 µs の範囲で一致し、DE440 惑星エフェメリスは JPL Horizons（月・太陽の地心位置）と一致します。どちらも常時有効な CI ゲートです。
• ウェブプレイグラウンドは、結果に性能指標の行がない場合は性能指標タブを非表示にするため、グラフのみのパック（エフェメリス、RAIM、スプーフィング）は空の表ではなく、そのグラフ（エフェメリスでは地上軌跡）が最初に開きます。
• プレイグラウンドのガイド付きスライダーとパラメーター掃引が、エフェメリス / 地上軌跡シナリオで使えるようになりました。地上局の緯度・経度、時間ステップ、継続時間、UT1−UTC を調整でき、パス幾何（最大仰角、ピークのドップラー、高度、速度）をそれらのいずれかに対してプロットする掃引もできます（例：最大仰角と地上局の緯度）。掃引タブは、シナリオが実際に掃引可能な場合にのみ表示されるため、何もプロットしない操作がどのパックにも現れることはありません。
• GMST の呼び出し箇所で、SGP4 の DUT1 ≈ 0 近似を文書化しました（回転誤差は ≤ 約13″ で、SGP4 自身のモデル誤差よりはるかに小さい）。あわせて CAPABILITY.md を更新しました。

0.15.1 - 2026-06-09#

追加#

• Kshana — PNT simulator の JetBrains プラグインが公開・承認され、JetBrains Marketplace で入手できます。README、kshana.dev、配布ドキュメントから直接リンクしています。

修正#

• MCP レジストリへの公開が成功するようになりました。server.json の description がレジストリの100文字の上限を超えていました（HTTP 422）。これを短縮し、サーバー名（およびイメージの所有者ラベル）を正式な名前空間 io.github.ashfordeOU/kshana-mcp に揃えました。
• JetBrains Marketplace への公開が成功するようになりました。CI が、手動で掲載済みのものと同じバージョンのプラグインを再アップロードしており、Marketplace に拒否されていました。プラグインのバージョンを 0.1.1 に更新し、冪等性ガードも「already contains version」という応答を、何もしない成功として扱うようになりました。
• kshana.dev のキャッシュバスティング：バージョンを付けた style.css/app.js のクエリ文字列がリリースに追従するため、再訪問したユーザーも常に最新のビルドを取得できます。

0.15.0 - 2026-06-08#

追加#

• kshana-mcp — Model Context Protocol（MCP）サーバーとしての Kshana（mcp/kshana-mcp/）。ワークスペースから除外した独立クレート（rmcp SDK は edition 2024）で、独立した外部の参照で確認済みのエンジンを、stdio 経由で AI エージェントやアシスタント（Cursor、JetBrains AI Assistant / Junie、あらゆる MCP クライアント）に公開します。ツール：run_scenario、list_scenario_kinds、validate_scenario、export_sp3、export_omm。いずれも kshana::api の薄いラッパーです。
• JetBrains IDE プラグイン（ide/jetbrains/）。シナリオの .toml を右クリックして Run Kshana Scenario を選ぶと、性能指標と結果の JSON が Kshana ツールウィンドウにストリーミングされます。プラットフォームのみで構成した Kotlin プラグインで、2024.3 以降のすべての JetBrains IDE と互換性があります。
• 両方について、公開配布とリリースごとの自動公開を行います：
  • kshana-mcp を publish.yml 経由で crates.io（cargo install kshana-mcp）へ。
  • kshana-mcp をマルチアーキテクチャの OCI イメージとして ghcr.io（docker run ghcr.io/ashfordeou/kshana-mcp）へ、新しい mcp-publish.yml 経由で。
  • kshana-mcp を GitHub OIDC（シークレットなし）経由で公式 MCP レジストリへ。レジストリのエントリ（server.json）は、ラベルで所有者を確認する OCI パッケージタイプを使います。
  • IDE プラグインを、各リリースタグで publishPlugin（トークン制御、開発者署名は任意）経由で JetBrains Marketplace へ。

0.14.1 - 2026-06-08#

追加#

• ANISE/SPICE による独立した座標系のクロスバリデーション（xval/anise-frames/）。ワークスペースから除外した独立クレートが、kshana の IAU 2006/2000A CIO 換算（kshana::cio::gcrs_to_itrs_matrix、GCRS→ITRS）を、JPL の earth_latest_high_prec.bpc を使って GCRF→ITRF93 を回転させる ANISE（Rust のみで再実装した NAIF/SPICE）と照合します。両側に同じ IERS finals2000A の地球姿勢パラメーターを与え、2020〜2023 年の四半期ごと八つのエポックで比較しました。独立した二つの座標系の実現は、最大の相対回転で 0.028″ の範囲で一致しました。これは地上で ≤ 0.86 m、LEO で ≤ 0.93 m、GNSS 軌道で ≤ 3.6 m です。長年の ROADMAP にある「< 10 m」の座標系クロスチェックに、大きな余裕を持って適合しています（既存のビット単位で一致する SOFA/ERFA のアンカーを補完するものであり、置き換えるものではありません）。anise と hifitime は MPL-2.0 / edition-2024 であり、公開する kshana の依存関係グラフ、その Cargo.lock、cargo deny のライセンスゲート、MSRV ビルドには決して入れてはならないため、このクレートは隔離しています。ANISE は default-features = false で固定しています。frame-xval バイナリ（約5 MB の BPC を取得し、表を出力し、report.{json,md} を書き出します）、カーネル・ネットワークがなければ自動でスキップするテストゲート、workflow_dispatch のみで動く任意の CI ジョブ（main を止めることはありません）を含みます。docs/VALIDATION.md（CIO の行）と ROADMAP.md に記載しています。

修正#

• モバイルに適したプレイグラウンド。スマートフォンでプレイグラウンドの .panel に生じていた横方向のはみ出しを修正しました（CSS グリッドのアイテムが既定で min-width: auto となり、ビューポートより約100 px 広く描画されていました）。min-width: 0 と幅を制限したコントロールで対処し、360 / 390 / 414 / 768 px で問題がないことを確認しました。「Pin to compare」と「Download report」のアクションボタンを揃えました（flex の行内でマージンボックスを同じにしました）。実行ボタン、スライダー、セレクト、ナビゲーションリンクを、スマートフォンとタッチ端末で WCAG 2.5.5 / Apple HIG のタッチターゲット最小値である約44 px に拡大しました。デスクトップでの大きさは変更ありません。

0.14.0 - 2026-06-08#

修正#

• 敵対的なバトルテストで見つかった堅牢性の強化。（1）sbas_protection_level は、有限でない仰角・方位角・分散と、負または有限でない共分散の対角成分を拒否するようになりました（小さな σ でスケールアップされたほぼ特異なジオメトリが、従来は絶対ピボットのゲートをすり抜け、NaN の VPL や異常な HPL を有効な Some として返すことがありました。これは黙って起きるインテグリティの失敗でした）。（2）数値伝播器（propagate/propagate_dopri）は、有限でない初期状態に対して、適応制御を延々と回し続けるのではなく、安全側で失敗するようになりました。（3）DEM のセルヘルパーは、単一サンプル（1×N）のグリッドでパニックしなくなりました。（4）lunar_look_angle の方位角は [0, 360) に厳密に収まります。（5）SphericalHarmonicField::from_gfc は、物理的にあり得ない（NaN または非正の）GM・半径を拒否します。

追加#

• validation_report バイナリとリリース成果物：依存関係のないジェネレーターで、CI が強制するすべての検証（SGP4 666/666、EGM2008、ビット単位で一致する座標系、NIST Allan、IMU データシート、ARAIM/SBAS、3 OS での再現性、カバレッジ）を、そのテストと外部オラクルに対応づけた、印刷に適した一ページの HTML 検証サマリーを出力します。リリースワークフローは kshana-validation-summary.html を生成し、（SLSA の来歴情報とともに）各タグ付きリリースに添付します。
• numpy 連携の pytest とホイールの強化：tests/python/test_numpy_interop.py（CI で実行）、およびバージョンを固定した manylinux コンテナと、ホイールのビルドでの auditwheel show による確認ステップ。
• チュートリアルと教育：docs/tutorials/（三つの実践的なチュートリアル、領域ごとに注釈を付けたシナリオ、Tier-1/2/3 の演習）と、引用しているすべての数値をエンジンの実際の出力に固定する tests/tutorials.rs。
• 外部提出用の成果物（paper/、notebooks/、submissions/）：JOSS 論文の草稿、量子と古典のノートブック、awesome-gnss / ESA Navipedia / NASA ASCL / ESA ESSR / ION/IAC にそのまま提出できるキット、および FUNDING.yml。提出に向けた外部の手順を準備します。
• 地形参照航法と複合の代替 PNT 航法（altpnt モジュール）：DEM 上の TERCOM/SITAN 地形照合ナビゲーター（.hgt ローダー + 合成フィクスチャのジェネレーター）と、重力 + 磁気（IGRF）+ 地形を組み合わせた GPS 拒否下ナビゲーターを、terrain-nav と combined-altpnt のシナリオ種別として公開しています。地形照合の収束（注入した既知のオフセットを復元）と、GPS 拒否区間にわたる複合フィルターの誤差が有界であることで確認しています。
• LunaNet LANS ジオメトリ（lunar）：権威ある月面座標を持つ名前付きの月面サイト（Apollo 11/15/16、Shackleton リム）、地表の見通し角（方位/仰角/距離）、可視性・カバレッジ、サイトの DOP を扱い、月の半径、公表されているサイト座標、真上で仰角 90° になるという恒等式と照合して確認済みです。
• ガイド付きブラウザープレイグラウンド：ガイドモードのスライダー、タブ付きの出力パネル、初回起動時のツアーオーバーレイ、パラメーター掃引と複数実行のオーバーレイモード、依存関係のない canvas/SVG の3D 軌道ビュー（orbit パックは追加の eci_track を出力するようになりました）、埋め込み/iframe モード、HTML レポートとしてのダウンロード。いずれも CI で node のユニットテストを実行しています。
• データシートと照合して確認済みの IMU 誤差モデル（tests/imu_allan_spec.rs）：ADIS16465/16488/16460 の ARW/VRW/バイアス不安定性を、合成したアラン偏差から復元し、メーカーの仕様と照合しています（NIST SP1065 / IEEE 952 による同定）。
• NIST SP1065 のアラン推定量の検証（tests/allan_nist_sp1065_1000point.rs）：四つの推定量が、公表されている1000点の参照偏差と Table-32 の信頼限界を再現します。
• SBAS / DO-229E の保護レベル、L1/L5 電離圏フリー、DO-316 の compliance マップ（sbas モジュール）。sbas_protection_level は、各衛星の仰角・方位角と UDRE/GIVE/航空機/対流圏の誤差バジェットから重み付きジオメトリ行列を構成し、正規行列を反転し（共有の orbit::invert4）、DO-229E の K 係数（PA 6.0/5.33、NPA 6.18）で分散を HPL/VPL に射影します。iono_free_l1l5 は GPS L1/L5 電離圏フリーの疑似距離（IS-GPS-705、γ₁₅ = 1.79327）を追加し、エンジンが独立に持つ一次の電離圏遅延を打ち消すことで確認しています。do316_compliance_map は、DO-316/DO-229E の要件を、それを実装する関数に対応づけます。閉形式の K 係数の定義、numpy の inv(GᵀG) による参照ジオメトリ、二経路の共分散の恒等式と照合して確認済みです。公表されている PL による RTKLIB/gLAB の適合性クロスチェックは、docs/COMPLIANCE.md にレビュー待ちと記載しています。
• 完全なテッセラル球面調和の重力 — 次数・位数 70 までの EGM2008 場。新しい gravity_sh::SphericalHarmonicField は、完全正規化された C̄_nm, S̄_nm 係数から、地球固定系でのジオポテンシャルとその加速度を、安定した Holmes–Featherstone の正規化ルジャンドル漸化式で評価します（この次数では、非正規化するとオーバーフローします）。同梱の係数は NGA の EGM2008 プロダクト（パブリックドメイン、ICGEM 経由）で、egm2008_data.rs に収録し、コミット済みの tools/egm2008_to70.gfc から tools/gen_egm2008.py によりビット単位で再現できます。ICGEM の .gfc モデルであれば from_gfc で読み込めます。三つの独立したオラクルと照合して確認済みです：質点への縮退（C̄00 のみ = −μr/|r|³）、帯球調和のみの場が既存の forces::zonal_accel を約 1e-9 まで再現すること、そして解析的な加速度が、直接合計したポテンシャルの有限差分勾配と <1e-6 で一致することです。
• 一般相対論のレンズ・ティリング（フレーム引きずり）加速度（forces::lense_thirring_accel、IERS 2010 式 10.12）。既存のシュワルツシルト補正に加わる重力磁気項で、新しい ForceModel::lense_thirring() フラグにより数値伝播器に組み込みました。地球の角運動量に対して線形であること、およびシュワルツシルト項より 1〜2 桁小さいこと（LAGEOS / Gravity Probe B の測定が対象とする領域）で確認しています。
• 解析的な軌道伝播器と数値的な軌道伝播器を統一する Propagator トレイト。数値的なコーウェルの力モデル伝播器は、SGP4 と対等な第一級の存在になりました。新しい NumericalPropagator 型（初期状態 + ForceModel + Tolerance + ステップ倍増または Dormand–Prince の Integrator の選択）と Sgp4 はどちらも propagator::Propagator を実装し、その state_at(t_seconds) -> StateVector は SI 単位（m、m/s）の慣性 TEME 状態を返すため、Box<dyn Propagator> の背後で二つを入れ替えて使えます。SGP4 の実装は、固有メソッドの km/min から SI への厳密な換算です（等価性テストで確認）。数値実装は同じサブメートルの厳密ケプラーのゲートをトレイト経由で満たし、二つの適応ドライバーは一致し、PropagatorError は下層の SGP4 コードを表に出します。

0.13.0 - 2026-06-08#

本リリースは、エンジンで最も大きな正確性のギャップを埋めます。地球姿勢と座標系の換算が、参照実装の水準で行われるようになりました（ERFA/SOFA とビット単位で一致することを確認済み）。インテグリティのスタックには、実際の GPS+Galileo の TLE を用いた二コンステレーションの ARAIM が加わり、伝播、量子センサー、月・地球月間空間、地磁気の各層も深まりました。さらに、型付きの Python API、より充実したブラウザープレイグラウンド、三つの OS での再現性マトリクスも加わります。ハイライト：

• 座標系をビット単位で一致。完全な IAU 2000A と 2000B の章動、IAU 2006 の歳差、CIO ベースの (X, Y, s) による IAU 2006/2000A の GCRS↔ITRS 換算、IERS の極運動、TEME→GCRS/ITRS の出力座標系。いずれも ERFA/SOFA の参照ルーチンとビット単位で一致することを確認済みです。
• 実際の TLE を用いた二コンステレーションの ARAIM（GPS + Galileo）。HPL/VPL、Stanford 図の出力、公開された docs/ARAIM_REFERENCE.md を備えます。
• 地球・月間空間の PNT：地球・月の CR3BP 伝播器、MCI↔MCMF 座標系、月面座標、実行可能な LunaNet の月インテグリティシナリオ。
• 量子センシング：冷却原子干渉計のコリオリと AC シュタルクの系統誤差、ドリフト掃引、Freier（2016）のバジェットとの照合による確認。
• IGRF-14 地磁気主磁場モデル。自己完結で、確認済みです。
• 型付き Python API（PyO3 の RunOutput/ScenarioMeta、.data()、scenario_kinds、validate_toml、型スタブ）と CI でのホイールビルド、さらに GCRS/ITRS の伝播器出力と CCSDS OMM エクスポートも第一級でサポートします。
• 信頼性と再現性：独立した sgp4 クレートとの SGP4 精度の直接比較、CI のカバレッジゲート（src/ で行カバレッジ約97%）、三つの OS（ubuntu/macos/windows）での再現性マトリクス。

変更#

• プレイグラウンドのすべてのグラフがサイトのテーマに合うようになりました。十二個の SVG グラフ生成器すべて — 結果・ホールドオーバーのグラフ（src/report.rs + src/chart.rs）、アラン偏差のグラフ（web/app.js）、すべてのシナリオのグラフ（src/hybrid.rs、jamming.rs、timetransfer.rs、spoof.rs、raim.rs の Stanford と可用性、lunar.rs、ensemble.rs、sweep.rs、gnss_sim.rs、fusion/pack.rs、inertial/mod.rs）— は、冷たい紺色のパネル（#0e131b）、冷たい灰色の軸と文字、そして不揃いな赤・青・紫の系列パレットを使っていました。今後は全面的に暖色のグラファイトのパレットを使います。パネルは --bg、暖色のグリッドは --line、ラベルは --fg で、系列の割り当ても統一しました。量子 = はちみつ色のゴールド（--accent-bright）、古典 = 暖色のアンバー（--partial）、仕様・限界 = --crit です。安全に関わる色分けのビューは意味を保ちます。RAIM の Stanford 図は、緑（利用可能）/ アンバー（誤誘導）/ 赤（危険）/ くすんだスチール色（利用不可）のままで、HPL/VPL はゴールド/ブロンズで表示します。
• グラフは、保存・ダウンロードしても自己記述的になりました。どちらのグラフもタイトルを SVG に埋め込み（アラン偏差のグラフのタイトルと「lower is better」のサブタイトルは、これまで画像の周りの HTML にしかなく、保存した画像にはキャプションがありませんでした）、どちらも来歴フッター Kshana v<version> · <scenario-hash> · kshana.dev を備えるため、ダウンロードしたグラフはそれだけで成り立ち、再現も可能です。
• すべてのグラフが来歴フッターを備えるようになりました。フッター Kshana v<version> · scenario <hash> · kshana.dev は、api::run_toml ですべてのシナリオ種別に一括して刻印されるため（これまではホールドオーバーとアラン偏差のグラフにしかありませんでした）、プレイグラウンド、CLI の .chart.svg エクスポート、HTML スコアカードのいずれから保存・ダウンロードした画像でも、バージョン、シナリオのフィンガープリント、出典を特定できます。ハッシュには分かりやすいよう scenario のラベルを付け、結果の scenario_hash があればそこから取得し、インテグリティ・月レポートについてはソースのハッシュにフォールバックします。フィンガープリントが何であり、なぜあるのかは、README の「Output」の節と docs/PROVENANCE.md に記載しています。

修正#

• raim::chi2_quantile と RAIM の Stanford ノイズサンプラーは、範囲外や有限でない入力でもパニックしなくなりました（新しい ARAIM シナリオで見つかった、read_dir の順序に依存するファズの検出結果）。chi2_quantile は p/k を normal_quantile と同様に保護し（assert! でパニックする代わりに境界値を返します）、可用性の Stanford ノイズの Normal は厳密に正の σ に制限するため、インテグリティ・ARAIM のスタックは、改変されたシナリオや誤設定のシナリオでもパニックしません。

追加#

• クロスプラットフォームの再現性 CI マトリクス。新しい reproducibility-matrix ジョブが、プッシュのたびに ubuntu-latest、macos-latest、windows-latest で再現性テストを実行します。完全な結果 JSON は OS 間でバイト単位では一致しない（libm の最下位ビットの差）ため、プラットフォームに依存しない射影を厳密に検証します。すなわち、入力のフィンガープリントと出力の形状で、新しい tests/cross_platform_golden.rs により、シナリオごとの SHA-256 ゴールデンとして tests/golden/ に固定されています。これに加えて、数値の固定値（golden.rs、1e-6 まで）、SGP4 の状態（sgp4_verification.rs、2e-5 km まで）、同一プロセス内の決定性（determinism.rs）も検証します。これらを合わせることで、出力全体の厳密なバイトハッシュに伴う脆さなしに、三つの OS にわたるクロスプラットフォームの再現性を示します。docs/REPRODUCIBILITY.md にこの分け方を記載しています。
• CI のコードカバレッジゲート。新しい coverage ジョブが、LLVM のソースベースのエンジンで cargo-tarpaulin を実行し、lcov レポートをビルド成果物として公開し、src/（生成されたデータテーブル、CLI のエントリポイント、テスト、ウェブ資産は除外）に行カバレッジの下限を課します。実測の行カバレッジは src/ で約97%（SGP4 とクロックのモジュールは ≥95%）です。ゲートは 85% に設定しており、目標の ≥80% を上回り、かつ実測値から離れているため、不安定になることなく回帰を検出できます。カバレッジのバッジを README に掲載しています。
• 独立した sgp4 クレートとの SGP4/SDP4 の直接比較。新しいテスト（tests/sgp4_crate_comparison.rs）が、Kshana の伝播器を、最も広く使われている Rust の SGP4 ライブラリ（neuromorphicsystems/sgp4、テスト専用の dev-dependency として追加）と、同じ 666 個の AIAA 2006-6753 ベクトルでクロスバリデーションします。ベクトルが使う WGS72 重力モデルで両方を駆動すると、二つの独立した実装は、近地球軌道と共鳴軌道でサブミクロン、すべての領域を通じた最悪値で 4.12 mm の範囲で一致し、どちらも参照の tcppver.out の表を再現します。コミット済みの比較表（tests/fixtures/sgp4_comparison.md、KSHANA_REGEN_FIXTURES=1 で再生成）は、結果を領域ごと（LEO/MEO、深宇宙、半日共鳴と1日共鳴）に分け、このクレートが構築時に拒否する意図的に病的な四つのケースを注記しています。実行時のアサーションは、両者が参照の 2e-5 km 以内にあり、互いに 4e-5 km 以内で一致することを保証します。一度きりの結果ではなく、回帰の防御です。これは競合に対する実績です。静的な表だけでなく、独立したコードベースに対する正確性です。（このクレートの既定の from_elements は WGS84 を使うため、WGS72 の参照とは約 km の差があります。これは表の説明文で率直に示しています。）
• CCSDS OMM エクスポートが、エンドツーエンドで使えるようになりました。OMM ライター（src/omm.rs）にはこれまで CLI/API の経路がありませんでしたが、orbit シナリオの平均要素を CCSDS 502.0-B-2 の OMM カタログとして公開できるようになりました。TLE で定義された衛星ごとに OMM KVN メッセージが一つ出力され、kshana <orbit.toml> --export-omm out.omm を使うか、シナリオで export_omm = true を指定すると <scenario>.omm が自動で書き出されます（既存の --export-sp3 と同様です）。各メッセージは、衛星の実際の NORAD カタログ番号、COSPAR 国際識別符号（YYYY-NNNP）、元期（CCSDS の年内通算日形式）を持ち、TLE の1行目から新しい tle::parse_tle_identity で解析します。名前行は OBJECT_NAME になります（なければ OBJECT <id>）。CREATION_DATE は実時間ではなくシナリオの元期なので、出力は再現可能です。新しい API：api::export_omm / api::auto_export_omm、OmmFile::from_tle_block、OrbitClockScenario::to_omm_string。合成の Walker や RINEX のシナリオ（TLE の平均要素がない）は、空のファイルを出力するのではなくエラーになります。同梱の30衛星 gps-ops スナップショット（tests/sp3_export_roundtrip.rs）と照合して確認済みです。
• プレイグラウンドのグラフでの対話的なホバー表示。グラフ上でカーソルを動かすと、十字線が最も近いサンプルに吸着し、値のツールチップが表示されます（web/hover.mjs、web/app.js で接続）。アラン偏差のグラフでは τ と各クロックの σ_y(τ) を、時系列のシナリオグラフ（クロックのホールドオーバー、推測航法、時刻比較、ハイブリッド PNT、GNSS/INS）では、時刻と各スイートの値をグラフ自身の単位（ns / m / ps / 利用率）で表示します。値は結果から解析するため、表示は曲線と一致します。専用の図（RAIM、スプーフィング、掃引）にはオーバーレイを付けません。グラフは引き続き自己記述的な blob の <img> のままです。オーバーレイはその上に重ねた透明な十字線とツールチップなので、ダウンロード、比較、エクスポートには影響しません。座標の計算（最近傍サンプル、カーソルからプロット内の比率への変換、ポリラインの解析）はユニットテスト済みです（web/hover.test.mjs、CI で実行）。
• プレイグラウンドの A/B 比較モード。任意の実行をベースライン A として固定し、二つ目のシナリオを実行すると、二つが並んで表示され、性能指標の差分表（ホールドオーバー、タイミングの RMS/p95、可用性）で指標ごとの優れた側に色が付きます（web/compare.mjs、web/app.js で接続。差分のロジックは web/compare.test.mjs でユニットテストし、CI で実行）。すべての値はテキストとして挿入し、すべてのグラフは blob の <img> 経由で表示するため、シナリオの文字列がマークアップとして注入されることは一切ありません。
• グラフのダウンロードボタン（SVG + PNG）。プレイグラウンドの各グラフに、テーマに合った「Download SVG / PNG」ツールバーが付きました（web/chartdl.mjs、web/app.js で接続）。SVG は忠実で拡大縮小できる原本を返し、PNG は同じ自己記述的な画像を、スライドや文書向けに2倍でラスタライズします。ファイル名には来歴を付けます — kshana-<chart>-v<version>-<scenario-hash>.<ext> — し、ファイル名とサイズのロジックはユニットテスト済みです（web/chartdl.test.mjs、CI で実行）。
• IGRF-14 地磁気主磁場モデル（src/igrf.rs）。IAGA 標準の球面調和場（次数・位数 13、2025.0 元期 + 2025〜2030 年の永年変化。係数は公式の igrf14coeffs.txt から tools/gen_igrf.py により src/igrf_data.rs に機械生成し、ビット単位で再現可能）。Schmidt 正規化の合成により、任意の測地学的な位置・日付での磁場ベクトル（北/東/下）と導出要素（偏角、伏角、水平・全磁力）、さらに地磁気極と双極子の強さを返します。これは、代替 PNT 航法における重力マップマッチャーに対応する磁気版です。自己完結で確認済みです：合成は厳密な閉形式の傾いた双極子と一致し、次数13の完全な解析場はスカラーポテンシャルの有限差分と一致し、双極子軸は既知の地磁気極（約80.7°N、−72.7°E）と約29.7 µT の強さを再現し、全球の磁場は物理的に妥当です。
• 型付き Python バインディング（src/python.rs）。文字列入力・文字列出力の run/run_full に加えて、モジュールは型付きの RunOutput クラス（.json、.svg、.summary、および結果をネイティブの Python dict に解析して返す .data() アクセサー — JSON を再解析する必要がなく、NumPy でラップできます）、さらに run_typed、scenario_kinds()（解析済みのメタデータ dict のリスト）、validate_toml()（例外を送出せずエラーメッセージのリストを返します）を公開します。mypy/pyright/エディター向けに PEP 561 の型スタブ（kshana.pyi + py.typed）と、docs/PYTHON_API.md のクイックスタートを同梱します。既存の関数は変更ありません。
• 伝播器の第一級の出力座標系（src/orbit.rs の Frame 列挙型 + position_in_frame + state_gcrs）。あらゆる Propagator（Kepler、SGP4、RINEX、GLONASS、SP3）が、位置を TEME、GCRS（≈ J2000）、ITRS（地球固定）で出力できるようになりました。TEME はネイティブで、GCRS は確認済みの TEME→GCRS 換算で、ITRS はそれを IAU 2006/2000A の CIO gcrs_to_itrs 回転につなげて得ます。また、state_gcrs により GCRS の完全な状態（位置 + 速度）も出力できます。当日の慣性系出力は、もう TEME だけではありません。
• CIO ベースの IAU 2006/2000A による天球系から地球系への換算（src/cio.rs）。現代的な、分点を使わない GCRS↔CIRS↔ITRS の連鎖です。IAU 2006/2000A のバイアス・歳差・章動行列から読み取った CIP 座標 X, Y（確認済みの FW 歳差 + 2000A 章動を eraNut06a の P03 調整とともに再利用）、66項の CIO ロケーター s 級数（eraS06。ERFA の参照から tools/gen_s06.py により src/cio_s06_data.rs に機械生成し、ビット単位で再現可能）、GCRS→CIRS 行列（eraC2ixys）、地球回転角（eraEra00）、そして完全な GCRS→ITRS 回転（eraC2tcio。既存の IERS 極運動と合成）を備えます。公表されている eraXys06a（JD_TT 2453736.5 で X=0.5791308482835292617e-3、Y=0.4020580099454020310e-4、s=-0.1220032294164579896e-7）、eraC2ixys、eraEra00 のテストベクトルと、ビット単位で一致することを確認済みです。CIO の連鎖と、従来の分点/GMST-1982 による TEME 換算は、文書化されている約2·（分点差）の恒星時の慣例の違いを除いて一致することを示しています。これは、分点/GMST の経路が近似していた厳密な換算です。
• 完全な IAU 2000A 章動級数（src/nutation.rs の nutation_iau2000a、nutation_matrix_2000a）。完全な MHB2000 モデル（月・太陽項678個 + 惑星項687個）で、精度は < 0.1 mas、既存の77項の 2000B 打ち切りと並存します。表は IAU SOFA / ERFA の nut00a 参照から tools/gen_nut00a.py により src/nutation_iau2000a_data.rs に機械生成され（ジェネレーターはコミット済みのファイルをビット単位で再現します）、IERS-2003 と MHB2000 の基本引数の両セットと惑星経度を含む級数全体が、公表されている eraNut00a のテストベクトル（JD_TT 2453736.5 で Δψ = −0.9630909107115518e-5、Δε = 0.4063239174001679e-4、1e-13 rad まで）とビット単位で一致することを確認済みです。既定の TEME→GCRS 換算は 2000B 級数（約1 mas。連鎖の速度座標系回転の簡略化より小さい）を使い続けます。nutation_matrix_2000a は、必要な呼び出し側のために < 0.1 mas の当日行列を提供します。
• 実行可能な月インテグリティシナリオ（kind = "lunar-integrity"、scenarios/lunanet-araim.toml）。月の南極の保護レベルパス（src/lunar.rs の LunarScenario → south_pole_hpl_pass）を、JSON の LunarReport と SVG の HPL 対時間グラフとともにシナリオランナーに接続し、地球・月間空間のインテグリティのケースを CLI から直接実行できるようにしました。ギャップは率直に示されます。30 m の LANS σ_URE では、南極の HPL（≈ 260〜450 m）が 50 m のアラート限界を超えます（可用性 0 %）。月の PNT のインテグリティは、まだ達成されていません。
• 実際の GPS+Galileo の TLE による二コンステレーション ARAIM の可用性と、シナリオランナーへの接続（src/raim.rs、src/orbit.rs、scenarios/araim-gps-galileo.toml）。araim_dual_constellation_availability（高度な ARAIM エンジン。単一衛星の故障とコンステレーション全体の故障の両方を、時間グリッド上で実行）と visible_positions_labeled を追加し、araim_dual フラグにより IntegrityScenario ランナーに接続したため、複数 GNSS の ARAIM スタディを TOML から直接実行できます。同梱した 2026-06-07 の Celestrak GPS+Galileo スナップショットを用いた実データのテスト（tests/araim_dual_real_data.rs）では、厳しい 12 m の VAL のもとで、Galileo をプールすると ARAIM の可用性が 0.21 から 0.67 に上がります（可視衛星数は 10.5 機から 21.8 機）。一方、コンステレーション故障に頑健なモードは、コンステレーションが二つしかないと本質的に限界があります。頑健な二コンステレーションのインテグリティが、三つ目のコンステレーションや SBAS へ向かう定量的な理由です。率直な残課題：バージョンを固定した単一エポックに対する、EU ARAIM TN の Table A-3 の数値的に厳密な再現と、Zenodo のフィクスチャ記録です。
• 地球・月系の円制限三体問題（CR3BP）（src/cr3bp.rs）。二体問題/SGP4 の伝播器では提供できない、地球・月間空間の新しい力学コアです。回転座標系の運動方程式（cr3bp_accel）、RK4 伝播器（propagate_cr3bp）、ヤコビ定数の積分（jacobi_constant）、五つのラグランジュ点（lagrange_points）を備えます。閉形式・公表値のアンカーと照合して確認済みです：地球・月の共線点（L1 ≈ 0.83692、L2 ≈ 1.15568、L3 ≈ −1.00506）、厳密な正三角形点 L4/L5 = (½−μ, ±√3/2, 0)、五点すべてが場の平衡点であること、伝播中にヤコビ定数が積分器の精度で保存されること、そしてハロー/NRHO 軌道を可能にする面外の復元力です。これは、実際の NRHO を表現するための基盤です。率直な残課題：微分補正した周期的な 9:2 の NRHO 初期条件、離心率・エフェメリス（DE）モデル、src/lunar.rs の月心座標系への非正規化変換です。
• IERS 極運動と TEME→ITRF 換算（src/frames.rs）。polar_motion_matrix（SOFA の iauPom00：TIO ロケーター s′ を伴う W = Rx(−y_p)·Ry(−x_p)·Rz(s′)）、pef_to_itrf / itrf_to_pef、そして teme_to_itrf を追加しました。後者は GMST ベースの TEME→PEF 回転に極運動を続けたもので、GMST のみの teme_to_ecef の上に、ITRF 精度の地球固定位置を完成させます（極運動は、軌道半径で数十メートルの効果です）。x_p/y_p は、呼び出し側が与える観測された IERS の量です。率直な残課題：完全に CIO ベースの (X, Y, s) 連鎖と、ANISE/SPICE による <10 m の数値クロスチェックは、今後の課題として残っています。
• 冷却原子干渉計の系統誤差、ドリフト掃引、公表済みの装置による検証（src/inertial/quantum_imu.rs、docs/QUANTUM.md）。第一原理の CAI 加速度計を、決定論的な主要系統誤差二つで拡張します。コリオリ/回転位相 Φ_cor = 2·k_eff·v_⊥·Ω·T²（coriolis_phase。等価な加速度バイアス 2·Ω×v は coriolis_accel_bias による）と、AC シュタルク光シフト位相 Φ_LS = (δ_LS,1 − δ_LS,3)/Ω_eff（ac_stark_phase。一定のシフトでは π/2–π–π/2 の対称性により打ち消されます）です。さらに cai_drift_sweep（サイクル時間に対する推測航法の位置ドリフト。量子と古典の比較の核心）と、Freier ら 2016 のモバイル重力計（arXiv:1512.05660）に対する検証テストを追加しました。モデル化した量子射影ノイズの下限は、公表されている短期ノイズ 96 nm/s²/√Hz を下回り、その約2 桁以内にあります。docs/QUANTUM.md を更新しました。率直な残課題：波面・ビーム指向の系統誤差、フリンジのアンビギュイティ解決、CARIOQA-PMP / Boeing-AOSense の飛行試験の厳密な再現（公表されたプラットフォームの PSD が必要）、JS プレイグラウンドのプリセットです。
• 地球・月間空間の座標系換算と、月の南極のインテグリティパス（src/lunar.rs）。月の ARAIM エンジンを、MCI↔MCMF（月心慣性系 ↔ 月固定系）回転（mci_to_mcmf / mcmf_to_mci。月の恒星時レートでの簡略化した平均回転モデル）、月面の緯度・経度・高度（mcmf_to_selenographic / selenographic_to_mcmf）、そして south_pole_hpl_pass で拡張します。後者は、アルテミス領域に着陸した受信機を、代表的な LunaNet 中継セットに対して 24 時間のパスで評価するもので、インテグリティのギャップを率直に定量化します。公称の 30 m の LANS σ_URE では保護レベルは有限ですが、50 m の地表運用のアラート限界を超えます。率直な残課題：正確な LANS NRHO エフェメリス（3体の地球・月間軌道）、物理秤動と歳差運動する月の極（DE421/SPICE）、LunaNet の TOML シナリオは、今後の課題として残っています。
• ARAIM インテグリティサポートメッセージ、Stanford 図の SVG、公開された ARAIM リファレンス（src/raim.rs、docs/ARAIM_REFERENCE.md）。明示的な IntegritySupportMessage（σ_URA / σ_URE / b_nom / P_sat / P_const。WG-C の GPS+Galileo の参照値と、単一故障の araim_raim およびコンステレーション全体の araim_dual_raim エンジンへの .fault_priors() / .dual_fault_priors() 変換を伴う）、Stanford インテグリティ図（四つのゾーン、PL = error の境界、アラート限界のガイド、エポックごとに色分けした一つのマーカー）の独立した stanford_svg レンダラー、そしてアルゴリズム、ISM、故障仮説、保護レベルの契約、二コンステレーションの利点を記述した docs/ARAIM_REFERENCE.md を追加しました。テストは、ジオメトリと冗長性の利得（二つ目のコンステレーションをプールすると単一故障の HPL が小さくなる）と、コンステレーション故障への耐性（二コンステレーションの利用者はコンステレーション一つを丸ごと失っても動作し続けるが、単一コンステレーションの利用者は動作し続けられない）を示します。率直な残課題：バージョンを固定した実際の TLE スナップショットに対する EU ARAIM TN の Table A-3 / 15〜25 % の可用性の数値の再現、Zenodo のフィクスチャ記録、araim_dual_raim のシナリオファイルランナーへの接続です。
• IAU 2000B 章動と、完全な TEME→GCRS/J2000 慣性系換算（src/nutation.rs）。提供済みの IAU 2006 歳差の上に、真の慣性系換算の二つ目と三つ目の部品を加えます。77項の月・太陽 MHB2000 章動級数（nutation_iau2000b。精度約1 mas の標準的な IAU 2000B 打ち切り）、Delaunay の基本引数と SOFA の iauNumat 章動行列、そして Vallado の AIAA-2006-6980 の連鎖である TEME→TOD（分点差）→ TOD→MOD（章動）→ MOD→GCRS（バイアス・歳差）で、teme_to_gcrs(r, v, jd_tt) / gcrs_to_teme として公開しています。級数、引数、単位定数は IAU SOFA / ERFA の nut00b 参照から転記し、公表されている eraNut00b のテストベクトル（Δψ、Δε を 1e-13 rad まで）とビット単位で一致することを確認済みです。率直な残課題：完全な IAU 2000A の678項級数（<0.1 mas）、ANISE/SPICE の <10 m の数値クロスチェック、極運動は、今後の課題として残っています（ROADMAP.md を参照）。

0.12.0 - 2026-06-06#

本リリースは、Kshana 初の非解析的な軌道伝播器を実現します。Cowell 積分器と、六つの摂動を階層化した力モデル（二体 + J2–J6 帯球調和 + エポック駆動の太陽・月の第三体 + 円錐の本影・半影の影を伴う太陽放射圧 + 大気抵抗 + ポストニュートン的なシュワルツシルト相対論補正）で、適応積分器二種類（RK4 のステップ倍増と、Dormand–Prince RK5(4) の埋め込みペア）から選んで駆動します。あわせて、マヌーバ・軌道設計の層（インパルスと有限推力のバーン、Izzo のランベルトソルバー、ポークチョップ掃引）、60分間の GPS 拒否下の軌跡を 500 m 未満で復元する重力マップマッチングの代替 PNT 層、バッチと逐次の軌道決定パイプライン、量子 CAI の推測航法を備えた完全な17状態の密結合 GNSS/INS UKF も加わります。数値的な機能はすべて、解析的な真値または手導出の閉形式に固定しており、既定で無効の摂動は、リリース済みのゴールデンに影響しません。

追加#

• ポストニュートン（シュワルツシルト）の相対論補正（forces::relativistic_accel + propagator::ForceModel::relativity）。地球近傍軌道で支配的な一般相対論の摂動（相対論的な近地点移動の主因）を、IERS / Montenbruck–Gill の β = γ = 1 の形式 a = (μ/c²r³)·{[4μ/r − v²]·r + 4(r·v)·v} で追加しました。大気抵抗と同様に速度依存であるため、(r, v) 積分器の右辺に [accel_rv] 経由で組み込まれ、オプトインで、既定では無効です。自己完結で確認済みです：円軌道では閉形式 3μ²/(c²r³)·r̂（純粋に動径方向で外向き、軌道面外の成分は厳密にゼロ）に帰着し、二体項に対する比は LEO で教科書的な ≈1.9·10⁻⁹（μ/(c²r) の特徴）となり、動径速度のケースは手で簡略化した μ(4μ + 3v²r)/(c²r³) と一致し、伝播器内では軌道を散逸させることなく摂動を与えます。長半径は一日あたり一メートルを十分に下回る精度で保存され、これは抵抗による単調な減衰とは構造的に正反対です。既定で無効のため、二体/J2/帯球調和のゴールデンには影響しません。PPN パラメーター（β、γ）の調整とレンズ・ティリングのフレーム引きずり項は、今後の課題として残っています。
• 円錐の本影 + 半影の影モデル（forces::conical_shadow）。太陽放射圧で使うようになりました。二値の本影円柱による食を、滑らかな ν ∈ [0,1] の係数に置き換えます。太陽と地球を、見かけの角半径 a = asin(R☉/d☉)、b = asin(Rₑ/|r|) の円盤、見かけの中心間隔 c としてモデル化し、ν は、太陽の円盤が地球の円盤に隠される割合（円と円のレンズ状の重なり面積）を一から引いた値です。c ≥ a+b では完全な日照、c ≤ b−a では皆既の本影、c ≤ a−b では金環、その間は連続的な半影です。srp_accel がこれを使うようになったため、SRP の力はオン/オフの切り替えではなく、食の間を滑らかに推移します。IAU の公称値 forces::SOLAR_RADIUS を追加しました。自己完結で確認済みです：完全な日照で ν = 1、本影の深部で ν = 0（厳密）、滑らかで単調な半影（ν は [b−a, b+a] の帯で 0 → c = b で約½ → 1 と上昇）、そして円錐の半影が本影円柱の外まで広がること（二値の円柱が完全に日照とみなす点が、円錐では 0 < ν < 1 になる）です。より単純な cylindrical_shadow も引き続き使えます。太陽の周縁減光と扁平な地球の影は、今後の課題として残っています。
• Dormand–Prince RK5(4) 埋め込み積分器（integrator::dopri54_step / integrator::integrate_dopri + propagator::propagate_dopri）。標準的な Dormand–Prince（1980）の埋め込み Butcher 表のペアを、既存の RK4 ステップ倍増ドライバーと並べて追加しました。七つの FSAL ステージにより、一組の評価から5次解と4次の誤差推定が得られ（一ステップあたりの関数呼び出しは 7 回で、11 回に対して少なく）、局所誤差の推定が安価になります。適応ドライバーは同じ RMS 誤差ノルムと 0.9·(1/err)^(1/5) のステップ制御を再利用するため、そのまま差し替えて使えます。propagator::propagate_dopri が、軌道の力モデルに公開します。自己完結で確認済みです：埋め込みの誤差推定は O(h⁵) で（ステップを半分にすると約32× 小さくなる）、DP5(4) は y' = y を e まで積分し、調和振動子を 50 周期にわたって積分してエネルギーを <1e-6 まで保存します。同じ許容差で同じ終点に、ステップ倍増より少ない関数評価回数で（精度を犠牲にすることなく）到達します。propagate_dopri は RK4 経路と同じ解析的な真値のゲートを通過し、24 時間の LEO 軌道で、厳密な普遍変数のケプラー解に対してサブメートルです。また二つのドライバーは、J2..J6 の軌道（閉形式なし）で <1 m 以内で一致します。より高次の埋め込みペア（RKF7(8) / DOP853）は、今後の課題として残っています。
• 大気抵抗を、伝播器に最初の速度依存の力として接続（forces::atmospheric_density + forces::drag_accel + propagator::ForceModel::drag）。Vallado の Table 8-4 の区分指数関数大気 ρ = ρ0·exp(−(h−h0)/H)（海面から 1000 km 超まで28の帯。地表より下は下限で固定）と、共回転する大気 v_rel = v − ωₑ ẑ × r（forces::EARTH_ROTATION_RATE = 7.2921151467e-5）に対する二次の抵抗 a = −½ · ρ(h) · (C_D·A/m) · |v_rel| · v_rel を追加しました。抵抗は速度に依存するため、ForceModel に新しい accel_rv(t, r, v) が加わり、積分器の右辺は速度を渡すようになりました（f(t,[r;v]) = [v; a(t,r,v)]）。位置のみの accel_at は変更なしのため、保存力の項とゴールデンには影響しません。自己完結で確認済みです：密度は海面値 1.225 kg/m³ に固定され、地表より下では下限で固定され、LEO を通じて単調に減少し、400 km で太陽活動平均の約1e-12 kg/m³ の帯に入り、復元した局所スケールハイト（400 km で ≈ 58 km）は物理的に妥当です。抵抗は、C_D·A/m = 0.02 m²/kg のとき約2e-6 m/s² の LEO の大きさで、共回転する相対速度に逆らいます。そして決定的な特徴として、抵抗は散逸的です。300 km の軌道は比エネルギーを単調に失い、長半径は有界の約 km/日で減衰しますが、真空のベースラインではエネルギーが <1e-9 まで保存されます。NRLMSISE-00 の熱圏密度（< 5 % という抵抗密度の条項）は、今後の課題として残っています。
• 太陽放射圧を、エポック駆動で伝播器の力モデルに接続（forces::srp_accel + propagator::ForceModel::solar_radiation）。キャノンボール SRP モデル a = ν · P☉ · cᵣ · (A/m) · (AU/d)² · d̂ を、円筒影による食の係数（forces::cylindrical_shadow、ν ∈ {0,1}）とともに追加しました。現代の全太陽放射照度 1361 W/m²（≈ 4.5398·10⁻⁶ N/m²）による放射圧 P☉ = Φ☉/c、逆二乗の (AU/d)² による照度の減衰、そして太陽から遠ざかる動径方向の押しを含みます。第三体と同じエポック駆動の右辺に組み込まれ、ephem の太陽を、太陽の第三体と SRP で共有する進んだエポック epoch_jd_tt + t/86400 で一度だけサンプリングします。組み合わせ可能です：with_zonals_j2_j6().third_body(true, true, epoch).solar_radiation(1.5, 0.02)。手で導出した特徴に対して、自己完結で確認済みです：1 AU の放射圧は教科書的な ≈ 4.5398·10⁻⁶ N/m² に固定され、完全に日照下の LEO 衛星の SRP は、キャノンボールの式とビット単位で同一で、太陽から遠ざかる向きを指し、cᵣ = 1.5、A/m = 0.02 m²/kg で 約1.36·10⁻⁷ m/s² の帯に入ります。太陽までの距離を倍にすると大きさは四分の一になり（逆二乗）、円筒影は本影の円柱だけを食とし（太陽と反対側かつ地球と太陽を結ぶ線から地球半径以内）、食の間の SRP は厳密にゼロになります。伝播器内では、SRP は LEO 軌道にA/m にほぼ線形に比例する、小さく有界の摂動を与えます。一方、摂動のないモデルはビット単位で時間に依存しないままで、二体/J2/帯球調和のゴールデンには影響しません。円錐の本影・半影（滑らかな ν ∈ [0,1]）、大気抵抗、GMAT/Orekit との外部クロスバリデーションは、今後の課題として残っています。
• エポック駆動の太陽・月の第三体を、時間変化する伝播器の右辺に接続（propagator::ForceModel::third_body / accel_at）。第三体の摂動は、独立した力の項ではなくなり、Cowell 伝播器が時間変化する力として本当に積分するようになりました。右辺を評価するたびに、ephem の太陽・月の位置を進んだエポック epoch_jd_tt + t/86400 でサンプリングする（日と世紀の換算には precession::julian_centuries_tt を再利用）ため、摂動天体は開始時点で凍結されるのではなく、積分の間、軌道に沿って動きます。どの重力モデルとも組み合わせられます（ForceModel::with_zonals_j2_j6().third_body(true, true, epoch)）。自己完結で確認済みです：右辺の太陽項は、t = 0 と t = 1 day の両方で、その時刻の天体暦の位置で評価した third_body_accel とビット単位で同一で（86400 秒 ↔ 1 日 ↔ 1/36525 世紀の対応づけが厳密であることの証明）、摂動天体はサンプル間で約2.6·10⁹ m/日だけ進み（凍結されていません）、LEO での瞬間的な潮汐力の大きさは教科書的な約5·10⁻⁷ m/s²（太陽）と約1.1·10⁻⁶ m/s²（月。太陽の ≈ 2×）の帯に入り、各天体は一日分の軌道に測定可能な摂動を与えつつ、有界にとどまり、同じ初期状態を四半年離れたエポックで伝播すると異なる軌道になります（潮汐軸が 90° 回転）。一方、どちらの天体も有効にしないモデルはビット単位で時間に依存せず、二体/J2/帯球調和のゴールデンには影響しません。DE 水準のエフェメリス精度と GMAT/Orekit との外部クロスバリデーションは、今後の課題として残っています。
• 低精度の月エフェメリス（ephem::moon_position）。太陽と月の第三体の組を完成させます。太陽モデルと並べて、Montenbruck & Gill の低精度の月の級数（§3.3.2）を追加したため、天体を問わない forces::third_body_accel を、外部の DE/SPK カーネルなしに、どちらの天体でも駆動できるようになりました。手で導出した月の特徴に対して、自己完結で確認済みです：地心距離は、一か月を通じて実際の近地点・遠地点の範囲（約356,500〜406,700 km）に収まり、その月平均は約384,400 km の長半径を復元し、黄緯は月の軌道傾斜角約5.3° を超えず（赤道座標で黄道極に射影して確認し、緯度の級数と黄道傾斜の回転を合わせて検証）、月の方向は一恒星月（27.3217 日）後に 1° 以内に戻り、一日あたりの移動は物理的な 12〜15°/日の帯に収まり、LEO 衛星への月の第三体摂動は教科書的な約1.1·10⁻⁶ m/s² の大きさ（太陽の約二倍）です。DE 水準の位置精度、大気抵抗、SRP は、今後の課題として残っています。
• 内蔵の低精度エフェメリスによる第三体（太陽）の重力（forces::third_body_accel、ephem::sun_position）。力モデルに第三体の摂動を追加しました。a = GM₃·((s−r)/|s−r|³ − s/|s|³)（直接の引力から、地心座標系が差し引かなければならない間接項を引いたもの）で、太陽の位置は新しい ephem モジュールの Montenbruck & Gill の低精度の解析級数から与えます。低忠実度の実行には、外部の DE/SPK カーネルは不要です。自己完結で確認済みです：加速度は自身の摂動ポテンシャルの厳密な勾配と一致し（third_body_potential）、摂動は地心で消え、LEO 衛星で教科書的な約5·10⁻⁷ m/s² の大きさを持ち、太陽エフェメリスは手で導出した J2000 のアンカーに一致します。近日点距離 ≈ 1.471·10¹¹ m、12月の冬至付近の赤緯 ≈ −23°、見かけの運動 ≈ 1°/日（四半年で ≈ 90°）、そして一年を通じて 0.983〜1.017 AU の地球軌道の範囲に収まる距離です。数値伝播器のマイルストーンの力モデルのステップのうち、第三体の半分を提供します（月は、上の別項目で提供しています）。DE 水準の位置精度、大気抵抗、SRP は、今後の課題として残っています。
• J2–J6 帯球調和の力モデル（forces::zonal_accel / zonal_potential）。Cowell 伝播器の力モデルを J2 を超えて、次数 6 までの地球の帯球場全体（公表されている標準の EGM-96 非正規化 J2..J6）に拡張し、ForceModel::with_zonals_j2_j6() として伝播器に接続しました。加速度は、帯球の摂動ポテンシャル R(r) = −(μ/r)·Σ Jₙ(Re/r)ⁿPₙ(z/r)（ルジャンドル多項式は上方向の漸化式）の厳密な解析的勾配で、三通りの独立した方法で確認済みです：[J2] に限定すると、666ベクトルで確認済みの j2_accel に機械精度で帰着し、J2..J6 の場全体で自身のポテンシャルの数値勾配と一致し（保存場の標準的な検査）、奇数次の J3 と偶数次の J2/J4..J6 の項は、z → −z のもとで南北の（反）対称という特徴を示します。これは洋ナシ形の非対称性です。J2..J6 の軌道を伝播すると、全エネルギー（運動 + 中心 + 帯球ポテンシャル）が一日で約1e-8 まで保存され、J2 のみの軌道に対して小さいがゼロでない摂動を与えます。これで、数値伝播器のマイルストーンのステップ2（「J2–J6 帯球調和」）を実現しました。高次の EGM テッセラル場、大気抵抗、SRP、第三体、GMAT/Orekit との外部クロスバリデーションは、今後の課題として残っています。
• 数値的（Cowell）軌道伝播器（src/propagator.rs）。Kshana 初の非解析的伝播器です（軌道スタックのそれ以外は解析的な SGP4/SDP4）。二体 + J2 の力モデル（src/forces.rs）を、適応ステップ倍増 RK4 ドライバー（src/integrator.rs）に f(t,[r;v]) = [v; a(r)] として接続し、ForceModel の切り替えを備えます。数値的な相互ツール比較よりも強力な解析的な真値に対して確認済みです：摂動のない軌道は、24時間の LEO 軌道で、厳密な普遍変数のケプラー解をサブメートルで再現し（マイルストーンが言う「数値参照に対して < 10 m」より厳しいゲート）、比エネルギーと角運動量は相対で約1e-9 まで保存され、J2 の昇交点の後退は、閉形式の j2_secular_rates を一次理論（2 % 以内。O(J2²) の残差）まで再現します。また、solve_kepler_checked を追加しました。ケプラー方程式のニュートン法ソルバーで、反復回数の上限内に収束しない場合は、黙って誤った答えを返すのではなく、Err を返します（近地点付近の e = 0.999 のケース）。適用範囲についての率直な注記：力モデルは二体 + J2 のみです。高次の EGM テッセラル場（200×200 + ローダー）、大気抵抗（NRLMSISE-00）、SRP、第三体の力、GMAT/Orekit との外部クロスバリデーションは、今後の課題として残っています。
• 60分間の GPS 拒否下での重力マップマッチングを < 500 m に（run_gps_denied_gravity_nav）。代替 PNT 層を、ESA NAVISP の Quantum Wayfarer の検証目標に合わせて深めました。車両が約700 km の軌跡を、まる一時間の GNSS 途絶のあいだ飛行し、慣性解は ≈ 70 km までドリフトします。冷却原子重力計と階層的な粗から細への粒子/グリッドマッチャーにより、一定の INS ドリフトを ≈ 145 m（< 500 m）まで復元し、> 480× の削減となります。重力計の実際のホワイトノイズの下限は決定論的なシード付きの系列として注入するため、マッチャーにノイズのない真値が渡されることはなく、それでも実行は完全に再現できます（ビット単位で同一であることを確認済みで、ノイズの実現が変わっても数メートル以内で安定）。回帰レベルのテストで、この精緻化が必要であることを示しています。単一の粗いグリッドでは約2 km で停滞し、三段階の精緻化だけが 500 m の壁を破ります。新たにコミットしたシナリオ scenarios/gps-denied-gravity-nav.toml。docs/CAPABILITY.md の行は、率直に部分的のままです（EGM2008 の地図はまだ同梱していません）が、その根拠を60分間・< 500 m の結果に更新しました。適用範囲についての率直な注記は変わりません：低次の球面調和場 + 合成マスコンであり、地図表現の誤差の実現にわたるモンテカルロは、今後の課題です。
• 過大表現の台帳 + 回帰ガード（docs/CLAIMS-VS-REALITY.md、tests/no_overclaims.rs）。誠実さのための、主張の取り下げの取り組みを締めくくります。以前の監査で整理した十四件の過大表現（OC-0…OC-13）は、すべてGREENになりました。強い主張（OC-0 のクロック+位置の結合カルマン、OC-2 のジャミング J/S→C/N₀→ロックロス、OC-7 の Mach–Zehnder CAI 物理、OC-8 の ARAIM HPL/VPL）は、表現をやわらげたのではなく、提供済みでテスト済みの機能に置き換えられ、残りの行は、コードに合わせて主張を取り下げました。新しい CI テストは、公開している現行の面（README、CAPABILITY、GLOSSARY、web/）を走査し、取り下げた裸の過大表現が注意書きなしで再び現れた場合は失敗します。そのため、GREENの行が黙って後退することはありません。実行ごとの「インテグリティ」性能指標は、率直にフィルターの自己整合性（航空のインテグリティではありません）と表記し、実際の ARAIM HPL/VPL は別に示すため、両者が混同されることはありません。
• 重力マップマッチング航法（GPS 拒否下の代替 PNT）。新しい src/gravimeter.rs は、ESA NAVISP の Quantum Wayfarer / QT-CCI の重力マップマッチングの研究が求める代替 PNT 機能層を追加します。CAI 加速度計の ASD（σ = ASD/√τ）から導出したホワイトノイズの下限を持つ冷却原子の重力計の測定モデル、低次で完全正規化した球面調和の重力異常場（閉形式のルジャンドル関数 P̄₁₁=√3·cosφ、P̄₂₀=(√5/2)(3sin²φ−1)、P̄₂₂=(√15/2)cos²φ と、手で導出した単一項の異常 1.897 mGal と照合して確認済み）に、高次の局所的な特徴のための合成マスコンを加えたもの、そして、通過する異常の系列から GPS 拒否下の軌跡を復元する重力マップマッチングの粒子フィルター（mapmatch + particle_filter を組み合わせ）です。コミット済みの NAVISP ベンチマーク（scenarios/gravity-map-nav.toml）は、約73 km の自由慣性ドリフトを数 km に抑えます。適用範囲についての率直な注記：Kshana は、EGM2008 の 2190° の完全な係数セットを同梱していません。場は低次 + マスコンであり、実際の高解像度の地図ではありません。EGM/EIGEN のローダー、磁気マップ、地形支援 SLAM、SVG のドリフトグラフを伴うシナリオエンジンの kind= への接続は、今後の課題として残っています。docs/CAPABILITY.md の「Gravity-map / alt-PNT navigation」は部分的になります。
• マヌーバのモデリングと軌道設計の足がかり。新しい src/maneuver.rs は、SGP4 の上に最初の軌道設計層を追加します。速度の不連続を与えて 6×6 の共分散を前方へ引き継ぐインパルス ΔV ノード（決定論的なバーン ⇒ 状態遷移は恒等。実行誤差の共分散は、バーン座標系（ECI または LVLH）から速度ブロックへ回転）、達成された ΔV を閉形式の Tsiolkovsky ロケット方程式と 0.01 % より良く照合する有限推力のバーン積分（バーン弧にわたる一定推力で、質量を状態として扱う）、Izzo-2015 の単一周回のランベルトソルバー（r1、r2、飛行時間 ⇒ v1、v2）、厳密な普遍変数のケプラー伝播器（二体の真値）、そして、出発エポック × 到着エポックのグリッドを出発 C3 と到着 V∞ に対応づけ、ブラウザーの等高線描画向けに2次元の JSON 配列として出力するポークチョップ掃引です。検証は自己完結で、チュートリアルの読み出しより強力です。ランベルトのすべての出力はケプラー伝播器で往復させ（r2 に戻らなければなりません）、ポークチョップの最小値は、二つの共面円軌道に対する解析的なホーマン遷移の C3 下限と照合します。Kshana はこれを、GMAT/Orekit の上位にある性能シミュレーション層として位置づけており、置き換えではありません（複数周回の分岐と実際の惑星エフェメリスは対象外です）。十件のテスト。
• 量子 CAI の推測航法を備えた、完全な17状態の密結合 GNSS/INS UKF。新しい src/fusion/tightly_coupled17.rs は、密結合フィルターが推定する完全な慣性航法の状態 — [position, velocity, attitude-error, accelerometer bias, gyro bias, clock bias, clock drift]（17 状態）— を保持し、測定した比力と角速度で駆動するストラップダウン機構を通じて伝播します。小角度の C ≈ I + [ψ×] による機体座標系から慣性系への回転により、姿勢誤差が水平加速度に結合します（標準的な INS の傾斜結合）。GNSS 途絶中は IMU だけでコーストし、速度ランダムウォークのプロセスノイズは、冷却原子干渉計の加速度計から導出した q_va（crate::inertial::quantum_imu）です。そのため推測航法のドリフトは量子センサーが限界を決めるもので、120秒の途絶でも数百メートルに収まります。航法グレードの自由 INS では数キロメートルに達します。疑似距離・距離変化率の更新は、共有のアンセンテッドフィルターを通じて実行します（この状態サイズで重みの条件を良好にするため α = 1）。五件のテスト：測定モデルの恒等性、完全な IMU での等速積分、GNSS 支援、加速度計バイアスの推定、そして CAI が限界を決める120秒の途絶ベンチマークです。

0.11.0 - 2026-06-05#

変更#

• 量子測位についての率直な位置づけ。看板となる説明は、README のキャッチコピー、引用行、CITATION.cff（タイトル + 概要）、バナーのアートワークで一貫して、「PNT-resilience simulator with quantum-sensor performance models」になりました。これは、従来のゆるい「hybrid quantum/classical PNT simulator」という宣伝的な表現を置き換えるものです。README の What it is / is not の節には、明示的な「It is not (yet)」の範囲の記述（第一原理の原子干渉計の物理エンジンではなく、GNSS 受信機/PVT ソルバーではなく、ミッション設計ツールでもない）が加わり、新しいトップレベルの ROADMAP.md は量子物理層を P2 項目とする（Mach–Zehnder の CAI 位相、射影ノイズ、振動テンソル）ことで、第一原理の物理は範囲に含まれ、今後取り組むもので、放棄されたわけではないことを読者に示します。動作と API に変更はありません。

追加#

• コンステレーション設計のトレードスタディ：パレート前線を伴う Walker 設計の掃引、再訪時間の JSON、キロメートル未満の Walker 式の検証。 src/walker.rs に walker_design_sweep が加わりました。これは、一定の軌道傾斜角で planes × sats_per_plane のグリッド（例：3×3 のトレード）を実行し、設計ごとに、カバレッジの割合、最悪時の PDOP、再訪間隔の最大値・平均値を表にします。pareto_front は非劣解の設計（衛星数が少ない、カバレッジが大きい、PDOP が低い、再訪が短い）に印を付け、WalkerDesignReport::to_json は、再訪時間のフィールドを含め、セルとパレート前線を JSON にシリアライズします。新しい検証では、ジェネレーターを Walker の i:T/P/F の式に固定します。隣り合う軌道面の同じスロットの衛星は、SGP4 伝播の全 24 時間にわたって、厳密な R_z(2π/P) 回転により互いに写像でき、その差は 1 km 未満であることを示し（J2 の短周期の振動は同相で打ち消されます）、軌道面内のスロットが平均で 2π/S の間隔であることを確認しています。コミット済みの実際の Celestrak gps-ops の 2021-07-28 のスナップショット（scenarios/orbit-sgp4-gps.toml。シナリオカバレッジと SP3 往復のテストで使用）の上に構築されています。
• 高度な時刻・周波数比較：TWSTFT、GNSS コモンビュー、PPP、光、IEEE-1139 のべき乗則フィット、クロックアンサンブル。新しい src/timetransfer_adv.rs は、提供済みの Sagnac/コモンビューの閉形式とアラン安定度ツールの上に、運用上の比較手法を構築します。twstft_sagnac は、双方向衛星時刻・周波数比較（TWSTFT）の Sagnac 補正を、三ホップのループ和として与え、BIPM の閉形式 Δt = 2·A·ω_E/c² と厳密に一致します（独立した twstft_sagnac_bipm でクロスチェック済み）。run_twstft は一日分の T_A − T_B の系列とその TDEV を出力します。gnss_common_view_series は、二つの合成地上局を一重差分して、衛星クロックを打ち消します。iono_free_combination + ppp_receiver_clock は、SP3 グレード（合成）の真値に対する PPP の電離圏フリー結合と受信機クロックの解で、一次の電離圏を厳密に打ち消します。rytov_variance、fried_parameter、単位平均の lognormal_fading は、自由空間光リンクの乱流によるシンチレーションをモデル化します。fit_power_law_psd は、アラン分散曲線に対する、完全な IEEE-1139 の五係数 h_α の最小二乗フィット（五つの標準的なノイズ過程を同時に扱う）で、τ の十年区間ごとに支配的な過程を報告します。ensemble_timescale は、逆分散で重み付けした紙上の時系列を構成し、そのアラン偏差は、寄与する最良のクロックを厳密に下回ります。31 件のユニットテスト。検証の対象は閉形式と合成の真値であり、実際の BIPM Circular-T / IGS SP3 の取り込みは今後の課題です。
• IONEX 電離圏マップ：ファイルパーサー、時間補間、斜め方向の傾斜係数マッピング。 src/ionex.rs に parse_ionex が加わりました。これは IONEX のファイル形式（ヘッダーのグリッド定義 + START/END OF TEC MAP のブロック）を IonexMap の系列に読み込み、ファイルの北から南への緯度の並びを正のステップの TecGrid に正規化し、値を 10^EXPONENT でスケーリングします。interpolate_tec_in_time は連続する二つのマップを問い合わせエポックにブレンドし、obliquity_factor / slant_tec は、単層の薄殻の係数 M(z) = 1/cos z′（sin z′ = (Rₑ/(Rₑ+H))·sin z）で、鉛直 TEC を斜め方向の経路に写像します。提供済みのグリッドモデルと合わせて、実測の IGS 全球電離圏マップを、使える斜め方向の遅延に変換します。
• コンステレーション設計：ストリート・オブ・カバレッジの規模決定 + 複数コンステレーションの比較。 src/walker.rs に min_satellites_streets_of_coverage が加わりました。これは理想化したストリート・オブ・カバレッジによる最少衛星数のソルバーで、提供済みのカバレッジ半角 λ とストリート半幅 c から、連続した単一の全球カバレッジを得る準極軌道のコンステレーションの規模を、p = ⌈π/(2c)⌉ 面として求めます（例：GPS 高度で4衛星の軌道面なら 2 面、8 衛星）。衛星がまばらすぎて連続したストリートを作れない場合は None を返します。compare_constellations は複数コンステレーションの比較ツールで、名前付きの各 Walker 設計を pdop_sweep で同じ局・同じ期間について評価し、カバレッジ / PDOP / 規模を並べて返します。適用範囲についての率直な注記：逆回りの軌道面の境界での継ぎ目まで厳密な Rider 補正と、3次元のカバレッジ地球儀は、今後の課題です。
• 多層のスプーフィング検出：RAIM 整合性のパリティ検出器 + 層の融合。 src/spoof_monitors.rs に、三つ目で最後の検出層と融合の段階が加わりました。parity_raim_test は、冗長な疑似距離の集合に対して位置・クロックの解を最小二乗で当てはめ、残った重み付き残差二乗和を、その χ²(m−4) の閾値と照合します。これにより、衛星の偏った部分集合は検出し、（受信機クロックに吸収される）共通モードのバイアスは RAIM では見えないまま正しく残し、隠すことはしません。fuse_spoof_layers は、パリティ、AGC、SQM の各層を、どの層が発報したかを記録する一つの重み付き判定に統合します。モンテカルロで検出器の特性を調べました。経験的な P_fa ≈ 0.068（設計点は 0.05）で、見逃しは、2σ のスプーフィングバイアスでの 0.885 から 8σ での 0.16 に低下します。適用範囲についての率直な注記：公表されている特定の（Spirent / ION GNSS+）スプーフィングのテストベクトルとのクロスバリデーションには、それらの外部データセットが必要で、今後の課題として残っています。
• 結合型と分離型のカルマンの検証アンサンブル。src/fusion/coupled.rs の100試行のモンテカルロで、位置↔クロックの相互共分散を持ち続けることの価値を定量化します。忠実なインラインの分離型ベースライン（提供済みの CoupledPntFilter とビット単位で一致することを確認済み）に、クロス項をゼロにして同じデータを処理させ、ほぼ縮退した疑似距離とクロックのみの測位の後で、結合型フィルターは位置を 2.97 m RMS で復元し、分離型フィルターの 48.8 m に対して、100 試行中 97 試行で勝ちます。クロックの測位が位置を鋭くするのは、分離型のパックが捨てている相関を通じてのみです。これで、カルマンの正しさの検証スイート（Joseph 形式、PSD の安全性、NEES/NIS の整合性、そして今回の結合型フィルターのアンサンブル）が完成します。
• 軌道決定パイプライン（バッチ + 逐次）。新しい src/orbit_determination.rs は、地上局の距離追跡から衛星の軌道状態 [r, v] を復元します。提供済みの三つの部品を組み合わせます。二体 + J2 の力モデル（src/forces.rs）と RK4 積分器（src/integrator.rs）が候補の状態を弧にわたって伝播し、距離測定モデルが各局の距離を予測し、Gauss–Newton のバッチ補正器（src/batch_ls.rs）が候補を最良適合の状態に収束させます（determine_orbit_batch）。同じ力学と距離モデルは、提供済みのアンセンテッドフィルター上の逐次の再帰的な決定（determine_orbit_sequential）も駆動します。四件のテストで検証しています：弧にわたる距離予測、ノイズのない距離からの、サブメートル / mm·s⁻¹ へのバッチ復元、約2 m へのバッチ復元と、5 m のノイズ下限に等しいフィット後の残差（整合した最小二乗フィットの特徴）、そして数十メートル以内への逐次復元です。適用範囲についての率直な注記：距離変化率/ドップラーと角度の測定、解析的な J2 の状態遷移行列、局の可視マスクは、今後の課題です。
• 密結合 GNSS/INS UKF ナビゲーター。新しい src/fusion/tightly_coupled.rs は、提供済みのアンセンテッドカルマンのコア（src/fusion/ukf.rs）を、八状態の [px,py,pz,vx,vy,vz,b,d]（ECEF の位置・速度と、距離単位の受信機クロックバイアス・ドリフト）にわたる、動作する密結合ナビゲーターに組み上げます。事前に作った位置の測位ではなく、衛星の生の測定値、すなわち pseudorange（ρ = |p − sᵢ| + b）と range_rate/ドップラー（ρ̇ = (p − sᵢ)·(v − ṡᵢ)/|p − sᵢ| + d）を取り込むため、TightlyCoupled（propagate/propagate_orbital/update_gnss を伴う）は四機未満の衛星でも補正を続け、GNSS 途絶中は伝播した力学でコーストします。マイルストーンの受け入れシナリオを含め、五件のテストでエンドツーエンドに検証しています：疑似距離・ドップラーのジオメトリを手計算の値と照合、ノイズのない五機でのサブメートルへの収束、スナップショット PVT では測位すらできない三衛星のケースで約212 m から約13 m への収束、等速の120秒の途絶で 50 m 以内、そして、最も重要な受け入れ基準として、120秒の GNSS 途絶を含む30分間の曲線を描く LEO パス（実際の二体 + J2 の軌道）で、パスの RMS 0.77 m、途絶中の最悪値 2.9 m を維持しました。この軌道上のコーストは、提供済みの重力力モデル（src/forces.rs）と RK4 積分器（src/integrator.rs）を UKF のプロセスモデル（propagate_orbital）に組み合わせるため、フィルターは軌道の曲率に追従します。等速のコーストではそれができません（曲率だけで、LEO の 120 秒間に約58 km になります）。適用範囲についての率直な注記：軌道上のコーストは、生の IMU の比力ではなく、二体 + J2 の力モデルを使います（推進しない軌道上のプラットフォームでは両者は一致します）。ストラップダウン IMU の誤差状態と、ループ内の電離圏・対流圏補正の組み込みは、今後の課題です。
• マップマッチングの測定モデル（地形・重力参照航法）。新しい src/mapmatch.rs は、提供済みの逐次重要度リサンプリングの粒子フィルター（src/particle_filter.rs）を、動作する GPS 拒否下ナビゲーターにする測定モデルを提供します。field_likelihood（ガウス型の場の一致の尤度）と map_match_likelihood で、後者は、地形標高（TRN）や重力異常のような、任意の地理参照された参照場を粒子の位置でサンプリングし、車両の測定値との一致度で重み付けします。場は任意の Fn(lat, lon) -> value サンプラーなので、src/ionex.rs の双一次グリッドやクロージャと組み合わせられます。二件のテストで裏付けています。尤度は完全一致でピーク（=1）となり、一シグマで e^(−½) に下がります。また、特徴的な合成地形のパッチ上の粒子フィルターは、真の位置を 0.1 以内で復元します。適用範囲についての率直な注記：実際の参照地図（SRTM 標高、EGM/EIGEN の重力異常）とそのローダーは、今後の課題です。
• 地球・月間空間の PNT インテグリティ（月の ARAIM）。新しい src/lunar.rs は、地球側の MHSS ARAIM エンジンを、月のパラメーター（σ_URE ≈ 30 m。GPS は 0.6 m、P_sat ≈ 1e-4）を使った LunaNet 型の月航法サービスに適用します。月の定数、月心の東・北・上の基底と天空ジオメトリのヘルパー、そして lunar_araim（HPL/VPL）です。三件のテストで裏付けています：月心の正規直交基底、斜距離のジオメトリ、そして σ_URE に対する保護レベルの厳密な線形スケーリング（月の 30 m では、同じジオメトリで GPS の 0.6 m の場合より保護レベルが 50× 大きくなります。月の PNT のインテグリティが難しい、定量的な理由です）。適用範囲についての率直な注記：正確な LANS NRHO エフェメリス、信号空間の誤差バジェット、MCI↔MCMF の座標系換算は、今後の課題です。
• 二部構成（高精度）のユリウス日。新しい src/jd2.rs は Jd2 を追加します。これはユリウス日を、整数の day と、[0,1) の範囲の小数の frac（SOFA/hifitime の慣例）に分けたもので、new/from_parts/add_seconds/diff_seconds/total を備えます。近いエポック同士の差は f64 の下限まで厳密に保たれますが、単一の f64 のユリウス日では、J2000 付近で約50 µs が失われます。四件のテストで裏付けています：往復、小数の正規化、マイクロ秒の厳密な復元（単一の f64 での失敗を並べて示します）、そして加法的で可逆な秒の演算です。
• CCSDS OMM（Orbit Mean-Elements Message）ライター。新しい src/omm.rs は、oem エフェメリスライターを、平均要素メッセージで補完します。OmmFile::from_tle は SGP4/TLE の平均要素を OMM の単位（平均運動は rev/日、角度は度、加えて BSTAR）に対応づけ、to_omm_kvn は標準化過程の CCSDS 502.0-B-2 の KVN 形式にシリアライズするため、Kshana の軌道を、独自仕様の TLE ではなく、OMM に対応した任意のツールで利用できます。二件のテストで、TLE→OMM の単位変換（≈ 15.5 rev/日、軌道傾斜角 51.6° など）と、必須の KVN キーワードの存在を裏付けています。適用範囲についての率直な注記：KVN 形式と TLE の対応づけはここで提供します。XML（ndm/omm）の出力と、参照パーサーとの往復は、今後の課題です。
• 逐次重要度リサンプリングの粒子フィルター。新しい src/particle_filter.rs は、地図支援の GPS 拒否下航法（地形参照またはマップマッチング）の背後にある、非線形・非ガウスの推定器を追加します。predict（粒子を力学 + ガウスのプロセスノイズで伝播）、update（粒子ごとの測定尤度で重み付けし直す）、系統的な resample、effective_sample_size の縮退モニター、そして重み付き平均の推定です。六件のテストで決定論的なコアを厳密に裏付けています：1…N にわたる ESS、重みに比例してインデックスを選ぶ系統的リサンプリング、重み付き平均の凸結合、測定値に推定を引き寄せるガウス尤度、一様へのリサンプリングの挙動、シード付きの predict の決定性です。適用範囲についての率直な注記：エンジンはここで提供します。参照地図（SRTM 標高、EGM 重力異常）と地図の測定モデルは、今後の課題です（ionex のグリッド + 双一次サンプラーは、重力・地形の地図にも同様に使えます）。
• IONEX 形式の TEC 電離圏マップ。新しい src/ionex.rs は、放送の Klobuchar モデルに代わる、実測の電離圏を追加します。TecGrid（鉛直 TEC の規則的な緯度・経度グリッド、IGS の全球電離圏マップ）と、貫通点での双一次補間（vtec_at。グリッド外は端の値で固定）、および一次の遅延 Δ = 40.3·TEC/f²（vtec_to_delay_m、delay_at）です。四件のテストで裏付けています：L1 での 1 TECU ≈ 0.162 m と 1/f² のスケーリング、ノードでの厳密な補間、角を平均する双一次の中点、そして端の値で固定するグリッド外の問い合わせです。適用範囲についての率直な注記：グリッドと補間はここで提供します。IONEX ファイル形式の解析、マップ間の時間補間、斜め方向の写像関数は、今後の課題です。
• 幾何学的な時刻比較の補正（Sagnac + GNSS コモンビュー）。新しい src/timegeo.rs は、実際のクロック比較で考慮しなければならない二つの決定論的な効果を追加し、timetransfer の確率的な双方向モデルを補完します。sagnac_correction（Δt = (ω_E/c²)·(x₁y₂ − x₂y₁)。自転する地球による遅延で、大陸規模の基線では数十 ns）と、common_view_offset です。後者は GNSS コモンビューの一重差分で、衛星クロックの誤差を厳密に打ち消し、局間のオフセットを復元します。三件のテストが、これらを厳密な参照に基づいて裏付けています：赤道上の四分の一周での ≈ 33 ns の Sagnac、反対称性と動径・極のゼロのケース、そして衛星クロックの厳密な打ち消しです。適用範囲についての率直な注記：完全な TWSTFT のトランスポンダー/ハードウェア遅延バジェットと、PPP の電離圏フリーの時刻比較解は、今後の課題です。
• 軌道の力モデル（二体 + J2）。新しい src/forces.rs は、数値伝播器が積分する加速度モデルを追加します。two_body_accel（−μ·r/|r|³）、j2_accel の扁平摂動（ECI の閉形式）、それらを合計する gravity_accel で、src/integrator.rs と組み合わせると f(t,[r;v]) = [v; a(r)] になります。また、解析的な J2 の永年変化率（j2_secular_rates）も提供します。昇交点の後退 Ω̇、近地点の回転 ω̇、平均近点角のドリフト Ṁ です。六件のテストで、物理を厳密な参照に基づいて裏付けています：二体項の μ/r²、赤道での J2 の閉形式（二体項の大きさの約10⁻³）、近地点を固定する臨界傾斜角（63.4349°、ω̇ = 0）、ISS の昇交点の後退（Ω̇ ≈ −5°/day）、そして逆行する太陽同期軌道の東向きのドリフトです。適用範囲についての率直な注記：二体 + J2 のみです。J3–J6、大気抵抗、SRP、第三体は、今後の課題です。
• 共有できるシナリオのパーマリンク。新しい src/permalink.rs は、依存関係のない RFC 4648 の Base64 コーデック（パディング付きの標準 +/ アルファベットと、パディングなしの URL セーフな -_ アルファベット）と encode_scenario / decode_scenario のラッパーを追加します。これにより、プレイグラウンドの TOML を ?s= クエリパラメーターにエンコードして URL として共有できます。ブラウザーには encode_permalink / decode_permalink の wasm バインディングとして公開されます。四件のテストで、標準の RFC 4648 のベクトル（"foobar" → "Zm9vYmFy" など）、URL セーフなシナリオの往復（エスケープすべき +///= がありません）、無効なシンボルの拒否、そして256バイトすべての往復を裏付けています。適用範囲についての率直な注記：コーデックとバインディングはここで提供します。プレイグラウンドの共有ボタンの UI、Plotly/D3 の複数系列グラフ、A/B 比較モードは、今後の課題です。
• Gauss–Newton のバッチ最小二乗（バッチの微分補正器）。新しい src/batch_ls.rs は、バッチの軌道決定（または任意のパラメーターフィット）の土台となる推定のコアを追加します。gauss_newton は、ユーザーが与えるモデル h(x) を中心有限差分のヤコビアンで線形化し、重み付き正規方程式 (HᵀWH)·Δx = HᵀW·(z − h(x)) を作って解き（テスト済みの行列の逆を再利用）、測定ごとの重みで収束するまで反復します。四件のテストで裏付けています：厳密な重み付き最小二乗解に達する線形の直線フィット、真のパラメーターを復元する非線形の a·exp(b·t) フィット、ノイズのない距離から既知の位置を復元する3次元の距離多辺測量（軌道決定の原型）、そして不足決定・不整合な入力の拒否です。適用範囲についての率直な注記：これは汎用の補正器エンジンです。軌道固有の距離/距離変化率/方位・仰角の測定モデル、解析的な J2 の状態遷移行列、公表されたケースでの検証は、今後の課題です。
• RF層のスプーフィング監視（AGC電力とSQM）。新しいsrc/spoof_monitors.rsが、spoofのクロック支援型時刻スプーフィング監視を補完する、受信機フロントエンドの独立した二つのスプーフィング検出器を追加します。一つはAGC電力監視（combine_power_dbmの非コヒーレント電力和とAgcMonitor）で、スプーフィング送信機が加える受信電力の超過分を、設定可能なdBマージンを超えた時点で検出します。もう一つは信号品質監視（bpsk_autocorrの三角形コード自己相関とSqmMonitor）で、マルチパス、ミーコニング、リプレイが生じさせるEarly−Lateコリレーターの不均衡を検出します。四件のテストで厳密な閉形式を固定しています（電力が倍になったときの3.01 dB、10·log10(N)の集計、三角形のR(τ)=1−|τ|、10 %のEarly/Late警報しきい値）。範囲の限定：RAIM整合性パリティによる完全なスプーフィング検出器、監視出力の多層融合、公開されているSpirent/ION GNSS+のスプーフィングベクトルに対する照合は、今後の課題です。
• 適応型の数値ODE積分器。新しいsrc/integrator.rsが、数値伝播器の最初の部品を追加します（Kshanaの軌道伝播はそれ以外では解析的なSGP4/SDP4です）。任意の一階系y' = f(t, y)に対する汎用の四次ルンゲ＝クッタ法のステップ（rk4_step）と、ステップ倍加法（リチャードソン外挿）で局所誤差を制御し、標準的な0.9·(tol/err)^(1/5)のステップ制御器と採択・棄却の論理を備えた適応ドライバー（integrate）です。六件のテストを厳密解で固定しています。y' = y → eの指数関数を< 1e-9まで、ステップを半分にするたびに誤差が約16分の一になり四次収束を裏づけること、調和振動子の一周期にわたるエネルギーと復帰の保存、可変ステップで厳しい許容差を満たす適応ドライバーです。範囲の限定：これは積分器の中核とその誤差制御であり、これをNumericalPropagatorにするためのDormand–PrinceのRK5(4)/RKF7(8)埋め込みタブローと、階層的な軌道力モデル（二体＋J2〜J6＋大気抗力＋太陽輻射圧＋第三体）は、今後の課題です。
• アンセンテッド（シグマ点）カルマンフィルター。新しいsrc/fusion/ukf.rsが、ユーザーが与える過程関数と観測関数に対する汎用のn状態推定器として、スケーリング付きアンセンテッドカルマンフィルター（Julier & Uhlmann、Wan & van der Merwe）を追加します。これは、疑似距離・ドップラーのモデルが強い非線形で、EKFのヤコビアンが劣化する場合に、密結合GNSS/INS航法器が用いるシグマ点推定器です。支える密行列の線形代数（シグマ点の広がりのためのコレスキー分解、イノベーション共分散のためのガウス＝ジョルダン法による逆行列）と、ジョセフ形式を用いないP⁺ = P⁻ − K S Kᵀの更新を含みます。六件のテストで裏づけており、主なものは、線形モデルではアンセンテッド変換が数値精度の範囲でカルマンフィルターを再現するという厳密な性質を利用しています（予測、更新、予測と更新の一巡のすべてを、手計算で回した線形KFと照合したほか、1次元の解析的なベイズ事後分布の確認と、コレスキー分解・逆行列の恒等式の確認）。範囲の限定：これは推定器エンジンであり、17状態の密結合GNSS/INS航法器、疑似距離・ドップラーの観測モデル、途絶時の検証シナリオは、今後の課題です。
• 二衛星コンステレーションのARAIM保護レベル。新しいaraim_dual_raimが、単一故障のAdvanced RAIM（araim_raim）を、EU ARAIM／DO-316のコンステレーション全体の故障モードで拡張します。故障なしの仮説と衛星ごとの仮説に加えて、各コンステレーション（衛星ごとにラベル付け）が、そのすべての衛星を一度に取り除く仮説を一つずつ寄与し、事前確率はP_constです（新しいDualFaultPriors { p_sat, p_const }）。どの仮説も同じMHSSインテグリティ和に項を加えるため、VPL/HPLは、故障なし、単一SV、コンステレーション単位の故障にわたるP_HMIの合計が予算を満たす最小の限界になります（ボンフェローニ法による誤警報の配分はN + C個の仮説すべてにわたります）。P_const = 0のとき結果はaraim_raimとビット単位で一致し、単一コンステレーションのユーザーは自らのコンステレーション故障に対してNoneを返します（排除できません）。これこそが、二衛星コンステレーションによる覆域が重要である理由です。四件のテストで、等価性、保護レベルの拡大、単一コンステレーションでの利用不能、入力検証を確認しており、既存の解分離サブ解の仕組みを再利用しています。
• IAU 2006歳差（フクシマ＝ウィリアムズ角とバイアス・歳差行列）。新しいsrc/precession.rsが、IAU 2006（P03、Capitaine、Wallace & Chapront 2003）の歳差を実装します。TTユリウス世紀の多項式としての四つのフクシマ＝ウィリアムズ角(γ̄, φ̄, ψ̄, ε̄_A)（fw_angles）と、それらからSOFAのiauFw2mの構成（precession_matrix、補助関数はgcrs_to_modとmod_to_gcrs）で作るGCRSから平均分点座標への、バイアスと歳差の回転行列です。これは、既存のGMSTベースのframesの変換に続く、慣性座標系に関する最初の部品です。八件のテストを閉形式の基準値で検証しています。J2000の平均黄道傾斜角ε̄ = 84381.406″ = 23.4392794°、公表されている角度の定数項、一世紀にわたるψ̄ ≈ 5039.998″の一般歳差の累積、行列の正規直交性とdet = +1、J2000での恒等に近い（座標系バイアスのみの）値、世紀あたりの正味の回転角≈ 1.40°です。範囲の限定（ROADMAP.md）：歳差のみであり、IAU 2000Aの678項の章動、TEMEからGCRSへの完全な変換連鎖、SOFA/ANISEとのµas/<10 mの数値クロスチェックは、今後の課題です。
• 第一原理に基づく冷却原子干渉計（CAI）加速度計の物理。 src/inertial/quantum_imu.rsは、データシートではなく第一原理から、三パルスのマッハ＝ツェンダー型原子干渉計をモデル化します。有効波数ベクトルk_eff = 4π/λ、干渉計位相Φ = k_eff·a·T²、量子射影（ショット）ノイズσ_Φ = 1/(C·√N)、一回あたりの加速度感度、コントラストの減衰C(t) = C₀·e^(−t/τ)、そして要となるCaiAccelerometer::q_va()を扱い、後者は、従来のAccelModelがすでに利用している白色加速度PSDを、原子数、干渉時間、コントラストから導出します。モデルは振動結合も扱うようになりました。これは実機で支配的な項です。干渉計の加速度から位相への伝達関数|H(ω)| = (4/ω²)sin²(ωT/2)（accel_transfer_function）、白色PSDの位相分散σ_Φ² = k_eff²·S_a·T³/3（vibration_phase_variance_white、数値的なバンド積分による照合vibration_phase_variance_band付き）、ランク1のビーム軸方向のbeam_axis_projection、そしてCaiAccelerometer::vibration_phase_noiseとvibration_limited_accel（後者はk_effに依存しない√(S_a/(3T))の下限に帰着します）です。十一件のテストで物理を手計算により確認しています（Rb-87のk_eff ≈ 1.61×10⁷、Φ(1 g) ≈ 1.58×10⁴ rad、一回あたりσ_a ≈ 0.13 µgのショットノイズ下限と約5.9 µgの振動下限との比較、1/T²、1/√N、T³のスケーリング則）。docs/QUANTUM.mdでの範囲の限定：射影ノイズの下限と、それを上回る振動制限領域をカバーしており、レーザー位相ノイズ、コリオリ力と光シフトの系統誤差、PHARAO/CARIOQAの検証シナリオは今後の課題です。
• 慣性シナリオに組み込んだ量子CAI加速度計。慣性推測航法シナリオの加速度計は、新しいImuKindとして解決されるようになりました。Classical（従来のデータシート係数によるセンサー）か、任意の[cai]ブロックを持つ場合のQuantumCaiです（CaiCfg：波長、パルス間隔、原子数、コントラスト、サイクル時間、および任意のプラットフォームvibration_psd）。quantum_caiセンサーの速度ランダムウォークPSDq_vaは、与えられた係数ではなく、干渉計の物理から導出されます。ショットノイズの下限に、振動PSDが与えられている場合は振動制限の寄与を二乗和で加えたものです。実行の来歴には、ノイズが物理から導出されたことが記録されます。caiフィールドはskip_serializing_if = "Option::is_none"のため、既存のシナリオはこれを省略でき、バイト単位で同一にシリアライズされます（シナリオのハッシュは変わりません）。五件のテストで、導出、二乗和による振動の合成、ClassicalとQuantumCaiの選択、ハッシュが安定するシリアライズ、CAI駆動のエンドツーエンドの実行を確認しています。
• コンステレーション設計の最適化器と、ストリート・オブ・カバレッジの幾何。 src/walker.rsにoptimize_walker_designが加わります。これは勾配を使わないグリッド最適化器で、{planes × sats × inclination}の設計空間を探索し、すでに検証済みのPDOP掃引に対して、選んだDesignObjective（MinSatellitesForCoverage、MaxCoverage、MinWorstPdop）のもとで最良のウォーカー設計を返します（総当たりの勝者を返すことをテストで確認）。加えて、解析的なストリート・オブ・カバレッジの閉形式coverage_half_angle_rad（λ = arccos(Re/r·cos ε) − ε）とstreet_half_width_rad（cos c = cos λ / cos(π/s)、Rider/Beste）があり、教科書の幾何と手計算で照合し、衛星数不足による隙間も検出します。Riderの最小衛星数による全球覆域ソルバー、3Dのプレイグラウンド地球儀、外部ツールとのDOPクロスチェックは、今後の課題です。
• CLIからのSP3精密エフェメリスのエクスポート。伝播させた軌道・コンステレーションのシナリオを、SP3-cファイルとして書き出せるようになりました。kshana <orbit.toml> --export-sp3 out.sp3を実行するか、シナリオにexport_sp3 = trueを指定すると<scenario>.sp3が自動で書き出されます（api::export_sp3／auto_export_sp3、OrbitClockScenario::to_sp3_string、任意でepoch）。ラウンドトリップテスト（tests/sp3_export_roundtrip.rs）は、実際のCelestrakgps-opsスナップショットを伝播させてエクスポートし、再度パースして、復元したECEF位置が24 hにわたりSGP4の真値と< 0.5 mで一致することを確認します（TLE級の許容差10 mを十分に下回ります）。READMEには、相互運用上の役割を記載しています（RINEXはRTKLIB/gLAB向け、SP3はGinan/精密軌道プロダクト向け）。
• クロックと位置を結合したカルマンフィルター（ブロック間共分散）。 src/fusion/coupled.rs CoupledPntFilterは、積み重ねた単一の[pos, vel, phase, freq]フィルター（ジョセフ形式の更新）で、その疑似距離観測ρ = g·pos + c·phase + noiseが位置とクロックのブロックを実際に結合します。これは、ブロック間共分散を常に厳密にゼロに保つ、従来のフュージョンパックの独立した二つの二状態フィルターとは異なります。照合して確認した内容：共有の疑似距離がP[pos,phase]を非ゼロにすること。二つの異なる幾何により、単一の距離では分離できない、注入した位置とクロックのオフセットを同時に分解できること。クロックのみの固定が、相互共分散を通じて位置を鋭くすること（分離したフィルターでは得られない効果）。そして、モンテカルロのNEESがχ²(4)と整合することです。これは1自由度の実現（フュージョンパックの次元数）であり、3Dの8状態への拡張と実行可能なパックへの組み込みは、今後の課題として管理されています。
• カルマンフィルターの整合性ヘルス監視（NIS/NEES）。二状態クロックフィルターの共分散更新が、ジョセフ安定化形式`P⁺ = (I−KH)P(I−KH)ᵀ
  • KRKᵀ, which stays positive-semidefinite under extreme Q/R ratios (Cholesky-checked in CI at R=1e-26 / Q≈1e-30). A new src/filter_health.rsruns a Monte-Carlo consistency assessment (Bar-Shalom §5.4): pooled **NIS** (normalised innovation², target 1) and **NEES** (normalised estimation error², target 2) against 95% χ² bands, surfaced as afilter_health { nis_mean, nis_chi2_lower_95, nis_chi2_upper_95, nees_mean, nees_chi2_lower_95, nees_chi2_upper_95, consistent } block in the clock result JSON and as a green/amber card in the playground. A Q/R-mismatch sweep test proves the monitor flips to inconsistent when the process noise is mistuned by ×0.1–×10. Adds a general χ² quantile (detection::chi2_inv_cdf`、Wilson–Hilferty、数表で照合)。
• docs/PROVENANCE.md：引用可能な来歴の一覧表。すべてのセンサーパラメーター（クロック、慣性、時刻伝送）、物理・アルゴリズムのモデル（軌道、時刻系、座標系、電離圏・対流圏、インテグリティ、検出、ジャミング、アラン偏差）、検証用データセット（AIAA 2006-6753、Celestrakgps-ops）を、公表された出典（データシート、論文、ICD、規格）と、率直な成熟度ラベル（飛行適格／地上ラボ／地上ハードウェアでの宇宙目標）とともに一つにまとめています。READMEの冒頭とドキュメント一覧からリンクされており、結果JSONにすでに含まれる実行ごとのprovenance文字列を補完します。
• 型付きシナリオAPI。ディスパッチは、生のkind文字列のマッチではなく、型付きのScenarioKind列挙型に基づくようになり（ScenarioKind::classifyと網羅的なディスパッチ）、パックの追加がコンパイル時に検査されます。文字列を返す従来のrun_tomlは変わらず、並んで新しい型付きインターフェースが加わります。構造化されたエラー分類を持つrun_scenario(src) -> Result<RunOutput, KshanaError>（InvalidInput／NonConvergence／Unsupported／IoError、それぞれ安定したkind_tag()を持つ）、ScenarioトレイトとExternalPack拡張点（実例としてjammingパックがこれを通じて接続されています）、そしてlist_scenario_kinds()によるイントロスペクション（名前、説明、種別ごとの必須・任意フィールド）です。PythonとWebAssemblyのバインディングにはlist_kinds()とerror_kind()が加わります。docs/ARCHITECTURE.mdに記載しています。
• 実際のGPSコンステレーションと運用エンベロープの網羅。 scenarios/orbit-sgp4-gps.tomlは、合成のウォーカーTLEではなく、実際のCelestrakgps-opsスナップショット（2021-07-28、30機）を同梱するようになり、strict_checksum = trueにより、すべてのTLEチェックサムが有効な場合にのみ読み込まれます。scripts/fetch_tles.shに再現可能な更新手順を記載し、READMEにオープンデータの出典を明記しています。新しいtests/scenario_coverage.rsは、各パックを5種類以上のエンベロープ変種で実行して有限かつ有界の出力を確認し、有効にするとフリッカーFMフロアがクロックのコースティングを明確に劣化させること（現在は同梱の三つのシナリオで設定済み）、およびフュージョンフィルターが現実的な非ゼロの加速度計バイアスでも収束すること（バイアスをゼロにした場合の3倍以内）を確認し、「フュージョンはバイアスをゼロにした場合にしか動作しない」という現実性の隔たりを埋めます。docs/VALIDATION.mdには運用エンベロープの表が加わります。
• 観測領域のGNSSシミュレーション（gnss-sim種別）。疑似距離レベルの順方向モデルです。可視衛星ごとにρ = geometric range + c·δt_rx − c·δt_sv + I + T + noise + multipathとL1ドップラーを合成し、Klobucharの単一周波数電離圏（IS-GPS-200 §20.3.3.5.2.5）と、Niell（1996）の写像関数で投影したSaastamoinenの天頂対流圏を用います。これらは[iono]と[tropo]のTOMLブロックとして公開されています。残差はエポックごとのHPL/VPLのためにスナップショットRAIMに渡され、gnss_measurements[]のJSON配列が各SVの疑似距離、ドップラー、C/N₀、電離圏・対流圏の補正量を保持します。ノイズゼロの実行は、幾何と補正量をミリメートル未満の精度で再現します（CIテスト）。src/gnss_sim.rsとscenarios/gnss-sim-raim.tomlが新たに加わります。
• 確率的な時刻スプーフィング検出器（spoof種別）。スプーフィングパックは、決定論的なランプと限界値の比較ではなく、実際の検出器を実行するようになりました。四つの注入形状（linear_ramp、step_jump、meaconing、replay）、クロック支援型の監視統計量に対する両側χ²₁のエネルギー／ネイマン＝ピアソン検定（しきい値は目標誤警報予算target_pfaから設定）、そして見逃し確率P_mdを閉形式とモンテカルロ（仮説ごとにmc_runs回の試行。両者は1/√Nの数倍の範囲で一致）の両方で報告します。セキュリティの性能指標は、運用上有害な（仕様の）大きさでの1 − P_mdになりました。新しいsrc/detection.rs（ガウス裾関数、NP／エネルギー検定、モンテカルロのP_fa/P_md）とscenarios/spoof-meaconing.tomlが加わります。後方互換性があり、[attack] rate_ns_per_sだけの指定も引き続き線形ランプとして受け付けます。

変更#

• セキュリティ性能指標の定義（spoof種別）：解析的な検出可能性の限界1 − min_detectable/thresholdから、確率的な検出器の1 − P_mdへ。クロックパックのsecurityフィールドは、引き続きより高速な解析的な代用値です。

追加（続き）#

• RFジャミングモデル（jamming種別）。ジャマーの電力と幾何を衛星ごとのロックロスに変換する、リンクバジェット型の干渉モデルです。自由空間経路損失と方向ごとの受信アンテナ利得からジャマー対信号比を求め、標準的なアンチジャム式（逆拡散の処理利得×スペクトル分離係数Q、Kaplan & Hegarty §9.4）で有効C/N₀を求め、設定可能な追尾しきい値を適用して、ウォーカーコンステレーション全体でavailability_under_jammingの性能指標として評価します。src/jamming.rsとscenarios/jamming-demo.tomlが新たに加わります。範囲の限定（マルチパス、地形による遮蔽、AGC、適応ヌリングは含まない）は、docs/CAPABILITY.md／docs/VALIDATION.mdに記載しています。
• 任意のシナリオ種別に対する汎用のN次元パラメーター掃引（sweep-nd）。従来のN次元掃引はクロックパック専用でした。sweep-ndは、[base]シナリオのドット区切りTOMLキーを、各軸のデカルト積にわたって変化させ、各格子点を通常の実行経路で再ディスパッチし、結果から一つ以上の指標をドット区切りのJSONパスで読み出します。そのため、各パックのRust型と結合することなく、すべてのパック（慣性、gnss-ins、インテグリティ、スプーフィングなど）で動作します。格子点は、ネイティブターゲットではOSスレッド間で並列に評価され（依存関係の追加なし）、wasmでは逐次処理にフォールバックします。スレッド数にかかわらず決定論的で、行優先です。新しいscenarios/sweep-nd-inertial.tomlの例があります。
• gnss-insパックでTOMLから設定できる決定論的なIMU誤差モデル。三軸ストラップダウンの誤差の連鎖（スケールファクター、ミスアライメント、g感度、量子化、レートランプ。IEEE Std 952-1997 §A.2、Groves 2013 §4.3）に、シナリオファイルから任意の[imu_*.error_model]ブロックを通じてセンサーごとに到達できるようになり、定数のターンオンバイアスの上に重ねられます。このブロックを省略すると各センサーは純粋な定数バイアス源のままなので、既存のgnss-insの実行は変わりません。これにより、これまでライブラリ専用だった誤差モデルが、実行可能なパックと性能指標に組み込まれます。

0.10.0 - 2026-06-04#

変更#

• 実データでの検証。マルチGNSSのRINEX航法パーサー、GLONASSのRK4伝播器、SP3リーダーは、自作のサンプルだけでなく、本物のIGS/DLRファイル（実際のRINEX 3混合放送航法ファイルとIGSのSP3-c軌道プロダクト）でも実行されており、空でない衛星集合と、有限で物理的に妥当な大きさのECEF位置を確認しています。フィクスチャーはテスト専用です（公開クレートからは除外）。tests/fixtures/igs/NOTICEを参照してください。
• 実際の基準軌道の幾何でのRAIM。スナップショット、解分離（MHSS）、ARAIMの保護レベルの中核は、合成コンステレーションだけでなく、実際のIGS精密軌道（SP3）の幾何に対しても検証されています。視線方向の幾何は、実際の地上局での最初のSP3エポックから作られ、テストでは、メートルレベルでAPV-Iが利用可能な保護レベルであること、60 mの疑似距離バイアスがχ²監視を作動させること、解分離が故障した衛星を特定すること、ARAIMの保護レベルが割り当てられたP_HMIを満たすことを確認します。これにより、合成の幾何でしか検証されていないという隔たりが埋まります（完全なRINEX弧にわたる受信機領域でのgLAB照合は、疑似距離解が必要なため、ロードマップの項目として残っています）。

追加#

• N次元パラメーター掃引の格子点ごとの信頼区間（sweep::nd_sweep_ensemble）。N次元デカルト積掃引の各格子点を、シードのモンテカルロアンサンブルとして評価できるようになり、指標の平均、パーセンタイル、パーセンタイルブートストラップによる95%信頼区間を（両方のクロックについて）格子点ごとに報告します。これは、格子点あたり一回の試行ではなく、統計的に誠実な掃引です。アンサンブルとブートストラップの仕組み（metric_stat）を再利用しており、決定論的です。runs = 1は、単一シードのnd_sweepに厳密に帰着します。（全パックへの掃引の一般化、型付きScenarioのリファクタリングとの絡み、並列実行は残っています。）
• IMUノイズパイプラインのNaveGoによるクロスバリデーション（tests/navego_imu_crossval.rs）。NaveGo（R. GonzalezのオープンソースINS/GNSSツールボックス）との外部照合です。公表されているMicrostrain 3DM-GX3-35の基準プロファイルでnavego_example_allan.mの合成ラウンドトリップを再現し、当方の重なりありADEV推定器が、NaveGoの速度ランダムウォーク係数と角度ランダムウォーク係数（ADEV(1 s) = σ·√dt）を、想定される−1/2の白色ノイズ傾きとともに5%未満で復元することを確認します。（記録済みの40 MBのSTIM300の.matログは取り込んでいません。バイナリ形式の対応待ちです。）
• 密結合（疑似距離）GNSS/INSの更新。 GnssInsEkf::update_tightly_coupled（およびClosedLoopInsGnss::fuse_tightly_coupledラッパー）が、これまでスタブだった距離領域の観測を実装します。イノベーションは、INS位置から各衛星までの予測距離と、測定した疑似距離との差であり、位置誤差に対する視線方向のヤコビアンを持ちます。各衛星はスカラーの観測であるため、フィルターは四機未満の衛星でも補正を続けます。疎結合のPVT解が存在しない状況です。五件のテストで、四衛星でのゼロ化、二衛星での補正（PVTは不可能）、単一衛星での視線方向の可観測性、入力検証を確認しています。疑似距離のみであり、搬送波位相と明示的な受信機クロック状態はロードマップに残っています。古い誤差スタブを制御していた未使用のtight_couplingcargo機能は削除されました。
• 疎結合GNSS/INSシナリオパック（kind = "gnss-ins"、src/fusion/pack.rs）。三軸ストラップダウン航法器と15状態の誤差状態EKF（closed_loop／gnss_ins_ekf）を、性能指標を備えた実行可能なシナリオに接続します。EKFは、覆域がある間はノイズを含むGNSS解に対して機械化を律し、その後の途絶を惰行で通過します。従来の1自由度スカラーパックの真値へのスナップによるリセットを、本物のフュージョンに置き換えます。結果には、フュージョン後の水平誤差の系列、評価対象の位置性能指標（可用性／途絶時RMS／ホールドオーバー）、比較用のオープンループの自由INSのRMSが報告され、量子とクラシカルのIMUの組は真のバイアスだけが異なります。CLI/Python/wasmの入口からディスパッチされ、scenarios/gnss-ins.tomlの例があります。率直な位置づけ：疎結合のみで、決定論的な軌道は一つであり、途絶時のフュージョン誤差は引き継ぎ時の姿勢誤差で下限が決まる（そのためバイアスに比例して増えるとは主張しません）。堅牢な知見は、バイアスのあるセンサーではフュージョンが補助なしの推測航法を上回ることと、バイアスの小さいセンサーのほうが補助なしの惰行に優れることです。
• 検証済みSGP4コアの上でのコンステレーション設計（src/walker.rs）。新しいwalkerモジュールは、設計したウォーカー・デルタのパターン（i: T/P/F）をSGP4の平均要素として出力するため、合成コンステレーションは、解析的なケプラー生成器ではなく、AIAA 2006-6753のベクトルに対して4.12 mmまで検証済みの同じSGP4経路で伝播します。その上に、pdop_sweepが{planes × sats × inclination}の設計格子にわたる覆域とPDOPの中央値・最悪値を表にまとめ、coverage_revisitが地上の一点での覆域率と再訪の隙間（最悪／平均）を報告します。トレードオフが満たすべき物理的な単調性（衛星が増えれば、覆域が高く、PDOPが低く、再訪が短くなる）で検証しています。別に、実際のCelestrakgps-opsのTLEスナップショット（2021-07-28、運用中のGPS衛星30機）をテスト専用のフィクスチャーとして追加し、実際のTLEからSGP4、ECEFへの幾何経路をそれに対して検証しました（MEO全体の殻が1%以内、九衛星すべてが可視でPDOP 1.64）。既存のSP3とRINEXの実データ経路と並びます。
• アラン偏差の信頼区間のための、ノイズ種別ごとの有効自由度。 allan::edf_overlapping_adevは、五つの代表的なべき乗則ノイズ種別（ホワイト／フリッカーPM、ホワイト／フリッカーFM、ランダムウォークFM）のすべてについて、NIST SP 1065の表5の閉形式（Stable32の簡易セット）を実装し、χ²の自由度として用いてきた保守的な非重なりの個数を置き換えます。新しいPowerLawNoise列挙型とclassify_power_lawが、記録の修正アラン偏差の傾きから支配的な種別を特定します（MDEVはADEVにはできないホワイトPMとフリッカーPMの区別ができます）。そしてoverlapping_adev_curveは、特定したノイズ種別、そのedf、95%の信頼帯を、エクスポートされるADEV曲線のすべての点に付与するようになりました（AdevPointにnoise／edf／ci_lo／ci_hiが加わります。serdeの既定値を伴う追加です）。二通りで検証しています。五つの式は手計算の値と1e-12まで一致し、4 000記録のモンテカルロのホワイトFMアンサンブルにより、式が推定器の実際のχ²のedfを20%以内で予測すること（および保守的な個数を大きく上回ること）を確認しました。八件の新しいテストがあります。
• 双方向時刻伝送の確率モデル。 timetransfer::TwoWayLinkは、ホワイトノイズのみのサンプラーを、物理に根ざしたモデルに置き換えます。相反的な（同相の）経路遅延は(m_AB - m_BA)/2の推定で打ち消され（two_way_offset_estimate。独立した二つの片方向測定が平均されて1/sqrt(2)になります）、残差は非相反の差動遅延です。これを、色付きのホワイトFMとランダムウォークFMの過程（照合して確認済みのClockModel）としてモデル化し、平坦なホワイトノイズではなく、同期誤差の系列に現実的なアラン偏差の特性（sigma_y^2(tau) = q_rw*tau/3）を与えます。LinkCfgにはq_wf_s／q_rw_sが加わり（serdeの既定値は0で、従来のホワイトのみの動作とビット単位で一致）、リンクの性能指標はadev_tau0（基本ステップでのモデルのアラン偏差）を報告し、timetransferのシナリオとCLIがそれを公開します。ゴールデンの性能指標は固定し直しました。手計算で導いた六件のテスト（同相成分の相殺、双方向の利得sqrt(2)、リンク自身のstep()によるRWFMのtau/3則、q=0での従来動作との等価性、決定論性、性能指標のエンドツーエンドでの公開）です。
• アラン系推定器のStable32との数値一致（NBS14）。 tests/allan_reference.rsは、重なりありADEV、修正ADEV、時間偏差、重なりありアダマール推定器を、代表的なNBS14データセット（W. J. Riley、Handbook of Frequency Stability Analysis、NIST SP 1065、p.107付近）に対するStable32の基準偏差と、tau = 1、2で相対許容差1e-4の範囲で照合します。実際の一致は約1e-6です。これにより、推定器の数式は、推定器自身の解析的な自己整合性だけでなく、事実上の基準実装に対して固定されます。使うのは公開されている基準の数値だけで、第三者のコードは使いません。
• integrityシナリオがエクスポートする垂直スタンフォードインテグリティ図。実行可能なintegrityシナリオ種別は、HPL/VPLの可用性マップに加えて、垂直のスタンフォード（-ESA）図もエクスポートするようになりました。保護される各エポックで、シード付きで再現可能な故障なしの距離誤差の乱数を幾何を通して実際の垂直位置誤差に写像し、VPLと垂直アラートリミットに対して分類します（Available／System-Unavailable／Misleading／Hazardously-Misleading）。この図（エポックごとの点と領域ごとの件数）は結果のJSONに、インテグリティイベントとHMIの件数はCLIの要約に含まれるため、これまでライブラリ専用だったスタンフォード分類器にエンドツーエンドで到達できます。IntegrityScenarioにはseedフィールド（既定値0）が加わり、誤差の実現を制御します。可用性マップ自体は、引き続き幾何のみで決まり、シードには依存しません。
• 保護レベルのためのARAIMインテグリティリスク（P_HMI）予算。 raim::araim_raimは、固定のK_md乗数ではなく、明示的なインテグリティリスク予算から水平・垂直の保護レベルを導出します。全可視衛星の解と、衛星一機ずつを除外した各サブ解について、各軸のモードごとの(prior, detection threshold, σ)を作り、araim_protection_levelが、危険な誤誘導情報の確率の合計（araim_integrity_risk、P_HMI = Σ_k p_fault,k · Q((PL − T_k)/σ_k)、BlanchらBaseline ARAIM）が割り当てられたP_HMIを満たす最小のPLを解きます。結果には、レベルが実際に達成するインテグリティリスクが報告されるため、ユーザーはインテグリティとアラートリミットのトレードオフを明示的に行えます。手計算で導いた六件のテスト（故障なしとしきい値付き単一モードの閉形式、複数モードの総和と単調性、予算を10⁵倍厳しくするとPLが上がる故障なしのエンドツーエンドの保護、故障の検出と識別、六衛星の冗長性の下限）です。単一故障のMHSSはARAIMのベースラインであり、複数SV部分集合の同時故障、コンステレーション全体の故障モード、gLAB基準データセットでの検証は、文書化された拡張です。
• ストラップダウン機械化のための二速度コーニング／スカリング補償。 inertial::mechanization::coning_sculling_compensateは、粗い更新の順序付きサブ区間IMU増分から、高レートのコーニング（姿勢）と回転＋スカリング（速度）の項を畳み込みます。これにより、中程度のレートのNavState::step_incrementsは、生の合計に対する粗いステップでは見落とされる、振動で整流された運動を再現します。検証テストでは、10 Hzのコーニング＋スカリング環境を60 s駆動し、細かいレートの真値、素朴な粗い積分、畳み込んだ粗い積分を比較します。畳み込みにより位置誤差は約18分の一に減り（素朴な積分では数メートルのドリフトが、デシメートル未満に）、コーニングとスカリングの項が不可欠であることを確認します。ScalarErrorBudget型エイリアスは、従来の1自由度のAccelModelを、三軸のNavState航法器とは別のものとして、その実態どおりに名付けます。
• RINEX観測ファイルのパーサー。新しいrinex_obsモジュールは、RINEX 3.0x／4.00の観測ファイル（受信機の実際の測定値）を読み取り、既存の航法メッセージパーサーと並んでRINEXの対を完成させます。parse_obsは、ヘッダー（バージョンと種別、継続行を含むシステムごとのSYS / # / OBS TYPESリスト、概略位置、間隔、最初の観測の時刻）と、各エポックの衛星ごとのレコードを復号します。レコードは、疑似距離、搬送波位相、ドップラー、信号強度で、RINEX 3の観測コード（C1C、L1Cなど）をキーとし、ロスオブロック（LLI）と信号強度（SSI）のフラグを持ち、空欄はゼロではなく欠測として保持されます。範囲の限定：これは標準形式の取り込み（実際のRTKLIB／gLAB／IGS局の観測ログを入力し、型付きの測定値を出力）であり、測位エンジンではありません。ここには疑似距離解、PPP、RTKはありません。
• CCSDS OEM（Orbit Ephemeris Message）ライター。新しいoemモジュールは、伝播させたコンステレーションを、有効なCCSDS 502.0-B OEM 2.0メッセージとしてエクスポートします。GMAT、Orekit、STK、そしてほとんどの飛行力学ツールが取り込むKVN形式のエフェメリスです。OemFile::from_propagatorsは、各衛星の慣性系（TEME）状態（位置と速度）を、SP3のエクスポートとは異なり地球固定系への回転なしに伝播器からそのまま取り出し、時間格子上にサンプリングします。OemFile::to_oem_stringは、CCSDS_OEM_VERS／CREATION_DATE／ORIGINATORのヘッダーと、衛星ごとに一つのMETA_START … META_STOPセグメント（OBJECT_NAME／OBJECT_ID／CENTER_NAME／REF_FRAME = TEME／TIME_SYSTEM = GPS／START_TIME／STOP_TIME）を直列化し、続けてそのepoch X Y Z X_DOT Y_DOT Z_DOT行（km、km/s）を出力します。CREATION_DATEは呼び出し側が与えるもので、壁時計は使わないため、出力は実行間でバイト単位で同一です（再現性の約束）。これはGNSSのSP3エクスポートに対応する、宇宙機エフェメリス版です。Kshanaの軌道を標準形式で飛行力学ツールに渡せるようになりました。
• 伝播の入力源としてのSP3精密エフェメリス。 Sp3File::interpolatorは、衛星ごとのSp3Interpolatorを構築します。これは、表にあるSP3エポックの間の位置を9次のラグランジュ多項式（標準的なIGSの慣行）で補い、共通のTEME座標系に回転するもので、Propagator::Sp3Preciseとして公開されています。IGSや解析センターの精密軌道ファイルが、放送軌道や解析的な伝播器と同じ幾何・可視性・インテグリティのパイプラインを駆動できるようになりました。ラウンドトリップによる照合で確認：ケプラー軌道をSP3に書き出し、補間器を通して読み直すと、ノードではメートル未満、区間の中間では< 100 mで元の軌道と一致します。クロックの補間は次の課題です。
• GLONASS放送エフェメリス（マルチGNSSのRINEX航法を完成）。新しいglonassモジュール：GLONASSはケプラー要素ではなく、PZ-90地球固定系の状態ベクトル（位置、速度、日月の加速度）を放送します。parse_glonass_navはRINEX 3のRレコードを読み取り、任意の時刻の衛星位置は、GLONASSのICDの運動方程式（中心重力＋J2＋地球自転のコリオリ・遠心項＋放送された加速度）の4次のルンゲ＝クッタ積分で求められます。Propagator::Glonassとして公開されているため、GLONASS衛星はケプラー系のシステムと並んでコンステレーション・可視性・インテグリティのパイプラインを流れ、一つのrinexコンステレーションブロックでGPS、Galileo、QZSS、BeiDou、GLONASSを混在させられます。
• マルチGNSSのRINEX航法（GPS、Galileo、QZSS、BeiDou）。RINEX 3航法パーサーは、GPS（G）に加えて、Galileo（E）、QZSS（J）、BeiDou（C、MEO/IGSO）のレコードも復号するようになりました。これらはケプラーの配置とユーザーアルゴリズムを共有し、それぞれ固有の重力定数と地球自転率で評価されます（Galileo／BeiDouのμ、BeiDouのΩ̇ₑ）。混在コンステレーションのファイルはそのすべてを返し、Propagator::Rinexとしてコンステレーション・可視性・インテグリティのパイプラインを流れます。BeiDouの静止衛星は異なる座標回転を使うため、照合に用いる基準フィクスチャーが得られるまでスキップします。レコードの走査はシステムごとの行数を使い、四行のGLONASS／SBASのレコードが八行であるかのようにスキップされていた潜在バグを修正しました。GLONASS（状態ベクトルモデル）が次の課題です。
• SP3-c/d精密エフェメリスのリーダーとライター。新しいsp3モジュールは、PPPエンジン（Ginan、RTKLIB、gLAB）が基準として扱う、後処理されたECEFの位置・クロックのプロダクトであるIGS／解析センターのSP3精密軌道ファイル（parse_sp3）を構造化されたSp3Fileに解析します（ヘッダー、エポック格子、衛星ごとの位置km→m、クロックµs、Vプロダクトの速度dm/s→m/s）。SP3の不良値の番兵値は保持されます。逆方向も対象です。Sp3File::from_propagatorsが伝播させたコンステレーションからSP3を構築し（エポックごとにTEMEからECEFへ）、to_sp3_stringがそれを直列化するため、Kshanaの軌道を外部のPPPツールが取り込む形式でエクスポートできます。読み込みと書き出しのラウンドトリップです。エポック補間とSP3の伝播器入力源が次の課題です。
• 実行可能なコンステレーション入力源としてのRINEX放送エフェメリス。コンステレーションは、既存のtleオプションに加えて、インラインのrinexブロック（RINEX 3のGPS航法テキスト）を受け付けるようになり、実際の放送ファイルが、CLI、Python、ブラウザー内プレイグラウンドからシナリオをエンドツーエンドで駆動します。RINEXを入力し、PNTの幾何を出力します。新しいscenarios/orbit-rinex.tomlは、放送レコードから直接構築した八機のGPS衛星によるGNSSの可用性とDOPを示します。（GPSのLNAVのみです。マルチGNSSとSP3が次の課題です。）
• 伝播の入力源としてのRINEX放送エフェメリス。解析済みのRinexEphemerisは、orbit::Propagator（Propagator::Rinex）に変換できるようになりました。位置は、IS-GPS-200の放送軌道をECEFから共通のTEME慣性系へ回転したもの（sv_position_teme。うるう秒を正しく扱ったGPSからUT1への時刻変換付き）、速度は中心有限差分、そしてケプラーの軌道周期です。実際のGPS放送データが、解析的なSGP4／ケプラーの伝播器と同じ幾何、可視性、インテグリティ（RAIM）のパイプラインを駆動できるようになりました。（RINEXファイルのシナリオ種別としてはまだ公開していません。それとマルチGNSS／SP3が次の課題です。）

0.9.2 - 2026-06-03#

追加#

• アーカイブ用DOI。リリースはZenodoに登録され、引用可能なDOIが割り当てられるようになりました。

0.9.1 - 2026-06-03#

変更#

• ドキュメント。READMEを機関向けの水準に刷新しました。v0.9.0スタック全体の機能の概要、バージョニングとリリースの節、新しいマークを使ったすっきりしたヘッダー、簡潔なステータス行です。エンジンの変更はありません。

0.9.0 - 2026-06-03#

このリリースは、0.8.0のSGP4基盤の上に、三つの大きな機能領域を加えます。本格的な三軸ストラップダウンINS、閉ループのフィードバックを備えた疎結合GNSS/INSの誤差状態EKF、HPL/VPLを伴う実際のスナップショットと解分離（ARAIM型）のRAIMおよび実行可能なintegrityシナリオ、そしてGNSS形式の相互運用性の第一歩（RINEX-3のGPSエフェメリスの取り込み）です。

追加#

• RINEX 3のGPS航法メッセージパーサー（src/rinex.rs）。GNSS形式の相互運用性に向けた第一歩です。parse_navはRINEX 3.xの航法ファイルを読み取り、各GPS（G）放送エフェメリスのレコード（八行のSV／エポック＋BROADCAST ORBITブロック）を、IS-GPS-200に従ったフィールド名と単位で、ケプラー要素とクロック補正のRinexEphemerisに復号します。FortranのD指数形式の浮動小数点（parse_d）と固定幅の桁配置を扱います。GPS以外のシステムのレコードは拒否されずにスキップされるため、混在ファイルからもGPSエフェメリスが得られます。四件のテスト：D指数の解析（空欄とエラーを含む）、既知のフィールド値に対して復号した完全なレコードとGPSの軌道長半径の妥当性確認（√A² ≈ 26,560 km）、GPS以外のスキップ、空ファイルの場合です。
• GPS放送エフェメリスからECEF位置へ（src/rinex.rs）。 RinexEphemeris::sv_position_ecef(t_tow)は、解析したエフェメリスから、IS-GPS-200 §20.3.3.4.3.1のユーザーアルゴリズムにより、衛星の地球固定系での位置を評価します。離心近点角に対するケプラー方程式のニュートン法による解、二次高調波の緯度引数・動径・軌道傾斜角の補正、基準エポックからの地球自転を考慮したECEFへの回転です（仕様が定めるGPSのμとΩ̇ₑを使い、週のロールオーバーのtkの折り返しを含みます）。三件のテスト：地心距離がGPSの帯域（約26,560 km）にとどまること、地球固定系での速さが約3.9 km/sであること、丸一週間離れて評価しても同じ位置が再現されることです。
• 相対論補正付きのGPS SVクロックバイアス（src/rinex.rs）。 RinexEphemeris::sv_clock_bias_s(t_tow)は、Tocを中心とする放送クロック多項式af0 + af1·Δt + af2·Δt²に、相対論的な離心率項F·e·√A·sin Ek（IS-GPS-200 §20.3.3.3.3.1）を加えて評価します。新しいEpochUtc::gps_time_of_weekが、GPSエポック（1980-01-06）からのユリウス日の演算により、レコードの暦のエポックをGPSの週内時刻に変換し、ケプラー方程式の解は位置の評価と共有します。テスト：日曜・火曜・土曜（週の境界）のGPS週内時刻、そしてクロックバイアスがaf0に支配され、相対論的な項が存在して有界であることです。L1の群遅延TGDは公開していますが、意図的に組み込んでいません。範囲の限定：Propagator入力源、Galileo／BeiDou／GLONASS、SP3は、次の課題として残っています。（docs/CAPABILITY.mdも合わせて更新しました。）
• ユーザーが実行できるintegrityシナリオ種別（scenarios/integrity-raim.toml）。RAIMの可用性の機能に、他のすべてのパックと同様に、CLI／TOMLから到達できるようになりました。kind = "integrity"がIntegrityScenario（ユーザー軌道、一つ以上のGNSSコンステレーション、仰角マスク、(sigma, P_fa, P_md, AL_H, AL_V)のインテグリティ設定）を解析し、constellation_raim_availabilityを実行して、エポックごとのHPL/VPLの可用性マップをJSONで、さらに自己完結したSVGとして出力します。保護レベルを時間に対してアラートリミットと並べ、緑と赤の可用性の帯を付けたものです。kshana scenarios/integrity-raim.tomlはJSON、グラフ、HTMLレポートを書き出します。同梱のシナリオ（24衛星のウォーカー、1 mの二周波測距、APV-Iの限界値）の可用性は約95 %と報告され、単一周波数のRAIMは一つのコンステレーションでは垂直APV-Iの限界値を満たさず、そのため垂直誘導にはSBAS／二周波／ARAIMを使う、ということも記載しています。テストは、ディスパッチ、可用性マップのJSON、SVGを対象とします。
• コンステレーションにわたる実行可能なRAIM可用性（src/raim.rs）。インテグリティモジュールには呼び出し元がありませんでした。constellation_raim_availabilityがこれを、本物のエンドツーエンドの入口にします。時間格子上の各エポックで、可視衛星を伝播させ（エンジンが使うのと同じSGP4／ケプラーのPropagator）、故障なしの保護レベルを計算し、水平・垂直のアラートリミットに対して可用性を判定し、serdeでシリアライズできるRaimAvailabilityReport（エポックごとのn_visible／HPL／VPL／availableと可用性の割合）を返します。RaimConfigが(sigma, P_fa, P_md, AL_H, AL_V)をまとめ、エポックごとのraim_availability_epochは、自前で幾何を解決する呼び出し側のために公開されています。三件のテスト：十衛星の幾何でAPV-Iの限界値のもとで利用可能と判定されるエポック、あり得ないほど厳しい限界値で利用不能になるエポック、五機未満の衛星でのNoneのレベル。そして24衛星のウォーカーコンステレーションにわたるエンドツーエンドの実行で、有限の可用性マップが得られ、シリアライズできることです。（六衛星、すなわち残差RAIMの冗長性の下限では、1 mの測距でも率直にAPV-Iを満たしません。APV-Iの可用性には、テストが使うより密な幾何が必要です。）
• スタンフォード（-ESA）インテグリティ図の集計器（src/raim.rs）。多数のエポックにわたってインテグリティ監視を要約する標準的な方法です。実際の位置誤差（x）を保護レベル（y）に対してプロットし、対角線y = xとアラートリミットによって、各エポックを次のいずれかに分類します。Available（PLが誤差を包含し、ALの範囲内）、SystemUnavailable（PLが誤差を包含するがALを超える。安全だが使用不可）、MisleadingInformation（PL < 誤差 ≤ AL）、HazardouslyMisleadingInformation（PL < 誤差かつ誤差 > AL。安全でない故障）。classify_stanfordは純粋な分類器で、StanfordDiagramは固定のアラートリミットに対して(error, PL)の点を集計し、領域ごとの件数、可用性、インテグリティイベントの合計、プロットやJSONエクスポート用のserdeでシリアライズできる点を公開します。四件のテスト：すべての領域（error == PLの包含境界を含む）、件数と可用性の集計、JSONのラウンドトリップです。これはRAIMの保護レベルの報告面であり、コンステレーションのシナリオへの組み込みと公開データセットに対する照合は、ロードマップの項目として残っています。
• 解分離（ARAIM型）RAIM（src/raim.rs）。既存の残差／パリティのカイ二乗snapshot_raimと並ぶ、多重仮説のインテグリティ監視です。全可視衛星の最小二乗解と、衛星一機ずつを除外した各サブ解について、分離Δ_k = x_k − x₀を作ります。故障がなければ共分散Cov(x_k) − Cov(x₀)の平均ゼロのガウス分布に従い（入れ子の推定器の恒等式。全可視衛星の解がBLUEであるため成立）、故障を検出すると同時に、故障した衛星（その除外が最大の正規化分離をもたらすもの）を特定します。水平・垂直の保護レベルは、標準的なMHSSの配分PL = max(K_md·σ₀, max_k[K_fa·σ_ss,k + K_md·σ_k])に従い、K_fa = Φ⁻¹(1−P_fa/2)、K_md = Φ⁻¹(1−P_md)です。依存関係のないnormal_cdf／normal_quantileが新たに加わり、モジュールにある正則化不完全ガンマ関数（erf(x) = P(½,x²)）から構築されています。手計算で導いた四件のテスト：正規分布のCDFと分位点を教科書の値と照合（Φ(1.95996)=0.975、1e-7の裾 = 5.1993、対称性）。警報を出さず、有限で正のHPL/VPLを返す故障なしの幾何。60σの単一衛星バイアスが検出され、かつ正しく特定されること（excluded_sv == 2）。そして六衛星の冗長性の下限です。監査で指摘された「トートロジー的なインテグリティ。実際のRAIM/HPL/VPLがない」というP0の隔たりを、アルゴリズムの面で解消します。gLABデータセットでの照合とスタンフォード図の集計器は、ロードマップの項目として残っています。
• 閉ループGNSS/INS統合（src/fusion/closed_loop.rs）。 ClosedLoopInsGnssは、誤差状態EKFのカーネルを三軸ストラップダウン機械化に接続します。各IMUサンプルは、現在のバイアス推定値で補正され、前方に機械化され、EKFの共分散は対応する航法の文脈で時間伝播されます。各GNSSの位置・速度の解はINS−GNSSのイノベーションを作り、推定された位置、速度、姿勢誤差（ψ、クォータニオン回転として）、加速度計・ジャイロのバイアスを解にフィードバックし、誤差状態の平均をリセットします。安定性のためには、バイアスだけでなく姿勢もフィードバックする必要があります。傾きと加速度計バイアスは結合した対であり、片方だけを補正すると発散するためです。INSとGNSSは、機械化自身の曲率半径（新しいmechanization::radii_of_curvature。NavState::omega_ie_n／omega_en_nを公開）を使い、局所接平面のNED座標系で比較されます。これは、ハイブリッドパックの真値へのスナップによるリセットに代わる、率直な置き換えです。三件のテスト：注入した8 m／−5 mの位置誤差を<0.1 mまでゼロにする閉ループ、走行する軌道で、補助された解がメートル単位で有界（<6 m）にとどまる一方、自由走行のINSは100 mを超えて発散すること、そしてマイルストーンのベンチマークです。フュージョンした解の60 sのGNSS途絶にわたるモンテカルロ位置RMSは、補助なしのオープンループの推測航法を>2倍上回ります（シード全体で≈4倍）。モジュールに記載されている率直な制約：疎結合モードでは、加速度計バイアスと傾きは（どちらも重力を通じて結合するため）わずかにしか分離できません。したがって得られる価値は、有界で補正された状態と、途絶に入る時点のきれいな状態であり、精密な慣性の較正ではありません。より豊かな力学と密結合への拡張は、ロードマップの項目として残っています。
• 疎結合GNSS/INSの誤差状態EKFカーネル（src/fusion/gnss_ins_ekf.rs）。15状態の誤差状態拡張カルマンフィルターδx = [δp, δv, ψ, b_a, b_g]です。ストラップダウンの誤差力学はGroves 2013 §14.2に基づき（比力と傾きの結合、コリオリ、機体から航法系へのバイアス射影、ガウス＝マルコフのバイアスモデル）、一階の離散遷移Φ = I + F·dtと、ジョセフ形式の疎結合の位置＋速度の観測更新（H = [I₃ 0 0 0 0; 0 I₃ 0 0 0]）を備えます。依存関係のない密行列の線形代数（ガウス＝ジョルダン法の逆行列、ジョセフ形式の共分散更新）です。tight_couplingのcargo機能は、文書化されているが未実装の疑似距離／ドップラー更新を制御します。手計算で導いた期待値を持つ7件のテスト：歪対称・外積の恒等式、検証した3×3の逆行列、予測のもとで共分散が対称かつ半正定値にとどまること（補助なしでは位置の不確かさが増大すること）、位置の観測により位置共分散が縮むこと、解析的なカルマンゲインP/(P+R)での既知の位置誤差の厳密な復元、そして観測ノイズが大きいほど補正が小さくなることです。これは、ハイブリッドパックのオープンループの真値スナップによるリセットを、閉ループのフィードバックに置き換えるカーネルです（パックへの組み込みとNaveGoでの検証が続きます）。
• 3軸ストラップダウン航法器のための決定論的IMU誤差モデル（src/inertial/imu_errors.rs）。 ImuErrorModelは、機体座標系の真の(ω, f)の組を、五つの系統的な種類（IEEE Std 952-1997 §A.2、Groves 2013 §4.3、表4.1）を通じて、測定値の組へと歪めます。スケールファクター（軸ごとのppm単位の利得誤差）、ミスアライメント／クロスカップリング（トライアドの非直交性による非対角成分）、g感度（比力に比例するジャイロのレートバイアス）、量子化（出力のLSBへの丸め）、レートランプ（時間に対して線形のドリフト。アラン偏差の三番目の領域）、そして一定のターンオンバイアスです。すべての項の既定値はゼロなので、ImuErrorModel::ideal()は透過的な素通しとなり、既存のシナリオには影響しません。各誤差源には単独のテストがあります（スケールは<0.01%まで線形、ミスアライメントのクロス軸はVRWの下限より上、g感度のバイアス、LSBの格子、線形ランプ）。エンドツーエンドのテストは、歪めたIMUから機械化を通じて航法誤差を駆動します。モデル化していないもの：振動整流誤差、温度勾配によるドリフト。（同梱のinertialシナリオパックは、引き続き従来の1自由度のスカラー予算で動作します。このモデルは3軸のライブラリに供給します。）
• ストラップダウン積分器のためのコーニングとスカリングの補償。姿勢の経路には、二標本のconing_increment（½ Δθ_prev × Δθ_cur）が加わります。粗いレート（30 Hz、サイクルあたり5サンプル）による5 Hzのコーニング環境の積分は、補正により、素朴な増分の合計よりも細かいレートの真値を≥ 3倍よく追従することを確認しています。速度の経路には、sculling_increment（½ Δθ × Δv、Grovesの式5.82）が加わり、機体相対の回転Δθ_rel = Δθ_b − C_n^b ζを用いた新しい増分ベースのNavState::step_increments更新で、機体の速度増分を解決します。このため、地球に固定されたプラットフォームでは見かけのスカリングが生じず、本物の振動では完全な項が働きます。
• NED座標系での完全な三軸ストラップダウン機械化（src/inertial/mechanization.rs）。 NavState { q, v_ned, p_llh }は、標準的な地球固定系のNED方程式（Groves §5.4）を用いてstep(gyro_b, accel_f_b, dt)により進められます。機体からNEDへの姿勢は、慣性から航法系への角速度ω_in = ω_ie + ω_en（地球自転と輸送レート）で補正されます。比力はDCMを通じて機体からNEDに解決され、速度はv̇ = f_n − (2 ω_ie + ω_en) × v + g_n（コリオリ／輸送項と重力）を積分し、測地位置は子午線と卯酉線の曲率半径で求められます。重力は、WGS-84の閉形式のソミリアーナの正規（鉛直）重力に、NIMAのフリーエア高度補正を加えたもので、固定した定数ではありません。これは、1自由度のスカラー誤差予算の経路に代わる、本物の三軸航法器です。物理的な不変量で検証しています。北緯45°で回転する地球に固定されたプラットフォーム（地球自転レート＋1 gを検知）は、60 sにわたって1 mm以内にとどまります。水平な北向きの比力はv_N ≈ a·tと½ a t²の変位を与えます。正規重力は、既知の赤道・極・45°での地表の値と、フリーエアの減率に一致します。
• ストラップダウンINSのための三軸姿勢表現（src/inertial/attitude.rs）。機体から航法系への回転を保持する単位クォータニオンのQuaternion型（スカラー先頭、ハミルトン規約）で、DCMビュー（シェパード法によるto_dcm／from_dcm）、ハミルトン積、軸角と回転ベクトル（厳密な指数写像）のコンストラクター、そしてクォータニオン運動学を備えます。運動学は、一階のRKによるレート更新（q̇ = ½ q ⊗ ω）と、コーニング補正付きの回転ベクトル更新の両方です。二標本のconing_increment（Savage／Bryan–Lewantowski、½ Δθ_prev × Δθ_cur）は、スカラーの推測航法が省略している回転レートの相互結合項を与えます。これは、従来の1自由度の誤差予算の経路に代わる、完全な3軸機械化の姿勢の基盤です。閉形式の回転と照合して確認：一定レートの伝播は軸角クォータニオンと1e-6の範囲で一致し、DCMは行列式が一の正規直交であり、単軸の運動ではコーニングが消えます。（src/inertial.rsはsrc/inertial/モジュールのディレクトリになりました。公開パスのcrate::inertialは変わりません。）
• 測地学的に正しい地上局の可視性（src/frames.rs）。 elevation、is_visible、visible_countは、衛星の地上局の地平線からの仰角を、地心動径ではなく、WGS-84楕円体の法線（真の局所鉛直）に対して計算します。両者は最大で約0.19°の測地学的な偏差だけ異なり、地平線付近の衛星が仰角マスクの内外で入れ替わるのに十分な大きさです。エンドツーエンドで確認し（ウォーカーコンステレーションを伝播させ、TEMEからECEFへ回転し、測地の観測点から数える）、地心近似とも照合しました。

変更#

• CIの信頼性。test-python-bindingsジョブは、ホストのmaturin buildを直接使う代わりに、PyO3/maturin-action（manylinuxコンテナ）でホイールをビルドするようになり、ランナーイメージで間欠的に起きていたrustfmt-preview／cargo-fmtとrustupの競合を解消しました。denyジョブは、DockerベースのActioncargo-deny-actionの代わりに、taiki-e/install-actionでcargo-denyをビルド済みバイナリとしてインストールするようになり、Docker Hubのレジストリプルのタイムアウトを解消しました。どちらの変更も、実施するチェックには影響しません。

0.8.0 - 2026-06-02#

追加#

• 慣性系の速度が下流に公開されます。 Propagator::velocity_eciとPropagator::state_eci（StateEci { r_m, v_m_s }を返す）は、SGP4がすでに計算していながら以前は捨てられていた解析的なTEMEの速度を、呼び出し側にm/sで届けます。Orbit::velocity_eciは、ケプラーの経路にも一貫した速度を与えます。AIAA 2006-6753の検証テストは、すべての基準行について速度も確認するようになりました（666状態すべてにわたる最悪の速度誤差は1.85e-9 km/s）。比較する行数も、ちょうど666に固定します。

• より厳格で、パニックしないTLEの解析。行にはASCIIであることが求められ、安全にスライスされます（マルチバイト入力でのバイトインデックスのパニックはなくなりました）。要素は範囲検査されます（軌道傾斜角、離心率、平均運動）。69桁目のチェックサムは、ParseOpts { strict_checksum }／parse_propagators_optsと、ConstellationCfgの新しいstrict_checksumフラグで強制できます（既定では寛容）。

• 出力にアラン偏差の曲線。各クロックの実行はadev_curve（[{tau_s, adev, n_samples}]）を報告するようになり、ブラウザーのプレイグラウンドは、両対数の「Clock stability (ADEV)」グラフを描画します。

• 時間格子の入力検証。 TimeCfg::validateは、有限でない、ゼロの、負の、または大きすぎる時間格子（継続時間より大きいステップ、またはMAX_TIME_STEPSを超えるサンプル数）を、メモリ確保の前に拒否します。このため、不正なシナリオは、パニックやメモリの枯渇ではなく、エラーを返します。

• 慣性パックのモンテカルロアンサンブル。 慣性シナリオでのruns = Nは、N個のシードを実行し、各指標の平均、標準偏差、パーセンタイル、パーセンタイルブートストラップによる95%信頼区間（ensemble）を報告します。すべての慣性の実行にはmonte_carloフラグが付くようになり、単一の実現による性能指標が分布と取り違えられることはなくなりました。（CEP／2DRMSは、ロードマップにある3軸モデルが必要なため、意図的に報告しません。）

• ガイド付きのプレイグラウンドモード。ブラウザーのプレイグラウンドは、生のTOMLの壁にいきなり放り込むことはなくなりました。ワンクリックのシナリオカードが並ぶ「Start here」の帯が実例を読み込んで実行し、スライダーがTOMLに触れずに共通のつまみ（シード、タイミングのしきい値）を公開し、「How to read this」の注記が結果を説明し、完全なTOMLは折りたたみ一つで開けます。すべての実行は共有できます。Copy share linkがシナリオ全体をURLのフラグメントにエンコードするため（何もアップロードされません）、リンクを開くと正確な実行が再現されます。コーデックは単体テストされています（web/share.test.mjs、CIで実行）。

• N次元のパラメーター掃引（src/sweep.rs）。 nd_sweepは、複数のSweepAxis範囲の完全なデカルト積にわたって指標を、行優先の順序で、決定論的に評価します（多パラメーターのトレードスタディ）。追加機能であり、既存の1次元の掃引APIは変わりません。格子点ごとのブートストラップ信頼区間と、クロックパックを超えた一般化は、ロードマップに残っています。

• 実際のスナップショットRAIM（src/raim.rs）。本物の位置領域の受信機自律インテグリティ監視です。可視衛星への視線方向の幾何を構築し、最小二乗解と残差を作り、χ²残差による故障検出テストを実行し（依存関係のない不完全ガンマ関数によるχ²／非心χ²から厳密なしきい値を得る）、設定されたP_fa/P_mdに対して導いた見逃しバイアスを使った、傾きに基づく水平・垂直の保護レベル（HPL/VPL）を計算します。これは、シナリオパイプラインにあるフィルター自己整合性のインテグリティ性能指標とは別のものであり、それにまだ組み込まれていません。故障の除外、アラートリミットとP_HMIの予算配分、ARAIMは、ロードマップに残っています。

• 周波数安定度のスイート：MDEV、TDEV、HDEVと信頼区間（src/allan.rs）。重なりありADEVに加えて、修正アラン偏差（ホワイトとフリッカーの位相ノイズを分離）、時間偏差（TDEV = tau/sqrt(3) * MDEV）、アダマール偏差（線形の周波数ドリフトを厳密に除去し、発散するレッドノイズ型でも収束）を備えます。χ²に基づく信頼区間（deviation_ci）は、依存関係のない正規分布とχ²の分位点のペア（Acklam＋Wilson-Hilferty）と、保守的な非重なりのedfを使います。ノイズ種別ごとのedfとStable32との数値一致は、ロードマップに残っています。

• 座標系の変換（src/frames.rs）。GMSTに基づくTEMEとECEFの間の回転（伝播器と同じIAU-1982の恒星時を使用）、Bowring法を初期値とする反復逆変換を用いた厳密なWGS-84の測地座標とECEFの間の変換（MEO／GEOを含むすべての高度で機械精度）、そして局所のEast-North-Up座標系で方位角、仰角、距離を返す測地の地上局観測者です。極運動と秒角未満の章動は適用されません（GMSTのみで、地上軌跡でキロメートル未満）。ITRFの精密なCIO連鎖は、ロードマップにあります。

• 時間尺度の基盤（src/timescales.rs）。依存関係のないユリウス日のAPI（グレゴリオ暦の日付とJD、MJDの変換）、IERSの整数うるう秒の完全な履歴（UTCとTAIの間、1972年の10 sから2017年以降の37 sまで）、定義されたTAIからTTへのオフセット、与えられたDUT1によるUT1補正、IAU-2000の地球自転角です。これは、（計画中の）地球固定系の変換が載る時間の基盤です。時刻は単一のf64ユリウス日です（現在のエポックの近くで約50 µsの分解能。二部構成のJDはロードマップにあります）。1972年より前のラバー秒の時代はモデル化していません。どちらもモジュールに記載しています。

• 再現性と来歴。決定論的なCycloneDX SBOMの生成器（scripts/gen-sbom.sh）、リリースバイナリとSBOMに対するSLSAのビルド来歴の証明、CIに合わせて固定したリリースのツールチェーン。決定論性の保証、プラットフォーム間でのlibmの注意点、ゴールデン固定の方法は、docs/REPRODUCIBILITY.mdに記載しています。

• プロパティベーステストとファズテスト（tests/property.rs）。決定論的なランダム化テスト（新たな依存関係なし）が、数千の入力にわたって不変量を確認します。TLEとシナリオのパーサーは、でたらめな入力、非ASCII、変異させた入力、切り詰めた入力でもパニックしません。TimeCfg::validateは、NaN／inf／負の格子でもパニックしません。TLEのチェックサムは一貫しており、69桁目のみを対象とします。測地座標とECEFのラウンドトリップ、およびTEMEからECEFへの回転は、全球と広い高度帯にわたってノルムを保ちます。

変更#

• ゴールデンテストは、四つの基準シナリオについて、性能指標をフィールドごとに固定するようになりました（プラットフォーム間のlibmの揺らぎを吸収する許容差付き）。これまでの不等式のみのチェックに置き換わるため、数値の静かな退行がただちに検出されます。
• 結果アーティファクトのschema_versionを0.1から0.7に更新しました（エンジンが進んでも固定されたままでした）。
• cargo-denyは、yankされた依存関係を警告するのではなく、拒否するようになりました。
• 新しいドキュメント：CAPABILITY.md（範囲の率直な一覧）、SCHEMA.md（結果フィールドのリファレンス）、INTEGRITY.md、QUANTUM-MODELS.md、REAL_TLE_GUIDE.md。READMEのバージョンバッジがCargo.tomlとずれた場合は、CIのガードが失敗します。

0.7.0 - 2026-06-02#

追加#

• SGP4/SDP4軌道伝播。標準的な簡易摂動伝播器の、依存関係のない完全な実装です。地球近傍のSGP4に、深宇宙のSDP4拡張（日月の永年摂動と周期摂動、12 hおよび24 hの重力ポテンシャル共鳴）を加えています。公式のAIAA 2006-6753（「Revisiting Spacetrack Report #3」）の検証ベクトルと照合して確認しています。地球近傍、深宇宙、共鳴、エラーコードの各ケースにわたる666の基準状態すべてが、最悪で約4 mmの位置誤差の範囲で一致します。これは二行軌道要素セットが定義の基準とするモデルであり、実際のコンステレーションを表現できます。特に約12 hのGNSS軌道は、深宇宙かつ共鳴であり、従来の二体＋J2永年のモデルでは捉えられません。
• 完全な二行軌道要素セット（line 1＋line 2）として与えたコンステレーションは、SGP4/SDP4で伝播されるようになりました。line 2のみの要素で与えたコンステレーションは、従来どおり解析的なケプラーの二体伝播のままです。二つの形式は一つのブロックに混在させられます。新しいorbit-sgp4-gps.tomlの基準シナリオ（実際の二行形式の、GPSに似たMEOコンステレーション。SGP4で伝播）があります。最新のCelestrakの「gps-ops」セットを入れれば、現行のコンステレーションを調べられます。

0.6.0 - 2026-06-02#

追加#

• 能動的なスプーフィング攻撃のデモンストレーター。新しいspoofシナリオ種別は、徐々に増える偽の時刻のスプーフィングを注入し、各クロックのクロック支援型インテグリティ監視を実行して、スプーフィングが検出されたか、いつ検出されたか、検出されないまま運用仕様に達したかを報告します。これにより、セキュリティの性能指標が、具体的な攻撃と防御のデモンストレーションになります。新しいspoof-attack.tomlの基準シナリオがあります。
• マルチコンステレーションの可用性。軌道シナリオは、マルチGNSSの可用性とDOPのために、複数のコンステレーション（主となる[constellation]に加えた[[constellations]]のリスト）を組み合わせられます（例：GPSとGalileo）。新しいorbit-multignss.tomlの基準シナリオがあります。

0.5.0 - 2026-06-02#

追加#

• HTMLスコアカードのレポート。すべての実行は、自己完結したブランド付きのHTMLスコアカードも出力するようになりました。一行の要約、グラフ（不活性なデータURIの画像として埋め込み）、完全なJSONを含み、CLIがJSONとSVGとともに書き出します。スタディの成果物や付属書として共有できる、単一ファイルのアーティファクトです。
• 統合センサーフュージョン推定器。新しいfusionシナリオ種別は、独立した予測器を組み合わせるのではなく、単一の再帰カルマンフィルターを航法解として実行します。クロック状態[phase, frequency]と位置状態[position, velocity]を融合し、GNSSで律し（周波数オフセットと速度を学習）、途絶の間は光時刻伝送で補助します。フュージョンしたタイミングと位置のホールドオーバーと、結合共分散によるインテグリティを報告します。新しいfusion-pnt.tomlの基準シナリオがあります。
• より充実したIMUノイズモデル。加速度計は、一定のバイアスと速度ランダムウォークに加えて、残りのアラン分散の項もモデル化するようになりました。バイアス不安定性（標準的なアランのバイアス不安定性係数での1/fフリッカーの下限。クロックのフリッカー合成を再利用）と加速度ランダムウォークです。慣性シナリオに、任意のbias_instabilityとq_aaのフィールドが加わります。GNSSの再測位により、残りのバイアスドリフトが再較正されます。
• TLEから得る実際のコンステレーション幾何。コンステレーションを、tleフィールドで二行軌道要素セット（標準的なNORAD／Celestrak形式）のブロックとして与えられるようになり、可用性とDOPは、合成のウォーカーパターンではなく、実際のコンステレーションの公表された幾何を使います。エンジンは各TLEの平均ケプラー要素を読み取り、SGP4ではなく二体で伝播させます。共通のエポックからのスナップショットのスタディには妥当です。新しいorbit-real-tle.tomlの基準シナリオがあります。

0.4.0 - 2026-06-02#

追加#

• トレードスタディのパラメーター掃引。新しいsweepシナリオ種別は、一つのパラメーター（threshold_ns、duration_s、quantum_q_wf、classical_q_wfのいずれか）を線形または対数の範囲で変化させ、両方のクロックについて各点で選んだ性能指標を記録します。設計のトレードに必要な、「ホールドオーバーはクロックの安定度に対してどうスケールするか」の比較グラフが得られます。新しいsweep-clock-stability.tomlの基準シナリオがあります。
• モンテカルロの信頼帯。クロックのホールドオーバーシナリオは、多数の実現を実行できます（新しい任意のrunsフィールド）。各性能指標は、平均と5〜95パーセンタイルの広がりで報告され、グラフは各クロックの中央値の周りに5〜95%の誤差エンベロープを網掛けで示します。単一の実行が引き続き既定です。新しいclock-ensemble.tomlの基準シナリオがあります。
• 離心軌道とJ2ドリフト。軌道の種類は、完全なケプラー軌道（軌道長半径、離心率、軌道傾斜角、RAAN、近地点引数、平均近点角）になり、ケプラー方程式を解いて伝播され、任意で永年J2による昇交点の退行と近点の歳差が加わります。シナリオに、任意のeccentricity、argp_deg、j2のフィールドが加わり、orbit-molniya.tomlの基準シナリオ（12 hの高離心率・臨界傾斜角のユーザー）があります。円軌道は、従来の閉形式の経路とビット単位で一致します。
• ハイブリッド（複合PNT）パックは、インテグリティとセキュリティを報告するようになり、四つのパックすべてが、運用上の性能指標の全体をカバーします。インテグリティは、GNSSが正常な間は真値に律され、光の再同期のたびに（より緩く）再アンカーされるカルマン推定器による、タイミングチャネルの保護限界の包含率です。その限界にはリンクの観測ノイズの下限が含まれるため、リンクよりはるかに優れたクロックは、提供される解の実際のノイズに対して評価されます。セキュリティは、タイミング仕様に対するクロック支援型のスプーフィング検出スコアです。

変更#

• リリースノートは、タグに対応する、整えられたCHANGELOGの節から生成されるようになり（scripts/changelog-extract.sh）、各GitHubリリースは、生のコミットを並べるのではなく、何が変わったかを強調します。

0.3.0 - 2026-06-02#

追加#

• セキュリティの性能指標（以前は未設定）：クロックのホールドオーバーパックと軌道パックのための、クロック支援型のスプーフィング検出スコアです。GNSS由来の時刻を、コヒーレントな窓にわたってクロック自身の惰行予測と照合するインテグリティ監視をモデル化します。検出の下限は、平均化した観測ノイズとクロックの惰行の不確かさを合成したものなので、静かなクロックほど、より小さく遅い時刻スプーフィングを検出します。スコアは、タイミング仕様に対する相対値として[0, 1]で報告され、運用上の六つの性能指標が出そろいます。
• 軌道パックのための、幾何から導いた位置精度：可視衛星への視線方向の幾何から、設計行列とその共分散の因子Q = (HᵀH)⁻¹を作り、精度低下率の係数（GDOP／PDOP／HDOP／VDOP／TDOP）を求めます。位置精度は、位置DOPに、設定可能なユーザー等価距離誤差（新しい任意のsigma_uere_mシナリオフィールド）を掛けたものです。軌道の結果には、幾何の要約（解が得られたサンプルの割合、最良と中央値のPDOPと位置シグマ）が含まれるようになりました。
• エンジンをWebAssemblyとしてクライアント側で実行する、ブラウザー内のプレイグラウンド（web/）です。基準シナリオを選ぶかTOMLを編集して実行すると、要約、グラフ、完全なJSONが表示され、何もアップロードされません。pagesワークフローがこれをビルドしてGitHub Pagesに公開し、新しいsummaryのWebAssemblyエクスポートが表示内容を支えます。
• SVGグラフにラベル付きのy軸を追加しました。グリッド線、数値の目盛りラベル、単位の軸タイトルです（共有のchartヘルパー経由）。これにより、大きさが読み取れるようになります。
• crates.io、PyPI、npmのパッケージ公開ワークフロー（publish）です。それぞれ、レジストリのトークンが設定されている場合にのみ動き、公開されたリリースで起動します。

0.2.0 - 2026-06-02#

追加#

• クロック誤差モデルのためのフリッカー（1/f）FMの下限です。対数間隔のオルンシュタイン＝ウーレンベック過程の和として合成され、平坦なアラン偏差の下限が設定可能な水準になるよう較正されます。既定では無効で、任意のflicker_floorシナリオフィールドにより、クロックごとに有効にします。
• 慣性モデルのためのジャイロチャネルです。残りのジャイロバイアスと角度ランダムウォークが姿勢（傾き）の誤差を駆動し、それが重力を水平方向の比力誤差に結合します。これはストラップダウンで誤差が増大する主要な仕組みです。既定では無効で、任意のgyro_biasとq_arwのフィールドにより、センサーごとに有効にします。
• 厳密なヴァン・ローン法の過程雑音の離散化を備えた、二状態（位相、周波数）のカルマンクロック推定器です。既知の状態からの惰行は、解析的なホールドオーバー誤差の増大（q_wf*T + q_rw*T^3/3）を厳密に再現し、フィルターはさらに、オンラインで1シグマの不確かさの限界も与えます。
• クロックの実行は、インテグリティの性能指標（以前は未設定）を報告するようになりました。途絶中のサンプルのうち、誤差がフィルターの3シグマの保護限界の内側にとどまる割合で、JSONの結果とCLIの要約に表示されます。
• 幾何から導いたGNSSの可用性です。円軌道の伝播、ウォーカー・デルタのコンステレーション生成器、視線方向の可視性（地球による掩蔽と仰角マスク）により、実際の軌道幾何から可用性のタイムラインを作ります。新しいorbitシナリオ種別と、orbit-gnss-challenged.tomlの基準シナリオ（GNSSの殻の内側にあり、覆域が断続する宇宙機）があります。
• run、run_full、versionを公開する、任意のPython拡張（PyO3、abi3）です。maturin（pyproject.toml）でパッケージ化され、リリースタグのwheelsワークフローでLinux、macOS、Windows向けにビルドされます。このバインディングは、機能フラグで制御される任意の依存関係です。既定のビルド、テスト、依存関係の監査ゲートには影響しません。
• run、chart_svg、versionを公開する、任意のWebAssemblyモジュール（wasm-bindgen）です。wasm機能のもとでwasm-packによりビルドされ、getrandomは、wasm32でブラウザーのエントロピー源を使うようにターゲットで制御されます。
• CLIと両方のバインディングが使う共有のapi::run_tomlディスパッチです。これにより、コマンドラインとバインディングが食い違うことはありません。

変更#

• ホールドオーバーのスコアリングは、セグメントを意識するようになりました。途絶のタイムラインはGNSSの再捕捉で連続するセグメントに分割され、報告されるホールドオーバーは、それらのうち最悪（最短）の惰行です。単一の途絶のシナリオは変わりません。クロック、慣性、ハイブリッドのスコアラーに適用されます。
• 慣性モデルが報告するkindは、加速度計とジャイロを合わせたチャネルを反映して、inertialになりました（以前はaccelerometer）。

0.1.0 - 2026-06-01#

初回リリース。

追加#

• ハイブリッド量子／従来型PNTのための決定論的シミュレーションエンジンです。共通の誤差モデルインターフェース、宣言的なGNSS可用性シナリオ、ホールドオーバー／推測航法の推定器、標準的な運用PNT基準に対する性能指標のスコアリングを備えます。結果はscenario + seed + engine versionから再現可能で（シナリオのハッシュを含む、バージョン付きで自己記述的なJSON）、SVGグラフとして描画されます。CLIはシナリオをkindでディスパッチします。
• 四つのセンサーパックです。それぞれ公表データに基づいて較正され、標準的な関係式に対して照合して確認しています。
  • クロックのホールドオーバー：ホワイトFM、ランダムウォークFM、線形エージング。重なりありアラン偏差（Riley、NIST SP 1065）で照合して確認しています。チップスケール原子時計とストロンチウム光格子時計の比較です。
  • 慣性の推測航法：残りのバイアスと速度ランダムウォークを二重積分して位置誤差にします。Grovesの誤差増大の関係式と照合して確認しています。冷却原子型と航法級の加速度計の比較です。
  • 時刻伝送：光リンクとRFリンクのタイミングジッター、同期の精密度、そして片方向測距。
  • ハイブリッドフュージョン（総仕上げ）：タイミングと位置の両方を保持しなければならない複合PNTスイートで、任意で光衛星間時刻伝送によるクロック補助を備えます。
• scenarios/の下に、パックごとに出典付きの基準シナリオを一つずつ置き、すべての数値パラメーターに査読済みのprovenanceを付けています。
• 再現性とリポジトリの衛生に関するガード。CI（フォーマット、clippy、テスト、ガード、MSRV）と、すべてのチェックを再実行するタグ制御のリリースパイプライン。
• ドキュメント：アーキテクチャ図付きのREADME、検証状況のレポート、貢献ガイド、セキュリティポリシー、行動規範。Apache-2.0ライセンス。Issue／PRのテンプレートとDependabotの設定。
• 全体にわたって特定ベンダーに依存せず、査読済みの科学・計量学の引用は残しています。
• Apache-2.0のライセンス衛生：すべてのソースにSPDXヘッダー、商標表示を含むNOTICE、貢献に対するDeveloper Certificate of Origin（DCO）の署名、CIでの依存関係のライセンスと勧告に対するcargo-denyの強制。
• オープンコアの位置づけ（README）：無償のApache-2.0エンジンに加えて、Ashforde OÜによる商用サポート、統合、独自拡張を利用できます。ライセンス料ではなく、サービスで維持されます。
• ソフトウェアを引用できるようにCITATION.cffを用意しました。