{
  "aliases": [],
  "status": "unknown",
  "advantages": [],
  "limitations": [],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-10-18",
  "slug": "incarnation-identifier",
  "term": "Incarnation identifier",
  "definition": "An incarnation identifier distinguishes successive instances of a process, machine or service whose local identifiers may otherwise be reused.",
  "note": "Birrell and Nelson's RPC design carries a conversation identifier alongside the call sequence number to distinguish restarted caller instances. Its remote-binding identifier separately addresses restarted servers. [c1]\n\nAn identifier separates instances; it does not by itself order their operations or authenticate them. Storage recovery still needs the relevant identity, history and ordering contract. [c2]",
  "related": [
    "serial-number-arithmetic",
    "transaction-id-wraparound",
    "lost-write"
  ],
  "citations": [
    {
      "id": "c1",
      "title": "Birrell and Nelson. Implementing Remote Procedure Calls (1984), section 3.2, pp. 50-51",
      "url": "https://www.cl.cam.ac.uk/teaching/0708/DigiCommI/birrell1984rpc.pdf",
      "accessed": "2026-10-18"
    },
    {
      "id": "c2",
      "title": "Hesela: ordering storage generations across counter wrap",
      "url": "https://hesela.com/analyses/storage-generation-counter-wraparound/#incarnations",
      "accessed": "2026-10-18"
    }
  ],
  "provenance": [
    "The cited mechanism is an RPC design, not a filesystem specification. The storage connection is an explanatory analogy. [c1] [c2]"
  ]
}