Timeline: putting events in order

The idea

You have a pile of material — an email thread, an incident report, a chat export, server logs, your own notes — and you need to know what happened in what order. Paste it in and the tool extracts dated events, each carrying its precision, its origin and its source.

No page is fetched on your behalf. The timeline reads what you paste or hand over as a file, and nothing else. That is the same line the directory import draws in the research tool, and for the same reason: parsing material you lawfully obtained is a different act from going and getting it.

Starting one

Go to the timeline tool, give it a title and a one-line summary, choose who can see it, and create it. Then add material.

Adding a source

Paste a source

The main route. Paste the text, name it — "Support thread, ticket 44121" is a name that is still useful in six months — and optionally record where it came from. Press Extract and the tool reads dates out of it.

Danish date forms are handled first, because that is what the material here tends to be in:

An ambiguous numeric date is read day-first, marked at 65% confidence, and reported as ambiguous in the response. 03/04/2024 is the 3rd of April here and the 4th of March in an American document, and there is no way to tell from the string alone. The tool commits to a reading, tells you it did, and lets you correct it — which is the only honest option. Check those before you rely on the order.

Adding a file

The tool decides what a file is from its content, not its extension: text, logs, CSV, TSV, JSON, JSON Lines, XML, YAML, HTML, .eml, .har, and documents — PDF, .docx, .odt and .rtf.

A document is read twice: for its text and for its properties. The prose gives up its dates; the file itself gives up the author, the company, and the real created and modified times. That second half is often the more useful one — a report whose text says "March" but whose properties say it was last saved in June is telling you something.

.doc, .xlsx and .pptx are not accepted. Nothing installed here reads a legacy Word binary or a spreadsheet's cells, and a spreadsheet reduced to its author and two timestamps is a worse source than pasting the relevant rows in. Export to .docx, .csv or PDF and it reads properly.

Machine input is aggregated rather than listed. Nine thousand log lines become one span with the outliers called out, because ten thousand points on an axis is not a timeline, it is a smear. The unusual entries — the first, the last, the burst, the gap — are what get their own events.

Uploads live in storage and are pruned once read; the timeline keeps the extracted events and the text it read, which is what an investigation needs. If you need the file itself to persist, import it from a filio.dk share instead — then the durable copy is yours and this platform holds a reference and a SHA-256.

Adding an event by hand

For what you know rather than what a document says. Set the date and its precision honestly: "some time that week" is a real precision and the chart draws it as one. A hand-added event is marked analyst for good, in the interface and in the PDF.

Precision, origin and confidence

Every event carries three separate things, and conflating them is how a timeline misleads:

• Precision — how exactly the date is known. Second, minute, hour, day, month, year. Drawn differently on the axis.
• Origin — where it came from. Extracted from a source, analyst (you), or model (AI).
• Confidence — how sure the extraction is. An ambiguous numeric date sits at 65%; so does anything an AI suggested.

An event can be precise and wrong, or vague and certain. Keeping the three apart is what lets a reader tell the difference.

The compressed view

View compressed in the toolbar swaps the scrolling list for the whole chronology on one screen — the same picture the PNG export gives you, drawn live so it fits your window instead of being a fixed image you have to zoom.

• The band across the top is density — where the events cluster. The eye finds the busy periods before it reads a single label.
• Points on the axis are events, coloured by severity. Where several would overlap they merge into one larger dot carrying the count and the worst severity in the group.
• Labels alternate above and below, one per slot across the axis, so a fortnight of important events does not stack twelve labels on one pixel.
• Click any point — the dot or the label — to open that event in the side pane.

It respects your filters, which the exported PNG does not: filter to one category and switch to compressed and you have a one-screen view of just that thread. The choice is remembered per browser.

Resize the window and it redraws. That is deliberate rather than decorative: whether two events a week apart are one dot or two depends on how much room the axis has, so a layout kept from a wider window would be quietly out of date.

Reading the axis

• Filter by text, by category, or hide the vague ones to see only what is firmly dated.
• Categories are matched on word boundaries with a compound tail allowed only from four characters — which sounds like trivia until you know that ret once matched inside sporet and filed a patch note as a court case.
• Ticks within a few pixels merge into one sized, counted dot rather than a smear.
• Callouts are picked by slot, not by rank — the twelve most significant events are usually in the same fortnight, and ranking put eleven labels on one pixel.

Exports

report.pdf, timeline.png, data.json and events.csv, all plain GETs under the timeline's own URL. Links, not buttons: they survive being pasted into a ticket, and they carry the timeline's own access rules.

The chart is rendered on the server — the opposite choice to the research graph, which is captured from your browser. A graph has a layout you arranged by hand; a timeline has exactly one correct layout, so the PDF, the download and the link preview are all the same picture.

What the PDF proves

A graph answers "what is connected to what". A chronology is a claim about a source for every single row, so the report is built to survive that being challenged. Every event prints its stated precision, its origin and its source.

And the gaps get their own section. A reader who is not told where the silence is will read the silence as absence — as "nothing happened then" rather than "we have nothing from then". On a timeline that is the single most consequential misreading available, so it is called out rather than left to be noticed.

AI extraction

If you hold an AI provider key, the tool can read a source and suggest events. Suggestions are capped at 65% confidence, carry the words the date was read from, and are marked with a model-suggested pill in the interface, a diamond on the axis and in the chart, and a named model in the PDF.

Treat them as a first pass over material you have not read yet, not as extraction you can skip checking.

Sending a timeline into research

A timeline can hand its entities to the research tool and start an investigation from them. Useful when a chronology has surfaced a name, a domain or an address that you now want the fan-out pointed at.