Rules
Part of Professional networks: how to judge profile claims
Building a professional networks list from a written inclusion rule
Professional networks list built from a written inclusion rule: five observable tests, the borderline cases decided in advance, and an omission table.
Every list has a rule that decides what is on it, and most lists never write that rule down. That is why they rot.
Six months after publication, the editor has changed. One service added a job board; another dropped its real-name requirement. Nobody can say whether either still belongs. The list keeps its old shape by inertia and gradually stops meaning anything.
This page is about the rule itself: how to write an admission test for professional networks that a stranger could apply to a service you have never seen, and get the same answer you would.
What to take away
- An inclusion rule is a short set of yes-or-no tests on observable properties, not a feeling about what "professional" means.
- The borderline cases are the rule. Decide them first and the easy cases follow.
- Record every rejection with the test it failed. A list of what was left out is half the value of a list of what was kept.
Start with what the reader will do with the list
A list of professional networks assembled for a job seeker, one assembled for a recruiter, and one assembled for someone researching a company's employees are three different lists with three different rules. A service that is essential to one is noise to the others.
The first line of the rule is the reader's task. Everything below assumes the commonest one: a person deciding where to keep a work identity others will look up.
If your reader is different, the tests change. Say so at the top of the page, rather than let the reader find out halfway down.
The tests, in the order to apply them
Apply these to a candidate service in sequence and stop at the first failure. Each is answerable from the service's own public description and from creating an account, without trusting anyone's characterisation of it.
Five Tests in Order
Work identity is the unit?
Membership is open?
Social network, not professional
| Test | Pass when | Fail when |
|---|---|---|
| Work identity is the unit | The profile is built around occupation, employer, and history | The profile is built around interests, media, or a pseudonymous handle |
| Membership is open | Anyone in the stated occupation or region can join under the published terms | Access requires an employer, an invitation, or a purchase |
| The graph is between people | Members connect to or follow other members, forming a social graph | Members only interact with listings, employers, or a marketplace |
| The profile persists | The record stays visible when the member is not actively seeking anything | The record exists only for the duration of an application or a contract |
| Discovery is public or semi-public | A non-connected member can find and read at least part of a profile | Profiles are visible only to a hiring counterparty |
A service that passes all five qualifies. A service that fails the first is a social network with a work-related audience, a different list.
A service that fails the second is an enterprise tool and belongs in a workplace software catalog.
The third separates networks from job boards, the fourth separates them from application systems, and the fifth separates them from private talent databases.
The borderline cases, decided
Write these down before you look at any candidate, because they are where two editors disagree.
Freelance marketplaces. Profiles are work-based and persistent, but the graph runs between workers and buyers, not among workers. Under the tests above they fail the third and are out. If your reader is a freelancer, that is the wrong answer, and you should be writing a different list with a different third test.
Alumni networks. Membership is closed by definition. Out under the second test, noted in the omissions with the reason, and worth a pointer to wherever you catalog closed networks.
Industry-specific communities. Where the profile is occupational and the graph is member to member, they pass, even if small. Size is not a test, and for the reasons set out in the notes on platform figures, it could not be a reliable one even if you wanted it. A specialist network with a few hundred active members is a professional network; the notes on small networks cover how to tell whether one is still alive.
General networks with a professional mode. A service that lets you mark a profile as a business or creator account has not become a professional network. The test is what the profile is built around by default, not what a setting can approximate.
Portfolio and publication hosts. Persistent, public, work-based, but the connection between members is often incidental to the display of work. Decide by the third test honestly: if members follow and message each other as a primary activity, in; if the follow is a bookmark, out. A portfolio host that adds member-to-member messaging changes its structure, and a platform comparisons pass would catch that shift.
Regional services. Pass or fail on the same tests. A network that only operates in one language or one country still belongs if the reader might plausibly use it. Note the coverage in the entry rather than excluding for it.
The omission note
Every entry you reject goes in a second table, with the test it failed and the date you applied it. This is not bureaucracy. It lets a reader who expected to find a particular service understand why it is missing, and it lets the next editor re-run your decision when the service changes.
Omission Table Columns
- Candidateservice as it described itself
- Test failedfirst test not passed
- Evidencepage or account behavior
- Checkeddate of decision
- Would re-enter ifsingle change
The last column is the useful one. A marketplace that added member-to-member connection would pass. A closed network that opened registration would pass. Writing the condition down means a future check takes one minute instead of a fresh evaluation.
Sorting is not ranking
Once the rule has produced a set, the set needs an order. Any order will be read as a judgment. Choose a key that carries none: alphabetical, date of your check, or grouping by which tests were the hardest calls.
The anatomy of a ranked list sets out what happens when a key is chosen for other reasons. State the key at the top of the list.
If you want to put a particular service first because it is the one people expect, that is a reader-expectation problem. The fix is a sentence explaining that the list is unordered, not a quiet reordering.
What this rule cannot do
It cannot tell you which network is best, because it deliberately measures nothing that varies by quality. It cannot tell you which one your peers use, since that is a fact about your peers.
It cannot verify what a service says about itself, because the tests measure what a service is, not what it claims to achieve. To read a specific profile on any, the professional networks overview covers the verification ladder.
Common questions
Should the rule be stricter, so the list is shorter?
Only if the shorter list serves the reader better. A rule tightened to exclude everything unfamiliar is selection bias with a procedure attached, and it reproduces the editor's habits. Tighten by adding a test with an observable answer, never by adding a judgment call.
A service passes every test but is plainly dying. Does it stay?
Yes, with a status field that says so and the evidence for it. The list records what exists, not what you recommend. Removing a service because it is declining is a ranking decision in disguise.
What about a service that passes the tests only in some countries?
Include it, and record where the tests were applied. Registration rules, identity requirements, and visibility settings vary by market, and the honest entry says which market you checked.
How often does the rule need re-running?
Whenever a candidate changes its registration model, its profile structure, or its graph, which are the three things the tests measure. In practice, an annual pass over the whole set and an immediate check whenever a service announces a redesign.
