Sponsored research
A reproducible benchmark, compatibility study or reference implementation, published with the sponsor, method, limitations and conflicts disclosed. You buy the work, not the conclusion.
Partners & sponsors
Open research.
Serious partnerships.
Private investigations for a single organisation are covered under services. This page is for work with a wider audience: vendors sponsoring a reproducible benchmark or reference implementation, consortia and funded programmes that need a defined work package, and technology or open-source partnerships.
Ways to work with us
Research work packages
A defined work package inside a consortium or funded programme: an evaluation harness, reproducibility package, simulator or systems experiment, with named deliverables and dependencies.
Technology and ecosystem partnerships
Provider programmes, technical integrations, reference implementations, and co-development around relevant infrastructure.
Open-source pilots
Scoped evaluation or adaptation of a published Skelf project against a clearly defined technical problem.
Published capabilities
Start from evidence.
Our public work is the starting point for every conversation. A proposed engagement should connect to a published research area or product and have a defined technical outcome.
- LLM and agent infrastructure
- Search, retrieval, and local embeddings
- Safe and verifiable computing
- Formal optimisation and decision systems
- Privacy, trust, and edge intelligence
- Robotics and autonomous-systems simulation
Verified company facts
Application-ready identity.
- Legal name
- Skelf Research Limited
- Company number
- SC809174
- Entity
- Private limited company
- Incorporated
- 1 May 2024
- Jurisdiction
- Scotland, United Kingdom
- Team size
- Fewer than 5 people
- Registered office
- 19 Drumcarrow Road, St Andrews, KY16 8SE, Scotland, United Kingdom
- Founder
- Dipankar Sarkar
- Applications
- admin@skelfresearch.com
How an engagement is scoped
Four things we establish first.
Most enquiries fail at scoping rather than at capability, so we try to settle four questions before either side invests time.
- Which published artefact this connects to
- Every engagement starts from something already public — a research pillar, a named product, or an article. If the work has no connection to what we have already built and published, we are probably the wrong lab and will say so quickly.
- What the technical outcome is
- A defined artefact: a benchmark result, an adapter, a reproducible evaluation, a hardened component, a written finding. Open-ended advisory retainers without an artefact do not fit a lab this size; where repeat work makes sense, it is tied to agreed change events.
- What may be published
- It depends on who the work is for. Sponsored research and work packages are published by default, with the sponsor, method, limitations and any conflict disclosed: the sponsor buys the work, not the conclusion, and gets no veto over results. Private investigations are the opposite: confidential unless the client expressly agrees to publication (see procurement). Either way, client data, credentials and commercial context are never published, and any embargo is agreed at the start rather than negotiated after a result exists.
- Who carries the licence obligations
- The portfolio spans MIT, Apache-2.0 and GPL-3.0, and the GPL components carry obligations that matter for redistribution. We will tell you which licence applies to the component you are interested in before a proposal, not after one.
Constraints worth knowing early
What we will not do.
Stating the boundaries saves everyone a call. We do not take sponsored work that requires us to withhold a method or an unfavourable result, because the method is the research output. We do not operate hosted production services, so an engagement that needs a managed SLA needs a different supplier alongside us. We do not claim certifications, framework places, or partner statuses that have not been issued and cannot be verified. And we do not take on work outside the research areas and services where we can show evidence of capability, however well it pays, because capability we cannot evidence is capability we should not sell.
Assurance and certification
Requirements follow the work.
We are willing to complete proportionate training, certification, supplier onboarding, and due diligence for a genuine opportunity. We do not claim a certification, supplier identifier, programme membership, or partner status until it has been issued and can be verified.
Suitability, capacity, security controls, data handling, licensing, and delivery terms are assessed for each proposed engagement.
Make the first message useful
Tell us the problem, evidence, and decision date.
Include the relevant Skelf project or research area, the desired outcome, delivery geography, expected timeline, funding or procurement route, and any mandatory assurance requirements.