Daily Organiser bot

Who this is

The operator is Mykola Konovalov. Daily Organiser bot is the name on the Google consent screen. Daily Organiser is the household log. It keeps household tasks, commitments, and a morning brief. It is not a public service people can join from these pages.

The Google account is the personal account whose refresh token is configured for the house. This page does not name that account.

What this policy covers

It covers Google user data the calendar connection can receive: calendar events and the calendar list. Household notes a person types into the log are a different store. They are mentioned below only where they could be confused with calendar data.

Google access this software is built for

The source names two read-only scopes and no write scope:

• https://www.googleapis.com/auth/calendar.events.readonly. Google’s own description of this scope is “View events on all your calendars.”
• https://www.googleapis.com/auth/calendar.calendarlist.readonly. Google’s own description is “See the list of Google calendars you’re subscribed to.”

Those descriptions are wider than the subset this process asks for on an ordinary morning. For events, it asks for the configured calendars, for the local calendar day, up to 50 events. The default configured calendar is the primary calendar when no calendar id is set. The operator can add another calendar by name; that stores the calendar’s Google id and its display name.

The refresh request does not send a scope. This process cannot widen the grant at refresh time. It also cannot, from the source alone, prove which scopes the live token was given. That token was not checked against Google for this page.

The software does not create, change, or delete Google Calendar events. It does not request the broader calendar scopes that would allow that.

How the grant is obtained

There is no Google OAuth callback in this app. The client id, client secret, and refresh token are acquired outside the app and read from the house environment (GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET, GOOGLE_OAUTH_REFRESH_TOKEN). Those values are not written into the database by this code.

The refresh token is not sealed with the key this app uses for a different, optional connection. This page does not claim the environment file or the disk is encrypted. That was not inspected.

To read the calendar, the app sends the client id, client secret, and refresh token to https://oauth2.googleapis.com/token and receives a short-lived access token. It then calls Google’s Calendar API at https://www.googleapis.com with that access token. Both calls use HTTPS URLs in the source. This page does not describe the house network beyond that.

What a read takes from Google

On the morning brief, the app asks for events from local midnight to the next local midnight in the configured house timezone. The default timezone in the source is Europe/London. That names a zone, not a street address.

The event request does not set a field mask. Google’s response can include more than the title and the start, such as a description, a place, attendees, or an organiser address. This code keeps three things for the brief: the title (or Busy), a local time or All day, and a 12-character hash of the event id. The rest is not copied into the brief. It is still received into process memory for that request. There is no coded wipe of that memory.

Cancelled events are skipped. The same event id is shown once. A blank title is shown as Busy. Before a title is shown, the software drops titles that match a fixed household block list. The Google response is received before that check. A title that does not match the list is still shown. The list is not a guarantee that every non-household event is dropped.

The calendar list is requested when the operator adds a calendar by name, not on every brief. That request asks for up to 100 calendars and does not follow a further page.

What the data is used for

Event titles and times are shown on the household morning brief so the house can see today’s appointments. Calendar names are shown in settings so the operator can add or remove a calendar. A short hash of the event id is returned with the brief line so the page can tell lines apart. It is not the Google event id.

Google’s user-data policy includes extra rules, often called Limited Use, for some scopes. This software’s calendar use, as written, is the brief and the settings list above. It has no advertising and no analytics. It has no function that sells or rents Google data. This page does not say Google has judged that use acceptable.

Google’s policy text: Google API Services User Data Policy.

What is stored

• The refresh token, client id, and client secret stay in the house environment until an operator removes them. They are not a row in the application database.
• A short-lived access token is kept in the memory of the running process until it is near expiry, or until the process stops. The source uses the lifetime Google sends, or 3600 seconds if that lifetime is missing, and refreshes a little early. The token is not written to the database by this code.
• After the operator adds a calendar in settings, the database stores the provider name, the Google calendar id, and the display name. Google’s id for a primary calendar is often the account email. The live database was not read for this page, so it does not say whether any such row is stored today. Reading the brief alone does not create that row.
• Each diary attempt updates a status row: the time of the last success, or an error class of “unconfigured” or “unavailable”. That row has no event title and no token.

What this code does not store

Event titles, times, descriptions, places, attendees, and the short hash are not written as calendar-event rows. The brief is answered and then dropped by this code. The browser keeps the brief on the open page. The app does not put the brief into browser local storage. Local storage in this app is used for a colour theme and a layout preview, not for the diary.

There is no fixed retention period in the source for data that is not stored as a row. There is also no fixed retention period for a calendar id once it has been saved. It stays until that settings row is deleted, or until the database itself is removed by means this page did not inspect.

Copies this page cannot see

The application log for a request records the method, the path, the status, and the duration. It does not record the body. A failed diary call logs a fixed sentence, “diary request failed” or “diary list failed”, not the Google response.

This does not describe Cloudflare, the system journal, a crash dump, a proxy, or a database backup. Those were not inspected. They may keep copies this application does not. This page does not promise that those copies are encrypted, or that they are deleted on a schedule.

Other services, including the assistant

The morning review builds the whole brief, and building the brief reads today’s calendar events. It then builds the text it sends to Mistral. That text includes tasks and commitments only. The function that builds it skips every other section, including appointments. The assistant’s searches read tasks and commitments. They do not query the calendar.

A morning review can therefore cause a Google Calendar read in the same server step as a call to Mistral, while the appointments are not part of the text this code sends. Mistral is asked to store that conversation and the app then asks Mistral to delete it. If the delete fails, the log records the conversation id, not the calendar. This is not a claim about what Mistral keeps on its side. Calendar titles are not in that packet today. If a later change puts them in, this policy has to be updated first.

If a person types an appointment into a task, a note, or the assistant box, that typed line is house-log text. It can be sent to Mistral. The calendar code does not copy event titles into those records.

Voice input, when the house turns it on, can send one recording to Mistral for a transcript. It is off unless enabled. When no transcription model is set, the source default is voxtral-mini-transcribe-3. A value set in the environment is what is sent instead. Voice is not a calendar read. Optional weather, journey, and X connections are separate. The calendar code does not pass Google event fields to them.

Google receives the OAuth refresh and the Calendar API requests, because Google holds the calendar. That is the provider the data comes from.

Who can see the brief

The household app has no user accounts of its own. Whoever is admitted by the house access check can open the morning brief, including today’s appointment titles and times. This repository does not set that allow list, and this page does not say who is on it. The public description pages do not show the brief.

The household app’s existing address is https://organiser.apidiscoverysolution.uk. It is not a link here. It stays behind the access check. It is not this policy.

Revoking access is not the same as deleting stored data

The account holder can review or remove the app’s access in their Google Account. Google’s help page, as fetched on 7 November 2026, is Manage links between your Google Account and apps from other developers. The steps there can change. Removing access tells Google to stop honouring the grant. It does not, by itself, delete rows in this household database.

This app has no Google disconnect button. It does not call Google’s token-revoke endpoint. It notices a dead grant when a later refresh or calendar call fails. The brief then says the diary is not connected. An access token already cached in the running process can still be used until that cache expires or the process stops. Whether Google rejects that access token immediately is Google’s behaviour and was not tested.

Removing the three environment values and restarting the process stops new refreshes. That is an operator action on the host, not a control in the app. It does not delete a calendar row already stored.

Removing one calendar in settings deletes that calendar’s stored id and display name. It does not revoke the Google grant. It does not delete event titles, because those titles are not stored as rows. There is no control that deletes “all Google data”, and there is no job that clears logs outside this application.

Google’s OAuth policy says developers should store tokens encrypted at rest, revoke them when they are no longer needed, and then delete them. This software does not yet do that for the Google refresh token.

Notice inside the app

The appointments section shows “Read only. This is not a calendar.” Settings describe the diary as read-only. The app does not yet show this privacy policy, or a link to it, inside the household interface. Google’s branding rules also ask for a privacy notice in the product. The words for that link are written down for review. They are not in the app.

Changes

If Google data is used in a new way, this page has to be updated first. The current software cannot ask for a fresh grant by itself, because it has no OAuth callback. A new grant would be made outside the app.

Support

The public support email for Daily Organiser bot is mykolakonovalov@gmail.com. The operator is Mykola Konovalov.