Spatial-Temporal Reasoning Module
Deterministic, explainable spatial-temporal reasoning deployed as infrastructure your systems can query.
Identical inputs, identical outputs.
Every conclusion includes geometric proof.
Query primitives combine into complex inferences.
This is a simplified demonstration of STRM's core query types running client-side. Select entities, run queries, and drag to reposition. Every result includes assumptions, confidence, and geometric evidence.
Every trajectory projected forward.
Every assumption declared.
Every conclusion with geometric proof.
Select entities and run a query — or hit Run Demo Scenario to see STRM reason.
Production STRM operates in 3D ECEF coordinates with DTED terrain, kinematic-constrained trajectory models, and PostGIS/MobilityDB persistence. This demo uses 2D constant-velocity projections for illustration.
The demo above runs simplified 2D math client-side. Production STRM is a persistent service with capabilities that go far beyond what a browser demo can show.
STRM maintains a two-layer world model. An ambient layer provides immediate global coverage using a simplified earth model, so any entity can be tracked as soon as its first observation arrives. Where fidelity is required, detail regions load terrain elevation data, precise airspace volumes, and obstacle databases on demand, so resource usage scales with operational activity rather than planetary surface area.
Production line-of-sight queries evaluate actual terrain occlusion using DTED elevation data at Level 0, 1, or 2 resolution (MIL-PRF-89020B). Ray-terrain intersection uses bilinear interpolation for smooth elevation sampling and Moller-Trumbore ray-triangle intersection for complex mesh geometry. Results report whether terrain was consulted and at what resolution, so operators can see exactly what informed each answer.
Different entities operate under different physics, and STRM encodes those differences as platform profiles. Profiles define maximum speed, acceleration, turn rate, and collision radius per entity type without code changes. Queries automatically apply the correct profile and return the profile version used, so new domains such as maritime, ground, and space are added through configuration rather than rewrites.
Every STRM result includes assumptions, geometric evidence, profile versions, and a deterministic confidence score. Evidence is not post-hoc logging; it is produced by the exact computation path that generates the conclusion. The geometry used to derive an answer is the same geometry returned for audit, review, and challenge.
The browser demo uses constant-velocity projection, but production STRM provides a projection hierarchy selected per query. Analysts can use constant velocity for broad awareness, constant acceleration for maneuvering entities, kinematically constrained projection for profile-limited motion, and reachability envelopes for full future occupancy analysis. The same entity can be projected at different fidelities for different operational questions.
STRM deploys from a single Docker container on tactical edge hardware to Kubernetes-orchestrated enterprise environments. The pure reasoning kernel has no runtime dependency on external services because all state arrives through immutable snapshots. Air-gapped enclaves, IL5/IL6 networks, and commercial cloud all run the same deterministic engine with deployment profile changes handled by configuration.
All spatial-temporal inference runs here with zero I/O and zero side effects. Identical inputs produce identical outputs, enabling deterministic replay, audit, and formal verification.
Maintains entity state, spatial indices, platform profiles, and regional detail. It provides consistent point-in-time snapshots to the kernel while continuous updates proceed without blocking queries.
REST and gRPC endpoints parse requests, acquire snapshots, invoke the kernel, and format results. OpenAPI and Protobuf contracts support MOSA-aligned integration across federated systems.
STRM is a query service, not a platform. It does not fuse sensors, render tactical displays, or make decisions. It expects pre-fused entity tracks as input and returns structured assessments with explicit evidence.
Consuming systems integrate through the query API, using synchronous calls at mission decision points and polling patterns for continuous monitoring. STRM builds on PostGIS and MobilityDB rather than replacing existing spatial infrastructure, adding the forward reasoning layer those databases are not designed to provide. OpenAPI and Protobuf contracts align with MOSA and JADC2 integration patterns for federated operation.
| Query | What It Answers |
|---|---|
| Distance | Current separation between two entities |
| Time to Collision | When and where two trajectories intersect within a combined collision radius |
| Closest Point of Approach | Minimum future separation and when it occurs |
| Line of Sight | Whether terrain or volumes block direct observation between two entities |
| Containment | Whether an entity will enter a defined volume within a time horizon |
| Proximity | Which entities are within a specified radius |
| Feasibility | Whether an entity can reach a target position given its kinematic constraints |
| Intercept | Whether an interceptor can reach a target before the target reaches a location |
| Relationships | Proximity graph with TTC edges across an entity population |
| Group Detection | Spatial clusters via connected components over a proximity threshold |
| Interaction Likelihood | Multi-factor threat score (proximity, velocity, TTC) |
Bring us the hard constraint set. We design, build, and deliver systems that hold up in operational reality.