Governance
WAYSCloud Impact operates as a governance program with explicit isolation, an approval process, defined limitations, and recorded transparency.
Isolation model
No shared runtime
Impact workloads never share runtime with customer environments.
No shared storage
Impact data lives in a separate storage boundary with its own keys.
No customer access path
Impact workloads have no route to production systems or customer-managed infrastructure.
Separate identity boundary
Impact identities cannot assume customer identities, and vice versa.
Network isolation at platform level
Enforced by the platform — not by application logic, which can fail.
Approval process
-
01
Organization vetting
Institutional standing, EU/EEA registration via EUID, mandate, and prior research output.
-
02
Workload review
What is being computed, on what data, with what expected output.
-
03
Governance committee approval
Final decision rests with a committee whose composition is documented and rotated.
Limitations
Preemptible
Production traffic always has priority. Workloads can be paused mid-run.
Pool-bounded
Allocations cannot grow during a grant period — the pool changes month to month.
Time-bounded
Grants have explicit end dates. Renewal goes through the same review.
Revocable at any time
Governance or production demand can pause or terminate workloads on no notice.
Owner-checkpointed
Workload owners are responsible for checkpointing and restart strategy.
Transparency
Allocation grants are recorded. Aggregate program usage — sector breakdown, total contributed capacity, number of active grants — is published periodically and openly.
Individual organizations and projects are disclosed only with their consent. The composition of the governance committee, its decision criteria, and material program changes are documented on this site.
Governance is not a one-time review. It is an ongoing condition of the grant.