A recheck calendar and change log format for professional networks entries

A catalog entry is correct for about as long as it takes to publish it. What keeps it useful afterwards is a calendar: a written decision about which fields get rechecked, how often, and what gets written down when one has moved.

This page is that calendar for professional networks, plus the format of a change log entry that will still make sense in three years.

What to take away

The recheck calendar

Group the fields of an entry by how fast they move, and put each group on its own cycle.

Quarterly sounds like a lot. In practice a quarterly pass over one entry is under an hour, because most of it is diffing a saved document against the live one and confirming nothing moved. The pass that takes a whole afternoon is the one that finds something.

What "recheck" means for each kind of field

Policy text. Fetch the current document, diff it against your saved copy. Read the diff, not the document. Most revisions are restructuring; the ones that matter are a new category of recipient in a sharing clause, a changed retention period, or a widened license grant. Save the new copy with its date, keep the old one, and treat the pair the way version control treats two commits.

Help articles. Same method, but help articles are often undated and revised silently, so your saved copy and whatever a web archive happens to hold are the only history that exists. Where a feature's help article has vanished, that is itself an event: record it.

Behavior. Re-run the written observation procedure with the measurement account. Compare the result to the last one. The notes on collecting observations cover the procedure; the recheck is just running it again.

Pricing. Fetch each buyer-facing pricing page. Record whether a tier appeared, disappeared, or changed what it includes. Prices themselves are the least interesting part; the appearance of a new paid gate on something that was free is the finding.

Entity and jurisdiction. Read the current terms for the operating entity and governing law. Search for news of an acquisition or a restructuring. This is the one field where a secondary source is a useful prompt, because the primary document sometimes lags the event by months.

The change log entry

Every detected change gets one entry, in this shape.

The consequence column does real work. A change in identity model usually changes verification. A change in operator usually changes the privacy policy within a year. A change in graph type changes reach and messaging. Writing the expected knock-on down is what turns a log of isolated events into a record of what the service is becoming.

Effective date versus detected date

These are different, and a log that conflates them is untrustworthy. A service may state that a policy takes effect on a given day. It may roll a behavior change out gradually with no announcement. It may change a help article without any date at all.

Record what you know: the stated effective date when there is one, and always the date you noticed. A reader who sees "detected on" beside a change understands that the true date is earlier and unknown, which is the honest position.

Three kinds of change and what they do to the entry

A change to a product feature usually alters one field and nothing else. Log it, update the field, keep the old value visible.

A change to policy alters what the reader is permitted or exposed to. Log it, update the field, and reread the whole entry, because policy changes travel in groups.

A change of ownership invalidates confidence in every field. Nothing may have moved yet, but the old values held because of the old owner's decisions.

Log it, mark every field due for recheck, and shorten the cycles for the following year. The overview of update patterns on large services sets out why enforcement changes in particular are the hardest kind to see.

Keeping the log readable

A change log becomes noise when it records everything, so skip restructured pages, renamed menu items, or visual redesigns unless they moved a field.

But log a field checked and found unchanged in a separate, compact form (field, date, unchanged). A reader wants to know it was looked at; a long gap of silence reads as neglect, not stability.

Once a year, write a short paragraph per service summarizing the year's entries in plain language. That paragraph is what most readers will actually read, and it is worth more than the log it summarizes, provided the log exists underneath it.

Common questions

What if I miss a change and find it a year later?

Log it with the detection date and an honest interval: previous value recorded on one date, new value observed on another, change occurred somewhere between. The interval is a fact. A backdated precise date is not.

Is there any way to be told about changes rather than looking for them?

Some services publish a changelog for policies or a developer changelog; where one exists, subscribe to it and treat it as a prompt, not as the record, in the way the notes on reading an announcement describe. The record is still your own saved copies and your own diff.

How is this different from the recheck advice for the whole catalog?

It is the same discipline applied to one category. Professional networks differ in one way: the fields that move fastest (verification, messaging, recruiter products) are exactly the ones a reader relies on most. That is why the quarterly group here is larger than it would be for, say, a photo service.

Does the entry need a "last reviewed" date at all, then?

Keep it, but make it the date of the most recent field check of any kind, and show the per-field dates beside it. The single date is a summary. The per-field dates are the truth.