# Shared GPU resources: agreeing laboratory, operator and partner roles

A responsibility matrix for a joint GPU pilot: equipment, funding, configuration changes, acceptance, technical stops and decisions to continue.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/research-pool-governance/
Language: en

A joint GPU project may include an equipment owner, technical operator and funding partner. All want useful server work, but are responsible for different parts. Without straightforward decision ownership, even a small pilot can depend on informal promises.

A responsibility matrix helps prevent this. It describes working interaction without replacing contracts, organisational authority or grant conditions.

## Identify roles, not only people

The owner determines which resource can be offered and which constraints remain. The operator is responsible for agreed technical work. The partner discusses funding a defined stage and the evidence required.

One person can hold several roles without making them identical. Paying operating expenses does not by itself authorise changes to a research environment or control of equipment. Agree these rights separately.

## Map common decisions

A few rows are enough to begin:

| Decision | What to establish |
| --- | --- |
| Select a test window | Who confirms machine availability |
| Change the environment | Who approves changes and restoration |
| Additional expense | Who approves budget before commitment |
| Technical stop | Who stops work and informs others |
| Continue the pilot | Evidence each party requires |

Assign an owner and communication method to each. A heavy management system is unnecessary; the document should help people act rather than complicate a brief experiment.

## Define how plans change

A pilot may reveal the need for a different model, another disk or a longer window. Separate a technical proposal from approval of extra costs. Until agreed, a new option remains a proposal rather than the partner's obligation.

For example, a model launches but longer context needs a different configuration. The operator explains the constraint and alternatives, the owner confirms permitted changes and the partner decides the budget. Expenses should not first become visible in the final report.

## Share completion criteria

Agree sufficient results: measurements, limitations, a recovery check and a change list. Record early-stop conditions and how the machine returns to its primary work.

For grants, consider original agreements. [UKRI](https://www.ukri.org/manage-your-award/meeting-ukri-terms-and-conditions-for-funding/) stresses programme-specific terms, reminding participants to review their documents rather than apply another organisation's matrix automatically.

If an owner is temporarily unavailable, specify what may proceed and what must pause. In a small team, absence must not become silent permission to broaden access, extend the test or increase expenditure.

## Keep shared expense transparent

When several teams use the resource, specify allocation rules. [FinOps Allocation](https://www.finops.org/framework/capabilities/allocation/) provides a useful principle: participants should understand data sources and cost owners. Adapt the procedure to the site.

Discuss them together while keeping each party's responsibility distinct.