Isambard-AI and Dawn AIRR supercomputers: Gateway route

Isambard-AI and Dawn AIRR supercomputers: Gateway route

The Isambard-AI and Dawn Gateway route is one of UKRI’s active compute access mechanisms under the AIRR (Artificial Intelligence Research Resource) programme. Unlike a classic grant, this opportunity is explicitly for computational resources rather than direct funding. It is currently open, and UKRI lists the close date as open – no closing date. For teams in 2026/27 planning, that makes it unusually useful: there is no fixed annual deadline to memorize, but there are recurring operational constraints around batching, start dates, and assessment expectations that affect when you should submit.

If your team is at the stage where you need GPU access to test an idea, compare model versions, prototype an algorithm, or create a realistic demo that can move into a larger AIRR pathway, this is often the right first practical route.

Key details at a glance

What this opportunity is really funding (and what it does not)

This is not a normal R&D grant call with line-item funding, budget envelopes, and a fixed award amount. UKRI publishes this as an open access route for people needing compute cycles. The core value is direct access to high-end GPU compute for AI-related projects. The official guidance states that a successful project can be awarded up to 10,000 GPU hours and that those hours should be used within three months of project start.

A practical way to interpret this:

• This route reduces the barrier to testing and iteration.
• It is designed for early-stage work, prototyping, and feasibility progression.
• It creates a stepping-stone for teams that later apply to larger AIRR opportunities such as larger compute lanes or specialist programmes.

That said, because there is no monetary award, teams should not treat it as a substitute for budgets needed for data acquisition, cloud storage costs outside AIRR access expectations, staffing salary, or specialist consultancy. The route can significantly accelerate scientific and technical progress but does not cover project costs in the way grant funding does.

Why this is a relevant 2026/2027 opportunity

You asked for current, recurring, and forward-looking support-oriented opportunities for the 2026 and 2027 cycle. This route fits that requirement in three ways:

1. It is listed as open with no fixed close date, meaning teams do not need to wait for a one-off annual publication window.
2. It has an active “Gateway” intake model with periodic resource allocation by batching.
3. It explicitly links use of compute resources to broader UK innovation goals and industrial strategy priorities, so teams planning long-window project paths can use successful small-scale pilots as stepping stones into the 2026/27 activity stream.

For many teams, the relevant timing question is no longer when is the deadline, but how fast can you submit a quality-ready packet, and how well aligned is it to AIRR’s scope and batching process.

Who can apply and who should think twice first

The core eligibility criteria are broad but structured. Officially, this route is open to eligible UKRI-remit researchers across academia and industry. The lead applicant must be in a position with a contract longer than the proposed project period.

The route supports a wide range of UK organisations:

• UK registered business of any size with Companies House registration number.
• Research organisations eligible for UKRI funding.
• Charities and non-profits.

There is no per-organisation application cap and no per-researcher limit, with a caveat: each application must be standalone.

This broad access model has real value, but it creates a quality-control challenge. If you are over-applying or sending near-duplicate project concepts, reviewers and the system are likely to penalize clarity and maturity. UKRI specifically notes that this path is not aimed at large consortia, so if your concept relies heavily on broad partnership architecture, test whether a focused sub-team can own a discrete, computable aim.

Good fit

This route is especially strong for:

• teams testing a new model, algorithm, or workflow before a larger deployment
• researchers trying to benchmark methods under real conditions
• interdisciplinary groups where AI engineering is foundational and domain science contributes novel use-cases
• projects with a clear technical plan and measurable outputs.

Not-for-me profiles

It is less strong if:

• your main ask is salary, staffing funding, procurement, or direct grant support
• your project needs a large budget rather than a compute allocation
• your plan requires extensive non-compute resources to produce meaningful outputs but has no near-term computing milestone.

Scope, use cases, and project design expectations

The official guidance lists this route as supporting early experimentation, workflow testing, and novel AI methods. The scope is broad in theme but narrow in form:

• Novel algorithm and software tool development.
• AI-assisted workflows (for example simulation, parameter optimization, or hypothesis generation support).
• AI data collection/curation pipelines.
• Responsible AI work such as bias detection or privacy-aware methods, when tied to clearly defined technical novelty.

To interpret “scope and novelty” correctly, applications should avoid generic statements like “AI is useful” and instead describe a concrete compute-dependent question:

• What exact workload requires H100-style scale or equivalent multi-GPU throughput?
• How will your model complexity or dataset size change because of this access?
• What constitutes success in 8–10 weeks of compute usage?

The page also references policy alignment themes such as modern missions and sectors, including economy, NHS-related innovation, safety, energy, and industrial sectors. These aren’t optional marketing lines; they provide a signal for portfolio fit. A stronger strategy is to connect your compute request to one policy outcome and one measurable technical outcome.

Application package design: what to include, what to avoid

The AIRRPortal application is split into core project sections plus uploads for supporting documentation and assessed questions. UKRI’s key warning here is operational: missing format, missing required documents, or non-compliant submissions can be rejected without review flexibility.

Minimum expectations before submission

• Confirm your team and lead have organisation-level continuity for the project period.
• Ensure each team member uses official organisational email addresses; functional/shared mailbox patterns are discouraged and may create eligibility issues.
• If your team includes industry participants, model support ratios and cost-share logic early.
• Read and prepare according to AIRRPortal guidance before pressing “submit”.

What makes a strong technical submission

Strong teams do three things early:

1. State a constrained workload: “train model family X, compare models A/B/C across dataset Y, run sensitivity experiments Z over 5 days each”.
2. Set realistic compute consumption: show how 10,000 GPUh maps to a credible experiment plan.
3. Set reproducible output goals: include expected artifacts such as benchmark curves, ablation results, model cards, or deployment-ready scripts.

The most common weak submissions fail because they are concept-heavy and execution-light. Since this is a compute route, the committee wants practical execution evidence.

Project finances, ratios, and non-financial compliance details

Because this is resource-only, the language around costs is different. The important detail is that non-academic or industry applications under feasibility studies, industrial research, or experimental development still need to provide eligible cost context and show compliance with Subsidy Control rules where relevant.

The route provides practical percentages for balance and support ratios:

• For feasibility studies/industrial research: up to 70% support for micro/small organisations, 60% for medium, 50% for large.
• For experimental development: up to 45% (micro/small), 35% (medium), 25% (large).

What this means in practice:

• Academic organisations are not subject to the same support-ratio requirements in the same way.
• Industry teams should model whether the compute allocation is materially meaningful relative to the rest of the project budget.
• Since compute is a constrained pool, over-allocating hours to non-critical experiments can weaken your proposal’s expected scientific return.

The page also explicitly says the project can request software development and staff training aligned to objectives. This is a good signal: teams with concrete workforce-upskilling outputs (e.g., pipeline migration, reproducible scripts, team competency gains) often produce stronger technical narratives.

Assessment and allocation mechanics (important for timing)

Unlike fixed-deadline calls, this route allocates through ongoing batching. UKRI DSIT delivery teams review and tier applications, then assign compute until the available budget is exhausted.

From the official guidance:

• Applications are assessed and placed into tiers.
• Top-tier applications receive resources first, with partial randomization and explicit consideration of previous AIRR users.
• Middle-tier can still receive resources, also with partial randomization.
• Unsuccessful applications are not automatically reconsidered in future batches.

This makes timing and quality at first submit important. There is no useful reason to submit an intentionally “minimal” application just to learn the rules; that strategy can lock you out of that batching opportunity entirely.

What “open with no close date” actually means in practice

A lot of teams interpret open/rolling as “take it slow.” In reality, rolling routes reward teams who are ready.

Three practical constraints still matter:

• The AIRRPortal process is still formal and rejection-prone when guidance is missed.
• There are likely finite compute windows; repeated failed cycles can reduce chances in later batches because resources are limited.
• A successful plan has a start-date logic: UKRI can typically honour requested start dates up to about a month out, but allocation may still take time.

A good workflow is:

1. Draft a focused technical scope for 3–8 weeks of GPU usage.
2. Prepare data preprocessing and benchmarking script plan before submission.
3. Submit with complete docs and clean compliance context.
4. If successful, start immediately to meet the 3-month usage window.

Common mistakes that weaken AIRR Gateway applications

1. Treating this as a grant with only scientific objectives
   • This route is compute-first. You must show clearly why compute is the critical bottleneck.
2. Over-ambitious, high-risk scope
   • If you cannot prove 10,000 GPUh supports your milestones, downscope.
3. Unclear cost-ratio logic for industry
   • If your support-ratio narrative is weak, your compliance score is weaker.
4. Weak deliverables
   • “We will improve model quality” is not enough. Define benchmark, baseline, and pass criteria.
5. External links in application content
   • UKRI explicitly says external links can invalidate the submission.
6. Ignoring post-application mechanics
   • Start date management, top-up limitations, and usage window planning must be part of your strategy before submitting.

Practical preparation checklist

Before pressing submit:

• Define the exact compute plan by week and stage.
• Set a realistic experiment graph: baseline → variant A → variant B → ablation.
• Confirm every team member submission identity uses institutional addresses.
• Prepare DSIT-compliant supporting documentation as required.
• Include internal milestone review points within the 3-month access window.
• Keep a compliance file containing:
  • subsidy questions answered
  • organisational legal status
  • project cost rationale (where applicable)
  • and internal contact responsibilities.

FAQ

Is this route suitable for non-UK organizations?

The route is UK-led in structure and is aimed at UKRI-eligible research actors, UK organisations, and UK-based applicants through eligible channels. You should treat international collaboration as possible only within the framework UKRI provides for TR&I and related compliance requirements.

Can we submit multiple applications from one team?

Yes, there is no hard limit on applications from one organisation or one researcher, but each application must be standalone. Duplicate packaging without clear differentiation usually dilutes internal review quality.

What is the expected value of “top-up policy”?

The route indicates a one-off top-up of 50% may be requested in a narrow set of circumstances (after substantial usage and sufficient remaining project time). This should be used as a contingency mechanism, not a planning baseline.

Does this help for 2026/2027 planning?

Yes. Because there is no fixed close date and assessment is rolling/batched, this can support multi-quarter planning. But because unsuccessful applications are not automatically reconsidered, submission quality at first round is critical.

Is there any monetary award?

No. The opportunity is explicit: resources only, no funding provided.

Official links and next steps

Use official sources only:

• https://www.ukri.org/opportunity/access-to-isambard-ai-and-dawn-airr-supercomputers-gateway-route/
• https://portal-airr.isambard.ac.uk/
• https://www.ukri.org/opportunity/access-to-isambard-ai-and-dawn-airr-supercomputers-gateway-route/ (same opportunity landing page; open in a browser to confirm latest updates)

If you want to move quickly, prepare a one-page compute experiment plan before opening AIRRPortal. Treat this as a contract with a finite compute envelope, not a broad funding application. Teams that submit a tight plan with measurable compute outcomes usually get clearer outcomes than teams that submit broad narratives with weak execution logic.