GCRI · Foundry
Project workstations
A project workstation holds a team’s question, data, models, agents and decisions together for as long as the work lasts. The main risk is context that outlives its purpose: access granted for one task persists, data stays on terms nobody rechecks, and an output leaves before review. This page sets out how permission and context drift develop, how they are measured, and what project owners and data owners need to keep a workstation inside its mandate.
Project workstations on the record.
Project workstations: how the risk develops.
Project onboarding, persistent context and permissions. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Permission drift
Access is granted for a task, a role or a deadline and then outlives it. People move teams, contractors finish, agents are added for one analysis and kept. Each grant was reasonable when made; together they open more than any current purpose justifies.
Context accumulates
Notes, intermediate files, cached extracts and agent memory pile up over months. Persistent context is what makes a workstation useful, and it is also where restricted data ends up in places its owner never approved, outside the record of what entered the project.
Terms change underneath
A data owner narrows a licence, withdraws a permitted purpose or reclassifies a dataset. Unless the change reaches every copy, derived table and model trained on the data, the project keeps working on terms that no longer hold.
Outputs leave the boundary
An unreviewed figure is pasted into a briefing, a draft map is shared by link, a model is exported. Once outside, an output carries the authority of the project without its caveats, and recalling it is slow or impossible.
Workspace and job console.
The screen a team would use to follow this subject: its measures, states and decisions. Names are examples and values are illustrative.
Workspace and job console
Project workstations · Project space 12 · Cluster east
- Jobs running11Active
- Queue wait, p503minNormal
- Runs today81023
- Quota used, % this month79Watch
Jobs
| J-19648 | Flood model ensemble | Project owner | 00:46:12 | Running |
| J-32079 | Tile render, zoom 0 to 12 | GIS workspace | 00:04:40 | Running |
| J-63588 | Evidence export | Model steward | 00:00:39 | Done |
| J-74223 | Agent tool call batch | Agent sandbox | 00:01:41 | Policy block |
Policy events
- 10:40GateAgent call needs human approval
- 10:53InfoRun record sealed
- 11:21WarnQuota at 80 pct for project
Workstations are designed to let national teams work across domains in one place.
- WaterIn practiceA basin team works with water, energy and farm data together.What a reader can checkData access recorded
- HealthIn practiceA health team reads power and water dependencies.What a reader can checkPermissions recorded
- BiodiversityIn practiceAn environment team builds ecosystem accounts.What a reader can checkLineage recorded
Readiness is reported in the Foundry Build and Readiness series. Descriptions state design purpose; information and enquiries are open today.
- Requirements from national teams.
- Usability feedback.
How project workstations 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 project workstations, 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
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 |
|---|---|---|---|---|
| Access grants past their review date | count per project | weekly | Access-control records | OBSERVED |
| Time from role change to access revocation | hours | per event | Identity and access logs | OBSERVED |
| Data sources with current owner terms recorded | proportion of registered sources | monthly | Source register | DECLARED |
| Requests failed closed at the policy gate | count per period | daily | Policy decision logs | OBSERVED |
| Outputs released with a recorded review | proportion of released outputs | per release | Review and release records | OBSERVED |
| Stored artefacts without a declared data class | count | weekly | Storage inventory scan | OBSERVED |
| Projects past closeout with live access | count | monthly | Project register | OBSERVED |
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 |
|---|---|---|
| ORCID registry | Persistent identifiers for researchers, used to tie actions to verified people | CC0 for public data |
| Research Organization Registry (ROR) | Persistent identifiers for the institutions that own projects and data | CC0 |
| GA4GH Data Use Ontology | Machine-readable data-use conditions that can travel with a dataset | Free and open, attribution |
| RDA DMP Common Standard | A machine-actionable data management plan covering purpose, storage, retention and sharing | Free and open, attribution |
| SPDX License List | Standard identifiers for the licences recorded against each source | CC0 |
| Creative Commons and Open Data Commons licence texts | The terms behind most open datasets a project draws on | Public licence texts |
| National data protection authority guidance | Lawful bases, transfer rules and breach notification duties for personal data | Public records, per authority |
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 |
|---|---|---|
| Project owners | Who may act in the project, on which systems, and when it closes | Current grants against roles; grants past review; closeout status |
| Data owners | Whether their data may enter, for which purpose, and whether it may train models or be published | Source register with terms; copies and derived products traced to the source |
| Data protection authorities and officers | Whether personal data processing in the project has a lawful basis and adequate safeguards | Data classes present, processing locations, access logs, retention schedule |
| Review leads | Whether an output is ready to leave the project | Lineage of the output, its evidence labels and the review record |
Outputs this topic produces
- Project charter with owner, purpose, data terms, openness profile and closeout point
- Access reviews listing grants past their date
- Source register with current owner terms per dataset
- Release log linking each output to its review
What practitioners ask about project environments.
- Who owns the question, and who is accountable for what the project produces?
- Which data may enter, on whose terms, and for which purpose?
- How is context kept across months of work without becoming an unmanaged archive?
- How do permissions follow people, roles and agents as they change?
- What happens to data, outputs and access when the project closes?
Scope first, then context, then permission.
A project is defined before it is opened: the question and the institution that owns it, an accountable owner, the people and agents who may act, the data sources with the owner’s terms for each, the systems it may reach, the deployment profile it runs on, an openness profile from open through consortium-shared and confidential to restricted, a review plan and a closeout point.
Persistent context is the main source of value and the main source of risk. Workstations are designed to share a common set of rooms, such as Station, Mission, Maps, Data, Builder, Reports and Knowledge, so that work looks the same across systems. What a person sees in each room depends on the project’s permissions, not on the room. Permission drift, where access granted for one purpose outlives that purpose, is a well-documented failure in shared research environments; the design answers it by evaluating each request, in the NXS-NSF (trust, authorisation and assurance) Sovereignty Framework, against identity, mandate, purpose and data class, and by failing closed when no explicit decision exists.
How it is engineered, and where the limits are.
Verified and delegated
Identity assurance and recorded delegation, so that an action can always be traced to a person or an accountable agent.
Attribute-based decisions
Access rules that combine role, purpose and data class, so that one sign-in does not open everything a person has ever been granted.
Receipts
Each consequential action produces a receipt that the project owner can review.
Limits: policy engines are only as good as the policies written into them, and receipts show what happened, not whether it was wise. Project reviews remain a human responsibility.
How it is studied, and what the methods cannot say.
- 01Systems engineeringCanonical system inventory · Contract-first interfaces · Requirements traced to evidenceApplied here
- 02Software and safety-critical systems engineeringFail-closed policy gates · Build provenance and bills of materials · Assurance casesApplied here
- 03Data engineering, interoperability and stewardshipValidation at the ingest boundary · Frozen data cuts for reproducible productsApplied here
- 04Artificial intelligence and machine learningEarth observation models with spatial validation · Model cards and promotion recordsApplied 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.
What is permission drift?
Does signing in open everything a person has been granted?
What happens when a project closes?
Can a workstation hold personal data?
Can I open a workstation now?
Does the openness profile affect results?
What happens at closeout?
Can a project span several countries?
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.