Did you know? A calendar agent can move one meeting on a Tuesday and accidentally move every Tuesday meeting in the series—or silently erase a colleague’s more recent change. The difficult part is not displaying appointments. It is preserving the distinction between an event resource, a recurring series, an individual occurrence, the calendar’s time-zone interpretation, and the remote server’s current revision.
The safe answer is to treat CalDAV calendar synchronisation as an evidence-controlled process: discover the authorised calendar collection, read full iCalendar resources rather than relying on truncated event labels, interpret recurrence identifiers and exceptions under the calendaring standard, compare entity tags before changes, and reconcile collection changes before claiming success. A recurring appointment should never be flattened into independent events without an explicit ownership and update strategy.
This article explains engineering for presently available AI assistants and calendar tools. Artificial superintelligence remains hypothetical, and nothing in the examples implies that an autonomous future system exists. Every sample calendar, time and count below is illustrative. It describes what a responsible integration should check, not a claim that a live calendar was accessed or changed.
Contents
- Why a calendar item has more than one identity
- Discover capabilities before issuing a write
- A recurrence rule defines a set, not a row-per-day table
- RECURRENCE-ID is the bridge between an override and its original slot
- Worked calendar example: six Tuesdays, an exclusion and a moved occurrence
- Why time zones and date-only items need separate rules
- An ETag guards an individual representation from a lost update
- Collection sync tokens and per-resource validators answer different questions
- Worked reconciliation: nine resources, three changes and one deletion
- A safe write transaction for one authorised calendar edit
- Scheduling participants requires more than editing a date
- Calendar descriptions are data, not instructions to the agent
- Nine failure patterns and the appropriate first repair
- Transfer exercise: a postponed workshop and a cancelled series member
- What CalDAV validation can and cannot guarantee
- Frequently asked questions
- Reader pathways and exact primary references
Why a calendar item has more than one identity
A human sees a box labelled “team review at 10 am”. A synchronising client sees an addressable collection containing resources, each with an HTTP representation, calendar properties and identifiers inside an iCalendar component. Confusing those layers leads to duplicated events, accidental mass edits and incorrect deletion. A URI identifies a resource within a collection; the iCalendar UID helps identify the logical event; a recurrence identifier distinguishes one occurrence or override. These are related but not interchangeable.
Suppose two users see the same shared meeting but access it through different calendar collection URLs. A path displayed in one account is not proof of authority to change the other account’s resource. The agent should resolve which principal, calendar home set and collection belong to the authorised user and which resource may be read or written. Human wording about an appointment is not itself a permission to edit every shared calendar containing a matching title.
A recurring series commonly lives as one iCalendar object with recurrence rules and possibly exception components. Multiple visual calendar squares can derive from that one object. An agent that stores each square as a separate canonical meeting may fail to preserve the relation among occurrences. Conversely, a calendar may contain independent meetings with identical text. Matching only summary, date and participants can wrongly merge them.
Use a durable local mapping for calendar collection identity, resource URI, UID, known ETag and last verified sync state. If the calendar server relocates a resource, the mapping needs reconciliation. A UID is not an HTTP authorization token; a resource URL is not a permanent promise that a series contains the same set of occurrences. The state must be revalidated at the point of a consequential operation.
The protocol baseline is RFC 4791, Calendaring Extensions to WebDAV. It builds on WebDAV rather than inventing a separate calendar-only transport. For the object grammar, recurrence logic and time semantics, consult RFC 5545, Internet Calendaring and Scheduling Core Object Specification.
Discover capabilities before issuing a write
CalDAV servers expose collections and supported methods through authenticated WebDAV mechanisms. A client should learn which principal and calendar collections it is entitled to use, which reports the server supports and whether the target collection is writable. Do not infer capability from the appearance of a calendar in an app. A read-only subscribed calendar may resemble a writable owned calendar in the interface.
A useful initial read distinguishes calendar home sets, actual calendar collections and other WebDAV resources. Properties identify supported calendar component types and server behaviour. The collection might permit VEVENT but not VTODO; another might be configured with different limits. The agent’s proposed action must match the target collection’s advertised affordances and the user’s authorisation.
Do not assume all servers implement every optional WebDAV synchronization extension. Standard CalDAV reports can query time ranges and resource data. Incremental synchronization with DAV:sync-collection is defined separately in RFC 6578 and requires advertised support. If a server lacks that extension, use a supported collection inventory approach rather than pretending a sync token exists.
The identity of the calendar host matters. Credentials and authorization tokens must not follow arbitrary redirects to unrelated hosts. An invitation description, VEVENT ATTACH link or meeting notes can include external addresses, but these remain untrusted content. Parsing a calendar is not permission to fetch remote attachments or transfer credentials. Keep network and credential scopes narrow.
A client should record capability results with the time of discovery and recheck after changes or unexpected responses. A server upgrade may alter supported reports, limits and error semantics. Robust integrations adapt to authenticated evidence rather than hard-code assumptions based on a single familiar calendar service.
A recurrence rule defines a set, not a row-per-day table
In iCalendar, DTSTART identifies the initial start and RRULE, RDATE and EXDATE contribute to the recurrence set. RRULE can express weekly frequency, intervals, day-of-week filters and finite counts or limits. RDATE adds explicitly included dates; EXDATE removes dates. Duplicates do not become repeated occurrences merely because both RRULE and RDATE mention the same start. Treat the set semantics as a defined algorithm, not a casual text pattern.
RFC 5545 specifies that excluded start date-times take precedence over recurrence inclusions. A calendar series containing a weekly meeting and one EXDATE therefore does not include that occurrence in its recurrence set. If an agent expands the RRULE but forgets EXDATE, it may send a reminder for a cancelled meeting. If it assumes RDATE overrides exclusion, it can also reintroduce an intentionally removed instance.
A series can use a local time zone. A meeting scheduled for a consistent local wall-clock hour across a daylight-saving change may correspond to different UTC offsets at different dates. Adding seven times twenty-four hours to a UTC timestamp is not a general substitute for computing a recurrence in its original time-zone semantics. The agent temporal semantics guide explains related boundaries between a displayed time and an effective timestamp.
Recurrence expansion should be bounded to the required interval. Expanding a recurring appointment forever is neither necessary nor safe. A user asking for tomorrow’s schedule needs a defined time window, and an agent estimating future workload might need a three-month window. The chosen window, inclusion boundary and time zone belong in the calculation receipt.
The agent must distinguish changing a rule from changing a single generated occurrence. If the user says “skip next Tuesday”, the repair may be a single exclusion or exception rather than deleting the series. If they say “move every Tuesday review to Wednesday”, the series definition may need revision. Vague language can affect many events; where intent is unclear, propose the precise impact rather than silently selecting the broadest operation.
RECURRENCE-ID is the bridge between an override and its original slot
An individual exception to a recurring event is not necessarily a fresh unrelated appointment. A component using RECURRENCE-ID identifies the original recurrence instance being overridden. Its actual DTSTART may differ because the particular meeting was moved. This distinction means a client cannot identify the overridden instance solely by the updated time now visible on the screen.
Imagine a weekly Tuesday meeting at 10:00. One occurrence originally scheduled for 10:00 is moved to 11:30. An override may carry RECURRENCE-ID matching the original 10:00 slot while DTSTART expresses 11:30. If the agent searches for an occurrence starting at 11:30 and tries to edit that as a new independent meeting, it risks creating a duplicate or losing the link to the parent series.
Exceptions can interact with cancellations, start changes and future series changes. An edit to the master recurrence definition may not automatically produce the human-intended result for every previously overridden instance. A good interface previews the affected instances and presents those with special modifications separately. An override can contain changed location or participants as well as time; preserving only the start time is not enough.
The standard distinguishes recurrence identity from occurrence data. An agent should parse the complete component fields and preserve unfamiliar but valid properties where its implementation permits lossless round-tripping. An application that rebuilds a resource from a handful of fields may strip organizer, attendee, alarm or vendor-extension information that it was never authorised to discard.
Before modifying a single instance, resolve the UID, original RECURRENCE-ID, current representation, ETag and permitted scope. After the write, re-fetch and expand the target window again. The correctness question is not only whether the intended occurrence moved; it is whether every other occurrence and exception stayed intact.
Worked calendar example: six Tuesdays, an exclusion and a moved occurrence
Consider a fictional weekly meeting beginning Tuesday 6 October 2026 at 10:00 local time, with a COUNT of six. With a simple weekly rule and a matching DTSTART, the six nominal dates are 6, 13, 20 and 27 October, then 3 and 10 November. The example assumes a time zone without a daylight-saving offset change in this interval, merely to keep the arithmetic focused on recurrence membership.
Now remove the 20 October instance using EXDATE, and move the originally scheduled 3 November instance from 10:00 to 11:30 with an override whose RECURRENCE-ID is the original 3 November 10:00 slot. The set has six nominal dates minus one excluded date, leaving five active occurrence identities. The moved item changes start time but does not add a sixth active identity.
The resulting displayed meetings are 6 October 10:00, 13 October 10:00, 27 October 10:00, 3 November 11:30, and 10 November 10:00. Counting calendar boxes yields five. A naive importer could produce six by ignoring EXDATE, or six by counting the 3 November override as an extra event while retaining the original slot. A more damaging importer might delete the entire series upon seeing a cancelled instance.
Suppose a client is asked to send reminders for the active occurrences in the first calendar month of the sequence, October 2026. Three remain: 6, 13 and 27 October. The excluded 20 October is not a reminder target, and the moved 3 November event is outside the October window. Under the specific fictional rules, the number of October reminders is 3, not 4 or 5.
This is a checked set-membership example, not a test on a real calendar server. Real implementations must also account for local time-zone identifiers, potentially different recurrence constraints, attendee scheduling rules and any server-specific supported extensions. The key invariant is that expansion of a window follows the source recurrence semantics and current resource version.
Why time zones and date-only items need separate rules
A date-only event is not simply a midnight instant. An all-day event might carry a DATE rather than a DATE-TIME. Converting the date to midnight UTC and showing it in a distant time zone can shift the displayed day. A calendar assistant should preserve the value type, time-zone context and explicit end semantics rather than passing everything through a generic timestamp field.
Floating local times, UTC times and local times associated with a TZID represent different kinds of information. A meeting tied to a named geographic time zone can cross a daylight-saving transition while retaining a consistent intended local clock time. A floating time does not have the same fixed mapping to a global instant. The agent needs the original representation or a carefully controlled conversion, not an accidental default from the server where its code runs.
In scheduling conflicts, compare actual instants only after interpreting the time zones correctly. Two meetings displayed at 09:00 in different zones may not overlap. Conversely, events with different local display hours can overlap after conversion. Conflicts also involve durations and exclusive end boundaries; point-in-time comparison alone is insufficient.
For a cross-border meeting that lasts sixty minutes, compute UTC start and end using the event’s valid time-zone rules for that date. Do not reuse today’s offset for a future date across a seasonal transition. When a local time is ambiguous or nonexistent because of a clock change, follow the calendaring standard and the application’s documented policy and present uncertainty when necessary.
Sensitive tasks deserve an audit trail recording original value type, TZID, expanded UTC instants and the user’s displayed time zone. The agent should never silently rewrite all-day events into timed events or schedule reminders at the wrong local date in the name of normalization.
An ETag guards an individual representation from a lost update
A calendar resource can change between reading it and writing an update. ETags are server-issued validators for representations. A client that reads version A, changes a meeting locally and PUTs a replacement after another participant has saved version B may erase B if no precondition is used. Sending If-Match with the ETag observed for the intended resource can protect against that lost-update pattern where the server enforces HTTP conditional semantics.
Consider a fictional resource with ETag ‘v7’. The agent reads v7 and proposes moving one occurrence. Meanwhile another participant adds a call-in detail, creating v8. A conditional PUT using If-Match for v7 should fail rather than overwrite v8. The agent must then fetch v8, compare the intended change with the intervening difference, and produce a revised proposal. It must not suppress the precondition to make the request pass.
An ETag is not a universal calendar identity. It can change when the representation changes and must not be treated as an immutable UID. Nor does matching an ETag guarantee semantic correctness. A valid conditional write could still unintentionally modify every instance because the agent interpreted the user’s request incorrectly. Use both optimistic concurrency and domain-aware scope checks.
HTTP conditional request handling is defined in RFC 9110, HTTP Semantics. An ETag-related mismatch can yield a precondition failure; the recovery path is read–compare–repair rather than blind overwrite. The sibling concurrent document edits guide explains ETag guards in more general editing contexts.
Save the ETag used, write action, response and new ETag or verification result. A successful status code is evidence about one server request, not proof that a user’s devices all show the same calendar view. A subsequent read of the specific resource and, where necessary, collection sync establishes what the server currently holds.
Collection sync tokens and per-resource validators answer different questions
RFC 6578 introduces the DAV:sync-collection report and synchronization tokens for servers that support it. A token tracks a collection-level change state so a client can ask what member resources changed or were removed since its previous synchronization. A per-resource ETag, by contrast, helps identify a particular resource representation. These are separate controls and should not be interchanged.
A sync report can identify changed and removed member URIs and return a new token. It normally does not hand the application a complete trusted reconstruction of all calendar event semantics. The client still needs to fetch or inspect changed calendar resources as necessary, interpret recurrence and compare versions. It may also encounter a new change between reading a sync response and fetching a resource.
An old token can become invalid when a server no longer retains sufficient history or changes its implementation. RFC 6578 specifies a recovery path: resynchronise using an empty token and inventory the collection. The agent should treat this as a state-rebuilding event, not as a signal to delete all local meetings or assume none changed.
Tokens are opaque. Do not parse them as sequential counters or compare numeric substrings to infer order. A string that happens to end in 100 is not necessarily newer than one ending in 99. The server’s reported semantics, not guessed token structure, define the progress marker. Preserve the token associated with a completed stable reconciliation point.
Because CalDAV and WebDAV sync are related but separable standards, a client must check actual support. It is acceptable to use another supported report and ETag inventory strategy when sync-collection is unavailable. It is not acceptable to claim incremental completeness based on a method the server never advertised.
Worked reconciliation: nine resources, three changes and one deletion
Imagine a fictional calendar collection containing nine resource URIs at the last verified sync token. Since that state, the server has changed three of those resources and removed one other resource; no new resource was added. On a supported incremental sync, the client should account for the three changed members and the removed member. Eight resources remain, because the starting nine minus one deletion equals eight.
The three changed resources may contain many displayed recurrence instances. Do not confuse ‘three changed resources’ with ‘three changed meetings’. One modified weekly series might affect dozens of visible occurrences, while a single deleted independent event might remove one. The client first reconciles resource membership, then expands the affected iCalendar contents within the user’s required view window.
Suppose the client successfully refetches two changed resources but its connection drops before the third is fully stored. It must not permanently advance its authoritative local sync checkpoint as though all three changes were incorporated. Keep a provisional token and a pending-work list, or use a durable staging transaction, then finish the reconciliation. Otherwise a later incremental report may omit the missing change because the token says it was already consumed.
Now imagine the missing resource was modified again before retrieval. The client should use the current fetched version and suitable ETag comparisons rather than falsely assuming that a prior snapshot remains available forever. RFC 6578 explicitly recognizes the window between sync reporting and later resource fetching. An inconsistent partial snapshot calls for another reconciliation pass, not a made-up claim that every member was captured at one instant.
If the remote reports the formerly removed URI as newly created before the next sync, identity handling must respect the current resource mapping and underlying calendar identifiers. The name alone does not establish that the old item returned unchanged. The bookkeeping needs separate fields for URI membership, UID semantics and observed representation.
A safe write transaction for one authorised calendar edit
Begin by resolving the actual user instruction. Does ‘move the meeting’ mean one instance, the full series or a time-bound set of future occurrences? Extract the UID, recurrence identifier if any, intended new time and calendar authority. Identify who owns the calendar and whether scheduling notifications or attendee invitations could be triggered by the server or client.
Fetch the complete current resource and ETag. Make a diff at the iCalendar semantic level before serialising an updated representation. The diff should state which component changes, which properties are intentionally preserved and which new times are computed. Compare the affected recurrence expansion before and after the proposal in a bounded window that includes adjacent occurrences and exceptions.
Review scope and conflicts. If the change would alter more than the intended occurrence, stop or obtain further approval. If there is a conflict with another event, the agent should report it rather than secretly move unrelated meetings. Other attendees can have conflicting availability even when the owner is free. A proposed time is not confirmed merely because the local calendar grid is empty.
Perform a conditional write against the saved ETag where supported and appropriate. On precondition failure, fetch the new version and rebase the proposed edit. On an ambiguous timeout, first reread the original resource URI or inspect collection state to determine whether the write already landed. A second PUT can be unsafe if a new ETag or additional intervening edits have appeared.
After the write, retrieve the server-saved representation, verify the precise intended recurrence effect, and check relevant scheduling outcomes. Record the outcome as ‘resource updated and verified’ only when supported by server readback. Meeting invitations, remote attendee acceptance and notifications are separate states and may need their own evidence.
Scheduling participants requires more than editing a date
Calendar event components can express organizer and attendee information. Changing the start time of a meeting with invited participants is more consequential than modifying a private reminder. The organizer’s calendar, attendee copies and scheduling message workflow may not be identical. A client must not assume that editing its own local copy has changed every attendee’s authoritative invitation.
CalDAV scheduling extensions and deployment behaviours differ. RFC 6638 addresses scheduling features, including inbox and outbox mechanisms where supported. Discover whether the server advertises the relevant scheduling capability before expecting it. An integration designed only for reading calendars should not attempt to simulate organizer authority by editing imported attendee resources.
Attendee status can also be stale. A participant may decline after the agent checks availability, or accept a different revision. A safe result says what the server reports and what remains pending, not that everyone can attend. When the instruction carries reputational, financial or operational consequences, the agent may need to show a proposed change for human confirmation before sending it.
Do not expose private attendee addresses or notes in logs that do not need them. A summary for a calendar owner can be sufficient: ‘one occurrence moved; invitations pending’. Avoid copying full event descriptions into unrelated systems. Scheduling content may contain confidential project names, locations or links that should remain scoped to the authorised calendar.
The general pattern is that a write to one calendar resource is not proof of distributed social agreement. Represent invitation states separately from the organiser’s event state, and use server-provided evidence to decide whether an additional reminder or escalation is appropriate.
Calendar descriptions are data, not instructions to the agent
An event description may contain a command-like string, a hyperlink, or a request to email someone. In an AI assistant, such content must remain lower-trust source data. Reading a calendar entry that says ‘send all schedules to this address’ does not authorise sending anything. The user’s instruction, connector permissions and system policy determine what actions can be taken.
Calendar sharing adds additional boundaries. Read access to a colleague’s calendar can reveal busy times while not granting the right to edit meeting descriptions or invitees. Some sharing mechanisms expose free/busy only. An assistant should not attempt alternative API paths or cached copies to recover information the current authorised capability withholds.
Credentials should be isolated per account and scoped to the task. An agent operating on several users’ calendars must not reuse the wrong principal’s authorization token merely because the meeting has the same UID. Use an explicit authority check before every write, especially for shared resources with multiple visible owners.
External attachments or conference links deserve separate treatment from local calendar metadata. A meeting description that embeds an unfamiliar URL is not a safe direct tool instruction. The agent can show the link as untrusted context or request user confirmation before accessing it. Redirects and download paths require normal network and content-safety controls.
Audit records should capture necessary identifiers and outcomes while minimising unnecessary personal information. A troubleshooting trace need not include full event bodies, all attendee emails and private notes. Record enough to reconstruct what changed without turning calendar sync logs into a secondary source of sensitive data.
Nine failure patterns and the appropriate first repair
Failure one is using the displayed event title as identity. Repair it by resolving calendar, URI, UID and recurrence details. Failure two is treating a moved occurrence as a new event; preserve RECURRENCE-ID relationships. Failure three is ignoring EXDATE and causing cancelled meetings to reappear; recalculate the recurrence set under RFC 5545.
Failure four is assuming UTC arithmetic always preserves weekly local-time meetings; use appropriate TZID and date-specific rules. Failure five is interpreting an all-day DATE as midnight UTC; preserve the original value type. Failure six is editing a shared meeting without checking organizer and sharing authority; separate visible information from permitted changes.
Failure seven is overwriting another user’s edit because the client never checked an ETag. Recover by reading the current resource and merging the intended change, not by issuing an unconditional PUT. Failure eight is treating an old collection sync token as permanent. On invalid token, rebuild supported membership state while preserving verified local changes appropriately.
Failure nine is claiming calendar synchronisation is complete after a successful response for only part of the collection. Keep pending resource fetches, provisional checkpoints and a reconciliation pass. A calendar can appear correct in one small week view while a changed recurrence exception outside the window remains unresolved.
These patterns reveal the deeper problem: an agent confuses its own convenient representation with the external system’s state. Repair begins at the earliest uncertain boundary. For changes to an individual resource, reconcile its current ETag and contents. For changes across a collection, reconcile the membership and token. For participant decisions, seek their authoritative scheduling status rather than inference.
Do not compensate for an incomplete state model by adding increasingly confident natural-language summaries. The calendar should be verifiable through concrete identifiers, resource versions, recurrence expansion and current permissions.
Transfer exercise: a postponed workshop and a cancelled series member
Imagine a training workshop scheduled for the first Friday of each month from January through April. Its master recurrence yields four nominal occurrences. February’s session is cancelled with EXDATE, and March’s session is rescheduled to the following Monday through a RECURRENCE-ID override. The active recurrence identities therefore number four minus one, or three; moving March does not add an extra identity.
An assistant asked ‘How many sessions still exist?’ should clarify the relevant date window and which occurrences are past. For the complete January–April window, the illustrative active series has three sessions: January’s original, March’s moved occurrence and April’s original. For an April-only view, there is one. This distinction demonstrates how the same series can generate different correct counts under different query windows.
Now change the context. Another organiser has edited the April location since the agent fetched the resource. The user asks to change March’s workshop time. The client cannot safely serialize an old version of the entire resource with March updated and April location stale. The conditional ETag guard should reject the stale write. The repair is to fetch the current representation, preserve the April location and reapply the single March change.
Finally suppose the server does not advertise DAV:sync-collection. The agent must not report that a collection sync token is missing because the collection is corrupt. It can use CalDAV-supported REPORTs or property-based inventory methods that the server actually advertises. Complete verification means the required window and affected resources were checked, not that a particular optional extension was invoked.
The transfer principle is stable: scope the user’s requested outcome, resolve unique identity, preserve recurrence and property semantics, condition writes on current evidence, and re-fetch the external truth before declaring success. It applies to calendars that look different in the interface because the underlying correctness job is the same.
What CalDAV validation can and cannot guarantee
CalDAV and iCalendar standards tell clients how calendar data should be represented and exchanged. A conforming representation does not guarantee that the participants agree, that a room is available, or that an organisation’s internal booking policy has been satisfied. Those are distinct external facts requiring their own authoritative checks.
A successful conditional PUT can establish that one resource update was accepted under server conditions, but not that every attendee received a notification. A complete collection sync can establish that the client processed the reported collection changes, but not that its interpretation of every future recurrence is human-intended. An agent must communicate the boundary of each verified receipt.
Not every server supports every optional feature. Some CalDAV deployment extensions or scheduling workflows are service-specific. Prefer capability discovery and official server documentation for such features. Do not treat the examples in one vendor’s guide as universal protocol requirements, or erase valid unknown properties simply because a narrow client does not recognize them.
Recurring series can include intricate rules, local time zones, overrides and changing participant states. A resource may be too complicated for an agent’s current implementation to edit safely. The right behaviour is to provide a bounded proposed change or escalate to a supported client, not to serialize a simplified series that silently discards data.
The numerical cases here were constructed for clarity. They establish how to count and compare under given assumptions, not evidence of a particular calendar service’s reliability or compatibility. A production integration needs conformance tests, permission tests, adverse-time-zone cases and repeatable reconciliation results.
Frequently asked questions
What is CalDAV? It is a set of calendaring extensions to WebDAV for accessing and managing calendar resources over HTTP. The full standard is RFC 4791, with iCalendar object semantics defined in RFC 5545.
What is the difference between UID and RECURRENCE-ID? UID identifies the logical calendar component or series; RECURRENCE-ID identifies an original recurrence instance to which an exception belongs. A moved occurrence’s new start time is not its recurrence identifier.
Can a recurring meeting be stored as separate events? A calendar app may display separate occurrence boxes, but a client should preserve the original recurrence series semantics unless explicitly migrating them under a carefully defined strategy.
Why is EXDATE important? It removes specified occurrence start values from the recurrence set. Ignoring it can re-create cancelled events or send incorrect reminders.
Why use If-Match with ETags? It helps prevent replacing a resource that changed after the client read it. A stale write should be reconciled instead of forced through.
Does a sync token replace individual ETags? No. The token describes a collection change state; ETags validate individual resource representations. They answer different questions.
What should happen if a sync token expires? Where RFC 6578 is supported, the client can recover with a full synchronization path. It must not assume the calendar is empty or drop verified local information without reconciliation.
Can an assistant move all future meetings without confirmation? Only when the user has actually authorised that scope and the integration can preserve exceptions and attendee requirements. A request about one Tuesday should not silently edit the entire series.
Is a successful calendar update the same as attendee acceptance? No. Organizer resource state and each attendee’s invitation decision are separate facts.
Do these instructions require an artificial superintelligence? No. They are conventional integration safety rules for existing calendars and AI-assisted workflows; future ASI is hypothetical.
Reader pathways and exact primary references
If you build calendar integrations, begin with a small test collection containing one independent event, one weekly series, one EXDATE and one moved override. Check bounded expansion before and after a conditional edit. Then add two concurrent writers and an invalid synchronization token; verify that the system refuses stale edits and reconstructs collection state without deleting unmodified items.
If you audit an assistant, ask for the calendar collection, resource URI, UID, recurrence identifier, original and new ETag, selected time window, participant authority and readback result. If the assistant cannot provide those, it should report what remains uncertain. For adjacent safety, read Agent Scheduled Work and WebDAV Multi-Status.
The official sources are RFC 4791 (CalDAV), RFC 5545 (iCalendar), RFC 6578 (WebDAV collection sync), RFC 6638 (CalDAV scheduling extensions), and RFC 9110 (HTTP Semantics). Check each server’s actual advertised support; a standard describing a feature is not proof that a particular server implements it.
The calendar workflow is one example of learning to differentiate a proposal, a protected change and a verified external outcome. For the wider engineering series visit How Super Intelligence Works, and for education that transfers into everyday reasoning read The Gold Standard of Education.