DeepFellow Use Case: Trustworthy Data at Sea, Without the Cloud

The Challenge: Deploying AI Inside a System That Can't Use the Cloud

MORSIK* was designed to help maritime operators assess the reliability of navigational data – AIS positions, NAVTEX and BHMW radio broadcasts, satellite feeds. These data often contradict each other. This solution, instead of raw, conflicting inputs, gives operators a single, justified picture: what to trust, and why.

That logic had to run inside constraints the cloud couldn't accommodate. The radio data MORSIK processes must never leave the infrastructure that handles it, and the same stack serves both civilian and defense operators. DeepFellow's made that possible in the most satisfying way – the MORSIK team did not need to build an inference layer from scratch, allowing them to focus on the features instead.

Key Constraints

Two hard constraints ruled out any cloud-based model:

1. Data residency. The radio data MORSIK processes – NAVTEX, BHMW, VHF – must never leave the infrastructure that processes it.
2. Dual-use requirement. The same stack serves both civilian and defense customers. A public, external endpoint isn't viable operationally – it may be unreachable in the field, and its existence is itself a risk.

This meant that the project required an offline AI stack that could run without a GPU in an environment where internet access is blocked by default.

The Solution

DeepFellow provided a self-hosted, OpenAI-compatible endpoint running on small models, CPU-only, with all communication staying inside the cluster and no public route. This let the MORSIK team focus on the logic of correlating navigational data, instead of building and maintaining an inference layer from scratch.

Architecture

Infrastructure: k3s on 16 GB RAM, No GPU

The system runs on a lightweight k3s cluster on 16 GB RAM, no GPU. This reflects the real constraint: MORSIK runs on infrastructure actually available on board a vessel or at a resource-limited shore facility, not in a data center. DeepFellow suits both small and large scale deployments.

The inference backend is llama.cpp, CPU-only. In order to handle model provisioning and store the project key as a Kubernetes Secret, the version of DeepFellow used assumed a Docker Compose deployment rather than a native Kubernetes deployment. Therefore, the team ran it in an isolated Docker-in-Docker pod managed by a Helm chart via ArgoCD.

Model Selection

Given the 16 GB RAM ceiling and no GPU, the team used sub-1B models in GGUF format, which DeepFellow supports out-of-the-box. The final choice was Qwen3-0.6B as the default extraction model. Granite 4.0 H 350M and LFM2-350M were tested as a cascade – an internal quality/cost experiment, not a DeepFellow requirement. The team settled on the single Qwen3-0.6B model.

Security & Attack Surface

Each extraction call is fully independent: a single message, no conversation history, no external knowledge, no tool access. RAG, the vector database, and tool-calling were all disabled. This reduces exposure to context poisoning — a crafted, malicious context designed to manipulate model output. A system assessing data trustworthiness can't itself be vulnerable to context-based manipulation.

Two built-in DeepFellow plugins run on Qwen3-0.6B:

• Abuse detection – flags risky content; abusive prompts return HTTP 422, normal ones return 200.
• Anonymize – strips identifying data, enabled on every call, no exceptions.

API Usage

The application uses one endpoint only: POST /v1/chat/completions, authorized via a project key as a Bearer token. Configuration: temperature 0, response_format: json_schema enforcing the system's event schema, model "thinking" disabled, timeout with offline fallback. /v1/models and /health are used only as helpers; the Infra admin API is used only during provisioning, never by the production application.

Security Design

The DeepFellow project key is the only credential on the path from application to model. It lives in a Kubernetes Secret – never in git, never in logs.

Additional safeguards:

• Constrained decoding via JSON schema – no freedom in output structure.
• System prompt inaccessible to the client.
• Messages treated strictly as data, never as instructions.
• Model allowlist – only approved models serve production traffic.
• Numbers never come from the model. Positions and dates are parsed deterministically outside the model; the model handles only event type, description, and entity identification. Hallucinations in such data are not acceptable for a navigation system.

Simply declaring that weights stay inside the pod does not satisfy the dual-use requirement. Rather, it requires demonstrating that they cannot leave it. Two controls provide this demonstration: egress is blocked by default, meaning that there is no network path out for a compromised or malicious runtime, and weights are only fetched in a separate, controlled provisioning phase. This makes the set of boundary crossings finite and auditable.

Deployment Steps

1. Infrastructure setup – k3s cluster on 16 GB RAM, isolated container environment, egress blocked by default.
2. Install Infra and Server via DeepFellow CLI – selecting only needed functionality, reducing attack surface by omitting the rest.
3. Register a custom lightweight model – sized for the 16 GB RAM limit, served via llama.cpp.
4. Generate a project key – restricting API access to key holders.
5. Configure abuse detection and anonymize plugins.
6. Integrate MORSIK with DeepFellow – using OpenAI API compatibility, temperature 0, thinking disabled, constrained decoding via json_schema.

What This Means for Dual-Use Deployments

Civilian infrastructure can become strategically critical overnight. A port, a shipping route, a monitoring network – none of it is military by design, but any of it can become a strategic asset without warning. MORSIK, built during a hackathon, was designed to help maritime operators resolve conflicting navigational records – with that possibility in mind from the start. The same stack runs unchanged for civilian and defense operators alike.

DeepFellow achieved this without developing the inference layer from scratch, eliminating the need for custom llama.cpp integration, a key management system or in-house safety filtering. With the platform problem solved, the team can focus on the real challenge: turning floods of data into information that operators can trust.

*MORSIK is a project designed during the Baltic Dual Use Hackathon 2026. It won second place in the "From Scratch" category. The Polantir team behind the project included Joanna Wachowska, Kamil Rybacki, Marcin Kolago and Rafał Tomaszczyk.