No. 06 · Study

One thing, arriving twice

The same calendar event can arrive in an exported file and again through a live connection. It should be drawn once, keep both arrivals, and never be merged with a stranger that merely looks the same.

Information reaches a person by many routes: an export, a sync, a device, an upload. Often the same thing arrives more than once. A view that counts arrivals will show the ferry twice. A view that merges anything with the same title and time will, sooner or later, fold two different things into one.

The approach here keeps every arrival exactly as it came, and asks a narrower question of each: is this the same record at its source? Only the source’s own identifier, within the same calendar, can answer yes. Then the thing is drawn once, and each arrival stays inspectable behind it.

Arrivals

  1. A Ferry to the island 12 Jun 2027, 08:40 Export file · Calendar “Travel” uid 7f3a…e1
  2. B Ferry to the island 12 Jun 2027, 08:40 Provider API · Calendar “Travel” uid 7f3a…e1
  3. C Ferry to the island 12 Jun 2027, 08:40 Provider API · Calendar “Family” uid 02bc…9d

Kept as

  • AFerry to the island
  • BFerry to the island
  • CFerry to the island
  • ABFerry to the island One source record, seen by two routes. Both arrivals are kept.
  • CFerry to the island Same title and time, different record. Kept apart; at most a possible match for you to decide.

Drawn on Saturday 12 June

08:00
Ferry to the island
Ferry to the island
Ferry to the island
Ferry to the island A·B
Ferry to the island C
09:00

Three marks. One ferry has been counted twice, and nothing says which. Each thing is drawn once. Nothing was merged away: every arrival can still be inspected.

Illustration · made for this site

Three invented arrivals. A and B are one record from one calendar, delivered by two routes. C only looks the same. Switch between counting arrivals and reconciling them.

Looking the same is not being the same

A title, a start time, a file name or a matching phrase is never treated as proof. Two records with the same title from two different calendars might be the same real-world event, or they might be a coincidence; that is a decision for a person, offered as a possible match, never made silently.

When a person does decide that two records are one thing, the link is kept as a decision, and it can be undone. The sources keep their own histories either way.

Where it stands

Exists

  • A written contract that keeps five questions apart, from whether two files hold the same bytes to where a thing should appear.
  • A tested reference implementation of reconciliation, and a ledger that keeps every arrival as received.
  • A read-only calendar connection that records what it reads as arrivals in that ledger.

Not yet, or not decided

  • Evidence from real exports that their identifiers survive the journey. The checks so far use invented records.
  • A way to bring a calendar file in from the web app.