KRONUS

Build with
assurance.determinism.traceability.Kronus.

01
Why Kronus

Writing the software was never the bottleneck.

Critical systems are increasingly software-defined. Software is faster to write than the hardware it replaced, and coding tools have raised that rate again. Writing it is not the constraint. Showing that it does what the system requires, with evidence a certification authority will accept, takes longer than writing it. That gap is widening.

Software ate the system

When these workflows were conceived, software was small, static, and bounded. The F-4A Phantom II carried on the order of a thousand lines of onboard code, and around 8% of its functions were performed in software. Everything else was mechanism, hydraulics, and analogue circuitry. All of it could be inspected, bench-tested, and reasoned about physically.

Today, the F-35 carries roughly 8 million lines of code onboard with about 24 million more in the ground systems that keep it flying. The aircraft became a machine whose behaviour is almost entirely expressed in software.

The tools for writing that software improved by orders of magnitude. The way intent is captured, how it becomes an implementation, how that implementation is shown to be correct has not meaningfully changed. And the gap widens every year.

Onboard software, combat aircraft

Where the old workflow breaks

01 Intent is scattered, translation is manual Requirements, interface documents, spreadsheets, and models hold the intent. Engineers convert it into code, tests, and documentation by hand, then repeat the conversion whenever something changes.
02 Assumptions and evidence drift apart Assumptions are revised and evidence accumulates across a programme. Artefacts produced against an earlier configuration stay in the record and give no signal that they are stale.
03 Certification is treated as the last step Certification constrains a design as tightly as mass or power. If the system cannot fly until it is certified, the objectives are a design input. Deferring them moves architectural problems to the point where rework is most expensive.
04 Verification is unrepresentative Test environments rarely match the target. Hardware arrives late and rigs approximate it, so behaviour specific to the real system first appears at integration.
02
How it works

One pass, intent to evidence.

Kronus runs a single pass from source artefacts to an evidenced system. Every output is bound to the configuration that produced it.

01 / Capture

Read intent from existing artefacts

Kronus reads the requirements, interface documents, and design data a programme already holds. No migration step, and no new modelling language to adopt first. Conflicting sources are reported rather than silently reconciled.

02 / Specify

Compile intent into a checkable specification

States, interfaces, contracts, and timing become explicit and machine-checkable before any implementation exists. The specification reports conflicting requirements, unreachable states, and timing with no satisfying schedule.

03 / Generate

Generate implementation and evidence together

One specification produces the source, the tests, the documentation, and the trace links back to intent, in a single pass. Every output carries a configuration identity, so evidence cannot drift from the build that made it.

04 / Execute

Execute inside deterministic bounds

Generated software runs on an execution model Kronus designs and controls. Static scheduling, explicit ordering, no dynamic allocation, no cache. Timing becomes a property of the architecture, not a measurement taken at the end.

05 / Evidence

Built for the standards that matter

Kronus is organised around certification objectives rather than around code that gets certified afterwards. The evidence model is common to every standard.

Primary target
DO⁠-⁠178C Airborne software The objective set the platform is built against.
DO⁠-⁠330 Tool qualification How generated output earns credit.
DO⁠-⁠331 Model-based supplement Where the specification carries verification weight.
DO⁠-⁠333 Formal methods supplement Where sound analysis replaces categories of test.
A(M)C 20⁠-⁠193 Multi-core processors Where interference between cores has to be identified and bounded.
Designed to extend to
IEC 61508Industrial functional safety
ISO 26262Road vehicles
EN 5012xRail
IEC 62304Medical device software
MIL⁠-⁠STD⁠-⁠882Defence system safety
IEC 61513Nuclear instrumentation

Kronus is not, and does not replace, a certification authority.

03
Demonstration

Watch the demo.

Walkthrough. Recording in preparation. Come back soon.
04

The team.

Patrick BellamyCo-founder & CEO
Jack Ulbrich-BakerCo-founder & CTO
Kavya RangaswamyFounding engineer
Edward HolmesFounding engineer
05
Partner with us

Systems built for the future need workflows built for them.