scroll ↓
compile-time verification

The software is either proven or it does not compile.

Aether enforces safety, security, and reliability as structural invariants before a single byte of machine code is generated. A program that violates a declared property cannot be compiled. There is no runtime check. There is no advisory warning. The program does not compile. Uncompromising? That’s the feature.

4U.S. provisionals filed
35patent claims
39manifest types
sub-msper-op compile

Four U.S. provisional applications filed with the USPTO (July–August 2026), converting to full applications through 2027 — building toward a single certification pass for systems where a bug is a recall: implantable devices, battery management, avionics.Provisionals, not granted patents; priority attaches on the Office’s receipt. Patent-pending.

aether v8.0.0 — GENXR_V8.0.0 / STRICT_MODE

for non-technical readers · everything in one place

Software that can’t ship unless it’s proven safe.

In planes, cars, medical devices, and defense systems, a single software fault can cost lives. Today that software is trusted because it was tested a lot — but as Edsger Dijkstra put it, testing can reveal that a bug is present, never that none remain. We took that personally.

Aether is a compiler — the tool that turns a programmer’s code into what runs on the chip — with a rule built in: if the code can’t be proven to obey the safety limits you declared, it simply does not build. No warning to ignore. No test to pass later. The unsafe version never exists.

The guarantee isn’t a promise on paper. We put it on a real chip and measured it.

Plenty of tools claim to make software safer. What sets this apart: we took the compiler’s own output, ran it on a real microcontroller (the kind inside a car or a drone), and measured the physical behaviour with lab instruments. The predictions the compiler made up front matched what the hardware actually did.

No timing leak

We told the compiler to build a lookup that takes the same amount of time no matter what secret it is handling. On the chip it ran identically for every input — a would-be eavesdropper learns nothing from the timing. A normal version of the same lookup gave the secret away by running faster or slower.

240 clock cycles, flat across all 20 test inputs, zero spread; the ordinary version varied ~116%.

Held under stress

That “same-time” behaviour did not crack when we starved the chip of power (down toward its brown-out point) or heated it up. The protection is built into the shape of the code, not a lucky condition.

Timing spread stayed ~0.08% across a 3.3 V→~2.4 V supply sweep and to ~65 °C.

Battery predicted to ~1.4%

We asked the compiler to predict the electrical charge a 60-second mission would draw from the battery — before running it. The meter agreed with the prediction to within about one and a half percent.

358.42 mC projected vs 353.43 mC measured; ±10% tolerance fixed before the run.

11× under the power ceiling

We set a power ceiling the device was not allowed to exceed. In practice its worst peak stayed eleven times below that ceiling, and the compiler’s power math matched the meter.

Worst measured peak ~91 mW vs a declared 1000 mW envelope; power (V×I) tracked to within 2%.

~1.7 microseconds, guaranteed

In real-time systems the device must always react to an urgent signal within a fixed deadline. We proved — by inspecting every program the compiler produces — that this reaction time can never exceed a small fixed bound, no matter how large the program.

Worst-case interrupt latency bounded at 27 cycles (~1.69 µs), from an audit of all 821 emitted files plus a measured 16-cycle entry cost.

Bit-for-bit reproducible

Rebuilt from the same source, weeks apart and across a major version change, the compiler produced byte-for-byte identical output — twenty times in a row. That makes the evidence auditable: anyone can rebuild and get exactly the same thing.

All 356 emitted artifacts hashed identical across 20 consecutive passes; instruction stream unchanged across a v7.3→v8 version bump (fixtures tested).

Why it’s defensible

  • Provisional applications filed with the USPTO — four US provisional applications covering the core methods submitted July–August 2026 (Canadian filings to follow); the crown-jewel method is already demonstrated on real silicon.
  • A working compiler, not a slide — roughly 12,300 lines of hand-authored Rust in the current compiler (~26,000 distinct across three related codebases) producing the results above.
  • Honesty-first evidence trail: every claim ties to a dated lab log and a reproducible build — exactly what safety auditors and acquirers want to see.

Who has to buy this

Industries where certification is mandatory and expensive:

Aerospace · DO-178CAutomotive · ISO 26262Medical devicesIndustrial · IEC 61508Defense

These teams spend heavily proving their software is safe. Aether aims to turn a slow, after-the-fact testing bill into proof produced automatically at build time.

The straight version — because that’s the whole point

Proven: the results above are real measurements of the compiler’s own output on real hardware, each recorded with a fixed method and a reproducible build.

Scope, stated plainly: the compiler-determined results — constant-time (240 cycles flat, zero spread), the naive-C timing leak (+120 cycles), and cycle-count flatness (~1%) — were re-measured on a second, independent NUCLEO-F411RE board on 2026-07-24, under pass/fail criteria fixed and wet-signed before the run, and they replicated across both parts, so those properties are no longer single-board. The absolute analog magnitudes (current, energy) still carry normal part-to-part variation: on the second board one energy comparison was method-limited and one cold-temperature current reading differed by ~12.5%, so those remain single-board for absolute value. This is a strong two-board proof-of-concept — not yet a temperature-qualified multi-part characterization across parts, and not independently certified. We do not claim all five re-measured results agree.

Not claimed: Aether has not been formally qualified or certified under any of the safety standards it maps to; the compiler references those frameworks as evidence, which is not the same as third-party certification. Some capabilities are still specification-only. The company is early-stage and pre-revenue. Four US provisional applications were submitted to the USPTO in July–August 2026 (filing dates attach on the Office’s receipt); these are provisionals, not granted patents, and confer no enforceable rights yet.

We would rather show exactly what is and isn’t done than oversell it — the same discipline that makes the compiler refuse to lie is how we run the company.


the problem

Three vectors. One compiler. Zero runtime.

In contested environments, adversaries exploit three software attack vectors. Aether addresses all three at compile time — before the binary exists.

01
attack vector
Binary tampering after certification
An adversary modifies firmware after it leaves the build environment. Existing toolchains have no mechanism to detect post-compilation modification at deployment.
→ Aether: an attestation token (a keyless integrity hash over the complete manifest chain) is emitted at compile time. Any modification invalidates the token. Detected when the token is checked, before execution.
02
attack vector
Operator impersonation and privilege escalation
Captured or compromised hardware is operated by personnel without the required clearance. No existing compiler binds operator identity to the binary itself.
→ Aether: CCBP binds an operator-clearance check at compile time; clearance below the data classification is rejected before codegen. (Reference implementation — the challenge/response flow is defined; PKI signing is not yet implemented.)
03
attack vector
Information leakage across classification boundaries
Classified sensor data flows to unclassified telemetry channels. Timing side-channels leak cryptographic keys. No existing compiler enforces information flow at the type level.
→ Aether: Bell-LaPadula + Biba enforced at variable binding level. Classified data cannot flow to under-classified destinations. Constant-time execution enforced structurally.

what aether produces

39 certification manifest types. One compiler pass. Sub-millisecond.

Aether emits machine-verifiable certification manifest blocks during a single compilation — up to 21 in one program, drawn from a catalog of 39 block types. The standalone verifier (aether-verify) independently re-checks the manifest chain and attestation token — without the compiler or source code — and parses the core manifest block types individually. The output is deterministic: all 356 emitted artifacts hashed byte-identical across 20 consecutive build-and-execute passes (2026-07-10). Manifests are compile-time evidence artifacts, not third-party certifications.

identity_manifest
Source fingerprint · tamper-evident chain
memory_manifest
MISRA-C Dir 4.12 / Rule 21.3 · AUTOSAR M18-4-1
stack_manifest
MISRA-C Rule 17.2 · stack depth bound
wcet_manifest
DO-178C Level A · worst-case execution time
power_manifest
DO-160 · MIL-STD-461 · power envelope
interrupt_manifest
IEC 61508 SIL4 · ISO 26262 ASIL-D
mls_manifest
Bell-LaPadula + Biba · CC EAL6 · IEC 62443 SL4
smp_manifest
AUTOSAR AP · DO-178C partitioned systems
timing_manifest
FIPS 140-3 · NSA Suite B · CC EAL6+
network_manifest
NIST SP 800-53 SC-8 · NSA CNSSI 1253
verification_manifest
DO-333 FM · Common Criteria EAL7
attestation_manifest
NIST SP 800-193 · TCG TPM 2.0 · RFC 9334
operator_manifest
FIPS 201-3 · CCBP-v1.0 · NSA CNSSI 1253
tensor_manifest
ML tensor classification · DoD AI Strategy 2023
adversarial_manifest
Adversarial taint · Track X
federated_manifest
Federated learning · Bell-LaPadula gradient
quantum_manifest
NIST FIPS 203/204/205 · post-quantum
crypto_defense_manifest
Downgrade prevention · FIPS-140-3 · CNSA 2.0
sbom_manifest
SPDX / CycloneDX · EO 14028 · NTIA
rtos_manifest
Liu-Layland · POSIX 1003.1b · IEC 61508-3
temporal_manifest
LTL call-graph ordering · DO-178C §6.3.4
protocol_manifest
BFS reachability · ARINC 429 · DO-178C
standards_manifest
Cross-standard compatibility lattice
mte_manifest
ARM MTE v8.5-A · ISO 26262 ASIL-D
bpc_manifest
Magic 0x41455448 · BPC-1.0 · RFC 9334
privacy_manifest
Differential privacy · GDPR Art.5 · CCPA
residency_manifest
GDPR Art.44 · CLOUD Act · data residency
retention_manifest
GDPR Art.5(1)(e) · HIPAA · CCPA
model_card_manifest
EU AI Act Art.13 · NIST AI RMF 1.0
explainability_manifest
EU AI Act Art.17 · DoD AI Assurance
ai_output_manifest
Bell-LaPadula ML output · DoD AI Strategy
provenance_manifest
SLSA Level 3 · NIST SP 800-218 · EO 14028
dependency_manifest
EO 14028 · CISA SBOM · SLSA L3
evidence_manifest
DO-178C / DO-333 / CC clause mapping
inference_manifest
AI invariant inference · Track RR
gap_manifest
Structural gap detection · Track SS
correctness_certificate
Track TT · tamper-evident self-consistency
cxx_annotation_manifest
C/C++ sidecar · no source modification
infer_manifest
Track R · AI classification inference

measured on silicon

The physical claims now have physical measurements — and the constant-time one is measured on the compiler's own output.

Beginning 2026-07-17 and continuing through 2026-07-20, the compiler's physical-domain outputs were measured on hardware — a Nordic Power Profiler Kit II in series with an STM32F411 (ARM Cortex-M4) on a NUCLEO-F411RE board, at the reset-default 16 MHz clock. Most results below were first recorded as a single datapoint on one board of one silicon part, taken with AI assistance at the inventor's direction under a methodology fixed before the measurement. On 2026-07-24 the compiler-determined subset — constant-time (240 cycles flat), the naive-C timing leak, and cycle-count flatness — was re-measured on a second, independent NUCLEO-F411RE board under pass/fail criteria fixed and wet-signed before the run, and those results replicated across the two parts; the absolute analog magnitudes (current, energy) still carry normal part-to-part variation and remain single-board for absolute value, and one energy comparison on the second board was method-limited. None is yet a certified measurement or a temperature-qualified multi-part characterization across parts. What began as four verbatim-compiler-emitted results has since been strengthened and extended: the constant-time property is now measured directly on the compiler's OWN emitted lookup, cycle-exact (240 cycles flat across all 20 query positions, no match-vs-absent leak) — the earlier hand-assembled caveat is retired — and a single program carrying six typed constraints at once (energy, WCET, power, interrupt-latency, constant-time, and a Secret classification) was accepted by the compiler in one pass and measured end-to-end on that one binary. A separate static audit further bounds the worst-case interrupt latency of every emitted program to 27 cycles. The constant-time behaviour was further observed to hold as the supply was starved toward the part's brown-out floor and at elevated temperature, the declared power envelope tracked measured power to within 2%, and the emitted code was byte-identical across a major version bump — evidence that the numbers describe the compiler's own output rather than one lucky build. Each number is recorded with full chain of custody in a dated rig log; where a result is still bound only to a hand-assembled instance, it says so.

Cross-part replication (two boards)
On 2026-07-24 the compiler-determined results were re-measured on a second, independent NUCLEO-F411RE board under pass/fail criteria fixed and wet-signed before the run. The constant-time lookup held at 240 cycles flat with zero spread and the naive-C comparator leaked +120 cycles — both matching the first board exactly — and ART-path cycle counts agreed to within ~1%. The absolute analog magnitudes carried normal part-to-part variation: one energy comparison was method-limited (the first board’s reference used non-identical manual integration, ~15% low), and a cold-temperature current reading differed by ~12.5%. So the compiler-determined timing, cycle, and constant-time properties replicate across parts; the absolute current and energy magnitudes do not yet. This does not claim all re-measured results agree. [two-board, pre-registered]
WFI current delta
Two compiler-emitted binaries that differ by whether the compiler emitted its 14-byte clock-halt (WFI) sequence for the entry mode, measured 3.45 mA (39%) apart — 5.28 vs 8.73 mA median. Pre-registered 6-trial protocol; PASS. [compiler-emitted]
Coulomb budget
Projected and measured integrated charge agree to 1.39% (358.42 vs 353.43 mC) over a 60 s duty-cycled mission; additive per-state model, ±10% band fixed before the run. [compiler-emitted]
Clock-halt residency
Measured clock-halted time fraction matches designed 0.50 / 0.80 / 0.95 to within 0.0002, across three missions. [compiler-emitted]
Constant-time timing
The compiler’s OWN emitted fixed-depth mask-accumulate lookup, measured cycle-exact (DWT) on silicon, runs 240 cycles at all 20 query positions — present and absent keys alike, zero spread, no match-vs-absent leak; a branchy comparator over the same table varies 116%. This supersedes the earlier hand-assembled instance and binds the constant-time result to verbatim compiler output. [compiler-emitted]
WCET instantiation
One compiler-emitted function measured at 140.9 processor cycles, superseding a placeholder constant of 100 [compiler-emitted]. The finer per-construct cycle table, measured by differencing, uses hand-assembled fixtures and awaits an assembly-level equivalence check [derived-template].
Aether-vs-C energy
Energy per invocation of the same 16-slot lookup, compiler-emitted vs gcc -O2, from measured active current × cycle-exact time: the compiler’s automatic constant-time output costs 417 nJ/call — between two hand-written constant-time C variants (298 and 432 nJ) — so enforced constant-time costs about what a careful C programmer spends by hand. The only cheaper option (146 nJ, naive C) is variable-time and leaks the query position. [compiler-emitted vs gcc -O2]
Unified capstone
One program declaring six typed constraints at once — energy, WCET, power, interrupt-latency, constant-time, and a Secret classification — is accepted by the compiler in a single pass and emits code byte-identical to the separately-validated fixtures. Three of those constraints were then measured on that one binary in a single run: constant-time (flat, 239 cycles), WCET (24 cycles, within the declared model), and a measurable run-vs-idle current difference. [compiler-emitted + measured]
Interrupt-latency bound
A static audit of all 821 emitted assembly files finds only 7 interrupt-disabled regions — every one the identical 5-instruction clock-halt sequence, with no function call or data-dependent loop inside any of them. Combined with the measured 16-cycle exception-entry law (identical minimum, mean, and maximum over 50,000 interrupts; the instrument was validated by inserting a known 32-cycle critical section, which moved the measured maximum by the predicted amount), the worst-case added interrupt latency of any emitted program is bounded at 27 cycles (1.69 µs at 16 MHz), independent of program size or input. [static audit of compiler-emitted corpus + measured entry law]
Constant-time under voltage & temperature
A constant-time lookup in the emitted pattern was measured cycle-stable as the supply was swept from a nominal 3.3 V down toward the part’s ~2.4 V brown-out floor and at an elevated (~65 °C) die temperature — position spread held ~0.08%, versus ~116% for a conventional branchy comparator over the same table. Evidence the timing invariance is a structural property of the instruction sequence, not an artifact of one operating point. [measured]
Power-envelope accuracy
Instantaneous power derived as voltage × current tracked the measured power to within 2%, and the worst measured peak was ~91 mW against a declared 1000 mW envelope — an 11× margin under budget. [measured]
Codegen determinism over time
For the fixtures tested, the compiler’s emitted instruction stream was byte-identical across a major version bump (v7.3 → v8.0.0, ~12 days apart); only the version-header comment differed. Together with the 20-pass byte-identical artifact stability, this is evidence the physical numbers bind to what the compiler emits, not to a single build. [measured / emitted]

standards coverage

Mapped to the standards that matter.

Aether's manifests reference the certification frameworks used across NATO member nations and major regulatory jurisdictions. These references are compile-time evidence — Aether has not been qualified or certified under these standards, and manifest emission is not a substitute for tool qualification (e.g. DO-330, ISO 26262).

DO-178C Level A
Aviation software · FAA · EASA
ISO 26262 ASIL-D
Automotive functional safety
IEC 62443 SL4
Industrial control system security
IEC 61508 SIL4
Functional safety E/E/PE systems
CC EAL6/7
IT security evaluation · formal verification
FIPS 140-3
Cryptographic module validation
NSA CNSA 2.0
Constant-time · post-quantum crypto
NIST FIPS 203–205
Post-quantum cryptography mandate
NIST SP 800-193
Platform firmware resilience
MIL-STD-461
EMC · defence systems
DO-333 FM
Formal methods supplement DO-178C
MISRA-C 2012
Embedded C · safety-critical
AUTOSAR AP
Adaptive platform · multi-core automotive
EO 14028 / SBOM
US software supply chain security
GDPR Art.5 / 44
EU data protection · residency
EU AI Act Art.13/17
AI transparency · explainability
SLSA Level 3
Build provenance integrity
ARM MTE v8.5-A
Memory tagging · spatial safety
mission

Aether-Lang.org Inc. exists to raise the bar for what “verified” means in embedded safety-critical software. We build compile-time certification tools that structurally prove correctness before code is deployed — producing machine-verifiable evidence of every safety, security, and reliability invariant a system depends on.

Our discipline is that honesty is central: our tools refuse to compile code whose invariants cannot be proven, we document what we don’t yet do, and we treat auditable evidence as more valuable than confident claims.

We serve aerospace, automotive, medical device, and defense engineering teams whose work protects human lives, and we believe the software their systems depend on should be structurally correct by construction — not correct-by-testing-that-hopefully-caught-everything.

Your C code. Aether certification manifests. No rewrites.

Add a sidecar declaration file alongside your existing C/C++ firmware. Aether enforces the properties you declare and produces a machine-verifiable certification manifest in under one millisecond per operation.

email us

contact@aether-lang.org