Transparency in orbital mechanics, API specifications, and screening limitations
STX Sentinel is a conjunction screening engine designed to provide satellite operators with automated risk assessment and maneuver decision support. This document describes our technical approach, data sources, computational methods, API specifications, and known limitations.
Important: STX Orbital provides decision-support tools, not operational commands. All maneuver decisions remain the sole responsibility of the spacecraft operator.
| Endpoint | Method | Purpose | Status |
|---|---|---|---|
/api/screen |
POST | Single TLE/CDM screening | LIVE |
/api/spacex/o2o |
POST | O/O ephemeris screening (awaiting partner access) | DEPLOYED |
/api/watchtower |
GET/POST | Asset monitoring management | LIVE |
/api/report/{job_id} |
GET | PDF report generation | LIVE |
All endpoints accept and return JSON. Example screening request:
| Feature | Description | Timeline |
|---|---|---|
| OpenAPI 3.0 Spec | Machine-readable API documentation | Q1 2026 |
| Trajectory UUID | Passthrough of operator tracking IDs | Q1 2026 |
| Upload Types | Definitive/predictive ephemeris tagging | Q1 2026 |
| Per-Client Rate Limits | Configurable throttling with burst allowance | Q1 2026 |
| Maneuver Claim Endpoint | POST responsibility claims, receive acknowledgments | Q2 2026 |
| Bulk Fleet Screening | 1000+ objects per request with async delivery | Q3 2026 |
API requests are authenticated via bearer tokens transmitted over TLS 1.3 encrypted connections. Tokens are issued per-organization and support role-based access controls.
Mutual TLS client certificate authentication for enterprise integrations requiring zero-trust patterns. Operators provide their own certificates; we validate against registered certificate authorities.
STX Sentinel uses the Simplified General Perturbations (SGP4) and Simplified Deep-space Perturbations (SDP4) models for orbital propagation. These are the standard analytical models used with Two-Line Element sets (TLEs) and are implemented via the Skyfield library.
Planned optional numerical integration with perturbation modeling:
⚠ Heuristic Approach: When screening TLE-derived ephemeris, Sentinel uses heuristic covariance estimates rather than propagated state covariance matrices. This is a known limitation.
Two-Line Elements do not include covariance information. When processing TLEs, Sentinel applies default positional uncertainty values based on object classification:
These values are conservative defaults. Actual uncertainty varies significantly based on TLE age, orbital regime, and atmospheric conditions.
When processing CCSDS Conjunction Data Messages, Sentinel extracts the embedded covariance matrices directly:
Planned enhancement: time-based covariance growth models that account for process noise over extended prediction windows. This addresses the limitation of static covariance snapshots when TCA is days from epoch.
Sentinel applies different risk thresholds based on object classification. Higher-value assets (manned stations) trigger alerts at larger miss distances than debris-on-debris encounters.
Custom thresholds per-asset are planned for Q3 2026. Contact us for interim custom configurations.
STX Sentinel is designed to integrate into existing operator coordination workflows:
Dedicated REST endpoint (/api/spacex/o2o) is deployed and awaiting partner data access agreements.
Architecture supports enhanced ephemeris ingestion for higher-fidelity constellation screening upon integration.
Planned two-way coordination support:
This enables full responsibility handoff tracking for multi-party conjunction events, particularly relevant for mega-constellation operators.
We build to operator specs, not the other way around. If you have an existing coordination endpoint or workflow, we'll adapt. Contact us with your integration requirements.
STX Sentinel maintains a synchronized catalog of tracked objects sourced from Space-Track.org (U.S. Space Force 18th Space Defense Squadron public data).
| Sync frequency | Every 8 hours via automated cron job |
| Full catalog | ~60,000 tracked objects |
| Priority screening set | Up to 10,000 objects per scan (dynamically filtered) |
| Data format | Three-Line Element sets (3LE) |
⚠ Catalog-Only Screening: Sentinel currently screens operator ephemeris against the public Space-Track catalog only. Operators with proprietary high-precision ephemeris (O/O data) cannot yet inject their own state vectors. This capability is planned for Q2 2026 — see roadmap.
STX Sentinel uses a multi-stage filtering pipeline to efficiently screen against the full tracked object catalog while returning only actionable conjunction data.
All 60,000+ catalog objects are evaluated against the primary spacecraft's orbital parameters. Objects outside the conjunction-feasible regime are excluded:
Result: Typically 5,000–20,000 candidates depending on the primary's orbital shell.
Filtered candidates are sorted by operational risk priority:
| Priority | Category | Examples |
|---|---|---|
| 0 (Highest) | Crewed Vehicles | ISS (25544), Tiangong/CSS (48274) |
| 1 | Known Debris Fields | Cosmos-2251, Fengyun-1C fragments |
| 2 | High-Eccentricity Objects | Molniya debris, GTO objects (e > 0.3) |
| 3 | Active Constellations | Starlink, OneWeb, Planet (NORAD 44000–75000) |
| 4 | Remainder | Dormant payloads, rocket bodies, misc. debris |
Objects like dormant Iridium satellites, spent boosters, and mission-related debris (tools, panels) are screened if they pass the orbital filter — they're in Priority 4, not excluded.
The top 10,000 priority-sorted candidates (or all candidates if fewer) are propagated and screened:
*R/I/C geometry is derived from ECI position differences at TCA. This is a first-order approximation suitable for decision support; it does not perform a full rotation into the primary's orbital reference frame. For authoritative geometry, request a CDM from 18 SDS.
Only operationally relevant conjunctions are returned to the operator:
Result: Typically 5–50 actionable threats instead of thousands of low-priority alerts.
STX Sentinel uses two different metrics depending on the data source:
When screening TLEs against the catalog, Sentinel computes a Proximity Score — a prioritization metric based on miss distance relative to operational thresholds.
| Score = 100 | At or below RED threshold (immediate action) |
| Score = 50–99 | Within YELLOW zone (elevated monitoring) |
| Score < 50 | Beyond YELLOW threshold (routine awareness) |
⚠ Not a Collision Probability: Proximity Score is a screening metric for prioritization. It is NOT a physics-based probability of collision (Pc). For authoritative Pc values, request a CDM from 18th Space Defense Squadron.
When processing CCSDS Conjunction Data Messages, Sentinel displays the official collision probability (Pc) computed by 18 SDS using full covariance matrices. This value is extracted directly from the CDM — Sentinel does not recalculate it.
CDM-derived Pc values are marked with an "18 SDS" badge in the UI and reports to indicate authoritative provenance.
To ensure appropriate use, operators should understand Sentinel's boundaries:
We're building validation infrastructure to provide operators with confidence metrics:
| Benchmark | Status | Target |
|---|---|---|
| Screening latency (single object) | LIVE | < 5 seconds |
| Batch fleet screening | LIVE | Up to 100 TLEs per request |
| CDM cross-validation | Q3 2026 | Published accuracy vs 18 SDS CDMs |
| Constellation-scale benchmark | Q3 2026 | 1000+ object screening metrics |
Batch screening latency scales with fleet size and catalog depth. Operators interested in running controlled benchmarks against their data can contact us to arrange validation testing.
For detailed technical inquiries about Sentinel's methodology, API integration, custom threshold configuration, or enterprise authentication requirements:
We're happy to share draft API schemas, discuss integration requirements, or scope custom capabilities for your timeline.