A calendar says who you are talking to, not only when
A calendar is the most indiscreet source a company can connect. An appointment's title names the person on the other side, a two-hour slot on a Tuesday morning says something is going on, and the guest list tells the rest. A medical appointment, an exit interview and lunch with a competitor all carry a title.
It is also the source that places work in time better than any other. Who met this client, when, with whom, and what the meeting was about. Those answers are worth something to an AI preparing a review or tracking down a decision, and none of them requires opening anybody's private life.
The Google Calendar connector is therefore written the other way round from most integrations. It starts by excluding, and what it excludes is settled before a single line is written into your Kastel.
Work meetings, minus the ones you marked private
On a calendar, the boundary is described appointment by appointment. Here is what your Kastel writes, and what it leaves in Google.
The calendars Google provides are excluded by their identifier, never by their name. The difference matters: it avoids discarding a work calendar whose name happens to mention birthdays or holidays, which would be silent data loss.
What happens before an event is written
The order of these filters is the guarantee. Each one runs before the write, and none of them makes up for it afterwards.
The calendars Google provides itself are never opened
Public holidays, birthdays drawn from your contacts, week numbers, weather. Those calendars are recognised by their technical identifier, the one you can read in your Google Calendar settings, and never by their name. A work calendar someone called “Client birthdays” is therefore not mistaken for Google's own, and it comes in normally.
An event with no text has nothing to write
A busy block, an empty all-day placeholder, a slot held with no title. There is nothing to take from it, so nothing is written, and that does not count as a rejection.
An event marked “Private” or “Confidential” is dropped
The visibility you set on the event in Google Calendar is enough to drop it. It is read before the write, so the title of a private appointment goes nowhere, not even into a holding area.
Everything else is judged on the whole page it would produce
Title, time, location, guest list and description are examined together, exactly as they would be written. A personal signal anywhere in that set drops the entire event. A family lunch sitting on a work calendar shows up through its guests, even when its title says nothing.
What survives is filed by the calendar's sharing
The event inherits the sharing of the calendar holding it, and that sharing decides who can read it through a connected AI.
The calendar's sharing decides, and the event has no say
In Google Calendar an event carries no permissions of its own. It is the permissions of the calendar holding it that say who may read its detail, and that list is what your Kastel inherits, calendar by calendar, without touching it.
Only the people who can read an event's content count in that calculation. Someone you show nothing but your availability widens nothing at all, since they see no titles in Google either. It is the same rule as for your other sources, and it is set out in governing your knowledge.
Five situations put a calendar on hold instead of filing it. In each one no department is designated, so nobody reads its events until an administrator rules on it.
- The calendar is public, and therefore readable by anyone on the internet
- The calendar is shared with a whole domain, with nobody named
- The calendar is shared with a group your organisation cannot expand into people
- The people it is shared with span more than one department
- The sharing list cannot be read, or it is too long to be read in full
A series comes in as occurrences, and a sharing change is caught separately
Google returns a recurring meeting as concrete occurrences, and the connector takes them as they come. The Monday review enters as a run of dated appointments, each filed in its own right, which means a moved or cancelled occurrence is handled at its own level and never at the level of the whole series.
The first pass over a calendar reaches one year back and takes everything ahead of it, with no bound in the future. After that, the connector follows the stream of changes Google publishes rather than rereading the whole calendar. An employee who has already connected their mailbox has no second consent to give when the authorisations are requested together, because the calendar rides the same Google application as Gmail and Google Drive.
A sharing change, on the other hand, produces no event change in Google. It is therefore caught by a dedicated reconciliation pass, on its own cadence. Between two passes an event can stay filed in yesterday's department. That window is short and we own it.
That reconciliation also spots what has disappeared, and it is deliberately timid. The connector only declares an event gone if it can prove the event fell inside the window it has just reread. An old appointment that has aged out of that window stays silent rather than passing for deleted.
What this connector does not do
It does not touch your calendar. It creates no event, moves none, and answers no invitation. The authorisations requested from Google cover reading calendars and their events only, so no write path exists.
An event's description is free text, so its content is whatever your team writes there. An agenda holding something sensitive comes in with the event. Attached files are not read, and only the event's text is taken.
The sort that drops personal material is a judgement on text, not a certainty. It is set to exclude at the slightest doubt, which means it sometimes drops a genuine work meeting whose title looks like a private appointment. That error suits us better than the other one.
An event cancelled in Google Calendar is not erased from your Kastel. The disappearance is noted and the content stays, its read permissions intact, for as long as no administrator has asked for its erasure. The connector therefore never makes what it has read disappear on its own.
See the whole mechanism before you connect a calendar.
The product page shows what your Kastel builds from your sources, where each thing is filed, and what a connected AI receives depending on the person it is working for.
See the product
