GCRI · Foundry
Usage metering, quotas and cost transparency
Shared technical environments run into trouble when nobody can see what was used, by whom and on whose account, or when budget pressure starts to shape which results are kept. This page sets out how metering error and cost pressure develop and spread into scientific and institutional decisions, how use is designed to be metered in declared service units against quotas and credits, and the rule that no charge applies unless it was disclosed in writing first.
Usage metering, quotas and cost transparency on the record.
Usage metering, quotas and cost transparency: how the risk develops.
Service units, credits, quotas and tenant charges. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Misattribution
Shared services, untagged resources and long-running jobs make it hard to tell which project used what. Costs land on the wrong account, and the project that caused them receives no signal to change.
Cost shapes science
When budgets are tight, ensembles shrink, validation runs are skipped and failed results go unreproduced. Metering kept independent of scientific state, and review decisions kept independent of cost, protect results from that pressure.
Quota cliffs
A hard limit reached mid-run can kill work in progress or force a rushed restart. Pausing new workloads instead of stopping running ones, with warnings before the limit, keeps quotas from destroying evidence.
Contributed and paid capacity blur
Capacity offered by one institution and capacity paid for by another can be mixed on a statement. Once blurred, nobody can show who funded a result, which matters for audit, ownership and conflicts of interest.
How usage metering, quotas and cost transparency is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
Model, equations and assumptions
The model structure used for usage metering, quotas and cost transparency, the assumptions it makes and how each is tested.
Ri = f(Hi, Ei, Vi, Ci)hazard, exposure, vulnerability and coping capacityEAL = ∑k pk · Lkover events k with annual probability pkxt+1 = A xt + B ut + εtA carries the couplings, u the shock, ε the error| Assumption | Why it is made | How it is tested |
|---|---|---|
| Hazard and exposure are independent within an event | Keeps the loss integral tractable | Compare with a copula fit on joint records |
| Couplings are linear near the operating point | Lets shocks propagate through A | Perturb beyond the linear range and compare |
| Vulnerability curves transfer between places | Local curves are rarely available | Validate against observed losses where they exist |
- Inputs
- versioned datasets with provenance
- Outputs
- distributions, never single numbers
- Code
- released with the model card and tests
- Reproduction
- same data, code, environment and seed
Usage records are designed to show what each domain’s work consumed.
- WaterIn practiceA basin study’s compute and storage use is recorded.What a reader can checkUsage record
- HealthIn practiceUsage is recorded without exposing data contents.What a reader can checkPrivacy of records
- BiodiversityIn practiceLarge Earth-observation workloads are recorded.What a reader can checkStorage and transfer
Usage reporting is designed for the Foundry Build and Readiness series. No fee is stated on these pages; any charge requires an issuer, currency, effective date and schedule on record, and the Global Centre for Risk and Innovation (GCRI Canada) operates the service on a not-for-profit basis.
- Questions about usage records.
- Proposals for transparent reporting.
What is measured, and how well.
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Metered use attributed to a project | proportion of total use | monthly | Metering records | OBSERVED |
| Use by service unit | declared service units | daily | Metering records | OBSERVED |
| Quota consumption | proportion of allocation | daily | Quota service | OBSERVED |
| Workloads paused at quota | count | per period | Scheduler records | OBSERVED |
| Statement discrepancies raised | count per statement | per billing period | Dispute records | REPORTED |
| Charges with prior written disclosure | proportion of charges | per billing period | Agreements and fee schedules | Published statistics |
| Credits issued and consumed | service units | monthly | Credit ledger | Published statistics |
Where the evidence comes from.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| FinOps Open Cost and Usage Specification (FOCUS) | A common schema for cloud cost and usage data across providers | Open specification |
| Public cloud price lists and billing exports | Published unit prices and detailed usage records from providers | Provider terms |
| Software Carbon Intensity specification (ISO/IEC 21031) | A method for rating the carbon intensity of software per functional unit | Published standard, purchase from ISO |
| Ember electricity data | Carbon intensity of grid electricity by country for emissions attribution | CC BY 4.0 |
| Institutional agreements and fee schedules | Units, quotas, credits and any fees agreed in writing | By agreement with each institution |
| Scheduler accounting records | Per-job resource use by person, project and queue | Operator records, shared with project owners |
Who decides, and what the evidence serves.
Foundry prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Finance officers of contracting institutions | Whether a statement matches the agreement and the metered use | Metering by project against declared units and disclosed fees |
| Project owners | How to spend an allocation across production runs, validation and storage | Quota consumption, forecast use, workloads paused |
| Programme owners and funders | Whether a programme’s compute budget is adequate to validate its models properly | Use by activity; validation runs skipped or deferred |
| Audit and oversight bodies | Whether charges were disclosed and attributed correctly | Disclosure records, dispute outcomes, contributed capacity kept separate |
Outputs this topic produces
- Service unit definitions agreed before work starts
- Statements of metered use against agreed units, by programme and project
- Quota and credit ledgers kept apart from contributed capacity
- Dispute records reviewed by someone outside the contested decision
What project owners and finance teams ask.
- Which units are we charged in, and how are they measured?
- Can we see use attributed to each project and workload?
- How are quotas set, and what happens when one is reached?
- Can cost considerations ever change a scientific result?
- How is capacity contributed by one institution kept distinct from capacity another has paid for?
Metering, quotas and separation.
Use is designed to be recorded and attributed to the programme and project that incurred it. Compute, storage and system use are measured in service units defined in the institutional agreement before work starts, and quotas set per project limit consumption to what was agreed. Credits, where an agreement provides for them, are an accounting allocation against those units, not money and not a right to restricted data.
Usage is metered independently of scientific state. Budget pressure must not change whether a result is reproduced or accepted, so a reviewer’s decision on a result never depends on its cost, and reaching a quota pauses new workloads rather than deleting work in progress. Statements are designed to show metered use against the agreed units, so that a project owner can check them against the agreement without relying on the operator’s summary.
What is and is not part of the service.
- 01
Agreement
Use is governed by an institutional agreement with the contracting party, GCRI Canada, or as that agreement provides.
- 02
Disclosure
Any fee appears only with the issuer, currency, effective date and applicable schedule recorded in writing.
- 03
Contributed capacity
Infrastructure offered by others never appears on a statement as if it were consumed or paid for.
- 04
Rails
NXS-RLS (participants, agreements and handoffs) records instructions and receipts between institutions; it never moves funds itself.
- 05
Disputes
A question about a charge is reviewed by someone not responsible for the contested decision.
Ordinary participation in working groups and learning carries no fee, and correction and integrity routes are never paywalled.
How it is studied, and what the methods cannot say.
- 01Systems engineeringCanonical system inventory · Contract-first interfaces · Requirements traced to evidenceApplied here
- 02High-performance, cloud and edge computingEnsemble scheduling across tiers · Federated execution next to the dataApplied here
- 03Data engineering, interoperability and stewardshipValidation at the ingest boundary · Frozen data cuts for reproducible productsApplied here
- 04Software and safety-critical systems engineeringFail-closed policy gates · Build provenance and bills of materials · Assurance casesApplied here
Where this page’s references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
How much does Foundry cost?
What is a service unit?
Can cost ever change a scientific result?
Are credits money?
Can I see my project’s usage?
Who do I ask about terms?
Contribute evidence from this page.
Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.
