Govern your supergraph at scale.

Automate graph protection, enforce domain ownership, and manage deprecations safely so your platform engineers can stop being human routers and start building.

Know exactly who owns what. Without asking anyone.

With the right guardrails in place, developers can move fast without breaking things.

Logical & physical ownership

Entity owners and subgraph owners. Both explicit. Both visible.

Required reviewers

Changes don't merge until the right people approve them.

Discussions on the canvas

Unresolved discussions block the merge. By design.

Traffic-aware deletion

Deprecations that actually work. Data decides when it's safe.

The Problem

At a certain scale, governance stops being a process. It becomes a full-time job.

When your organization grows faster than your tooling, the schema stops reflecting who owns what. Fields get renamed without warning, types get deleted while clients are still querying them, and PRs get merged without the right teams ever seeing them. By the time anyone notices, it may already be in production.

01

No single source of truth for ownership

As the graph grows, it becomes harder to know which team is responsible for which part of the schema.

02

The wrong changes slip through review

Without domain owners in the loop, breaking changes make it to production before anyone catches them.

03

Deprecations without visibility

Marking a field deprecated doesn't guarantee downstream teams know about it or have time to act on it.

Built for scale

The safe path is the default path.

Ownership visible

Ownership is visible in the graph, so there is no guessing who's responsible.

Reviews automatic

Touched subgraphs have their owners added as required reviewers.

Deprecations by data

Traffic data decides when deletion is allowed.

Discussions block merge

Unresolved discussions block the merge.

How It Works

Governance enforced by the system.

That's the difference between governance and guessing.

Logical & physical ownership

Define owners at the entity and subgraph level.

Architects own the logical shape of the schema; teams own the implementation, and both are visible on the canvas.

Every change goes through a proposal.

Hub inspects which subgraphs were touched and automatically adds their owners as required reviewers.

Required approvals

Affected teams must approve before anything merges.

Affected teams are notified and must approve before anything merges.

Anchored to the graph

Comments anchored to specific types and fields.

Open threads block approval, so decisions get made before changes go through, not after.

Traffic-aware

Deprecation and a grace period are required.

Hub uses traffic data to allow or block deletion. No accidental breakage.

Everything your graph needs to stay protected

Ownership, reviews, discussions, deprecations, and access control — all enforced by the system.

Ownership

Entity owners and subgraph owners. Both explicit. Both visible.

In most organizations, someone owns the logical definition of an entity and someone else owns the service that implements it. Hub lets you define both. Assign an architect as the entity owner of User to enforce schema standards. Assign the Payroll team as the owner of the payroll subgraph to control what gets implemented and when.

The "who do I ask?" question gets answered by the graph itself — so platform engineers stop being a human router.

Required Reviewers

Changes don't merge until the right people approve them.

Developers work in isolated branches and submit proposals when ready. Hub inspects which subgraphs were touched, identifies their owners, and adds them as required reviewers automatically.

Nothing merges until every required reviewer approves. That's not a convention. It's enforced.

Proposal · Billing touched
In Review
Schema checks passed
Pass
No breaking changes
Pass
All threads resolved
Pass
Awaiting: Billing Team
Pending
Auto-assigned: Billing · Architecture

Discussions

Unresolved discussions block the merge. By design.

Reviewers can anchor comments to specific types and fields directly on the canvas. Hub treats open threads as CI checks. If a discussion is unresolved, the proposal cannot be approved. Teams have to reach consensus, not just acknowledge a comment and move on.

The conversation is part of the workflow, not separate from it. Open threads block the merge.

Traffic-Aware Deletion

Deprecations that actually work. Data decides when it's safe.

Most deprecation processes rely on trust, but Hub enforces a hard lifecycle. Deprecation is required before deletion. Set a grace period and Hub monitors live client traffic against it. If clients are still querying the field, Hub blocks the deletion and shows exactly which operations are affected.

The decision isn't left to memory or trust. It's left to data.

Workspaces & RBAC

Your org chart. Already in Hub.

Admins get full access. Viewers get read-only. And if you are already a Cosmo user, your existing groups and roles import directly into Hub. No rebuilding your permissions model from scratch.

One place for ownership, reviews, and access. No duplicate setup.

Get Started

Governance that scales with your team, not against it.

When ownership is visible, reviews are automatic, and deprecations are enforced by traffic data, developers can move fast because the guardrails move with them.

WunderGraph Hub — Collaborative, automated governance for the supergraph teams that can't afford schema chaos.