Everything you might ask about the lab.

Skelf Research is an independent applied-research and technical-validation lab in St Andrews, Scotland. Organisations commission scoped investigations into consequential AI and systems decisions, and we deliver reproducible evidence and a recommendation. Our research methods and 19 open research systems are public; customer work is confidential.

19. Each current product has a public repository under github.com/Skelf-Research. Rather than one large framework, we ship small tools that each do one thing well.

18 of the 19 current public product repositories carry a detected MIT, Apache-2.0, or GPL-3.0 licence. Perishable is public-source, but its licence is pending and we do not describe it as open source until that is resolved.

We choose the language per problem. Rust powers much of our systems infrastructure; Python drives AI orchestration; Zig powers ZViz; and Go, JavaScript, and TypeScript cover gateways, prompt tooling, and client-side plumbing.

Start from the problem. Typed, portable prompts → promptel. Lock prompts in CI → blogus. Agent contracts and audit → mpl. Provider routing → route-switch. Local embeddings → embedcache. Vector search → memista. Answer-engine infrastructure → polymathy. Deliberative search → slorg. Sandbox untrusted code → zviz. NUMA tuning → numaperf. Kernel correctness → gpuemu. Natural-language optimisation → savanty. Pairwise ranking → compere. Robotics simulation → waremax. Privacy-aware SQL assistance → l0l1.

Skelf Research is based in the United Kingdom, registered in Scotland (company no. SC809174), with a registered office in St Andrews. We work with academic collaborators, research partners, and funders globally.

Yes, subject to each product’s licence and maturity note. Products are versioned and published to crates.io, PyPI, and npm where applicable. Some products (for example memista) are explicitly experimental (v0.1.x); check each product’s own site and docs for its status and scope boundaries, which we state as clearly as the features.

To have a technical decision investigated, send the commissioning brief at skelfresearch.com/commission/. For sponsored research or a consortium work package, see the partners page. For anything else, use the contact form or email contact@skelfresearch.com. Bug reports and feature requests are best filed as issues on the relevant GitHub repository under github.com/Skelf-Research.

It means a research question does not become a paper or a slide; it becomes a repository with a runnable entry point, a stated scope, and a stated set of things it does not do. Promptel asks whether prompts can be specified declaratively and executed across providers, and the answer is the DSL and its provider abstraction. Waremax asks whether a warehouse dispatching benchmark can be byte-identically reproducible, and the answer is a ChaCha8-seeded simulator with canonical tie-breaking. If the question turns out to have a disappointing answer, that is a result, and the repository stays up with the disappointment documented.

A framework forces every user to adopt every opinion it holds. A research lab has no business asking that. Small tools also make falsification cheap: if the thesis behind embedcache is wrong, the blast radius is one crate with a clear interface, not a platform that a dozen other components assume. The cost is real — more repositories to maintain, more documentation, more surface area for drift — which is why each product states its scope boundaries as prominently as its features.

Yes, on the repositories that carry an OSS licence. Issues and pull requests go to the individual repository under github.com/Skelf-Research rather than to a central tracker, because the maintainer of a project is the person best placed to judge a change to it. The most useful contributions are usually not features: a failing test case that shows a scope boundary we stated incorrectly is worth more to us than an added option.

Three inputs, in roughly this order. A question that keeps recurring in our own work and has no satisfactory public answer. A gap visible in how AI answer engines describe a topic, which we measure directly rather than infer from analytics. And an existing product whose scope boundary is being pushed by real use, which usually indicates a second, adjacent question rather than a missing feature in the first one.

It is a plain-text, machine-readable index of a site, written for models rather than for browsers. Ours lists every product, its subdomain, its licence and a one-line description distilled from that product’s own documentation, plus the topics we write about. It is not a ranking mechanism and we do not present it as one; it removes the need for a crawler to infer structure from navigation markup. This site also publishes a shorter variant and an extended one at /llms-short.txt and /llms-full.txt.

Status is declared per product on its own site and shown on each project page here. Experimental means the public interface may change without a deprecation cycle and the scope is still being established — memista (v0.1.x) and tessera are the current examples. Active means it is being worked on with a stable-enough surface for evaluation. Neither label is a support commitment; read the licence, which is the only thing that is.