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.
Protect Your GraphHubGovern at Scale
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.
Explore platform01
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.
Main is read-only
Every change goes through a proposal.
Hub inspects which subgraphs were touched and automatically adds their owners as required reviewers.
Protect Your GraphRequired approvals
Affected teams must approve before anything merges.
Affected teams are notified and must approve before anything merges.
Protect Your GraphAnchored to the graph
Comments anchored to specific types and fields.
Open threads block approval, so decisions get made before changes go through, not after.
Protect Your GraphTraffic-aware
Deprecation and a grace period are required.
Hub uses traffic data to allow or block deletion. No accidental breakage.
Protect Your GraphEverything 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.
Ownership Map
Synced
User EntityArchitecture Team
Payroll SubgraphPayroll Team
Billing SubgraphBilling Team
Cosmo user groups sync directly
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 touchedIn Review
Schema checks passed
PassNo breaking changes
PassAll threads resolved
PassAwaiting: Billing Team
PendingAuto-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.
Proposal Checks
Required approvalsPassed
1 open discussionBlocked
Open discussion = merge blocked
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.
Deletion Checkuser.legacyId
Traffic detected on fieldBlocked
Deprecated < 14 daysBlocked
14+ days, zero trafficAllowed
Grace period: 30 days
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.
Workspace Roles
AdminFull access
ViewerRead-only
Cosmo groups import directly
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.
Product
Resources
Related Projects
Legal
HIPAA Compliant© 2026 WunderGraph, Inc. All rights reserved.