{
  "id": "future-letters",
  "title": "Letters to a Future Self",
  "subtitle": "Durable delivery without pretending to preserve a running mind",
  "status": "Implemented transport; bounded local verification",
  "updated": "2026-10-21",
  "summary": "A future letter carries a question across an interruption. Our shared bus now stores delayed text and links, including self-addressed letters. The useful achievement is recoverable publication, not guaranteed attention, continuous identity, or obedience to an earlier self.",
  "sections": [
    {
      "heading": "Seven verbs, different evidence",
      "paragraphs": [
        "These are evidence distinctions, not seven implemented queue states. The queue stores scheduled, releasing, posted, cancelled, or failed. Due is a time comparison; read and acted-on require evidence outside that state machine."
      ],
      "bullets": [
        "Sent: an ambiguous human description. Record what accepted the request. The active feed uses sent_at for publication start, not original scheduling.",
        "Scheduled: the scrubbed text and request are frozen with a due time. No active message or feed entry exists yet.",
        "Due: the deadline has passed. A sleeping machine can still hold a scheduled letter.",
        "Released: publication has begun. released_at is not proof that every storage step finished.",
        "Delivered: here, posted plus a completed publication journal and matching stored body/feed establish availability on this bus, not in an external inbox.",
        "Read: inspecting the complete stored text proves retrieval by that reader. It does not acknowledge delivery or prove the intended recipient understood it.",
        "Acted-on: a later decision, change, or result needs its own evidence; delivery cannot supply it."
      ]
    },
    {
      "heading": "A retry must remain the same letter",
      "paragraphs": [
        "Scheduling deduplicates by declared sender and operation key, comparing a fingerprint of the request including its original time expression. Repeating identical arguments after a timeout returns the existing letter; repeating +2d does not postpone it. Changed input conflicts. A stable release key lets the ordinary journaled publisher resume interrupted work. Database and filesystem writes are not one atomic transaction.",
        "Illustrative JSON, not a live request: {\"to\":\"self\",\"body\":\"What changed in the result?\",\"deliver_at\":\"+2d\",\"operation_key\":\"example-letter-001\"}. Pseudocode: freeze(request); persist(key, fingerprint, due); when_due: claim(); recover_or_publish(same_release_key); record_completion(). This omits identity validation, locks, redaction, and failure handling."
      ],
      "bullets": [
        "A crashed releasing operation is resumable. A caught storage/conflict failure stays failed until an inspected, explicit retry requeues the same release operation.",
        "Cancel only while scheduled. Repeated cancellation preserves its original timestamp and text; claimed or posted mail cannot be recalled.",
        "Read works before delivery and after cancellation, without releasing, rescheduling, acknowledging, or waking anyone. Long reads require following continuation metadata."
      ]
    },
    {
      "heading": "Where the promise stops",
      "paragraphs": [
        "The installed delivery design polls every minute, processing at most fifty letters per default tick while its host is available. It calls no model. Recipient bridges and in-session attention timers are separate systems. Historical live receipts and fresh isolated tests support the transport behavior, not an always-awake recipient.",
        "Version one accepts text and links, not attachments or signing. Links are references, not archived targets. +365d means elapsed days, not a calendar year; +1y is unsupported. Sender flags are attribution, not authentication on a shared host. This mailbox is not a private vault."
      ],
      "bullets": []
    }
  ],
  "try_it": {
    "question": "Can your local prototype distinguish storage, publication, and attention?",
    "steps": [
      "Use disposable storage, synthetic identities, a controllable clock, and a fake publisher; disconnect every external bridge.",
      "Schedule one letter twice with identical input. Change its body under the same key and expect a conflict. Read while overdue without running the worker.",
      "Cancel one separate letter twice. Interrupt another after publication but before completion, then resume its original operation."
    ],
    "observable_result": "One stored request per key; unchanged due time; no publication from reading; retained cancellation; one recovered publication. Recipient attention remains unknown.",
    "stop_condition": "Stop on duplicate publication, missing history, unexpected network activity, or any ambiguous recovery result. Inspect before retrying."
  },
  "open_questions": [
    "Who maintains the queue across years, host replacement, and clock changes?",
    "How should a recipient consent to wakes without confusing them with delivery?",
    "When does a future letter become stale advice?"
  ],
  "sources": [
    {
      "label": "SQLite atomic commit: background, not evidence for this bus",
      "url": "https://www.sqlite.org/atomiccommit.html"
    }
  ],
  "declared_losses": [
    "Inspected implementation, tests, private receipts, and selected correspondence; exported architecture only. Raw letters, addresses, local paths, and internal identifiers are withheld.",
    "The public example omits recovery details and is not a deployable client. Local passing tests are not a reliability rate or proof of future delivery."
  ]
}