Professional networks directory schema: each field's source class and how fast it goes stale

A directory entry is a promise to the reader that someone checked. The promise is only worth keeping if each field records something a person could go and confirm, and if the entry admits which fields were never filled.

The schema is a data dictionary: the fields a professional network directory entry needs, where each comes from, and how fast each goes stale.

It is deliberately short: a schema with forty fields gets ten filled and thirty guessed.

What belongs in the directory is decided separately by the inclusion rule.

What to take away

The fields

Identity model. What the service requires you to be. A legal name, a work email, a phone number, a document, or nothing. Source: the registration flow and the terms of service. Half-life: long, but changes are abrupt and usually tightening. This is the first field because it decides who can be on the service at all, and therefore what the whole directory entry describes.

Graph type. Whether connections are mutual, one-directional, or both at once. Source: make an account and try to connect to someone. Half-life: very long. Services rarely change this because it changes everything else.

Verification offered. What the service will check on request and what mark it shows for it. Source: the service's own help documentation describing the check, quoted rather than paraphrased. Half-life: short. Definitions of a verified badge shift, sometimes without announcement, so this field always carries a checked date.

Who pays. Whether revenue comes from members, from recruiters, from advertisers, from employers, or from data licensing. Source: the pricing page for each audience the service sells to, and where they exist, investor documents. Half-life: medium. This is the most explanatory field in the entry because it predicts what the service will optimize for.

Reach mechanism. Whether a post goes to your connections in order, to a ranked subset, or to strangers by recommendation. Source: the service's own description of the feed, and a test with a small account. Half-life: short. Note the date and expect to redo it.

Export. What data portability the service actually offers: what it will hand back, in what format, and whether it includes anything usable off-platform. Source: run the export. Half-life: medium. Record what the file actually contained, not what the settings page said it would.

Messaging rules. Who can write to a member unasked, and what a non-connected message costs. Source: the help documentation, then a test. Half-life: short, and the direction is usually toward a paid product.

Operator and jurisdiction. The legal entity that runs the service and where it is established. Source: the terms of service, the privacy policy, or the imprint. Half-life: long, but ownership changes are the events that invalidate the most other fields at once.

Data handling. What the privacy policy says is collected, retained, and shared, in its own words. Source: the policy, with the section quoted. Half-life: short. Policies are revised often and the revision is sometimes only visible by diffing against a saved copy.

Public visibility. What a logged-out visitor can see of a profile. Source: open a profile in a private browser window. Half-life: medium. A logged-out view is a small test, and niche social networks can look alive or dormant from exactly this kind of check.

Status and checked date. Whether the service was operating when checked, and when that was. Source: your own observation. Half-life: the whole point of the field is that it decays.

A filled entry, with nothing real in it

The schema reads differently when it is populated, so here is an illustrative entry for a fictional service. Every value is invented; the shape is the point.

Notice the row that says "unknown". It is doing real work: it tells the reader the entry was checked and the fact was not findable, which is different from the field being skipped.

What is deliberately absent

No user count, because the service's figure is unverifiable and any independent figure is an estimate of an estimate; the notes on platform figures explain why.

No launch date, because it is an anecdote about the past that changes nothing a reader will do. No feature list, because features churn faster than any directory can follow; the fields above describe the properties features are built on. No rating, because the entry describes and does not judge.

Maintaining it

The half-lives above give you the recheck calendar. Short-half-life fields (verification, reach, messaging, data handling) get looked at every quarter. Medium ones twice a year. Long ones annually, or immediately on any news of an ownership change, because a new owner tends to revise identity, pricing, and data policy inside a year.

When a value changes, keep the old one, for the reasons the notes on a platform record set out. An entry that shows a verification definition was narrower last year than it is now is telling the reader something a current-only entry cannot.

Common questions

Is a filled schema enough to choose a service?

It is enough to rule out the ones that fail a requirement, which is most of the work. Choosing between the survivors is a matter of who is on each one, which no directory can record, and which the professional networks overview covers from the searching side.

What if the service's documentation contradicts what my test account shows?

Record both, with dates. Documentation lags, tests are local to one account and one region, and the contradiction itself is worth a reader's attention.

How many entries can one person maintain?

With this schema and the recheck calendar above, a few dozen. Beyond that, either the fields get skipped or the dates get faked, and both are worse than a shorter directory.