Mission-first defence procurement

From mission need to awarded contract — on evidence you can defend.

Kairon turns an operational need into graded requirements, matches them to procurable line items, and checks the origin of every declared component against your policy. A tender is held while a mandatory requirement is unmatched or a flagged origin is uncleared. An embargoed origin can't be cleared at all.

  • Fails closed by design
  • Every change attributed
  • Any language on request
Command ViewOrigin policy v74
Provenance gate5 tenders held — fail-closed
5
Blocked at the gate
2
Cleared to tender · of 7 in flight
Why held: 2 requirements · 3 provenance-compliance
HELD
Op SILVER LANCE
Embargoed origin — LI-008 battery cells (BY). Sanctions hard-block, non-clearable.
HELD
Op HIGH PASS
No requirement set derived yet.
ILLUSTRATIVE — DEMO DATA
  1. 01
    Mission need
    What has to happen, where, how soon
  2. 02
    Required effect
    Observe, strike, deliver
  3. 03
    Capability class
    ISR, loitering munitions, resupply
  4. 04
    Requirements
    Graded SHALL · SHOULD · MAY
  5. 05
    Line items
    Procurable, with a declared BOM
  6. 06
    Award and field
    Two actors, bound to a snapshot
Why Kairon

Procurement that can show its working.

Drone programmes move faster than the paperwork behind them. Kairon puts the reasoning in the record, so a tender can be explained line by line to an auditor, a minister or a supplier.

The usual failure

Requirements written around a product someone already likes.

In Kairon

You start from the effect the mission needs — observe, strike, deliver — and derive requirements from it. Products are matched afterwards, not before.

The usual failure

A component's origin surfaces after the contract is signed.

In Kairon

Origin is declared per component, classified against your policy and checked at the gate, before a tender can be issued.

The usual failure

Decisions nobody can reconstruct a year later.

In Kairon

Every change is attributed to the signed-in person and time-stamped in the mission's audit trail, including the justification behind each compliance decision.

How it works

Six steps, one chain, no orphans.

Every tender line traces back to the mission need that justified it. Kairon enforces the chain as you work, rather than documenting it after the fact. An orphan is a requirement with nothing procurable matched to it, and a mandatory one holds the tender until it is matched.

01 · Mission need

State the need, not the product.

Capture the mission against a shared capability taxonomy: effect, environment, threat, range, payload and urgency.

Op HIGH PASS — Austere mountain resupply
Logistics / Resupplyeffect: deliverurgency T1above 3,000 mGNSS-degraded
02 · Requirements

Derived from the mission, then graded.

Kairon derives the requirement set from the mission. Each requirement is SHALL, SHOULD or MAY, and the grade is shown by weight as well as colour.

SHALLOperate in littoral, maritime, GNSS-degraded environments.
SHOULDReach the objective endurance at the band's upper bound.
03 · Line items

Matched to what can actually be bought.

Requirements are matched to procurable line items. Each item carries its component bill of materials, with a country of origin and an evidence reference per component.

M-001-ISR-ENV →
LI-001 · Peregrine-S Maritime VTOL ISR
Matched · component origins declared
04 · Gate

Checked before anything is issued.

The gate tests four things. A SHALL with no matched line item — an orphan — holds the tender, and so does any uncleared origin flag.

  • Requirementsclear
  • Data qualityclear
  • Time-to-fieldclear
  • Provenance complianceheld
05 · Tender

Frozen as a versioned snapshot.

The tender document is generated from the validated set and frozen as a snapshot. While the gate is held, Kairon refuses to produce one.

tender snapshot v3
each requirement → mission_need_ref
each requirement → line_item_ref
06 · Award

Two actors, on the record.

One person records the award and a different approving authority approves it. The award is bound to the snapshot it was issued against, and the requirements become read-only.

Issued by
Contracting Officer
Approved by
Approving Authority
Bound to
snapshot v3
Provenance gate

The gate fails closed.

Kairon never assumes a component is clean. Origins are classified against your policy. A flag holds the tender until Compliance clears it with a written justification. An embargoed origin is a sanctions hard-block that no clearance can lift.

  • AllowedPrimary compliant tier. Passes.
  • AlliedOptional second compliant tier. Passes.
  • UnknownNot in your policy, or can't be established. Routes to compliance review.
  • RestrictedPartial embargo. Held until Compliance clears or rejects it.
  • EmbargoedHard block. Not clearable. Re-source the component.

A line item with no declared components is counted undeclared — never clean — and the tender says so.

LI-008 · Platform · Loitering Munitions
Talon-40 Loitering Munition
Airframe (folded-wing)allowed
Flight controllerallowed
ESC set (4×)unknown
Battery cells (Li-ion 18650)embargoed
Gate verdict — held
Embargoed origin: sanctions hard-block, non-clearable. The component must be re-sourced, or the origin de-listed in the origin policy.
ILLUSTRATIVE — DEMO DATA
Origin policy

Your policy is data, not code.

Each ministry brings its own origin policy. Kairon ships illustrative starting presets and seeds the restricted and embargoed lists from the public EU arms-embargo list.

  • Every edit bumps the version and records the full before and after.
  • Statuses recompute at once, across every mission.
  • Any clearance the change affects is re-opened for review.
  • Switching off an embargo entry downgrades it to unknown — never to allowed.
Origin policyv74audit-logged
Allowed · 42 · EU-27, NATO, close partners
ATCZDEFRGBPLSKUAUS+33
Restricted · 12 · partial embargoes
CNVELYIQAF+7
Embargoed · 6 · comprehensive embargoes
RUBYIRKPSYMM
Starting presets:EU / NATO baselineUK-styleGerman-stylePolish-style
ILLUSTRATIVE — DEMO DATA
Accountability

Every change has a name.

The signed-in identity is pinned on the server. Every change is attributed to that person and time-stamped in the mission's audit trail, and nobody can relabel it afterwards.

Role-scoped views
Requirements Owner
Authors and maintains the requirement set.
Contracting Officer
Turns validated requirements into tenders and works the gate.
Approver
Approves awards before issue, separate from the buyer.
Compliance and Audit
Reads the audit trail, provenance evidence and gate decisions.
Programme Director
Oversees the whole portfolio, every surface.
Mission audit trail
M-004
  1. 09:12
    requirement.updated · Requirements Owner
    Endurance threshold set to 4–12 hr.
  2. 10:04
    compliance.cleared · Contracting Officer
    Flags cleared. Justification: licence reference recorded verbatim.
  3. 10:31
    tender.snapshot · Contracting Officer
    Snapshot v3 issued. Mission moves to tendered.
  4. 11:02
    award.approver · Approver
    Award approved. Issuer and approver are different people.
  5. 11:40
    mission.awarded · Contracting Officer
    Bound to snapshot v3. Requirements now read-only.
ILLUSTRATIVE — DEMO DATA
Outside evidence

Imported evidence is labelled for what it is.

Kairon connects to outside sources, but it never lets them pass for checked evidence.

Public tender notices

A TED / eForms adapter brings in EU notices as untrusted records. You preview them before anything is written. Fields that TED doesn't carry, such as where something was manufactured, come in as unknown.

Simulation runs

Simulator results attach to a requirement as modelled predictions. They are kept apart from verified evidence and never treated as proof that a requirement is met.

How simulators connect →
Sovereign by construction

Built to run where your data has to live.

Your own instance

Every customer runs a dedicated instance, on premises or in the cloud.

Any language you need

English by default. Other languages are added on request.

Cost-effective

Set your own price-to-fit ratio for each mission, from the lowest compliant price to the closest capability match.

Print is a record

Tender snapshots and gate verdicts print as filed evidence, with nothing truncated and markings preserved.

Briefing mode

Projector-ready type and spacing. Classification markings and disclaimers stay visible.

Honest numbers

Figures are computed on the server from the live record.

Mission simulation

Test before you buy — in the simulator you already use.

Connect your own mission simulator, or use our partner's. Kairon hands it the mission and its requirements, and files every run against the requirement it tested.

  1. 01
    The mission goes out
    Environment, threat, range and payload, taken straight from the mission record.
  2. 02
    The simulator flies it
    Candidate line items run side by side, under the same conditions.
  3. 03
    Results come back labelled
    Each run is attached to its requirement as a modelled prediction, kept apart from verified evidence.
Option A

Bring your own simulator

Many customers already run their own simulation environment or test range. Connect it to Kairon, and your models and data stay on your own infrastructure.

your infrastructureyour modelsAPI connection
Option B · Partner

Use our partner's simulator

No simulator yet? Use our partner's flight simulation, built on Unreal Engine 5.7.

  • Battery simulation and motor electrodynamics
  • Aerodynamics including vortex ring state, translational lift and gyroscopic effects
  • Betaflight PID compatibility
  • Compare manufacturers side by side and train operators before award

Bring one real requirement. We'll show you where it would be held.

A briefing on your own mission need: requirements derived, line items matched and the gate run against your origin policy.