Capabilities reference

Four capabilities. Twelve POCs. One substrate.

Every defense POC on this site is built on some combination of four first-order capabilities of SolvNum. This page is the technical reference: what each capability is, why it matters operationally, and which POCs lead on it. Each capability tag in the rest of the site links back here.

DDeterminism

Cross-Platform Determinism

The same SolvNum computation produces the same answer — bit for bit — on every machine, certifiable by a single SHA-256 hash anyone can re-verify.

How it works

Floating-point math disagrees across machines because different CPUs round differently, different math libraries approximate sin / log / exp differently, and different compilers reorder operations. Across hundreds of integration steps those tiny gaps compound into visibly different answers.

SolvNum sidesteps this by using a deterministic arithmetic representation and fixed lookup tables. Every CPU performs the same operations on the same data the same way. So every CPU produces the same answer.

The table ships as a file with a published cryptographic hash. If the hash matches, the math is guaranteed identical — not 'likely identical.' Identical.

Why it matters operationally

  • Plan-to-execution consistency. The mission planner's number, the onboard system's number, the rehearsal sim's number, and the post-incident replay's number are the same number.
  • Coalition interoperability. Allied partners on different national hardware reach identical fusion answers without translation layers.
  • Digital test & evaluation. 'Same input, same output, every machine, every cycle' is a DoD certification requirement that today's stacks meet only by tightly pinning hardware. SolvNum meets it on heterogeneous hardware.
  • Forensic admissibility. Engagement replay is bit-identical to execution, attestable by hash. No 'approximate reconstruction' caveat.

Verified platforms

PlatformArchitectureStatus
x86_64 Linux / Windowsx86_64Bit-identical reference
Raspberry Piaarch64Bit-identical, verified
NVIDIA RTX 4070 GPUCUDA SIMTBit-identical, verified
WebAssemblyWASM virtual ISABit-identical, verified

Validation status

PASS — verified across x86_64, ARM, CUDA, WASM with matching SHA-256. Reproducible via the SolvNum cross-platform hash verification.

BStability guarantee

Per-Step Stability Guarantee

After every state transition, the per-step change is limited: no single step can move the value by more than a documented factor. The bound is a property of the data type, not a property the engineer remembered to add.

How it works

When you update a SolvNum value, no single step can change it by more than a factor of about 2.46×. This limit is enforced at the data-type layer — it is impossible to bypass, regardless of the control logic above it.

This is a constant-time check enforced at the data-type layer. It is the same primitive that absorbs cross-platform float wobble in capability D, and it is what makes a control loop robust to noise, faults, adversarial inputs, and runaway commands.

Why it matters operationally

  • Provable per-tick excursion bounds for certification. DO-178C, ISO 26262 ASIL-D, MIL-STD-882E system-safety reviews all want a deterministic answer to 'what is the maximum the state can change between integration steps?' SolvNum makes the answer a one-line constant.
  • Adversarial robustness. Spoofed sensors, jammed signals, Byzantine nodes, and malicious inputs cannot drag system state arbitrarily far in one step.
  • Anti-windup, no-overshoot, anti-bullwhip by construction. PID overshoot, optimizer divergence, supply-chain bullwhip — all the same mathematical pathology, all prevented by the built-in excursion limit.
  • Provable safety for autonomous effectors. Slew rate, acceleration limit, swarm collision avoidance — the safety bound is the data type, not the controller code.

Validation status

PASS — measured on POC 02: 0 violations across 10,000 adversarial trials vs. 9,997 violations for a hand-coded software limiter on the same inputs. Max excursion 2.4623× exactly matches the documented bound.

RScale classification

Scale-Aware Classification

Every SolvNum value carries a built-in magnitude band that answers 'what scale is this?' in zero arithmetic — it's already a native field in the representation.

How it works

A floating-point number gives you the value but not the scale; to get the scale, you call log(). SolvNum gives you the scale for free, as a native field, available without math. Two values in the same magnitude band are within a factor of 2 of each other — a natural locality-sensitive hash for numerical data.

That single fact rewrites the algorithm for anomaly detection (a 2+ band jump is 'something fundamentally changed,' no model required), data partitioning (shard by band), distributional fingerprinting (magnitude fingerprints are constant-memory summaries), and tier classification (threat tier, severity, calibration band — all become native field reads).

Why it matters operationally

  • Model-free anomaly detection. Sensor spoofing, jamming onset, equipment failure all manifest as scale discontinuities. One comparison, no ML stack, no training data, no distribution-drift retuning.
  • Magnitude-aware sensor fusion. Mixed-OOM data (µV-to-V on the same ADC, mm-to-km on the same tracking radar) routes by scale tier instead of by hand-tuned thresholds.
  • Identical classification across nodes without consensus protocol. Threat tier is the scale field — not the output of an ML classifier — so every node in a fleet reaches the same classification by construction. No arbitration round-trip.
  • Provenance fingerprinting. Magnitude fingerprints identify the computation that produced an output, useful for licensing forensics and regulatory provenance.

Validation status

PASS — measured on POC 03: scale-discontinuity detector holds 100% recall and 0 false positives per million samples across three baseline regimes (urban / maritime / contested) without retuning. The CUSUM detector, tuned for the urban regime, drops to 0% recall in the maritime regime.

CCompression

Compression with Explicit Error Bound

SolvNum is also a tunable lossy compressor with an explicit, audit-quality relative-error bound on every value. Decompression runs anywhere and costs nothing.

How it works

The k parameter controls how many bits of precision you keep. At k = 24 (full precision) there is no loss. At k = 16, every value has at most ~5.3e-6 relative error. At k = 12, every value has at most ~8.5e-5 relative error. At k = 8, every value has at most ~1.4e-3 relative error.

Three properties make this different from gzip / float16 / general-purpose compressors: (1) the error bound is per-value and exact, not statistical — you can put it on the wire in the protocol header; (2) no dictionary, no window, no state — each chunk compresses independently, perfect for streaming and packet-loss-tolerant links; (3) decompression is lightweight — runs on the receiver's signal-processing hardware without dedicated CPU.

Why it matters operationally

  • Tactical-link bandwidth efficiency. Link-16, TTNT, mesh radio, undersea acoustic, lunar SATCOM — all bandwidth-starved. SolvNum-encoded telemetry typically gives 3–4× more reporting density at the same link budget, with a guaranteed per-value error envelope on the wire.
  • Forensic-grade lossy archival. Mission-data recorders compressed with SolvNum carry the error bound on the artifact and decompress identically on every reviewing platform — eliminating the lossy-vs-lossless artifact ambiguity in engagement review.
  • Bandwidth-vs-fidelity tradeoff that's a contract, not a guess. Procurement requirements like 'no telemetry value shall be off by more than 0.1%' become a single k-parameter choice, not a long compression-statistics argument.

Validation status

PASS — measured on POC 04: SolvNum k=12 fits 50-platform UAS telemetry inside a 2.5 Mbps link budget at 90% utilization with 8.47e-05 measured max relative error (under the 8.46e-05 documented bound). gzip-on-float64 needs 7.5 Mbps for the same payload.

How they reinforce each other

Pair-wise and full-stack benefits

The pair-wise compounds are where most of the POCs live. The full-stack flagship — POC 12 — combines all four into a single substrate attestable by one hash.

D + B

Cross-platform identical and bounded — provable per-tick bound on every machine. The certification story (DO-178C, ISO 26262, FDA).

D + R

Cross-platform identical magnitude classification — sharded fusion gives the same result on every node. Critical for distributed combat systems.

D + C

Compressed data has the same hash on every machine — verifiable lossy compression for archival reproducibility.

B + R

Per-step excursion limits naturally operate in scale space — the bound is 'max one band shift per step,' which is the natural unit.

B + C

Bounded compression error — the precision quantization of C is exactly the excursion limit of B applied at storage time.

R + C

Compression by dropping precision bits while keeping the magnitude band — scale-preserving lossy code with explicit error bound.

D + B + R + C

The full substrate: same math, bounded transitions, magnitude-tagged tracks, bandwidth-budgeted links — end to end, attestable by one hash.