Deterministic cores
The 3DOF and 6DOF engines stay separate from product logic and take explicit physical inputs, which keeps their behavior predictable and reviewable.
Public whitepaper
Physics infrastructure for precision systems.
A deeper look at the architecture behind Black Telum: aerodynamic data, deterministic simulation, execution systems and product delivery.
01 Abstract
Black Telum builds physics infrastructure for systems that need to model, simulate, design around, and act on projectile flight.
Many precision-system tools begin and end as a trajectory solver wrapped in an interface. Black Telum builds the whole chain: projectile geometry and aerodynamic data, the deterministic engines that run on it, the state and execution control that tie them together, and the products placed in an operator's hands.
This document stays at the level of architecture and capability, not technical specification. It explains what the infrastructure does and how the parts relate, without exposing the internal methods, data, or formats behind them.
02 The problem
Physics that works in a lab is not software you can trust in the field.
A result computed against fixed assumptions says little about what happens when atmosphere, wind, terrain, and time all move at once. That gap is where most systems fail.
Closing it is an engineering problem, not a single equation. It takes authoritative physical data, models that behave predictably, a way to hold physical state consistent as inputs change, and control over when computation runs. Each of those is a system on its own. Black Telum builds all of them, and the connections between them.
03 The system, end to end
Projectile flight begins before a trajectory is calculated and continues after a result is returned.
The infrastructure runs as four connected stages, each one feeding the next.
-
Create physical data
Projectile geometry starts as parameters and becomes structured aerodynamic data through physics-based simulation: a model of how a body behaves across the conditions it will meet. The data is validated before it goes anywhere near the runtime, and an incomplete campaign never becomes a usable table.
- Parametric design
- Aerodynamic characterization
- Validated data
-
Compute physical behavior
Modular 3DOF and 6DOF engines resolve projectile flight under real atmospheric and environmental conditions. They are deterministic: the same inputs return the same result every time. Reproducibility and review depend on exactly that. The engines draw on shared models of atmosphere, gravity, Earth rotation, wind, terrain, and thermal behavior, instead of assumptions baked into one solver.
- Deterministic engines
- Environmental models
- Reproducible output
-
Maintain state and coordinate execution
Real use is never a single calculation. Inputs change, and the system has to stay consistent as they do. It keeps a valid, live physical state and captures immutable snapshots of it, so any result traces back to the exact conditions that produced it. Computation runs when its inputs are ready, and repeats as those conditions evolve.
- State management
- Controlled execution
- Traceable results
-
Deliver products
The same foundation can be composed into the systems people use: operator software, embedded systems, engineering tools, and integration interfaces for other languages and environments. Physical models and physical data carry their own versions, so a product can change without disturbing the physics underneath.
- STRIKEGRID
- Operator software
- Integration interfaces
04 The runtime
Praxis
One modular runtime behind every product.
Praxis separates concerns that usually tangle together: physical models, environmental data, state, execution control, and product interfaces, each one its own independent layer. A product can target a different environment or deployment profile without touching the physics underneath. Physical data and models carry their own versions, so products and physics can evolve without forcing changes on each other.
A model of the world
Atmosphere, wind, gravity, terrain, coordinates, and sensor inputs are reusable components of the system, not assumptions rebuilt for each product.
Controlled execution
State snapshots and execution control connect computation to real products and workflows, so any result can be reproduced on demand.
05 STRIKEGRID
Where the infrastructure meets the operator.
STRIKEGRID is the product layer, the software in an operator's hands. It turns Praxis computation, physical data, and mission context into an interface built for the task: on equipment, in the field, or on a screen.
It is the first product built on the foundation, not the foundation itself. Different missions call for different interfaces, all built on one shared physical foundation. The surface changes; the physics does not.
- Unmanned platforms
- Precision fire systems
- Operator software
- Training and simulation
- Planning and integration
06 Capabilities and maturity
Core infrastructure, active capability, and exploratory research.
Black Telum separates production-oriented infrastructure, active engineering capability, and exploratory research, so each layer can be evaluated on its own maturity.
-
Computational projectile design
Parametric geometries and repeatable simulation cases test a design before anyone commits to a physical prototype.
- Parametric geometry
- Simulation
- Early evaluation
-
Aerodynamic data generation
Simulation campaigns become structured, validated aerodynamic data that physical models consume at runtime.
- Simulation campaigns
- Validated data
- Runtime
-
Learned aerodynamic estimation
When authoritative data does not yet exist, learned estimation supports early design exploration. It works as a pre-validation tool, not an authoritative physical model.
- Estimation
- Early design
- Exploratory
-
Simulation-driven decision research
We study how systems make decisions across large numbers of physically valid outcomes. These models learn decisions, not physics, and stay isolated from the production engines.
- Decision research
- Simulation at scale
- Exploratory
07 Claims and disclosure
Public claims aligned to substantiated capability.
Black Telum keeps its public claims in line with what its architecture, engineering process, and current product layer can support. Empirical validation, commercial detail, certification status, and regulatory treatment are handled through controlled technical and diligence materials, not public marketing.
- Empirical validation, certification status, and regulatory treatment are reviewed in controlled technical materials.
- Customer, agency, and institutional discussions stay private, not in public material.
- Performance and accuracy are characterized under technical review, not advertised as figures.
- Public claims stay within what Black Telum can substantiate about the system, architecture, and product maturity.
The foundation we stand behind today is a connected physics infrastructure, built for deterministic computation, reproducible review, and controlled product deployment.
08 Briefing
We build the foundation, then the products on top of it.
The objective is a physics-infrastructure platform that many products, environments, and integration partners can build on. STRIKEGRID is the first product on it, not the last. We share commercial and technical detail in controlled briefings.
Request a briefing