Platform timelines risks explained with examples

A timeline is a small, confident document, and confidence is where the harm comes from. Readers take a dated list as settled, quote it, build on it, and the errors travel further than any correction. Some of the errors are merely wrong. Some attribute actions to companies that did not take them, erase people who were there, or invent a story from the order of the rows. This page is a set of rules for avoiding each, written as what goes wrong when the rule is broken.

What to take away

• The characteristic failures of a timeline are anachronism, false precision, merged identities, implied causation and attribution without evidence. Each has a rule that prevents it.
• The harms are not equal. A wrong date embarrasses; an unsupported attribution can defame; an erased community stays erased.
• The most dangerous entry is the one that looks most finished.

Rule: do not let the present name the past

Anachronism is the most common failure and the least noticed. A feature is described by its current name for its whole history; a company is called by the name it took later; a capability that was added quietly is treated as present from the start. None of this is a wrong date. It is the right date attached to a description that did not exist yet, and a reader who checks contemporary sources finds nothing and either distrusts the timeline or, worse, distrusts the sources.

The harm compounds because retroactive names are the ones searchable now, so a timeline using them is easier to find and cite than one using the contemporary names, and the anachronism propagates on the strength of its own convenience.

Rule: never write a date more precisely than the source does

False precision happens when a source says "around that year" and the entry says a day, because the format has a column for a day. The reader cannot tell a documented day from a guessed one, and once the day exists it is copied as a fact. A precise date on a timeline is a claim that a document exists giving that date; if none does, the entry is fabricating one.

The rule is to write the precision the source supports and no more. "Some time in this period, from a later account" is an entry. A date invented to fill a column is not.

Rule: keep separate things separate

Companies merge, products are renamed, teams move, and a timeline that tracks a name across all of this often ends up describing three different things as one. The harm is that actions get attributed to the wrong entity: a decision made by an acquired company under previous ownership appears as the buyer's decision, or a product's early problems are attached to the company that later bought and fixed it.

This is where timelines acquire legal weight. An entry that says a company did something is a factual claim about that company, and if the thing was done by a predecessor, a subsidiary, a contractor or a user, the claim is false about the company named. The critiques page notes that most critiques are about business models and not firms; a timeline that names firms alongside actions needs contemporary evidence for the attribution, and this site's rule is to make no such entry without it.

Rule: adjacency is not causation

Two rows next to each other invite a story. A policy change followed by a decline; a competitor's launch followed by a feature; a scandal followed by a departure. The timeline says nothing about the connection, and the reader supplies one, and the supplied connection is then repeated as if the timeline had established it.

The rule is to make the connection explicit or to break the adjacency. If two events are related and the relation is documented, say so in the entry. If the relation is inferred, say that. If it is unknown, consider whether the entries need to sit together at all. A table with a column for "connection, if any" is more honest than a line, because the column can be empty.

Rule: notice what the timeline cannot see

A timeline is built from what was recorded, and the recording favored the large, the public and the well-covered. Small communities that were widely used and then closed leave a thinner trail than small ones that persisted, and services that were important to people the press did not cover leave almost nothing. The early social networks page describes how thin that record is; a timeline built from it presents durability and coverage as importance, and the communities that were neither durable nor covered are not represented as absent. They are simply not there, and the reader has no way to know.

The harm is erasure, and it is permanent, because a timeline that omits something is not corrected by the people it omitted, who are gone. The rule is to say what the timeline is built from and therefore what it is likely to miss. An entry reading "no record survives for this period; the absence is not evidence" is legitimate and rare.

Rule: budget for corrections before publishing

Every timeline will need correcting, because the underlying record changes: a capture is found, a source is retracted, a participant surfaces with a document. A timeline that treats itself as finished cannot absorb this, and corrections are made silently, overwriting the earlier state, so that a reader who cited the old version now cites something that no longer says what they quoted.

The rule is to keep an update log, retain the prior state, and date the check. That turns the timeline from a claim into a record of claims, which is the only form that survives being wrong. The archive kinds described under internet culture archives are where the correcting evidence tends to come from, and they surface it on their own schedule.

The rules together

Failure	What it does to the reader	Rule that prevents it
Anachronism	Sends them to sources that cannot contain the name	Date the name separately from the thing
False precision	Turns a guess into a citable fact	Write the source's precision, not the column's
Merged identities	Attributes actions to the wrong company	One entity per row; document every attribution
Implied causation	Supplies a story the evidence does not support	Make connections explicit or break the adjacency
Survivorship	Presents coverage as importance	State what the timeline is built from and cannot see
Silent correction	Breaks every earlier citation	Keep a log; retain prior state; date the check

Nothing in the right-hand column requires better sources. The whole discipline, as the platform timelines page argues, is labeling: saying what each entry rests on, in the entry.

Common questions

Which of these is the most serious?

Merged identities, because it produces false statements about named companies, and those have consequences beyond embarrassment. Erasure is the most permanent.

Is an incomplete timeline better than a wrong one?

Yes, if it says where it is incomplete. A stated gap is information. An unstated gap is a claim that nothing happened.

Can these rules be applied to an existing timeline?

They can be applied as an audit: check each entry for the six failures and label what you find. Most published timelines fail several rows, and the audit is more useful than a replacement.