kshana 0.7.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- kshana-0.7.0/.editorconfig +14 -0
- kshana-0.7.0/.gitignore +20 -0
- kshana-0.7.0/CHANGELOG.md +225 -0
- kshana-0.7.0/CITATION.cff +25 -0
- kshana-0.7.0/CODE_OF_CONDUCT.md +85 -0
- kshana-0.7.0/CONTRIBUTING.md +94 -0
- kshana-0.7.0/Cargo.lock +612 -0
- kshana-0.7.0/Cargo.toml +53 -0
- kshana-0.7.0/LICENSE +202 -0
- kshana-0.7.0/NOTICE +8 -0
- kshana-0.7.0/PKG-INFO +557 -0
- kshana-0.7.0/README.md +538 -0
- kshana-0.7.0/SECURITY.md +15 -0
- kshana-0.7.0/deny.toml +25 -0
- kshana-0.7.0/docs/ARCHITECTURE.md +263 -0
- kshana-0.7.0/docs/CONCEPTS.md +102 -0
- kshana-0.7.0/docs/GLOSSARY.md +129 -0
- kshana-0.7.0/docs/VALIDATION.md +109 -0
- kshana-0.7.0/docs/assets/clock-ensemble-band.svg +1 -0
- kshana-0.7.0/docs/assets/clock-holdover.svg +1 -0
- kshana-0.7.0/docs/assets/inertial-deadreckoning.svg +1 -0
- kshana-0.7.0/docs/assets/kshana-banner.svg +23 -0
- kshana-0.7.0/docs/assets/orbit-gnss-challenged.svg +1 -0
- kshana-0.7.0/docs/assets/sweep-clock-stability.svg +1 -0
- kshana-0.7.0/pyproject.toml +28 -0
- kshana-0.7.0/rust-toolchain.toml +3 -0
- kshana-0.7.0/rustfmt.toml +2 -0
- kshana-0.7.0/scenarios/clock-ensemble.toml +34 -0
- kshana-0.7.0/scenarios/clock-holdover-labsr.toml +30 -0
- kshana-0.7.0/scenarios/clock-holdover.toml +29 -0
- kshana-0.7.0/scenarios/fusion-pnt.toml +57 -0
- kshana-0.7.0/scenarios/hybrid-pnt.toml +49 -0
- kshana-0.7.0/scenarios/imu-deadreckoning.toml +29 -0
- kshana-0.7.0/scenarios/orbit-gnss-challenged.toml +56 -0
- kshana-0.7.0/scenarios/orbit-molniya.toml +59 -0
- kshana-0.7.0/scenarios/orbit-multignss.toml +55 -0
- kshana-0.7.0/scenarios/orbit-real-tle.toml +52 -0
- kshana-0.7.0/scenarios/orbit-sgp4-gps.toml +98 -0
- kshana-0.7.0/scenarios/spoof-attack.toml +36 -0
- kshana-0.7.0/scenarios/sweep-clock-stability.toml +44 -0
- kshana-0.7.0/scenarios/timetransfer.toml +16 -0
- kshana-0.7.0/scripts/changelog-extract.sh +40 -0
- kshana-0.7.0/scripts/check-no-attribution.sh +19 -0
- kshana-0.7.0/scripts/check-reproducible.sh +11 -0
- kshana-0.7.0/src/allan.rs +47 -0
- kshana-0.7.0/src/api.rs +347 -0
- kshana-0.7.0/src/chart.rs +45 -0
- kshana-0.7.0/src/ensemble.rs +383 -0
- kshana-0.7.0/src/estimator.rs +101 -0
- kshana-0.7.0/src/fom.rs +226 -0
- kshana-0.7.0/src/fusion.rs +244 -0
- kshana-0.7.0/src/hybrid.rs +428 -0
- kshana-0.7.0/src/inertial.rs +609 -0
- kshana-0.7.0/src/kalman.rs +233 -0
- kshana-0.7.0/src/lib.rs +27 -0
- kshana-0.7.0/src/main.rs +49 -0
- kshana-0.7.0/src/models.rs +317 -0
- kshana-0.7.0/src/orbit.rs +1001 -0
- kshana-0.7.0/src/python.rs +47 -0
- kshana-0.7.0/src/report.rs +243 -0
- kshana-0.7.0/src/run.rs +219 -0
- kshana-0.7.0/src/scenario.rs +132 -0
- kshana-0.7.0/src/security.rs +167 -0
- kshana-0.7.0/src/sgp4.rs +1315 -0
- kshana-0.7.0/src/spoof.rs +288 -0
- kshana-0.7.0/src/sweep.rs +351 -0
- kshana-0.7.0/src/timetransfer.rs +326 -0
- kshana-0.7.0/src/tle.rs +330 -0
- kshana-0.7.0/src/types.rs +41 -0
- kshana-0.7.0/src/wasm.rs +42 -0
- kshana-0.7.0/tests/calibration.rs +91 -0
- kshana-0.7.0/tests/fixtures/sgp4/README.md +23 -0
- kshana-0.7.0/tests/fixtures/sgp4/SGP4-VER.TLE +110 -0
- kshana-0.7.0/tests/fixtures/sgp4/tcppver.out +700 -0
- kshana-0.7.0/tests/golden.rs +59 -0
- kshana-0.7.0/tests/sgp4_verification.rs +151 -0
kshana-0.7.0/.gitignore
ADDED
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
/target
|
|
2
|
+
*.result.json
|
|
3
|
+
*.chart.svg
|
|
4
|
+
*.report.html
|
|
5
|
+
|
|
6
|
+
# Python packaging / build artifacts (maturin)
|
|
7
|
+
/dist
|
|
8
|
+
*.so
|
|
9
|
+
*.pyd
|
|
10
|
+
__pycache__/
|
|
11
|
+
*.egg-info/
|
|
12
|
+
.venv/
|
|
13
|
+
|
|
14
|
+
# WebAssembly package (wasm-pack output)
|
|
15
|
+
/pkg
|
|
16
|
+
|
|
17
|
+
# Playground build outputs (generated/copied by web/build.sh and the Pages workflow)
|
|
18
|
+
/web/pkg
|
|
19
|
+
/web/scenarios
|
|
20
|
+
/web/assets
|
|
@@ -0,0 +1,225 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to Kshana are documented here.
|
|
4
|
+
|
|
5
|
+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
|
|
6
|
+
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
|
+
While the project is pre-1.0, the public scenario/result schema may still change;
|
|
8
|
+
breaking changes are called out explicitly.
|
|
9
|
+
|
|
10
|
+
## [Unreleased]
|
|
11
|
+
|
|
12
|
+
### Planned
|
|
13
|
+
- Velocity-domain outputs from the SGP4 propagator (currently position drives the
|
|
14
|
+
availability and dilution-of-precision geometry).
|
|
15
|
+
|
|
16
|
+
## [0.7.0] - 2026-06-02
|
|
17
|
+
|
|
18
|
+
### Added
|
|
19
|
+
- **SGP4/SDP4 orbit propagation.** A full, dependency-free implementation of the
|
|
20
|
+
standard simplified-perturbations propagator — near-Earth SGP4 together with the
|
|
21
|
+
deep-space SDP4 extension (lunar-solar secular and periodic perturbations and
|
|
22
|
+
12 h / 24 h geopotential resonance). It is validated against the official AIAA
|
|
23
|
+
2006-6753 ("Revisiting Spacetrack Report #3") verification vectors: all 666
|
|
24
|
+
reference states across the near-Earth, deep-space, resonant, and error-code
|
|
25
|
+
cases match to a worst-case position error of about 4 mm. This is the model
|
|
26
|
+
two-line element sets are defined against, so it represents real constellations
|
|
27
|
+
— notably the ~12 h GNSS orbits, which are deep-space and resonant and which the
|
|
28
|
+
earlier two-body + J2-secular model cannot capture.
|
|
29
|
+
- A constellation given as **full two-line element sets** (line 1 + line 2) is now
|
|
30
|
+
propagated with SGP4/SDP4; a constellation given as line-2-only elements keeps
|
|
31
|
+
the analytic Keplerian two-body propagation, unchanged. The two forms can be
|
|
32
|
+
mixed in one block. New `orbit-sgp4-gps.toml` reference scenario (a GPS-like MEO
|
|
33
|
+
constellation in real two-line format, propagated with SGP4) — drop in a current
|
|
34
|
+
Celestrak "gps-ops" set to study the live constellation.
|
|
35
|
+
|
|
36
|
+
## [0.6.0] - 2026-06-02
|
|
37
|
+
|
|
38
|
+
### Added
|
|
39
|
+
- **Active spoofing-attack demonstrator.** A new `spoof` scenario kind injects a
|
|
40
|
+
ramping false-time spoof and runs each clock's clock-aided integrity monitor,
|
|
41
|
+
reporting whether and when the spoof is detected and whether it reaches the
|
|
42
|
+
operational spec undetected — turning the Security figure of merit into a concrete
|
|
43
|
+
attack/defence demonstration. New `spoof-attack.toml` reference scenario.
|
|
44
|
+
- **Multi-constellation availability.** An orbit scenario can combine several
|
|
45
|
+
constellations (a `[[constellations]]` list alongside the primary
|
|
46
|
+
`[constellation]`) for multi-GNSS availability and dilution of precision — e.g.
|
|
47
|
+
GPS plus Galileo. New `orbit-multignss.toml` reference scenario.
|
|
48
|
+
|
|
49
|
+
## [0.5.0] - 2026-06-02
|
|
50
|
+
|
|
51
|
+
### Added
|
|
52
|
+
- **HTML scorecard report.** Every run now also produces a self-contained, branded
|
|
53
|
+
HTML scorecard — the one-line summary, the chart (embedded as an inert data-URI
|
|
54
|
+
image), and the full JSON — written by the CLI alongside the JSON and SVG. A
|
|
55
|
+
shareable single-file artifact for a study deliverable or annex.
|
|
56
|
+
- **Joint sensor-fusion estimator.** A new `fusion` scenario kind runs a single
|
|
57
|
+
recursive Kalman filter as the navigation solution — fusing the clock state
|
|
58
|
+
`[phase, frequency]` and the position state `[position, velocity]`, disciplined by
|
|
59
|
+
GNSS (learning the frequency offset and velocity) and aided by optical time
|
|
60
|
+
transfer during the outage — rather than composing independent predictors. It
|
|
61
|
+
reports fused timing/position holdover and a joint-covariance integrity. New
|
|
62
|
+
`fusion-pnt.toml` reference scenario.
|
|
63
|
+
- **Fuller IMU noise model.** The accelerometer now models the remaining
|
|
64
|
+
Allan-variance terms beyond the constant bias and velocity random walk:
|
|
65
|
+
**bias instability** (a 1/f flicker floor at the standard Allan bias-instability
|
|
66
|
+
coefficient, reusing the clock's flicker synthesis) and **acceleration random
|
|
67
|
+
walk**. New optional `bias_instability` and `q_aa` inertial scenario fields; a
|
|
68
|
+
GNSS re-fix re-calibrates the residual bias drift.
|
|
69
|
+
- **Real constellation geometry from TLEs.** A constellation can be given as a block
|
|
70
|
+
of two-line element sets (the standard NORAD/Celestrak format) via a `tle` field,
|
|
71
|
+
so availability and dilution of precision use a real constellation's published
|
|
72
|
+
geometry instead of a synthetic Walker pattern. The engine reads each TLE's mean
|
|
73
|
+
Keplerian elements and propagates them two-body — not SGP4 — which is sound for a
|
|
74
|
+
snapshot study from a common epoch. New `orbit-real-tle.toml` reference scenario.
|
|
75
|
+
|
|
76
|
+
## [0.4.0] - 2026-06-02
|
|
77
|
+
|
|
78
|
+
### Added
|
|
79
|
+
- **Trade-study parameter sweeps.** A new `sweep` scenario kind varies one
|
|
80
|
+
parameter (`threshold_ns`, `duration_s`, `quantum_q_wf`, or `classical_q_wf`)
|
|
81
|
+
across a linear or logarithmic range and records a chosen figure of merit at each
|
|
82
|
+
point for both clocks, producing the "how does holdover scale with clock
|
|
83
|
+
stability?" comparison chart a design trade needs. New `sweep-clock-stability.toml`
|
|
84
|
+
reference scenario.
|
|
85
|
+
- **Monte Carlo confidence bands.** The clock-holdover scenario can run many
|
|
86
|
+
realizations (new optional `runs` field): each figure of merit is then reported
|
|
87
|
+
as a mean with a 5th–95th-percentile spread, and the chart shades the 5–95%
|
|
88
|
+
error envelope around the median for each clock. A single run remains the default.
|
|
89
|
+
New `clock-ensemble.toml` reference scenario.
|
|
90
|
+
- **Eccentric orbits and J2 drift.** The orbit type is now a full Keplerian orbit
|
|
91
|
+
(semi-major axis, eccentricity, inclination, RAAN, argument of perigee, mean
|
|
92
|
+
anomaly), propagated by solving Kepler's equation, with optional secular J2 nodal
|
|
93
|
+
regression and apsidal precession. New optional `eccentricity`, `argp_deg`, and
|
|
94
|
+
`j2` scenario fields, and an `orbit-molniya.toml` reference scenario (a 12 h
|
|
95
|
+
highly-eccentric critically-inclined user). Circular orbits keep the original
|
|
96
|
+
closed-form path bit-for-bit.
|
|
97
|
+
- The hybrid (combined-PNT) pack now reports **Integrity** and **Security**, so all
|
|
98
|
+
four packs cover the full set of operational figures of merit. Integrity is the
|
|
99
|
+
timing-channel protection-bound containment from a Kalman estimator disciplined to
|
|
100
|
+
truth while GNSS is nominal and re-anchored (more loosely) at each optical re-sync;
|
|
101
|
+
its bound includes the link's measurement-noise floor, so a clock far better than
|
|
102
|
+
the link is scored against the delivered solution's actual noise. Security is the
|
|
103
|
+
clock-aided spoof-detection score against the timing spec.
|
|
104
|
+
|
|
105
|
+
### Changed
|
|
106
|
+
- Release notes are now generated from the curated CHANGELOG section for the tag
|
|
107
|
+
(`scripts/changelog-extract.sh`), so each GitHub release highlights what changed
|
|
108
|
+
instead of listing raw commits.
|
|
109
|
+
|
|
110
|
+
## [0.3.0] - 2026-06-02
|
|
111
|
+
|
|
112
|
+
### Added
|
|
113
|
+
- **Security** figure of merit (previously unpopulated): a clock-aided
|
|
114
|
+
spoof-detection score for the clock-holdover and orbit packs. It models an
|
|
115
|
+
integrity monitor that cross-checks GNSS-derived time against the clock's own
|
|
116
|
+
coasted prediction over a coherent window; the detection floor combines the
|
|
117
|
+
averaged measurement noise with the clock's coast uncertainty, so a quieter
|
|
118
|
+
clock detects smaller, slower time-spoofs. The score is reported in `[0, 1]`
|
|
119
|
+
relative to the timing spec, completing the six operational figures of merit.
|
|
120
|
+
- Geometry-derived **position accuracy** for the orbit pack: from the
|
|
121
|
+
line-of-sight geometry to the visible satellites it forms the design matrix
|
|
122
|
+
and its covariance factor `Q = (HᵀH)⁻¹`, yielding the dilution-of-precision
|
|
123
|
+
factors (GDOP/PDOP/HDOP/VDOP/TDOP). Position accuracy is the position DOP
|
|
124
|
+
scaled by a configurable user-equivalent range error (new optional
|
|
125
|
+
`sigma_uere_m` scenario field). An orbit result now carries a geometry summary
|
|
126
|
+
(fraction of samples with a fix, best and median PDOP and position sigma).
|
|
127
|
+
- An in-browser **playground** (`web/`) that runs the engine client-side as
|
|
128
|
+
WebAssembly: pick a reference scenario or edit the TOML, run it, and see the
|
|
129
|
+
summary, chart, and full JSON, with nothing uploaded. A `pages` workflow
|
|
130
|
+
builds and publishes it to GitHub Pages, and a new `summary` WebAssembly export
|
|
131
|
+
backs the readout.
|
|
132
|
+
- Labelled y-axes on the SVG charts: gridlines, numeric tick labels, and a units
|
|
133
|
+
axis title (via a shared `chart` helper), so magnitudes are readable.
|
|
134
|
+
- Package-publishing workflow (`publish`) for crates.io, PyPI, and npm, each
|
|
135
|
+
gated on its registry token and triggered by a published release.
|
|
136
|
+
|
|
137
|
+
## [0.2.0] - 2026-06-02
|
|
138
|
+
|
|
139
|
+
### Added
|
|
140
|
+
- Flicker (1/f) FM floor for the clock error model, synthesised as a sum of
|
|
141
|
+
log-spaced Ornstein-Uhlenbeck processes and calibrated so the flat
|
|
142
|
+
Allan-deviation floor sits at a configurable level. Off by default; enabled
|
|
143
|
+
per clock via the optional `flicker_floor` scenario field.
|
|
144
|
+
- Gyro channel for the inertial model: residual gyro bias and angular random
|
|
145
|
+
walk drive an attitude (tilt) error that couples gravity into a horizontal
|
|
146
|
+
specific-force error, the dominant strapdown error-growth mechanism. Off by
|
|
147
|
+
default; enabled per sensor via the optional `gyro_bias` and `q_arw` fields.
|
|
148
|
+
- Two-state (phase, frequency) Kalman clock estimator with exact van Loan
|
|
149
|
+
process-noise discretisation. Coasting from a known state reproduces the
|
|
150
|
+
analytic holdover error growth (`q_wf*T + q_rw*T^3/3`) exactly, and the filter
|
|
151
|
+
additionally yields an online 1-sigma uncertainty bound.
|
|
152
|
+
- The clock run now reports the **Integrity** figure of merit (previously
|
|
153
|
+
unpopulated): the fraction of outage samples whose error stays inside the
|
|
154
|
+
filter's 3-sigma protection bound, surfaced in the JSON result and CLI summary.
|
|
155
|
+
- Geometry-derived GNSS availability: circular-orbit propagation, a Walker-delta
|
|
156
|
+
constellation generator, and line-of-sight visibility (Earth-occultation plus
|
|
157
|
+
elevation mask) produce the availability timeline from real orbital geometry.
|
|
158
|
+
New `orbit` scenario kind and the `orbit-gnss-challenged.toml` reference
|
|
159
|
+
scenario (a spacecraft inside the GNSS shell with intermittent coverage).
|
|
160
|
+
- Optional Python extension (PyO3, abi3) exposing `run`, `run_full`, and
|
|
161
|
+
`version`, packaged with maturin (`pyproject.toml`) and built for Linux, macOS,
|
|
162
|
+
and Windows by a release-tag `wheels` workflow. The binding is a feature-gated,
|
|
163
|
+
optional dependency: the default build, tests, and dependency-audit gate are
|
|
164
|
+
unaffected.
|
|
165
|
+
- Optional WebAssembly module (wasm-bindgen) exposing `run`, `chart_svg`, and
|
|
166
|
+
`version`, built with wasm-pack under the `wasm` feature; `getrandom` is
|
|
167
|
+
target-gated to use the browser entropy source on `wasm32`.
|
|
168
|
+
- Shared `api::run_toml` dispatch used by the CLI and both bindings, so the
|
|
169
|
+
command line and the bindings cannot drift.
|
|
170
|
+
|
|
171
|
+
### Changed
|
|
172
|
+
- Holdover scoring is now segment-aware: outage timelines are split into
|
|
173
|
+
contiguous segments at GNSS re-acquisition, and the reported holdover is the
|
|
174
|
+
worst-case (shortest) coast across them. Single-outage scenarios are
|
|
175
|
+
unchanged. Applies to the clock, inertial, and hybrid scorers.
|
|
176
|
+
- The inertial model's reported `kind` is now `inertial` (was `accelerometer`),
|
|
177
|
+
reflecting the combined accelerometer and gyro channels.
|
|
178
|
+
|
|
179
|
+
## [0.1.0] - 2026-06-01
|
|
180
|
+
|
|
181
|
+
Initial release.
|
|
182
|
+
|
|
183
|
+
### Added
|
|
184
|
+
- **Deterministic simulation engine** for hybrid quantum/classical PNT: a common
|
|
185
|
+
error-model interface, declarative GNSS-availability scenarios, holdover /
|
|
186
|
+
dead-reckoning estimators, and figure-of-merit scoring against the standard
|
|
187
|
+
operational PNT criteria. Results are reproducible from `scenario + seed + engine
|
|
188
|
+
version` (versioned, self-describing JSON with a scenario hash) and rendered as SVG
|
|
189
|
+
charts. The CLI dispatches scenarios by `kind`.
|
|
190
|
+
- **Four sensor packs**, each calibrated to published data and validated against the
|
|
191
|
+
standard relation:
|
|
192
|
+
- **Clock holdover** — white FM, random-walk FM, and linear aging; validated by
|
|
193
|
+
overlapping Allan deviation (Riley, NIST SP 1065). Chip-scale atomic clock vs
|
|
194
|
+
strontium optical lattice clock.
|
|
195
|
+
- **Inertial dead-reckoning** — residual bias + velocity random walk, double
|
|
196
|
+
integrated to position error; validated against Groves' error-growth relations.
|
|
197
|
+
Cold-atom vs navigation-grade accelerometer.
|
|
198
|
+
- **Time transfer** — optical vs RF link timing jitter → synchronization precision →
|
|
199
|
+
one-way ranging.
|
|
200
|
+
- **Hybrid fusion (capstone)** — a combined PNT suite that must hold both timing and
|
|
201
|
+
position, with optional optical inter-satellite time-transfer clock-aiding.
|
|
202
|
+
- **One cited reference scenario per pack** under `scenarios/`, every numeric
|
|
203
|
+
parameter carrying a peer-reviewed `provenance`.
|
|
204
|
+
- **Reproducibility and repository-hygiene guards**; CI (format, clippy, tests,
|
|
205
|
+
guards, MSRV) and a tag-gated release pipeline that re-runs all checks.
|
|
206
|
+
- **Documentation**: README with architecture diagrams, validation-status report,
|
|
207
|
+
contributing guide, security policy, and code of conduct; Apache-2.0 license;
|
|
208
|
+
issue/PR templates and Dependabot configuration.
|
|
209
|
+
- Vendor-neutral throughout; peer-reviewed scientific and metrology citations retained.
|
|
210
|
+
- Apache-2.0 license hygiene: SPDX headers on all sources, a `NOTICE` with trademark
|
|
211
|
+
notice, Developer Certificate of Origin (DCO) sign-off for contributions, and
|
|
212
|
+
`cargo-deny` enforcement of dependency licenses/advisories in CI.
|
|
213
|
+
- Open-core positioning (README): a free Apache-2.0 engine plus available commercial
|
|
214
|
+
support, integration, and proprietary extensions from Ashforde OÜ — sustained by
|
|
215
|
+
services, not license fees.
|
|
216
|
+
- `CITATION.cff` so the software can be cited.
|
|
217
|
+
|
|
218
|
+
[Unreleased]: https://github.com/AshfordeOU/kshana/compare/v0.7.0...HEAD
|
|
219
|
+
[0.7.0]: https://github.com/AshfordeOU/kshana/compare/v0.6.0...v0.7.0
|
|
220
|
+
[0.6.0]: https://github.com/AshfordeOU/kshana/compare/v0.5.0...v0.6.0
|
|
221
|
+
[0.5.0]: https://github.com/AshfordeOU/kshana/compare/v0.4.0...v0.5.0
|
|
222
|
+
[0.4.0]: https://github.com/AshfordeOU/kshana/compare/v0.3.0...v0.4.0
|
|
223
|
+
[0.3.0]: https://github.com/AshfordeOU/kshana/compare/v0.2.0...v0.3.0
|
|
224
|
+
[0.2.0]: https://github.com/AshfordeOU/kshana/compare/v0.1.0...v0.2.0
|
|
225
|
+
[0.1.0]: https://github.com/AshfordeOU/kshana/releases/tag/v0.1.0
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
cff-version: 1.2.0
|
|
2
|
+
title: "Kshana — hybrid quantum/classical PNT performance simulator"
|
|
3
|
+
message: "If you use Kshana in your work, please cite it using this metadata."
|
|
4
|
+
type: software
|
|
5
|
+
authors:
|
|
6
|
+
- family-names: Baweja
|
|
7
|
+
given-names: Chakshu
|
|
8
|
+
email: contact@ashforde.org
|
|
9
|
+
repository-code: "https://github.com/AshfordeOU/kshana"
|
|
10
|
+
url: "https://github.com/AshfordeOU/kshana"
|
|
11
|
+
abstract: >-
|
|
12
|
+
Open, reproducible simulator for hybrid quantum/classical positioning,
|
|
13
|
+
navigation and timing (PNT). Quantifies the performance, autonomy, and
|
|
14
|
+
resilience advantage of quantum clocks, quantum inertial sensors, and optical
|
|
15
|
+
time transfer over classical PNT, scored against operational figures of merit,
|
|
16
|
+
with every sensor parameter traceable to a published source.
|
|
17
|
+
keywords:
|
|
18
|
+
- PNT
|
|
19
|
+
- navigation
|
|
20
|
+
- quantum
|
|
21
|
+
- GNSS
|
|
22
|
+
- simulation
|
|
23
|
+
license: Apache-2.0
|
|
24
|
+
version: 0.7.0
|
|
25
|
+
date-released: "2026-06-02"
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
|
|
2
|
+
# Contributor Covenant Code of Conduct
|
|
3
|
+
|
|
4
|
+
## Our Pledge
|
|
5
|
+
|
|
6
|
+
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
|
|
7
|
+
|
|
8
|
+
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
|
|
9
|
+
|
|
10
|
+
## Our Standards
|
|
11
|
+
|
|
12
|
+
Examples of behavior that contributes to a positive environment for our community include:
|
|
13
|
+
|
|
14
|
+
* Demonstrating empathy and kindness toward other people
|
|
15
|
+
* Being respectful of differing opinions, viewpoints, and experiences
|
|
16
|
+
* Giving and gracefully accepting constructive feedback
|
|
17
|
+
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
|
|
18
|
+
* Focusing on what is best not just for us as individuals, but for the overall community
|
|
19
|
+
|
|
20
|
+
Examples of unacceptable behavior include:
|
|
21
|
+
|
|
22
|
+
* The use of sexualized language or imagery, and sexual attention or advances of any kind
|
|
23
|
+
* Trolling, insulting or derogatory comments, and personal or political attacks
|
|
24
|
+
* Public or private harassment
|
|
25
|
+
* Publishing others' private information, such as a physical or email address, without their explicit permission
|
|
26
|
+
* Other conduct which could reasonably be considered inappropriate in a professional setting
|
|
27
|
+
|
|
28
|
+
## Enforcement Responsibilities
|
|
29
|
+
|
|
30
|
+
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
|
|
31
|
+
|
|
32
|
+
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
|
|
33
|
+
|
|
34
|
+
## Scope
|
|
35
|
+
|
|
36
|
+
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
|
|
37
|
+
|
|
38
|
+
## Enforcement
|
|
39
|
+
|
|
40
|
+
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at contact@ashforde.org. All complaints will be reviewed and investigated promptly and fairly.
|
|
41
|
+
|
|
42
|
+
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
|
|
43
|
+
|
|
44
|
+
## Enforcement Guidelines
|
|
45
|
+
|
|
46
|
+
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
|
|
47
|
+
|
|
48
|
+
### 1. Correction
|
|
49
|
+
|
|
50
|
+
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
|
|
51
|
+
|
|
52
|
+
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
|
|
53
|
+
|
|
54
|
+
### 2. Warning
|
|
55
|
+
|
|
56
|
+
**Community Impact**: A violation through a single incident or series of actions.
|
|
57
|
+
|
|
58
|
+
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
|
|
59
|
+
|
|
60
|
+
### 3. Temporary Ban
|
|
61
|
+
|
|
62
|
+
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
|
|
63
|
+
|
|
64
|
+
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
|
|
65
|
+
|
|
66
|
+
### 4. Permanent Ban
|
|
67
|
+
|
|
68
|
+
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
|
|
69
|
+
|
|
70
|
+
**Consequence**: A permanent ban from any sort of public interaction within the community.
|
|
71
|
+
|
|
72
|
+
## Attribution
|
|
73
|
+
|
|
74
|
+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
|
|
75
|
+
|
|
76
|
+
Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder][Mozilla CoC].
|
|
77
|
+
|
|
78
|
+
For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at [https://www.contributor-covenant.org/translations][translations].
|
|
79
|
+
|
|
80
|
+
[homepage]: https://www.contributor-covenant.org
|
|
81
|
+
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
|
|
82
|
+
[Mozilla CoC]: https://github.com/mozilla/diversity
|
|
83
|
+
[FAQ]: https://www.contributor-covenant.org/faq
|
|
84
|
+
[translations]: https://www.contributor-covenant.org/translations
|
|
85
|
+
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
# Contributing to Kshana
|
|
2
|
+
|
|
3
|
+
Thanks for your interest. Kshana aims to be a **neutral, reproducible, honestly-
|
|
4
|
+
validated** reference for hybrid quantum/classical PNT. Contributions are held to that
|
|
5
|
+
bar: correctness, citations, and reproducibility over breadth.
|
|
6
|
+
|
|
7
|
+
## Development
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
cargo build
|
|
11
|
+
cargo test # all tests must pass
|
|
12
|
+
cargo clippy # keep it warning-clean
|
|
13
|
+
cargo fmt
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
The optional language bindings are feature-gated and off by default (so the build
|
|
17
|
+
above and the dependency-audit gate never touch them). To work on them:
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
maturin develop --features python # Python extension (needs maturin)
|
|
21
|
+
wasm-pack build --target web -- --features wasm # WebAssembly module
|
|
22
|
+
cargo clippy --features python --features wasm # lint the binding modules
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Before every commit, both guards must pass
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
./scripts/check-reproducible.sh # reference scenario is byte-identical across runs
|
|
29
|
+
./scripts/check-no-attribution.sh # repo hygiene (see below)
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
- **Reproducibility is a hard invariant.** A change that makes `(scenario, seed,
|
|
33
|
+
version)` non-deterministic is a bug. Randomness must flow through the seeded RNG;
|
|
34
|
+
quantum and classical runs use independent, deterministically-derived seeds.
|
|
35
|
+
- **Repository hygiene.** Commits and content must carry no automated-tool attribution
|
|
36
|
+
trailers or footers, and must not name an AI assistant as an author anywhere in
|
|
37
|
+
content, file names, or history. The guard enforces this.
|
|
38
|
+
|
|
39
|
+
## Adding or changing a sensor model
|
|
40
|
+
|
|
41
|
+
1. **Every numeric parameter needs provenance.** Put the citation in the model's
|
|
42
|
+
`provenance` string and the scenario file. No anonymous constants.
|
|
43
|
+
2. **Validate against the standard relation,** not just internal consistency — e.g.
|
|
44
|
+
Allan deviation for clocks, Groves' dead-reckoning error growth for inertial, the
|
|
45
|
+
timing→ranging conversion for time transfer. Add a test that the simulated output
|
|
46
|
+
reproduces the published/relation value within a stated tolerance.
|
|
47
|
+
3. **Be honest about maturity.** Update `docs/VALIDATION.md`: mark each term
|
|
48
|
+
`validated` or `not modeled`, and label figures that are targets or ground-
|
|
49
|
+
demonstrator results as such.
|
|
50
|
+
|
|
51
|
+
## Tests
|
|
52
|
+
|
|
53
|
+
- Test-driven: write the failing test first, with the expected value **derived by
|
|
54
|
+
hand** from the physics/relation before implementing.
|
|
55
|
+
- Deterministic tests assert exact (hand-derived) values; statistical tests assert a
|
|
56
|
+
stated tolerance and, ideally, average over seeds to control scatter.
|
|
57
|
+
|
|
58
|
+
## Commits and versioning
|
|
59
|
+
|
|
60
|
+
- **Conventional Commits** (`feat:`, `fix:`, `docs:`, `test:`, `chore:` …).
|
|
61
|
+
- **Semantic Versioning.** Pre-1.0, the scenario/result schema may change; call out
|
|
62
|
+
breaking changes.
|
|
63
|
+
- **Publishing to crates.io is a manual maintainer step.** It requires a registry
|
|
64
|
+
token and is run by hand (`cargo publish`). The CI and Release pipelines never
|
|
65
|
+
publish to external registries automatically; the tag-gated Release workflow only
|
|
66
|
+
re-runs all checks and attaches a build artifact to a GitHub release.
|
|
67
|
+
|
|
68
|
+
## Changelog maintenance (required)
|
|
69
|
+
|
|
70
|
+
Every user-visible change updates [`CHANGELOG.md`](CHANGELOG.md):
|
|
71
|
+
|
|
72
|
+
1. Add an entry under the **`[Unreleased]`** section, in the right group
|
|
73
|
+
(`Added` / `Changed` / `Fixed` / `Removed` / `Documented` / `Planned`).
|
|
74
|
+
2. On release, rename `[Unreleased]` to the new `[x.y.z] - YYYY-MM-DD`, start a fresh
|
|
75
|
+
`[Unreleased]`, bump the `version` in `Cargo.toml` (so `engine_version` in result
|
|
76
|
+
JSON matches), update the compare links at the bottom, and tag `vx.y.z`.
|
|
77
|
+
3. Keep entries terse and user-facing; link issues/PRs where useful.
|
|
78
|
+
|
|
79
|
+
A pull request that changes behaviour without a changelog entry is incomplete.
|
|
80
|
+
|
|
81
|
+
## Export control
|
|
82
|
+
|
|
83
|
+
PNT resilience and quantum sensing can touch dual-use export controls. Keep the public
|
|
84
|
+
repository to generic, published models and methods. Anything resembling
|
|
85
|
+
export-sensitive resilience/anti-spoof depth belongs in the private overlay, not here.
|
|
86
|
+
If unsure, ask before contributing it.
|
|
87
|
+
|
|
88
|
+
## License
|
|
89
|
+
|
|
90
|
+
By contributing you agree your contributions are licensed under Apache-2.0.
|
|
91
|
+
|
|
92
|
+
Sign off each commit to certify the [Developer Certificate of Origin](https://developercertificate.org/):
|
|
93
|
+
`git commit -s` (adds a `Signed-off-by` line). Inbound contributions are under the
|
|
94
|
+
same Apache-2.0 license as the project (inbound = outbound); there is no CLA.
|