realtime-frame-eop (scenario kind)

Scenario kind of the engine v0.38.0, family GNSS measurements, positioning and integrity. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service. Every label here is the engine's or the verification matrix's; a kind is MODELLED unless the matrix says otherwise (how a label is earned: the README's Evidence section).

What it does#

Real-time lunar frame / Earth-orientation prediction budget: P4 Table 1 (the frame-error consistency check — post-processed ~0.27 m ↔ ~0.010 ms and real-time ~15 m ↔ ~0.5 ms, each frame position expressed as its equivalent UT1 error via the L19 lever arm Δr = D_EM·ω⊕·ΔUT1) and Table 2 (measured UT1 prediction error vs horizon — the L18 curve read directly off the real IERS finals2000A series: the Bulletin A − Bulletin B final floor and the multi-day persistence-predictor error, each mapped to a Moon-frame position by L19), plus the L21 root-sum-square real-time frame-error budget (EOP + ephemeris + realisation floor). VALIDATED closed form (the L19 lever arm, ω⊕ cross-checked against the CIO Earth-rotation angle) and VALIDATED real data (the L18 curve off the real finals2000A rows); MODELLED are the lunar-relay OD covariance magnitudes and frame-realisation floor (representative allocations) and the persistence predictor (not IERS's operational Bulletin A algorithm). Not a certified real-time frame product.

One run of scenarios/realtime-frame-eop.toml summarises as: realtime-frame-eop | Table 1: post-proc 0.27 m (0.0096 ms UT1) ↔ real-time 14.4 m (0.514 ms UT1) | Table 2: final floor 0.0171 ms → 3-day 1.6644 ms | budget total 20.1 m (67.0 ns) | L19 lever arm + L18 real-data (Validated), OD cov (Modelled)

Inputs#

From the schema (kshana kinds --json):

• Required fields: none
• Optional fields: epoch, horizons_days, ephemeris_pos_sigma_m, ephemeris_vel_sigma_mps, latency_s, frame_realization_floor_m, delta_ut1_ms, delta_xp_mas, delta_yp_mas, eop_finals2000a, eop_finals2000a_later, frame_realization_tie_noise_m, operational_window_days, operational_min_cycle_fraction, operational_anchor_residual

The example scenarios/realtime-frame-eop.toml sets, among others:

Run it#

kshana scenarios/realtime-frame-eop.toml

What it gives#

The scalar results of that run, with the units the engine states:

Result label (the engine's): Real-time lunar frame / Earth-orientation prediction budget. VALIDATED closed form: the L19 lever arm (1 ms ↔ 28.03 m ↔ 93.5 ns), ω⊕ cross-checked against the CIO Earth-rotation angle. VALIDATED real data: the L18 UT1 and polar-motion prediction-error curves read directly off the real IERS finals200

Evidence#

MODELLED 1 · VALIDATED 2: the verification matrix rows that name this kind.

• VALIDATED One table reports the UT1 prediction error, the polar-motion pole error and their quadrature combination at the Moon over an IDENTICAL epoch set per horizon, emitting the epochs each component was measured at. Tests: embedded_eop_vintage_astropy_preregistered.rs.
• VALIDATED The realtime-frame-eop runtime default is the library own embedded copy of a verbatim IERS finals2000A extract (tools/finals2000A_20260930.txt: 174 consecutive daily rows, MJD 61224-61397, cut from the finals2000A.all of 2026-09-30) carry Tests: operational_eop_predictor_reference.rs.
• MODELLED A least-squares bias-plus-rate fit over a trailing window plus the principal periodic terms — annual, semi-annual and the two principal zonal tides for UT1; Chandler, annual and semi-annual for the pole — extrapolated with the last in-windo Tests: operational_eop_predictor_reference.rs.

The rows the run itself exercised, with the oracle the matrix gives each (the public sources are named there):

• MODELLED Deterministic, scenario-hashed, SBOM + cross-platform golden gates. Oracle (ExternalDataset): SBOM conformance to the official CycloneDX 1.5 JSON Schema (+ valid SPDX identifiers) — an external published standard, zero validation errors over the full dependency graph; the FoM-determinism / byte-reproducibility part remains a pinned self-consistency check, so the row stays MODELLED
• VALIDATED One table reports the UT1 prediction error, the polar-motion pole error and their quadrature combination at the Moon over an IDENTICAL epoch set per horizon, em. Oracle (ExternalDataset): astropy 8.0.1 utils.iers (BSD-3) reading the IERS finals2000A product with its own Bulletin-B-else-A rule, and pyerfa 2.0.1.5 (SOFA) full celestial-to-terrestrial rotations (c2i06a, sp00, pom00, c2tcio; the Earth rotation angle per IERS 2010 eq. 5.15 in exact arithmetic), run as separate programs on verbatim rows of the frozen 2026-09-30 finals2000A.all; pre-registered (455b8fb5) with amendments A1 and A2 fixing only
• VALIDATED The realtime-frame-eop runtime default is the library own embedded copy of a verbatim IERS finals2000A extract (tools/finals2000A_20260930.txt: 174 consecutiv. Oracle (ExternalDataset): astropy 8.0.1 astropy.utils.iers.IERS_A (BSD-3-Clause), reading the same bytes with its own reader, and the IERS Bulletin A Vol. XXXIX No. 039 table, copied number for number; pre-registered (6fdae01b) with six exact criteria before astropy was run. All six hold: 30 final, 54 rapid and 90 predicted rows with equal MJD lists, every predicted row flag P, the default-run census equal, and the predictions equal to Bullet
• MODELLED A least-squares bias-plus-rate fit over a trailing window plus the principal periodic terms — annual, semi-annual and the two principal zonal tides for UT1; Cha. Oracle (ReferenceImpl): Three independent routes, none of them a published prediction-accuracy figure. (1) An analytic signal with known coefficients — the only way to exercise the periodic machinery, since no committed series is long enough to admit an annual term. (2) The textbook closed-form least-squares solution, different algebra from the matrix solve under test, on real rows. (3) The genuine archived Bulletin A prediction rows the re

Limitations#

What the run's own report says is not modelled or not validated:

• Real-time lunar frame / Earth-orientation prediction budget. VALIDATED closed form: the L19 lever arm (1 ms ↔ 28.03 m ↔ 93.5 ns), ω⊕ cross-checked against the CIO Earth-rotation angle. VALIDATED real data: the L18 UT1 and polar-motion prediction-error curves read directly off the real IERS finals2000A series (Bulletin A rapid vs Bulletin B final, and multi-day persistence over the real daily rows). DERIVED: the frame (result label)
• VALIDATED closed form (the L19 lever arm, ω⊕ cross-checked against the CIO Earth-rotation angle) and VALIDATED real data (the L18 curve off the real finals2000A rows); MODELLED are the lunar-relay OD covariance magnitudes and frame-realisation floor (representative allocations) and the persistence predictor (not IERS's operational Bulletin A algorithm). (kind catalogue (kshana kinds --json))
• Honesty: VALIDATED closed form (the L19 lever arm, omega_earth cross-checked against the CIO Earth-rotation angle) and VALIDATED real data (the L18 UT1 and polar-motion curves off the real finals2000A rows). DERIVED frame-realisation floor (the Helmert post-fit residual). MODELLED are the lunar-relay OD covariance magnitudes (0.27 m post-processed, ~14.4 m real-time at one-hour latency — a round, not back-solved, all (scenario file comment, lines 27 to 32)
• Reproducibility & software assurance is MODELLED, not validated: a sub-claim is externally checked, but the whole capability composes modelled pieces, so the capability stays Modelled. (verification matrix (docs/MODELLED-RATIONALE.md))
• Operational-style Earth-orientation prediction error, measured predicted-versus-final is MODELLED, not validated: checked against a separate implementation in this same codebase — independent of the unit under test, but not externally authoritative. (verification matrix (docs/MODELLED-RATIONALE.md))

See also#

• Family page: GNSS measurements, positioning and integrity
• All kinds: KINDS.md
• Topic page: integrations.md