Platform timelines examples: lessons and useful context

A timeline entry looks like the simplest unit of writing there is: a date, a colon, an event. The examples below are the cases where that simplicity breaks, and each is worked through to show what a defensible entry looks like. Every example is a type, not an instance. No service is named, no date is real, and the names of features are placeholders, because the point is the shape of the problem and the shape recurs across every company that has ever shipped anything.

What to take away

• Most timeline errors are not wrong dates. They are the right date for the wrong event, attached to a name that did not exist at the time.
• Staged releases, renames, acquisitions, removals and policy changes each have a characteristic trap, and each has a fix that is mostly labeling.
• An entry that says less, with its date type and source attached, outlives an entry that says more without them.

Example one: the staged rollout

A feature is released to one region, then to invited users elsewhere, then to everyone with a certain account type, then generally. The press notices at stage two. The company's own history page gives the date of stage four. Most timelines pick one of these and call it the launch.

A defensible entry records the stages it can document and marks the rest as unknown. "Available to some users from around this period; general availability documented by this date; earlier stages reported but not confirmed." It is longer than a single date and it is the only version that is true for every reader.

Example two: the retroactive name

A capability existed under one name, was renamed, and is now known by the second name. Every account written after the rename uses the second name for the whole history, so the timeline says the thing existed years before anything by that name did. Readers who search for the second name in contemporary sources find nothing and conclude the timeline is wrong. It is not wrong; it is anachronistic, which is a different failure.

The fix is to date the name separately from the thing. "The capability, then called X, from this period; renamed Y at this later date." A changelog, where one survives, is the best source for both, because it was written at the time by people who used the current name.

Example three: the acquisition with five dates

One company buys another. There is the date the deal was agreed, the date it was announced, the date regulators cleared it, the date it closed, and the date the acquired product was folded into the buyer's. Any of these can be years apart from the others. A timeline that says "acquired in" has chosen one without saying which.

The entry should name the event it is dating. "Announced" and "closed" are different facts, and a reader who needs one cannot use the other. Where only one date is documented, say which it is; where the type is unknown, say that too.

Example four: the feature that came back

A capability is removed, then reintroduced under a new name years later, and the reintroduction is reported as an innovation. Timelines built from coverage record two launches and no removal, because removals get little coverage and the second launch's coverage does not mention the first.

The fix requires a contemporary source for the removal, which is usually a complaint thread rather than an announcement. Users notice removals; companies do not announce them. The internet culture archives page describes where such threads survive and how far their dates can be trusted.

Example five: the policy with two dates

A terms change is published on one date and takes effect on another, and the enforcement that people notice begins on a third. A timeline entry that says the policy "changed" on the publication date is technically right and practically misleading, because nothing changed for anyone that day.

Record all three where known, and where the entry has room for one, use the effective date and label it. The publication date is a fact about a document; the effective date is a fact about users; the enforcement date is a fact about behavior, and it is the one that is hardest to document and most often what the reader wants.

Example six: the version that was not a release

Software carries version numbers, and version numbering has conventions that vary by company and by era. A timeline that lists versions as events is listing labels, some of which corresponded to a public release, some to an internal build, and some to a renumbering that shipped nothing. The number is not the event.

Date the release, not the version, and treat a version number as a name that helps locate the release in a changelog. Where a version was never publicly released, it does not belong on a timeline of what users experienced, though it may belong on a timeline of what was built.

The pattern across the examples

Trap	What went wrong	The labeling fix
Staged rollout	One stage's date used for all	Record the stages, mark unknown ones
Retroactive name	Present name applied to past thing	Date the name and the thing separately
Acquisition	Five events, one date	Name the event being dated
Removal and return	Second launch recorded as first	Find the complaint thread; record the removal
Policy change	Publication date used for effect	Prefer the effective date; label it
Version number	Label treated as event	Date the release; treat the number as a name

The fixes are all labeling. None requires better sources than most timelines already have; they require saying what the source established, which is the rule the platform timelines page treats as the whole discipline.

Two cases with no fix

Some entries cannot be made right, only honest. A capability that a service had, undocumented, before anyone wrote about it has no date and can only be entered as "present by" the date of the earliest surviving mention. And the stored-connection feature that the early social networks page treats as the defining capability was often added quietly to a system that had existed for years without it, so "the system launched" and "the system became a social network" are separate entries and the second is usually undocumented.

The same applies to standing signals: a verification mark or a count whose meaning changed under an unannounced policy, described under online status and identity, has a history that no timeline can recover, because the change was never dated by anyone who could see it.

Common questions

Should every entry really carry a date type?

Every entry that could be misread without one, which is most of them. The type costs a word and saves a correction.

What if my sources disagree?

Enter both, with what each rests on. An averaged date is a third claim nobody made.

Why are all the examples hypothetical?

Because a real example would carry a real company's real dates, and this site does not assert those without contemporary evidence, which for most of them is missing or contested.