Confirmation and Safety
Calendaria is designed around a simple rule: reads can be fast, writes must be confirmed.
Read operations
Read-only commands execute immediately:
- listing events
- checking what is on a day
- looking at a time window
- finding free slots
- listing booking links or group invites
- answering status-style questions
Write operations
Calendar mutations create a pending action first:
- create an event
- move or edit an event
- respond to an invitation
- delete an event
- invite attendees
- create a booking link
- create a group invite
The bot shows a human-readable summary. The real provider API call happens only after you confirm.
Some restrictive actions execute immediately because they only reduce access:
- revoke a booking link
- close a group invite
Those actions stop future public use of a link. They do not delete existing calendar events.
Why this exists
Natural language can be ambiguous. A model can misread a time, choose the wrong event, or infer a parameter you did not intend. Confirmation keeps the speed of natural language while protecting the real calendar.
Conflict warnings
When Calendaria detects conflicts for a create or move request, it warns you and may suggest alternative slots. Choosing an alternative slot is treated as explicit confirmation for that slot.
Calendaria does not refuse a double-booking on your behalf. The warning is shown next to the confirmation controls so you can decide.
Audio requests
Audio never bypasses the confirmation model. Calendaria transcribes supported audio first, then treats the transcript like a typed user request: reads may run immediately, while writes still create a pending action and wait for confirmation.
Raw audio is not persisted by Calendaria. The transcript may be saved in normal conversation history as the user prompt, just like text you typed directly.