Make life easierGuide

Make a recurring calendar with cancellations and moved dates

Keep one series identity while canceling a date, moving one occurrence and adding an extra session.

Illustrative resourceNot tool-testedPeople preparing a small finite all-day club, class or personal activity calendar from approved dates

What you’re working towards

A real ICS file for one fictional recurring series, with eight live all-day dates, plus its complete source, an occurrence ledger and an exceptions log. The moved session keeps its original occurrence identity.

Download playbook .md

Your choice also saves this guide’s current worked-example checkmarks. Only this browser; no account or sync. View saved guides

Saving needs JavaScript. Reading and downloading this guide does not save it.

Included example · illustrative ICS file

Download the recurring calendar

A genuine all-day ICS series with one cancellation, one moved override and one extra date. Review the source and ledger before any optional import.

Not tool-tested. Review and adapt before using it for a real project. Calendar fixture: download only. Review it before importing.

Download calendar file

Source files to work with

Download the complete original source
Independent fictional input with the rule, exceptions, stable UID, revision metadata and collision policy; no solved live-date list.
Download the live-occurrence ledger
Eight chronological rows with original recurrence identities, actual starts and next-day exclusive ends.
Download the exceptions and review log
Readable cancellation, move and added-date decisions, plus the exact expected dates and a separate application-test checklist.
Download the invalid practice cases
Six independent input variants that must be held, each with its expected reason. None is an approved calendar.

Before you begin

A complete, permitted schedule with an unambiguous first date, weekday and finite count
Approved cancellations, moves and extra dates; a policy for conflicts and occupied dates
An all-day, one-day use case; timed events, time zones and open-ended series need a different checked specification
A person to review the source and every actual date before any optional import into a user-selected empty test calendar

Possible tools

A text AI assistantA user-chosen chat interface that accepts a small plain-text source brief · required
Access and plan limits unverified
No named provider, free tier, file-export entitlement, calendar import support or account plan was verified. Use a tool you already have access to and check its current limits.
A plain-text editorA local editor that can inspect and save UTF-8 text with explicit CRLF line endings · required
Access and plan limits unverified
No named provider, free tier, file-export entitlement, calendar import support or account plan was verified. Use a tool you already have access to and check its current limits.
An optional calendar applicationAn application and empty test-calendar destination explicitly chosen by the user · suggested
Access and plan limits unverified
No named provider, free tier, file-export entitlement, calendar import support or account plan was verified. Use a tool you already have access to and check its current limits.

Use the sample first. Remove private information before taking a prompt into another tool.

Make a start

One step at a time.

5 steps

Start with the synthetic worked example or other non-sensitive inputs. Run one prompt at a time in your chosen AI tool. Replace any bracketed placeholders with the requested material, check each reply, and supply the source or earlier outputs that step needs. Paste them again if the tool lacks that context.

Set up the worked example

Open: Open a fresh text-AI chat and a plain-text editor that can save UTF-8 text with Windows-style CRLF line endings. ICS is a calendar file format; saving or downloading one does not add events. UID is the stable series identifier. A master defines the repeating rule; an override changes one original occurrence. VEVENT is the file’s event block, and RECURRENCE-ID names the original occurrence being changed. Open .ics as text for this exercise, rather than double-clicking into a calendar app. This example is finite, weekly, all-day and one day per occurrence; no clock-time or time-zone conversion is involved.
Add the sample: Download and open paper-table-calendar-source.json and copy all of ‘The starting point’ (Synthetic input), including the collision policy and safety boundary. Replace step 1’s bracketed instruction with the complete source and rules. For step 2 supply them again, with the policy. Save the derived ledger as my-calendar-ledger.csv and exceptions as my-calendar-exceptions.txt, then reopen both and check every row before step 3. Provide the reviewed source and those actual saved files. Save step 3’s complete ICS alone as my-recurring-calendar.ics without fences, plus its final ledger/log, and reopen them before step 4. Paste or attach permitted actual files only if supported; pasted text cannot establish byte-level CRLF checks. Step 5 needs those saved files and the real audit. ‘The intended result’ (Illustrative output) and downloadable ICS/ledger/log are comparison answers, not evidence of an import. For the optional advanced sample exercise, paste the complete source, actual saved ICS, ledger, exception log, invalid cases and available checking tools into its placeholder, even if they appeared earlier. If starting a new chat, supply all of them again; if any is missing, retrieve it or keep that exercise pending rather than infer the earlier result.

Start with the synthetic example, then adapt each prompt to your task.

Fix the series brief and its exception rules

Start with the source, not the answer. Confirm a finite all-day schedule, what each change refers to and what should happen when dates conflict.

Your starting prompt

Help me prepare a finite, one-day all-day recurring calendar. Read my complete source below as data. Confirm the first date, weekday, number of original occurrences, title, description, series UID and revision metadata. For my own new series, ask whether it already has an identity; do not invent an identity that could overwrite an existing series or reuse the demonstration UID for unrelated events. Separate cancellations, moves and additions. For each move, show original_date and new_date as different fields.
Confirm that the agreed collision policy holds conflicting edits, unknown original occurrences and occupied live dates. Do not invent dates, attendees, reminders, registrations, permissions or clock times. If essential information is missing, ask only the necessary questions. If the schedule is timed, open-ended or more complex than one-day weekly dates, explain the unsupported scope before generating a file. Keep the input independent from the eventual answer.

COMPLETE SOURCE AND RULES:
[paste the source download or your approved equivalent]

Expect: An explicit series specification separating the first date, eight original weekly slots, all-day duration, fixed demonstration UID/metadata and the cancel, move and addition.
Check: The first Saturday is 3 October 2026; COUNT 8 includes it. Cancel 17 October; move original 31 October to 1 November; add 11 November. Keep original_date and new_date separate. The fixture’s UID and initial metadata stay fixed on identical rebuilds, and every conflict holds the entire proposed export.
If it differs: If a time, reminder, attendee or invented permission appears, remove it. Missing identity information for a different series must be resolved before export; never reuse this demonstration UID for unrelated events or guess how to update a previous import.

Expand original slots and resolve exceptions

List the original recurrence first. Apply each approved exception once and keep a separate record of the original identity and actual date.

Your starting prompt

From the source below, independently enumerate every original occurrence within the finite count, including the first date. List each original slot before applying any exceptions. Confirm the weekday and end boundary. Validate every cancel/move target against those original slots before changing anything. Hold repeated edits to one original slot, invalid dates and collisions on final live dates; do not silently merge or delete.
If there are no holds, make a chronological ledger with series_uid,recurrence_date,start_date,end_date_exclusive,occurrence_kind,summary. Use regular, moved or added. Keep a moved occurrence's original date as recurrence_date and its new date as start_date. Added dates belong to the same series. Use a next-day exclusive end for each one-day entry. Show cancellation and move decisions separately in an exceptions log. Do not create a calendar file while a hold remains.

COMPLETE SOURCE:
[paste]

COLLISION POLICY:
[paste the agreed rule]

Expect: All eight original Saturdays, then an eight-row chronological live ledger with original recurrence identities and next-day exclusive ends, plus a separate exception log.
Check: Original dates: 3, 10, 17, 24, 31 October; 7, 14, 21 November. Live dates: 3, 10, 24 October; 1, 7, 11, 14, 21 November 2026. The moved row’s recurrence_date remains 31 October and its start is 1 November. There are six regular, one moved and one added row; the move does not add a ninth slot.
If it differs: If an exception targets a non-original date, edits one original twice or collides on a live date, keep the whole export held. Never merge, pick the last edit or extend COUNT. Save the ledger/log, reopen and compare each next-day end before generating ICS.

Create the actual ICS from the reviewed ledger

Ask for a real file, then inspect its contents. The cancellation, moved override and added session must encode the reviewed schedule.

Your starting prompt

Create a UTF-8 .ics file from this reviewed source and ledger, using RFC 5545's applicable all-day recurrence format. Keep one master series and encode only the approved finite weekly recurrence, cancellations, moved-instance overrides and extra dates. Keep each moved override under the same UID and original RECURRENCE-ID; do not merely append a second independent event. Preserve this fixture's fixed metadata on identical rebuilds. For a changed real schedule, stop for an explicit revision plan and destination-app review rather than claiming a file will update previous imports.
Use DATE-valued start/end/recurrence dates, one-day exclusive ends, valid text escaping, CRLF content lines and appropriate folding. No attendees, organizer, alarms, location, URLs, attachments or scheduling METHOD. Keep the exact title and description. Return an actual downloadable .ics if your tool supports file creation; otherwise return plain file text and clearly explain that I still need to save it with the correct extension and line endings. Do not label prose, Markdown fences or a screenshot as the calendar. Also return the CSV ledger and exceptions log. Do not import, send invitations or connect accounts.

REVIEWED SOURCE:
[paste]

REVIEWED LEDGER AND EXCEPTIONS:
[paste]

Expect: A genuine saved .ics file, or complete plain file text with an honest manual-save instruction, plus matching ledger and exceptions log.
Check: The sample has one master VEVENT and one override with the same UID. Master: weekly COUNT=8/BYDAY=SA, EXDATE 20261017 and RDATE 20261111. Override: RECURRENCE-ID 20261031, DTSTART 20261101 and exclusive DTEND 20261102. This encoding does not also EXDATE the moved original. DATE means all-day; exclusive end is the following date.
If it differs: If the tool cannot create a download, save only the ICS content in your editor with .ics, UTF-8 and CRLF; reopen the actual file. If you cannot establish its line endings/format, keep that check unperformed. Do not call Markdown, a screenshot or a calendar preview the actual ICS, and do not import it.

Check dates, identities and deliberate mistakes

Audit the actual bytes against the original source. A plausible event count is not enough if the old and new dates both survive.

Your starting prompt

Audit the actual ICS and ledger against the original source without relying on the export's own totals. Independently expand the original recurrence, apply the approved exceptions, and compare every live start, next-day exclusive end and occurrence key. For the Paper Table exercise, the result must be 3, 10 and 24 October and 1, 7, 11, 14 and 21 November 2026; neither 17 nor 31 October may remain live. The 1 November row must retain the original 31 October recurrence identity. Do not apply that example's dates to my different schedule.
Inspect the actual file format, exact title/description, stable UID, original exception targets and absence of unapproved properties. If a parser or local checker is available, state its name/version, exact scope and actual results. A recurrence library is not a calendar-app test. Reject a corrupt cancellation, a changed moved-instance identity, a duplicate occurrence and a wrong all-day end in disposable in-memory copies. Keep original files unchanged. Separate executed checks from proposed tests; if you cannot run a check, say so. Never regenerate a broken result before evaluating it.

ORIGINAL SOURCE:
[paste]

ACTUAL ICS AND LEDGER:
[attach or paste]

AVAILABLE CHECKING TOOLS:
[list]

Expect: An audit of the actual saved ICS and CSV, using an independently derived date/identity list and separately labeled deliberate-error tests.
Check: Check every row, both absent dates, shared UID and the original 31 October identity for the 1 November occurrence. All ends are next day. Verify exact title/description, DATE values, CRLF content lines and no unapproved properties. In disposable copies, wrong cancellation, moved identity, duplicate occurrence and same-day end must be detected even if counts look right.
If it differs: If you only paste text, say byte checks were not performed. If code/parser access is absent, do manual date/identity comparisons and label the other checks pending. Keep failures before editing; repair a new revision, reopen and audit again. A recurrence calculation is not an app import test.

Review the handoff before any optional import

The finished files are ready for review. Application behavior still needs a separate user-controlled test in an empty calendar.

Your starting prompt

Give me a concise handoff for the checked source, ICS, live ledger and exception log. List the actual checks, unresolved holds and untested behavior. Do not claim the file was imported, that reminders exist, or that repeated imports deduplicate. Make no named-provider or account-plan claim without current official evidence.
If I choose an application test, first ask me to confirm an empty test-calendar destination and review its import/notification options. Give a checklist to verify each live date, each removed original date, the moved occurrence and one-day spans. Suggest testing a second import only in a disposable calendar I control, recording the actual behavior. Do not carry out an import, replacement, deletion, account connection or message from this request. Explain that a later real/shared-calendar change needs an explicit decision and that a new unrelated series must not reuse the demonstration UID.

CHECKED FILES AND AUDIT:
[paste]

Expect: A concise handoff listing saved source, ICS, ledger/log, actual checks, unresolved holds and untested app behavior.
Check: Nothing has been imported, sent, cancelled in an account or set as a reminder. A stable UID and deterministic file do not guarantee repeated-import behavior. The optional application test needs the user’s chosen empty test calendar and review of its import/notification options first.
If it differs: If the handoff claims successful import or deduplication without observation, remove the claim. Do not execute an import, replacement, deletion or account connection here. Any later live/shared-calendar change requires a separate explicit decision.

Optional: improve the result

Challenge exceptions before adapting the template

Use deliberately invalid sources and corrupt output copies to prove the audit catches identity and collision mistakes. Keep application tests separate.

Advanced prompt

Work only with copies of the supplied fictional files. Independently test these invalid source variants: cancel a date outside the original series; move one original to two different dates; move onto an occupied live date; cancel and move the same original; add an already occupied date; and use an impossible date. Record the precise hold reason and do not export any held schedule. Next mutate output copies: alter the cancellation, substitute a move's new date for its recurrence identity, duplicate an override or ledger row, omit the added date, change COUNT and use a same-day end. Each must fail the relevant invariant even if the total event count looks plausible.
If you can rebuild the unchanged baseline, compare bytes and UID/recurrence keys across two builds. Record actual dates, tool versions, hashes and results; do not manufacture execution evidence. A read-only rerun must check existing artifacts before any regeneration, and report its real rerun date without refreshing an earlier documentation date. Do not import anything or infer application deduplication from deterministic bytes. For your own schedule, extend the source and independent oracle together only after its rules and new tests are reviewed.

SOURCE, OUTPUTS, INVALID CASES AND AVAILABLE CHECKING TOOLS:
[paste or attach]

Optional: use your own input

Prepare your own finite all-day series for review

Use permitted non-sensitive dates/title/description. Keep this route to a finite weekly series of one-day all-day events. New unrelated series need their own stable unique UID; existing imported series require an explicit revision plan and destination-app review before creating an update. Start with the prompt below and resolve essential questions. For a confirmed new, unrelated draft series, obtain a fresh UUID-based UID from an available UUID generator and record it once in the source; ask for help if that tool is unavailable. Review initial SEQUENCE 0 and real UTC creation timestamps with the source, rather than copying the sample’s historical timestamps. Keep those approved values fixed on identical rebuilds. For an existing series, keep the revision-plan hold. Review the complete source, then send:
“Enumerate MY finite original slots including the first, independently of any previous output. Validate every cancellation/move target, dates and repeated edits before applying them. Enforce MY hold policy for unknown originals, conflicting edits and occupied live dates, including duplicate additions. If clear, produce chronological CSV with series_uid,recurrence_date,start_date,end_date_exclusive,occurrence_kind,summary, using regular/moved/added, plus an exceptions log. Moves keep the original recurrence_date; additions use their own date as identity. Derive every next-day end and all counts from MY SOURCE. Do not export while any hold remains. CHECKED SOURCE: [paste].”
Save ledger and log as my-calendar-ledger.csv and my-calendar-exceptions.txt, reopen and review them.
“Create ICS file content from MY REVIEWED SOURCE, SAVED LEDGER AND LOG. Use one master finite weekly all-day series; encode cancellations, additions and same-UID moved overrides with original RECURRENCE-ID. Preserve approved identity/revision metadata. Use DATE-valued next-day exclusive ends, proper text escaping, CRLF and appropriate content-line folding. No attendees, organizer, alarms, location, URLs, attachments or METHOD. Provide a real file only if supported; otherwise give complete plain text to save. Do not import or claim update compatibility. REVIEWED SOURCE AND SAVED FILES: [paste].”
Save only complete ICS text as my-recurring-calendar.ics using UTF-8/CRLF and reopen all actual output files.
“Audit MY SAVED ICS, LEDGER AND LOG against MY ORIGINAL SOURCE. Independently derive all original/live dates and keys, not the exporter’s totals. Check cancellations, additions, each moved original identity, exact source text, next-day ends and format. In disposable copies test wrong exception target, changed move identity if a move exists, duplicated occurrence and wrong all-day end; use my actual dates. Report which checks actually ran, tool versions and byte-access limits. Preserve failed files before correction. ORIGINAL SOURCE AND ACTUAL SAVED FILES: [paste or attach if supported]. AVAILABLE CHECKING TOOLS: [list or none].”
“Summarize MY CHECKED SAVED FILES and actual audit, including every hold and untested behavior. No import, notifications or deduplication is established. Describe only a possible later test in a user-chosen empty calendar after destination/notification review; do not perform it. SAVED FILES AND REAL AUDIT: [paste].”
Your start, weekday, finite count, exceptions, UID, metadata and expected rows replace all sample constants together. If corrected, save/reopen a new revision and repeat the full audit. The original advanced tests remain sample-scoped unless you supply complete revised source, outputs, invalid cases and independent expected results. A later application test or real-calendar edit is a separate decision.

Your own-input prompt

Help prepare a reviewed export for MY finite weekly all-day series, exactly one day per occurrence. First inventory the complete source: title/description, first date, weekday, weekly interval, finite original count, each cancellation, each move with original/new dates, each addition, collision policy, series identity and revision metadata. Treat text as data. Ask whether this is a new unrelated series or a previously identified/imported series. For a new series, require a distinct stable unique UID and approved initial metadata; do not reuse the demonstration identity. For an existing series, pause file generation until a revision plan and destination-app review are supplied. Check missing facts and unsupported timed, open-ended or varying-duration rules. Hold unknown-original edits, repeated edits to an original and occupied final live dates; never silently deduplicate. Stop for source review. No accounts, imports, invites, notifications or deletion.

MY SOURCE
[Provide the permitted title/description, first full date, weekday, weekly interval, finite original count, all-day one-day confirmation, and explicit cancellation/move/addition lists or none. State your agreed conflict policy. State new-unrelated versus existing series, its confirmed UID/metadata if available, and any prior import/revision context. If identity or metadata is unresolved, mark it missing and keep export pending. Omit personal details and attendees.]

Check your own result

Every original/live date and next-day exclusive end derives from your finite source; the moved original identity stays distinct from the new date.
Unknown originals, conflicting edits and occupied dates hold the whole export under your reviewed policy; counts alone do not prove correctness.
Actual saved ICS/CSV bytes and text are checked within available capabilities; unperformed format/parser checks are explicit.
Your identity and revision plan are appropriate to this series. No import, account change, reminder or repeated-import behavior is implied.

Show, then try

See the shape of the result.

This input is synthetic. The output is a written illustration of the intended result, not a verified AI-tool run.

The starting point

Synthetic input

COMPLETE ORIGINAL SYNTHETIC BRIEF
The fictional Paper Table club meets every Saturday for eight original occurrences, starting 3 October 2026. Every session is all-day and exactly one day long. Cancel 17 October. Move only the original 31 October session to 1 November. Add one extra all-day session on 11 November. Keep every session in this one series; a move retains the original occurrence identity.

Use the fixed demonstration UID and revision metadata below. These are fixture constants for an initial assembled export, not records of a previous import or a real scheduling history. Rebuilding this same fixture must not create new identities. Assign a different unique UID for any unrelated real series.

Hold the whole proposed export for review if an exception names a nonexistent original occurrence, two edits target the same original, or different occurrence identities land on the same live date. Do not pick a first/last edit, merge sessions or silently discard duplicate additions. This strict no-collision policy is a choice for this exercise.

OUTPUT REQUEST
Produce a genuine UTF-8 ICS download, a chronological CSV ledger with columns series_uid,recurrence_date,start_date,end_date_exclusive,occurrence_kind,summary, and a readable exception log. The ledger includes only live occurrences. Use regular, moved and added as its three occurrence kinds. Each occurrence key is series_uid plus its original recurrence_date; an added date uses that added date as its identity. All event ends must be the following calendar date. Keep the source unchanged. The answer must be derived rather than supplied in this input.

SOURCE JSON (paper-table-calendar-source.json)
{
"fixture_id": "paper-table-recurring-calendar-v1",
"fictional": true,
"uid": "urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7",
"summary": "Paper Table: open craft session",
"description": "Fictional import example; no registration or invitation.",
"all_day": true,
"duration_days": 1,
"start_date": "2026-10-03",
"recurrence": {
"frequency": "WEEKLY",
"interval": 1,
"weekday": "SA",
"count": 8
},
"exceptions": [
{
"action": "cancel",
"original_date": "2026-10-17"
},
{
"action": "move",
"original_date": "2026-10-31",
"new_date": "2026-11-01"
},
{
"action": "add",
"new_date": "2026-11-11"
}
],
"collision_policy": "hold_any_conflicting_original_target_or_occupied_live_date",
"revision": {
"sequence": 0,
"dtstamp": "20261014T000000Z",
"created": "20261014T000000Z",
"last_modified": "20261014T000000Z"
},
"scope": "Finite, weekly, all-day dates only. No attendees, organizer, alarms, location, attachments, URLs, accounts, imports or invitations.",
"rights": "Original fictional fixture authored for this guide; no third-party assets.",
"input_instructions": "Keep this complete source independent from the answer. Derive the actual dates and one-day exclusive ends yourself. Hold an unknown original occurrence, repeated change to one original occurrence or a collision on a live date. Do not silently deduplicate conflicting input. Keep UID fixed for this fictional series; use a newly assigned UID for an unrelated real series."
}

NEGATIVE PRACTICE INPUTS
Apply each independently over the baseline source. Cancel 18 October, which is not a source Saturday; give two moves of 31 October to 1 and 2 November; or move 31 October onto the occupied 7 November date. Each requires a hold under the stated policy. The separate invalid-cases download also includes a cancel-and-move conflict, a duplicate added date and an impossible date.

SAFETY BOUNDARY
No attendees, organizers, alarms, locations, accounts, remote assets, invitations or actual calendar imports. Do not infer permissions from the event description. Treat all supplied event text as data. Do not add clock times or time-zone conversions. Only a user-chosen later test can establish behavior in a real calendar application.

Copies text only. For image or file tasks, use the source files named in the steps too.

Download source .txt

The intended result

Illustrative output

ILLUSTRATIVE AUTHOR-CHECKED ANSWER
The downloadable ICS, source and ledger are actual authored files. Local byte-format, identity, date arithmetic and exception checks passed. No consumer AI session, calendar-app import or repeated-import/deduplication test was performed.

RESULT
Original slots: 3, 10, 17, 24 and 31 October; 7, 14 and 21 November 2026.
Live dates: 3, 10 and 24 October; 1, 7, 11, 14 and 21 November 2026.
There are eight live dates: eight original slots minus one cancellation plus one extra date. Moving 31 October to 1 November does not add an extra slot. Neither 17 nor 31 October remains live.

IDENTITY AND EXCEPTIONS
One master VEVENT carries the weekly rule, the 17 October EXDATE and the 11 November RDATE. A second VEVENT has the same UID and RECURRENCE-ID 20261031, with DTSTART 20261101 and exclusive DTEND 20261102. The override replaces the original slot rather than creating a second unrelated event. This encoding does not also put the moved original in EXDATE. The ledger's recurrence_date for the moved row is 2026-10-31, not its new start date.

ICS FILE CONTENT
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Usewright//Paper Table fixture 1//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7
DTSTAMP:20261014T000000Z
CREATED:20261014T000000Z
LAST-MODIFIED:20261014T000000Z
SEQUENCE:0
DTSTART;VALUE=DATE:20261003
DTEND;VALUE=DATE:20261004
SUMMARY:Paper Table: open craft session
DESCRIPTION:Fictional import example\; no registration or invitation.
RRULE:FREQ=WEEKLY;COUNT=8;BYDAY=SA
EXDATE;VALUE=DATE:20261017
RDATE;VALUE=DATE:20261111
END:VEVENT
BEGIN:VEVENT
UID:urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7
DTSTAMP:20261014T000000Z
CREATED:20261014T000000Z
LAST-MODIFIED:20261014T000000Z
SEQUENCE:0
DTSTART;VALUE=DATE:20261101
DTEND;VALUE=DATE:20261102
SUMMARY:Paper Table: open craft session
DESCRIPTION:Fictional import example\; no registration or invitation.
RECURRENCE-ID;VALUE=DATE:20261031
END:VEVENT
END:VCALENDAR

CHRONOLOGICAL LIVE-OCCURRENCE LEDGER
series_uid,recurrence_date,start_date,end_date_exclusive,occurrence_kind,summary
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-10-03,2026-10-03,2026-10-04,regular,Paper Table: open craft session
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-10-10,2026-10-10,2026-10-11,regular,Paper Table: open craft session
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-10-24,2026-10-24,2026-10-25,regular,Paper Table: open craft session
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-10-31,2026-11-01,2026-11-02,moved,Paper Table: open craft session
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-11-07,2026-11-07,2026-11-08,regular,Paper Table: open craft session
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-11-11,2026-11-11,2026-11-12,added,Paper Table: open craft session
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-11-14,2026-11-14,2026-11-15,regular,Paper Table: open craft session
urn:uuid:c226895e-cc06-40fc-8469-986b9bd2c8b7,2026-11-21,2026-11-21,2026-11-22,regular,Paper Table: open craft session

WHAT WAS CHECKED
A read-only checker enumerated Saturdays by Gregorian calendar day, independently of the builder's seven-day arithmetic, and compared the full output to a separate literal eight-row oracle. python-dateutil 2.9.0.post0 independently expanded the master's recurrence-set rules; the detached move was then applied by the bounded checker. No independent full ICS parser was installed. The custom parser checks this narrow fixture, not every legal iCalendar construct.
Six invalid input variants, sixteen corrupt ICS variants and four bad ledger variants were rejected. The source and artifact hashes were unchanged after checking. A separate rebuild from the identical fixed input reproduced all five artifact files byte-for-byte, including the UID and recurrence identity. That checks the export builder; it does not prove how an application handles a second import.

BEFORE USING YOUR OWN SCHEDULE
Review the source and conflict policy. New unrelated series need a new UID. Keep a move's original date distinct from its new date. Stop if your schedule needs times, changing durations, unbounded rules or ambiguous exceptions. Preserve an unchanged source copy and a reviewed ledger.

OPTIONAL APPLICATION TEST, NOT YET PERFORMED
Select an empty test calendar yourself and review the destination and notification settings before importing. Check all eight dates, both absent dates and every one-day span. Test a repeated import only in a disposable calendar you control, then record whether that application duplicates, updates or rejects the file. Stable IDs alone do not establish this behavior. Do not treat a download as an import, reminder setup or cancellation notice. Any import into a live/shared calendar, replacement or deletion is a separate action requiring your decision.

Download result .txt

You’re the final check

Check the worked example.

These checks use the worked example and its particular facts. With your own material, check your actual names, numbers, sources and rules; do not reuse the sample’s values as the answer.

The eight original slots are Saturdays from 3 October through 21 November 2026; COUNT includes the first slot.The exact live dates are 3, 10 and 24 October and 1, 7, 11, 14 and 21 November. Neither 17 nor 31 October survives.The 1 November occurrence has the same series UID and original recurrence identity 2026-10-31. It is not an unrelated ninth event.Every live occurrence has a unique (series_uid, recurrence_date) key, a unique start date under the agreed policy and an exclusive end one day later.The master contains one cancellation and one extra date; the detached override changes only its targeted original slot. Titles, descriptions and revision controls match the source.Unknown original dates, conflicting edits and occupied-date moves are held before export. Corrupt exceptions and duplicated rows fail independent checks.The real ICS uses CRLF content lines and DATE values, with no attendees, organizer, alarms, accounts or external assets. A download does not create calendar entries.Consumer AI execution, full calendar-app import, repeat-import behavior, notifications and time savings remain untested or unmeasured.

Unsaved checks stay in this tab and reset when you reload. If you choose Save guide, its current example checkmarks are kept in this browser when storage is available.

A few things to watch for.

Replacing a moved occurrence with an extra independent event and accidentally keeping the original date.
Changing RECURRENCE-ID to the new date, which loses the identity of the original slot.
Treating COUNT as the number of dates left after cancellations, or extending the weekly rule to compensate.
Using the same date for DTSTART and DTEND on a one-day all-day event, or introducing midnight times and time-zone assumptions.
Automatically merging two sessions that land on the same day instead of asking how the conflict should be resolved.
Assuming stable UIDs mean every application will safely deduplicate a repeated import or update a previously imported calendar.

What has been checked?

Documentation: Reviewed 2026-10-14. Source review is not workflow execution.
Included files: Scoped checks passed on 2026-10-14. File parsing; Fixture checks. See scope below.
AI workflow: Not run in a recorded consumer-AI workflow.
Time savings: Time savings not measured

Read the scope and evidence

paper-table-recurring-calendar.ics

2026-10-14 · parser · passed

Custom parser for this exact finite all-day fixture: envelope, properties, DATE values, text escaping, CRLF and bounded content lines. This is not general RFC certification or application compatibility.

One VCALENDAR, one master VEVENT and one detached override
Physical lines use CRLF and are at most 75 octets
Description semicolon unescapes to the exact source text
No attendees, organizer, alarm, location, METHOD or external-resource property

Environment: Python 3.12.14 standard-library bounded ICS parser, csv, calendar/date arithmetic and SHA-256 checks on Linux; python-dateutil 2.9.0.post0 for separate recurrence-set expansion. No full independent ICS parser installed; no consumer AI or calendar application used.

SHA-256: 1af557fb6b25827183f95ed43f142bb185084b01d6f1eee8654f93d5f7e721cd

paper-table-recurring-calendar.ics

2026-10-14 · semantic fixture · passed

Independent day-by-day Saturday enumeration and literal outcome oracle; python-dateutil separately checks the master recurrence set, with the detached move applied by the bounded checker. Sixteen corrupt ICS variants rejected. A separate identical-input rebuild preserved exact bytes and identities.

Eight original Saturdays and exact eight live dates
17 and 31 October absent; exactly one live 1 November slot
Moved slot retains recurrence identity 31 October under the master UID
11 November is an extra date in the same series
All-day ends are the next date; fixed initial revision metadata preserved
16 corrupt ICS variants rejected, including wrong exception target, duplicate override, wrong UID and wrong all-day end

SHA-256: 1af557fb6b25827183f95ed43f142bb185084b01d6f1eee8654f93d5f7e721cd

paper-table-calendar-source.json

2026-10-14 · parser · passed

UTF-8 JSON parsing and explicit bounded input-contract validation on the complete source; no solved answer is read from this source.

Complete finite weekly rule and three exception records
Exact title, description, fixed UID and revision controls
All-day one-day duration and explicit no-collision policy

SHA-256: 8f11c8e189496adf3facd210d7badb460896850544b21e959a825d218acf6535

paper-table-calendar-source.json

2026-10-14 · semantic fixture · passed

Source expansion checked against independent calendar enumeration and a separate literal output oracle. Source hash remained unchanged during checking.

Eight Saturdays from 3 October through 21 November
Cancel 17 October; move original 31 October to 1 November; add 11 November
No duplicate live dates or occurrence identities
Identical fixed-input rebuild preserved source and generated artifact hashes

SHA-256: 8f11c8e189496adf3facd210d7badb460896850544b21e959a825d218acf6535

paper-table-occurrences.csv

2026-10-14 · parser · passed

Strict CSV parsing, exact six-column header and full-row oracle comparison. Literal CSV bytes are checked; no spreadsheet-app import.

One header and eight complete data rows
Exact source title and UID in every row
Chronological starts and unique series/recurrence key pairs

SHA-256: 92abf48527d9bd5f504d6e24bffd5429913c8e4a0aee0abf68bfb704fa7ed530

paper-table-occurrences.csv

2026-10-14 · semantic fixture · passed

Every row compared to independently transcribed identity/start/end/type controls, not only a row count. Four corrupted ledger variants rejected.

Exact eight live dates with next-day exclusive ends
Moved row has recurrence_date 2026-10-31 and start_date 2026-11-01
One added 11 November row; six regular rows and one moved row
Duplicate row, missing row, wrong recurrence key and changed title rejected

SHA-256: 92abf48527d9bd5f504d6e24bffd5429913c8e4a0aee0abf68bfb704fa7ed530

paper-table-exceptions.txt

2026-10-14 · semantic fixture · passed

Readable exception log reviewed against the source and exact live ledger; checker confirms all live starts/ends, moved original identity and the no-import boundary. This does not test app behavior.

Cancellation, moved-instance identity and addition described
All eight starts and next-day ends present
Import, repeated import and notification behavior explicitly untested
Stable UID is not presented as a deduplication guarantee

SHA-256: 284c80bf90ef80ddb0e190843ec6f0ac7dcaad571c7dc405c9756aa2db6cdcb0

paper-table-calendar-invalid-cases.json

2026-10-14 · semantic fixture · passed

Six independent replacement-exception lists were applied in memory to the original source; each was held for its expected reason before export.

Unknown original occurrence held
Conflicting moves and cancel-plus-move held
Move onto occupied live date and duplicate addition held
Impossible date held; source file unchanged

SHA-256: 60f26562d0ad596799380737de71c1e37ae8173996d5da446fe09dc271d81b3e