Governance¶
Vishwanath Grid is the work of an academic federation, and it should be run like one. This page sets out how the project is governed and what each partner can expect to see in public.
If you are landing on this page first, the short version: Vishwanath Grid is a research-computing cluster that several Indian universities run together. The pilot site is live at MIT-WPU Pune; everything in the software stack is open-source.
How decisions are made today¶
In Phase 0 the project is operated by the research-computing group at the MIT World Peace University, Pune, under the direction of the founding faculty. Day-to-day operational decisions — what software to run, how to schedule jobs, when to do maintenance — sit with this group.
That is the right structure for the pilot. It is not the right structure for a multi-university federation, and it is not the structure we intend to keep.
How decisions will be made in Phase 1 onward¶
Once the federation includes two or more partner universities, the project moves to a written governance structure with three layers.
1. Partner advisory committee¶
One representative per partner university. Sets technical and operational policy: queue rules, software-stack selection, hardware-refresh timing, acceptable-use enforcement, capacity sharing.
The committee meets quarterly. Decisions need a simple majority; on items that affect a specific partner's hardware, that partner holds a veto.
2. Operations team¶
The engineers and system administrators who actually run the cluster — one or two from each partner site, plus the research-computing group at MIT-WPU during the bootstrapping phase. The operations team is accountable to the partner advisory committee.
3. Foundation board¶
A formal academic board with representatives from partner universities and external advisors. Sets long-horizon strategy: which universities to add, how to evaluate funding offers, how the federation relates to national HPC bodies. The board meets twice a year.
This three-layer structure is conventional for academic federations — it mirrors how international research collaborations like the Worldwide LHC Computing Grid and the Open Science Grid are organised, at our (much smaller) scale.
Memoranda of understanding¶
Every partner signs a short written agreement before contributing hardware to the federation. The agreement covers, at minimum:
- Contribution. What hardware the partner provides and where it physically sits.
- Access. Which researchers at the partner site get access, and how their accounts are provisioned.
- Acceptable use. Common-sense restrictions: no commercial workloads, no cryptocurrency mining, no data subject to export controls without prior review.
- Resource accounting. What numbers each partner gets back — per-user, per-project, per-month.
- Exit. How a partner removes their hardware and people from the federation cleanly. No vendor-style lock-in; a partner can leave on three months' notice.
The current template is held by the operations team; copies are shared with prospective partners during onboarding conversations.
Transparency¶
Every partner sees:
- Who ran what, where. Per-job accounting visible to the partner site that owns the hardware.
- Aggregate utilisation. A public Grafana dashboard with cluster-wide summary metrics, refreshed on a short cadence.
- Issue tracker. Forgejo issues is the public record of bugs, feature requests, and operational incidents.
We intend to publish a brief annual report beginning with the end of Phase 0 — covering uptime, total compute-hours served, research outputs that touched the cluster, and a public summary of finances. The first report will appear once Phase 0 has a full year of operations behind it.
Acceptable use¶
The current acceptable-use policy in summary:
| Allowed | Not allowed |
|---|---|
| Research workloads connected to a partner-site research group | Commercial workloads |
| Coursework and student projects at partner sites | Cryptocurrency mining |
| Teaching and reproducibility of public research | Workloads attempting to circumvent identity controls |
| Open-source development that benefits the cluster itself | Storing personal data without an explicit research justification |
A full written policy is in preparation as part of the Phase 1 governance formalisation. Until that lands, anything not obviously in one column should be raised with the operations team.
Reporting a concern¶
If you believe the cluster is being misused, or you have a governance concern that the operations team has not addressed, the escalation path is the general contact address. Mark the subject governance; the message routes to the founding faculty and (once formed) the partner advisory committee.
We treat governance reports the same way a serious academic institution treats them — promptly, in writing, and with the reporter's confidentiality protected by default.