Evidence, not slides.
Most counter-UAS simulation vendors sell you graphs. UAVSimNet sells you evidence — a defensible chain of records that links every claim in a slide deck back to the physical models, the calibration data, and the deterministic runs that produced them. Seven pillars hold the chain up. Pull on any one and the rest tightens.
Every model, labelled. Every label, defensible.
Every interceptor, threat, sensor, and payload model lives in a registry with an explicit label — validated, provisional, or experimental — a version number, a validity envelope, and a model card explaining its provenance, test rig, and known limitations. When a run references a model, that model's id and version pin are baked into the run's compiled scenario and output manifest. A reviewer can always ask 'which model fed this number?' and get an auditable answer.
- Labels: validated · provisional · experimental
- Validity envelopes — mass, speed, altitude, threat-class bounds
- Model cards carry provenance, test rig, known limitations
- Version pins baked into every run's compiled scenario
Published boundaries, enforced at run submit.
The platform refuses to run a scenario whose conditions fall outside the validity envelope of the models it would need. Ask for a 1.6 kg, 240 m/s threat using a model rated to 110 m/s and the run is rejected with a clear envelope-violation message — before any Monte Carlo work is done. A procurement record of a rejected run is itself powerful evidence that the platform's boundaries are enforced, not suggested.
- Envelope violations blocked at the validation gate, not at output
- Rejected runs are themselves an auditable evidence artefact
- Envelope boundaries surface on the library page for every model
Catch the 2 % shift before live-fire does.
Approved runs can be promoted to a golden run — a blessed deterministic baseline. Subsequent runs covering the same scenario are compared automatically and report either zero-drift or a structured drift record naming the specific metric that moved and by how much. This catches the model change that silently shifted your predicted hit probability by 2 % — the kind of shift nobody notices until the live-fire window closes.
- Promote-to-golden gated behind reviewer approval
- Automated drift detection with structured per-metric records
- Drift-observed runs flagged; changes cannot land silently
- Same discipline engineers use to prevent flaky tests
No parameter change enters production silently.
When real-world telemetry arrives — PX4 ULog, ArduPilot binary, MAVLink tlog, CSV — engineers propose parameter deltas against a model. The platform records the proposal, replays the engagement with the proposed parameters, and captures before/after metrics. An admin accepts or rejects; acceptance bumps the model version and leaves an audit entry a reviewer can open months later to understand why the numbers shifted.
- Log formats: PX4 ULog, ArduPilot binary, MAVLink tlog, CSV
- Before/after replay captured against the same seed set
- Admin accept/reject gate with reviewer notes
- Acceptance bumps the model version; nothing changes quietly
The same inputs produce the same outputs. Always.
Given the same compiled scenario and the same Monte Carlo seed, UAVSimNet reproduces the same output. Every time. Bit-exact on the kinematic backend; metric-exact on the JSBSim-hybrid backend — identical miss distances, identical failure modes. This is what lets regression comparisons work at all, and what lets a scrutiny panel re-run your numbers independently six months after the fact.
- Bit-exact replay on the kinematic backend
- Metric-exact replay on the JSBSim-hybrid backend
- Seed · scenario · version captured on every run
- Independent third-party replay with nothing but the run record
One source of truth. Three formats. Zero contradiction.
Every run produces the compiled scenario (YAML), the numerical record (JSON + CSV), and the decision document (PDF and DOCX with embedded plots). The structured formats are what engineers and analysts consume; the decision document is what programme offices hand to reviewers. Both come from the same run, with the same provenance snapshot baked in, so there is no way for the deck to say one thing and the engineering record to say another.
- Compiled scenario (YAML) — the inputs, canonicalised
- Numerical record (JSON + CSV) — every metric, every seed
- Decision document (PDF + DOCX) — navy-themed, plot-embedded
- Same source of truth feeds every format
What ran is what ran — permanently.
Submitting a run freezes an immutable snapshot of every parameter that fed it — source, confidence, citation, and who last touched each value. Mutating the underlying library later does not mutate the snapshot. The run's evidence is locked the moment it starts, so a reviewer opening it months later sees exactly the state that produced the numbers.
- Snapshot captured at run submit, before execution begins
- Grouped by capability, with source + confidence + citation
- Preserves value at time of capture regardless of library edits
- Queryable via the run detail page and the exported report
Take the evidence further.
The credibility framework underwrites every capability surface and every use case. Read on or request a briefing.