Keep the source, the review and the exact calendar file.

Two downloads, different purposes

• ICS: title, UTC start/end, event ID and creation time for a calendar. No original message, raw answer or review notes.
• Calendar work JSON: entire source, raw answer, notes and any retained ICS/identity. This is the file to reopen in PromptKB. It can contain incomplete or invalid answers when there is no event yet. It is not a Test Bench project.

Neither is redacted. Work JSON is not encrypted, signed, proof of approval, a model-execution receipt or evidence that a calendar import happened. There is no autosave, account or server copy. If you share a work file, its full source and notes go with it.

1. Keep notes explaining what you checked or what is still missing. Save unfinished work whenever needed.
2. Preview the answer and inspect agreement, title and times against the original source. Explicitly approve before downloading ICS.
3. Download work JSON after preparing the ICS to retain that exact event file across visits. A work file saved earlier cannot contain an event created later.
4. On another visit, use Open calendar work JSON. Existing tab content asks before replacement; cancel leaves it unchanged. The approval checkbox is not restored.
5. Preview and approve again. Without source/answer edits, the next ICS download is byte-identical, including UID and creation time.

Try a new fictional handover

This source and answer were authored for the exercise, not generated in an independent model run or taken from real correspondence. The numeric offset is explicit; no named-zone inference is needed.

Source

Asha: Can we confirm the handover review for 2027-02-11 at 18:30, UTC+05:45, for 45 minutes? The offset stays +05:45 throughout.
Ben: Confirmed, handover review at that date and time for 45 minutes.

Authored answer

{
  "status": "ready",
  "title": "Handover review",
  "start": "2027-02-11T18:30:00+05:45",
  "end": "2027-02-11T19:15:00+05:45",
  "evidence": "Ben: Confirmed, handover review at that date and time for 45 minutes.",
  "questions": []
}

The expected interval is February 11, 2027, 12:45–13:30 UTC. A calendar displayed in America/New_York shows 07:45–08:30 that day. Display timezone does not change the underlying event instants.

• Download browser-saved example work JSON — open this in the calendar tool, then preview and review again.
• Exact retained fictional ICS — use a disposable practice calendar, not a real appointment.
• Fictional source, answer and reuse permission
• Local calendar-client observations · Artifact hashes and limits

The supplied example has a shared sample event ID; it is not a personalized appointment. Do not use it as an invitation.

What an actual local calendar client did

Agent-operated khal 0.14.1, configured to display America/New_York, imported these fictional browser downloads into disposable local-only calendars. No account, CalDAV server, real participant, cloud sync or invitation was involved.

• Two prior-release downloads of the same design review had different UIDs. Importing both created two entries at 08:00–08:45.
• The new handover's first, repeated and reopened files were byte-identical. Importing all three left one entry at 07:45–08:30. In this exercise, khal import --batch overwrote the same UID without prompting; it did not prove harmless behavior in other clients.
• After editing the answer, the new file had a different UID. Importing it left both the original and amended events, as disclosed.
• The prior year-rollover event displayed December 31, 23:45 to January 1, 00:15 in this calendar, although both endpoints were January 1 in UTC.

This is a bounded local-client result, not Google Calendar, Outlook, Apple Calendar, synchronization, invitation-delivery or universal duplicate-prevention evidence. The source and judgments share an agent context; no independent human benefit or model-quality result is claimed.

Calendar work file version 1

{
  "format": "promptkb-calendar-work",
  "version": 1,
  "source": "Original message text",
  "response": "Raw model answer, possibly unfinished",
  "notes": "Your review notes",
  "event": null
}

When an ICS has been prepared, event contains exactly uid, createdAt (UTC timestamp with seconds) and ics (the exact calendar text with CRLF line endings). The current converter must regenerate identical ICS from the answer and metadata before opening it. This consistency test is not a signature or proof of source authenticity.

UTF-8 JSON, at most 512 KB. Source: up to 20,000 JavaScript UTF-16 code units. Raw response: up to 30,000 UTF-8 bytes. Notes: up to 4,000 UTF-16 code units. Saved ICS: at most 16,000 UTF-8 bytes. Editor strings must use LF, not CR/CRLF, so native textareas do not silently rewrite them; JSON file whitespace may use CRLF. Duplicate JSON keys follow native parsing (last value wins). Unsupported versions/fields and malformed UTF-8 refuse without replacing current work.

These are provisional implementation bounds, not a cross-client standard. Keep the original if a future tool cannot open a file. No automatic migration, trimming, server recovery or verified approval is provided.

You may use, copy, modify and redistribute this fictional example, including commercially, without attribution. No warranty or endorsement.