Every organization has two versions of itself. The org chart says who is supposed to hold authority. The daily record of work shows who people actually defer to. Almost nobody gets to see the second version.
We built a way to see it. We pointed the UpTrust engine at Kubernetes, one of the largest engineering efforts in the world, and computed both versions from public records. This article shows what came back, and how to check every number yourself.
Why Kubernetes
Kubernetes is a real organization with real departments. Work is organized into Special Interest Groups, or SIGs: SIG Node, SIG Storage, SIG API Machinery, and about twenty more. Each SIG has official leadership, chairs and tech leads, named in a public file called sigs.yaml. That file is the org chart.
Authority there leaves a paper trail. A change only merges after named people sign off, and the sign-offs are public comments: /approve and /lgtm. Who defers to whom is a thing you can count.
Both records are public and free to download. That makes Kubernetes the rare organization where an outsider can measure the gap between stated authority and revealed authority, and where every reader can check the result against the source.
What we measured
- Stated authority: the chairs and tech leads named in sigs.yaml. 24 SIGs, 116 named seats.
- Revealed authority: contributors ranked by how many of a SIG's pull requests they approved during the study window. In the Kubernetes flow a change merges when an approver signs off, so deference to a sign-off is what authority means in practice.
The corpus covers October 2023 through May 2024: 138 repositories, 4,570 contributors, and 17,797 approval acts after filtering bots and dropping retracted approvals. From those acts the engine derived 5,768 person-to-person trust edges.
One side result raised our confidence in the data. When we asked the engine to find communities from behavior alone, it found eight, and they track real Kubernetes structure: core maintainers, SIG Docs, Cluster API, test infrastructure, Autoscaling, Storage, Gateway API and networking, and Kubespray. Nobody told it about SIGs. It recovered them from who approves whom.

The org chart, SIG by SIG
For each SIG we put the official roster next to the top ten approvers of that SIG's pull requests. "PRs approved" counts distinct pull requests carrying the SIG's label. "Trust mass" is that person's standing in the full trust graph our engine computed, shown as a second reading. The ranking itself is a raw count off the public stream and does not depend on our model.
SIG Node
The org chart names five people: chairs SergeyKanzhelev, haircommander, and mrunalp, and tech leads dchen1107, derekwaynecarr, and mrunalp again.
| Gatekeeper | PRs approved | Trust mass | On the roster? |
|---|---|---|---|
| dims | 170 | 10.6 | |
| bart0sh | 88 | 4.9 | |
| liggitt | 86 | 4.0 | |
| haircommander | 51 | 3.1 | chair |
| kannon92 | 46 | 11.1 | |
| pacoxu | 36 | 8.4 | |
| aojea | 26 | 10.3 | |
| klueska | 24 | 0.9 | |
| jsafrane | 23 | 3.9 | |
| thockin | 22 | 4.7 |
One of the five named people (haircommander) is among the top gatekeepers. dchen1107, a named tech lead, recorded 16 approvals, below the top ten. SergeyKanzhelev, mrunalp, and derekwaynecarr do not appear at all. The stream is led by dims, bart0sh, liggitt, kannon92, and pacoxu. None of them are on the Node roster.
SIG API Machinery
The org chart names chairs deads2k and fedebongio, with tech leads deads2k, jpbetz, and sttts.
| Gatekeeper | PRs approved | Trust mass | On the roster? |
|---|---|---|---|
| liggitt | 194 | 4.0 | |
| dims | 100 | 10.6 | |
| jpbetz | 91 | 3.9 | tech lead |
| deads2k | 78 | 1.5 | chair + tech lead |
| wojtek-t | 72 | 3.2 | |
| thockin | 33 | 4.7 | |
| cici37 | 29 | 4.1 | |
| aojea | 27 | 10.3 | |
| pacoxu | 23 | 8.4 | |
| sttts | 21 | 2.3 | tech lead |
Here the org chart holds up well at the tech lead level: jpbetz, deads2k, and sttts all rank high. But the busiest gatekeeper by a wide margin is liggitt, with 194 approvals and no formal API Machinery title, and chair fedebongio does not appear in the top ten.
SIG Storage
The org chart names chairs saad-ali and xing-yang, with tech leads jsafrane and msau42.
| Gatekeeper | PRs approved | Trust mass | On the roster? |
|---|---|---|---|
| jsafrane | 65 | 3.9 | tech lead |
| dims | 62 | 10.6 | |
| liggitt | 50 | 4.0 | |
| xing-yang | 44 | 1.3 | chair |
| msau42 | 27 | 1.1 | tech lead |
| bart0sh | 16 | 4.9 | |
| gnufied | 14 | 0.9 | |
| thockin | 13 | 4.7 | |
| carlory | 13 | 11.5 | |
| tengqm | 9 | 4.2 |
Three of the four named leaders show up: jsafrane, xing-yang, and msau42. The roster tracks reality better here than for Node. Still, chair saad-ali is absent from the top ten, and the cross-project reviewers dims and liggitt outrank two of the four named leaders.
The pattern
- A small set of cross-cutting authorities carries every SIG. dims (Davanum Srinivas) and liggitt (Jordan Liggitt) are top-three gatekeepers in Node, API Machinery, and Storage, and they appear on none of those rosters. Both hold seats elsewhere (dims chairs SIG Architecture, liggitt is a SIG Auth tech lead), so the project clearly knows what it has in them. The problem is structural: a per-department chart has no box for authority whose scope is the whole project. The revealed graph surfaces it immediately. And the three SIGs above are not a lucky pick: widening to every SIG with enough labeled traffic (19 of 24), dims is a top-three gatekeeper in 18 of them, liggitt in 11, and in 13 of the 19 the single busiest gatekeeper is not on that SIG's roster.
- The formal roster is real signal. Most named tech leads show up as top gatekeepers: jpbetz, sttts, jsafrane, msau42, xing-yang. Across all 19 SIGs, 41 percent of named seats rank in their SIG's top ten approvers, and 77 percent appear somewhere in its approval ranking. The org chart is incomplete more than it is wrong.
- Several chairs are nearly absent from the approval stream. Chair is a governance and coordination role, and day-to-day merge authority clearly lives elsewhere. Every organization has gaps like this. Almost none can see them.

What this does not say
- The window is October 2023 through May 2024, set by where the public archive is dense. Someone active mostly outside that window reads as absent here. Within the window the pattern is stable: split it into independent halves and dims and liggitt are top-four gatekeepers of all three SIGs in both halves.
- Approval counts measure merge authority, which is one kind of authority. Chairs do real work (roadmaps, meetings, escalations) that leaves no trace in this stream.
- SIG attribution comes from labels applied by the project's own automation. About 38 percent of approval acts carry a SIG label: enough to rank, but a sample rather than a census.
- A retracted approval (an /approve cancel or /lgtm cancel) is dropped, and we treat it as a retraction only. No distrust is inferred from anything in this corpus.
- Nothing here is a judgment of any person. Every number is a public act these contributors performed in the open, and the pattern the numbers reveal, a few people quietly carrying a huge review load across departments, reads as a credit to them.
Check our work
Every number traces to two public records: the GitHub event archive and the Kubernetes community's sigs.yaml. You can reproduce the core ranking with one query and no account. Open play.clickhouse.com and run this:
SELECT
actor_login AS gatekeeper,
uniqExact((repo_name, number)) AS prs_approved
FROM github_events
WHERE event_type = 'IssueCommentEvent'
AND (repo_name LIKE 'kubernetes/%' OR repo_name LIKE 'kubernetes-sigs/%')
AND created_at >= '2023-10-01' AND created_at < '2024-06-01'
AND actor_login NOT LIKE '%[bot]%'
AND actor_login NOT LIKE '%-bot'
AND actor_login NOT LIKE '%-robot'
AND has(labels, 'sig/node')
AND (
(match(body, '(?m)^/approve(\\s|$)') AND NOT match(body, '(?m)^/approve\\s+cancel'))
OR (match(body, '(?m)^/lgtm(\\s|$)') AND NOT match(body, '(?m)^/lgtm\\s+cancel'))
)
GROUP BY gatekeeper
ORDER BY prs_approved DESC
LIMIT 10That returns the SIG Node table above, exactly. Swap sig/node for sig/api-machinery, sig/storage, or any other SIG label to see the rest. The roster side is a single public file in the kubernetes/community repository.
Why we built this
UpTrust builds trust graphs. Our engine reads records of who endorses whom (follows, reviews, stars, approvals) and computes personal, explainable rankings, along with structure like communities and bridges. We have run it over research citations, open source stars, Wikipedia editor thanks, and consumer reviews. Kubernetes is the first corpus where the same engine could compare an organization's stated structure with its revealed one, because Kubernetes publishes both.
The same comparison works anywhere there is a record of people evaluating each other's work: code review, document comments, ticket handoffs. For a company that means seeing, privately and on its own systems, what this article shows in public: where authority actually lives, which people entire departments defer to, and which load-bearing reviewers no chart names. We run pilots with aggregate views first and governance controls from day one. If you want to see the second version of your organization, talk to us.