About Skelf Research
Research that ships.
Science that scales.
Skelf Research is an independent applied-research and technical-validation lab based in St Andrews, Scotland. Organisations bring us technical decisions that are too consequential to make from a demo, a vendor claim or an internal hunch; we investigate them and deliver reproducible evidence and a recommendation, including when the answer is no.
We operate at the boundary between academic inquiry and real-world systems. Our own research — on reasoning, retrieval, efficiency, correctness and privacy — is done by building working prototypes and publishing the methods and software. Customer work is the exception: it stays confidential unless the client agrees otherwise.
Our Methodology
Our methodology is simple: identify an open problem, construct a hypothesis as software, stress-test it against real workloads, and release the results. Every repository is a peer-reviewable experiment.
We don't stop at papers. We publish code that can be run, tested, and challenged. Each of our 19 public products encodes a specific research question. 18 currently carry a detected OSS licence.
Core Principles
Hypotheses as Software
Each project encodes a research question. The codebase is the proof — runnable, testable, and falsifiable.
Open Science by Default
19 current public products, each with inspectable source. Licensing and maturity are stated per project.
Systems-Level Rigour
We choose Rust, Zig, and Go not for fashion but for falsifiability — deterministic performance makes claims measurable.
Privacy as a Research Constraint
On-device inference and zero-trust architectures aren't add-ons — they're design constraints that shape better science.
Research Domains
LLM Cognition & Prompt Theory
Formalising the relationship between prompt structure and model behaviour. Declarative prompt specification, automatic optimisation, and routing.
Safe & Verifiable Computing
Memory-safe language design, container sandboxing, and NUMA-aware scheduling for trustworthy autonomous computation.
Formal Optimisation & Decision Science
Bridging human intent and formally provable solutions. Constraint satisfaction, signal compilation, and intelligent ranking.
Edge Intelligence & On-Device AI
On-device LLM execution, mobile agent architectures, and privacy-preserving AI at the edge.
Robotics & Autonomous Systems
Deterministic discrete-event simulation, RL benchmarks, and the systems engineering that turns research code into reproducible robotics experiments.
How a Question Becomes a Repository
The pipeline is deliberately short. A question that recurs in our own work and has no satisfactory public answer becomes a scoped problem statement. The problem statement becomes a repository with a runnable entry point, a declared scope, and — just as prominently — a declared list of what the artefact does not do. The repository is then stressed against a workload we did not design for it, and whatever that reveals is written up, including when it is unflattering.
The scope declaration is the part people find unusual. Waremax states that it models pod-to-person dispatching and not conveyor sortation or tugger trains. Perishable states that it raises the cost of casual key abuse and is not bot-proof. Memista states that it is experimental at v0.1.x. A tool that will not say where it stops cannot be evaluated, only adopted on faith, and faith is not a research output.
Publication is the default, not a reward for maturity. Several of the repositories here answer their question in the negative, and those stay up. A lab that only publishes the experiments that worked is reporting a filtered sample of its own evidence.
What We Deliberately Do Not Build
We do not build frameworks. A framework asks every user to adopt every opinion it holds, and a research group has no standing to ask that. We ship small components with narrow interfaces so that a wrong thesis costs one crate rather than a platform.
We do not build hosted services. Everything in the portfolio runs on infrastructure the user controls, because a research artefact behind an API is not inspectable and cannot be independently replicated. This rules out business models we would otherwise find attractive, which is the trade we have chosen.
We do not train foundation models. Frontier pre-training is a capital problem rather than an idea problem, and the questions we find interesting — how prompts should be specified, how agents should remember, how untrusted code should be contained, how natural language should meet a solver — sit above the model layer and are largely independent of which model is underneath.
We do not publish benchmark numbers we cannot reproduce from a seed. If a claim in our writing has a number attached, the method for regenerating it is in the repository the claim came from. Where we do not have a number, we describe the mechanism and say so.
Get in Touch
Facing a technical decision that deserves evidence rather than a hunch? Commission an investigation. Sponsors, consortia and research collaborators are welcome too.