Signed inference-routing layer that gets maritime surveillance alerts from drones to field teams when terrestrial links fail.

1. Public funding is now underwriting orbital AI infrastructure, so software suppliers can build against a real program instead of a speculative science project.
2. The architecture is explicitly direct-to-device plus orbital inference, which creates a new routing and model-placement problem between drone, satellite, and handset.
3. Named military and industrial buyers share the same failure mode: they need intelligence delivery when terrestrial networks are missing or degraded.
4. A program expected to exceed €40 million after a prior €150 million GEO contract suggests adjacent integrators will need deployable software before the network matures.

Catalyst. OrbitCloud’s funded push to combine direct-to-device connectivity with orbital inference makes resilient alert routing an immediate software layer customers can buy before full constellations scale.

Contested Link Inference Router is a control plane that turns a surveillance mission into signed model, routing, and evidence policies for drones, satellites, and field devices. Before launch, the platform packages approved computer-vision models and bandwidth budgets into a mission bundle; during operations, it decides whether to run inference on-drone, forward a crop to an orbital node, or deliver a thumbnail-and-coordinate alert to a handset. Operators get an audit trail showing which model version fired, what evidence was transmitted, and where connectivity failed, which matters for defense acceptance and after-action review. The product integrates with private satellite networks, drone ground stations, and existing command-and-control software rather than replacing them.

What's different. Incumbent SATCOM vendors move bits, drone software vendors manage aircraft, and command-and-control systems display tracks; none decide what inference should run where under sovereignty and bandwidth constraints. This startup owns the signed mission-bundle layer and learns which model placements and evidence-packet formats preserve acceptable detection quality under real link budgets. That operating data becomes a defensible tuning moat and a wedge into broader coalition edge-governance.

Jobs to be done

flowchart LR
  Buyer[Maritime ISR integrator] --> Pain[Detections die when terrestrial links fail]
  Pain --> Product[Signed inference-routing control plane]
  Product --> Outcome[Trusted alerts reach field teams in time]

Executive takeaways

• The best beachhead is not generic satellite AI; it is resilient alert delivery for one maritime-surveillance workflow where links fail and field teams still need trusted detections.
• The buyer is likely a mission-system integrator or framework prime, because the budget and operational authority already sit inside larger RPAS, secure-comms, and maritime-security programs.
• The product wedge is a control-plane gap between transport, autonomy, and command software: deciding what inference runs where and what minimum evidence should survive the link.
• The strongest proof points are public Baltic/Nordic maritime programs, EU secure-satcom buildout, and open evidence that D2D and airborne SATCOM remain too constrained for routine full-motion-video workflows.
• Competitive intensity is real but mostly adjacent: incumbents own transport, autonomy, or data mesh layers rather than signed mission bundles, provenance, and evidence-aware routing.

Market definition

The near-term market is mission software for denied-link maritime ISR: a layer that sits between drones, secure satellite connectivity, and field or command applications to package approved models, compress evidence, and preserve provenance when terrestrial backhaul is weak or absent.

Customer and buyer

The operational user is the maritime-surveillance team that needs fast, trusted alerts; the practical buyer is the integrator or prime responsible for delivering the pilot, accreditation package, and secure information flow into a coast-guard or border-security program.

Buying triggers

• A new maritime or border-surveillance pilot has to work outside reliable terrestrial coverage. [3][4][6][7]
• Regional security incidents raise pressure to integrate more surveillance assets and improve shared situational awareness in the Baltic. [8][9][10]
• A sovereign satcom or shared-maritime-picture program creates a fresh integration budget and a new interoperability deadline. [14][15][16][17][27]

Willingness to pay

Budget is more likely to appear as a line inside larger RPAS, surveillance-aircraft, or secure-connectivity programs than as a standalone AI-tool purchase. Adjacent public programs already fund multi-year RPAS services, surveillance aircraft with encrypted real-time transfer, and orbital-network R&D, which supports a plausible low-single-digit-million annual software layer when tied to readiness, bandwidth reduction, and auditability. [1][25][26]

Category dynamics

Growth signal 9.4% YoY global military spending growth in 2024, with Europe a key driver

Validation signals

• Business Finland put initial public funding behind ReOrbit’s orbital-AI and direct-to-device network thesis.
• The Finnish Border Guard is already using EMSA-supported RPAS with satellite communications for Baltic maritime missions.
• Frontex says its 2025 pilot could securely share real-time situational awareness anywhere needed, showing buyer appetite for mobile, infrastructure-independent dissemination.
• EMSA awarded a €30M RPAS framework, showing that service-based maritime-surveillance programs can carry meaningful integration budgets.
• Finland is funding both encrypted real-time surveillance-aircraft data transfer and classified maritime-picture exchange.

Regulatory & technical constraints

• Mixed-use deployments may face EU AI obligations even if purely military deployments are handled outside that scope.
• Cross-border software, technical assistance, and certain advanced capabilities can trigger EU dual-use export controls.
• Secure government satcom access is mediated by hub and program structures rather than open developer platforms.
• NTN and D2D are standardized and strategically important, but they remain constrained by link budgets, capacity, and coexistence rules.
• End-to-end interoperability across MARSUR, NATO digital backbones, drone stacks, and field systems will dominate early delivery risk.

The market is structurally adjacent to several stronger incumbents: satcom operators move data, autonomy vendors optimize vehicles, and surveillance platforms fuse pictures. The startup only wins if it stays narrow on signed model placement, evidence minimization, and chain-of-custody across drone, orbit, and handset.

Why incumbents do not win by default

• Cloud platforms. General cloud vendors do not solve classified transport, cross-domain exchange, or DDIL mission accreditation by default.
• SATCOM operators. Transport vendors can provide resilient links, but they do not inherently decide what inference should run on the drone versus upstream or what evidence packet is sufficient.
• Autonomy stacks. Autonomy software is strong at operating vehicles in denied environments, but weaker at cross-platform dissemination, provenance, and handheld delivery.
• Prime-built surveillance platforms. Custom multi-asset platforms can be procured inside existing programs, but they tend to be integration-heavy and less reusable across missions or countries.

Contested Link Inference Router is a mission-software layer for Baltic and Nordic maritime-surveillance programs that need trusted drone detections to reach field teams when terrestrial links fail. The beachhead is not generic orbital AI; it is one vessel-of-interest alert workflow inside an existing coast-guard or border-force pilot where SATCOM bandwidth is scarce and response time matters. The product packages approved models, routing policy, and evidence rules into signed mission bundles so an integrator can govern what runs on the drone, what is escalated upstream, and what minimum packet reaches a handset or C2 system. The researched market supports this wedge because Baltic RPAS operations, secure-satcom buildout, and maritime information-sharing programs already exist, while public-sector budgets are more likely to buy this capability as a line item inside a larger mission program than as a standalone AI tool. The deliberate strategy is to sell through mission-system integrators and secure-connectivity partners rather than pursue direct agency platform replacement. The biggest disconfirming risk is that operators may still require short video bursts or raw video in too many alert events, which would weaken the bandwidth and trust advantage of compressed evidence packets. Another material gap is that the specific first integrator, target API surface, and trusted evidence format are not yet identified in the source files, so the first 90 days must validate those three points before broad product build-out. If those assumptions hold, the company can expand from one maritime-alert workflow into adjacent maritime missions and later other intermittently connected sovereign-edge networks.

Problem

• Maritime RPAS teams in Baltic and Nordic waters cannot rely on terrestrial backhaul, but they still need sub-minute detections to reach field operators during live missions.
• Current alternatives either stream raw video expensively over SATCOM or leave model deployment and evidence handling fragmented across drone, network, and C2 vendors.
• Mixed fleets and coalition workflows make it hard to prove which model ran, what evidence was sent, and whether the alert should be trusted after link degradation.

Solution

• Provide a signed mission-bundle control plane that packages approved models, routing rules, and evidence budgets across drone, satellite, and handset nodes.
• Deliver compressed evidence packets with coordinates, confidence, thumbnails, and provenance instead of defaulting to full-motion video for every alert.
• Keep an audit trail for model version, routing decisions, and failed handoffs so integrators can support acceptance, after-action review, and mixed-use compliance.

Why we win

• The wedge sits in a control-plane gap that incumbents do not own cleanly: SATCOM vendors move data, autonomy stacks run vehicles, and C2 tools display outputs.
• The first product can ride existing RPAS and secure-connectivity budgets instead of asking agencies to replace transport or mission systems.
• Real mission logs on model placement, evidence sufficiency, and degraded-link performance can compound into a reusable optimization and trust dataset.

Milestones

flowchart LR
  Wedge[Vessel-of-interest alert wedge] --> MVP[Signed mission-bundle MVP]
  MVP --> Proof[Paid pilot proves sub-minute trusted alerts]
  Proof --> Expansion[Expand to more maritime programs and missions]

Founding team

Experiment roadmap

Risk assessment

What must be true

• One Baltic or Finnish integrator can add this software to an existing maritime-surveillance program without a net-new standalone procurement.
• Field operators will trust compressed evidence packets for a meaningful share of vessel-of-interest alerts.
• One target drone, network, and C2 stack exposes enough integration hooks to support signed mission bundles and routing policy.
• Program economics support a repeatable annual software spend of roughly $700k+ per production deployment.
• The first deployment produces reusable policy and trust data rather than one-off services work.

Open diligence questions

• Which named integrator owns the first pilot architecture and budget line?
• What exact alert packet will operators act on without asking for raw video?
• Which partner APIs or control surfaces are available in the first target stack?
• How much of the first contract is software versus custom integration labor?
• What accreditation or mixed-use compliance step is most likely to delay deployment?

Model sanity

• Revenue engine. Base-case revenue comes from moving from 1 paid pilot at Y1 exit to 4 paying maritime programs at roughly $820K of blended annual value each by Y3 exit.
• Must go right. The first pilot has to land by M9 and prove enough adapter reuse that two more maritime programs can close by Y2 exit without turning the company into a services shop.
• Model breaks if. If procurement or operator trust slips toward the downside case, the business exits Y3 about $0.35M below zero cash before it has enough scale to self-fund.
• Next-round proof. A credible seed story appears once the first pilot converts to production and 3 paying programs show reusable accreditation evidence plus a visible path to the fourth program.

Scenarios

Sensitivity

flowchart LR
  IntegratorLeads[Integrator design partners] --> PaidPilots
  PaidPilots --> ProductionPrograms
  ProductionPrograms --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: The model assumes one named integrator can attach the software to an existing maritime program without a net-new standalone procurement. · ARPU is anchored to research SOM math and the business-plan price range rather than to observed contract data from this exact category. · With only 4 paying programs in the base case, a single slipped conversion or non-renewal has an outsized effect on runway and next-round timing. · Gross margin only holds if the company keeps integrations reusable and avoids drifting into bespoke systems-integration work.

• Procurement drag. Defense and coast-guard buying cycles can delay standalone software adoption even when the mission pain is clear. Mitigation: Enter through funded integrator pilots and position the product as a mission-readiness line item tied to near-term exercises or acceptance milestones.
• Network fragmentation. Different satellite, drone, and command stacks may make the routing layer expensive to integrate and hard to standardize. Mitigation: Build a vendor-neutral policy engine with store-and-forward connectors, starting with one reference architecture for Nordic maritime pilots.
• Operator trust in AI alerts. If detections are noisy or provenance is weak, field teams will ignore the alerts and revert to raw video or manual workflows. Mitigation: Start with one high-value alert type, include evidence thumbnails and model provenance in every packet, and keep a human confirmation loop for retraining.