Independent technical verification
Evidence that an aviation algorithm does what its requirements mean.
We create independent, reproducible evidence that aviation algorithms behave according to their mathematical, operational, and safety requirements, and we show exactly where they do not.
The gap we work in
Conventional verification asks whether the code does what the team said the requirement means. We ask whether that is what the requirement actually means, and what happens at the boundary where the interpretation decides the outcome.
The work is deliberately narrow. It covers the part of assurance that tends to fall between systems engineering and ordinary software testing: reconstructing what an algorithm mathematically means, exposing the assumptions and conventions it hides, and producing numerical evidence that someone else can rerun and challenge.
It suits teams building separation, deconfliction, and conflict-management functions for UTM, advanced air mobility, and autonomous aircraft, before integration, flight test, partner acceptance, or assurance planning.
What we do
-
Specification reconstruction and convention control
Units, frames, signs, angle wrapping, branch selection, domains, tolerances, timing, and hidden parameters. Ambiguities are logged and returned to you for a decision, not silently resolved.
-
Independent reference implementation
Built from the normative specification in an isolated repository, without copying the structure of your implementation.
-
Three-way differential testing
Specification, your implementation, and our reference are compared against one another, so a discrepancy is attributed to its source rather than merely reported.
-
Boundary and adversarial exploration
Existence boundaries, discontinuities, branch transitions, wrap points, singularities, and operationally adverse geometries.
-
Uncertainty and sensitivity analysis
Analytic first-order propagation cross-checked against large-sample Monte Carlo, with an explicit statement of where linearization stops being valid.
-
A rerunnable evidence chain
Hashes, seeds, tool versions, environment, and run instructions for every result. You keep the artifacts.
How a claim becomes evidence
Every finding traces back through the same chain, in this order, so anyone on your side can follow it and challenge any link.
- ClaimWhat the algorithm is said to do
- RequirementThe governing text it answers to
- EquationWhat that text means mathematically
- BaselineThe frozen implementation under test
- TestDesigned at boundaries, not just nominal cases
- ResultRerunnable, with seeds and hashes
- FindingAttributed to spec, code, or reference
- DispositionYour decision, recorded
Why independence is the product
Your engineers and their AI tools can generate more tests, faster and more cheaply than we can. That is not what this is.
What an internal effort cannot produce is an organizationally separate party that selects and defends the governing assumptions, freezes the evidence baseline, decides which discrepancies are material, and puts a name on the conclusion. We don’t ask you to trust an output or a reputation. We give you the requirements-to-result chain, the executable evidence, and the stated limitations, so your engineers, safety team, integrator, or designee can challenge it and rerun it.
How we use AI
We use AI tools to speed up reconstruction, implementation, test ideation, and drafting. No finding is accepted because a model produced it. Every material conclusion is reproduced by deterministic computation or documented human analysis. Your data goes to external AI services only under your written data-handling rules.
Engagements
Every engagement is bounded: one named artifact baseline, a stated scope, and explicit non-claims. Uncertain work starts with paid scoping, so the fixed price is set against a real baseline.
| Engagement | What you get | Typical duration |
|---|---|---|
| Evidence Readiness Triage | A claim-to-evidence map, ranked material gaps, an ambiguity list, a recommended assurance scope, and explicit non-claims. Part of the fee is credited against a follow-on engagement. | Up to 3 delivery days |
| Paid Scoping | Scope, baseline, and acceptance criteria defined before an uncertain fixed-price engagement. Credited to execution. | 2 days |
| Algorithm Assurance Sprint | An independent assessment of one bounded mathematical kernel before integration, flight test, partner acceptance, or assurance planning. | 3–6 weeks |
| IV&V Evidence Module | A module aligned to your assurance plan, with uncertainty analysis, adversarial exploration, full traceability, and verification of corrections. | 6–12 weeks |
| Release & Regression Assurance | Corrections and later releases verified against the frozen baseline, with reserved days each month. | Monthly, 3-month minimum |
| Transaction / Partner Diligence | An independent view of a claimed algorithm’s maturity and evidence quality, for an investor, acquirer, insurer, or integration partner. | 2–5 weeks |
How we work with you
- Your code stays with you
- Your source code never has to leave your control. We can work specification-side and compare outputs only.
- You own the evidence
- Engagement-specific evidence and rerun artifacts are yours. We retain general methods, non-customer tooling, and anonymized defect patterns.
- Findings reach the right person
- Findings are issued to a sponsor separate from the development author. We decline work where material findings cannot be reported.
- Standard of care
- A stated standard of care and residual-risk limitation, not a guarantee of correctness. One factual-correction cycle per baseline; change orders for new versions or added requirements.
- Scope, not rate
- A first pilot covers fewer claims or one algorithm. We narrow the scope rather than discount the work.
Track record and its limits
Our own conflict-resolution research is published openly with its full validation supplement (DOI 10.5281/zenodo.21956633) and has been submitted to the AIAA Journal of Air Transportation. The current submission contains 122 numbered equations and 15 numerical tables. A 372-comparison audit of a draft table revision isolated a systematic sign defect in the draft uncertainty totals; a 28-test analytical and direct-simulation suite passed; and the published 144-run Monte Carlo dataset regenerated byte-for-byte from the archived script, seeds, and configuration. More on the research.
Stated plainly
- The published work is a preprint. It is not yet a peer-reviewed publication.
- The analytic implementation and its reference simulator came from the same two-author effort. That demonstrates diverse implementation, not third-party IV&V.
- Its demonstrated domain is two-dimensional, level-flight, pairwise encounters.
- We are a specialist practice, not a certification house.
What we do not claim
We produce independent technical verification evidence that can support your safety, integration, due-diligence, or certification process. Acceptance and compliance credit are determined by your approved process and the relevant authority or designee, not by us.
We do not claim FAA approval or recognition of our reports, authority to approve compliance data, DER or ODA status, certification of an algorithm or product, or compliance with DO-178C, ARP4754A/B, or DO-278A on the basis of a mathematical assessment alone. Where technical, managerial, and financial independence are not all established for an engagement, we call the work independent technical verification rather than full IV&V.
DO-178C assigns certain verification objectives “with independence” at higher software levels. That is an independence criterion, not a requirement to hire an outside company. The FAA’s proposed Part 108 and Part 146 rules would require service suppliers to document testing and verification procedures, but those rules are not final, and we don’t describe them as though they were.
Start with a conversation
Tell us what the algorithm does, which requirements it answers to, and what decision the evidence needs to support. We’ll say whether a triage, a scoped sprint, or nothing at all is the right next step.