Trust

Your deployment runs in your organisation’s Cloudflare account (the hosted trial is hosted by us). A TypeScript Worker handles sign-in, the API, calendar webhooks, planning and cron. The main Worker also runs the primary solver, an exact engine. The fallback is OR-Tools’ CP-SAT solver, which a second Worker, the solver Worker, runs in a Cloudflare container. By default the container steps in only when the engine can’t certify its answer; configuration can instead make the container the only solver, which takes more infrastructure management. The solver Worker has no public route; the main Worker reaches it only over an internal service binding. The database (D1), token cache (KV), DNS and Cloudflare Access are provisioned as code.

The API (/v1/*) is bearer-authenticated: a caller presents an OAuth token minted through a PKCE sign-in. Your assistant’s caller is codemode MCP, a separate MCP server in the same account; one codemode MCP serves the whole organisation, and Optical exposes only this REST API. Admin routes need a bearer token with the admin scope, held by a user with the admin role. The one browser-facing admin page uses Cloudflare Access instead.

Some routes take no bearer token:

• Emailed plan-accept links carry a signed, time-limited token.
• Calendar webhooks carry a signed channel token.
• When the booking page or meeting polls are on, their public pages accept submissions without sign-in, behind a Cloudflare Turnstile challenge or a per-invitee link token.
• The OAuth revocation endpoint accepts a token to revoke without authentication.

A deployment of Optical is two Workers (the main Worker, which also runs the primary solver, and the solver Worker, which runs the fallback solver’s container) and one D1 database, in one Cloudflare account. The operator decides who may sign in, with a membership allow-list of addresses or whole domains; everyone admitted shares that deployment. Every API query is scoped to the signed-in user (owner_subject), so one person’s tasks, plans and calendar sync state are not returned to another.

A person can choose to publish their availability through a booking page or a busy feed. People with access to the Cloudflare account itself can read the database directly.

In your deployment, that account is yours: every organisation deploys its own Optical, so there is no shared instance, and we have no standing access to it. We get temporary access only if you grant it because you want our help. Unlike customer deployments, the hosted trial is managed by us and we have full access to the Cloudflare account.

Unless a topic says otherwise, this page describes your deployment: your own Optical, in your own Cloudflare account. Unlike customer deployments, the hosted trial is managed by us and we have full access to its Cloudflare account.

The hosted trial is a single shared instance that Bajanov Advisory Pty Ltd operates, in Bajanov Advisory Pty Ltd’s Cloudflare account, with its own D1 database, KV and Durable Objects, kept apart from its other Optical deployments and from any customer deployment. It signs people in through its own verified Google OAuth client and its own application registration in Microsoft Entra, so the consent screen you see belongs to Bajanov Advisory, not your organisation.

Only invited people can sign in: each invitee is admitted by exact email address, not by domain. Everyone admitted shares that one deployment, and every API query is still scoped to the signed-in user, so one person’s tasks and plans are not returned to another.

Because Bajanov Advisory runs it, “no standing access” does not hold here. People with access to that Cloudflare account can read its database. Solver capture is off, as are debug logging and the extra diagnostic scopes.

How the hosted trial collects, uses and deletes your data is set out in the privacy policy. To have your data deleted, see deleting your data.

Google and Microsoft refresh tokens — the standing permission to read and write your calendar and send mail as you — are encrypted with AES-GCM before they are stored in D1. The key is a Cloudflare Worker secret, not a database value. Bearer tokens used to call the API are stored as hashes. Unless the operator sets separate keys, the encryption, hashing and signing keys all derive from one secret.

Scheduling data — tasks, projects, templates, proposed plans, calendar sync state — is keyed to its owner, and every API query is scoped to the signed-in user. People with access to the Cloudflare account can read the database directly.

Optical can capture solver inputs, which include task and event titles, to an R2 bucket in the same Cloudflare account for solver diagnostics. Capture is off by default in customer deployments, and off in the hosted trial. Your deployment’s operator decides who can reach its Cloudflare account; the hosted trial sets out who can reach the trial’s.

In your deployment, your operator offboards you. Offboarding removes your tasks, templates, projects, plans, calendar sync state, booking page, bookings, feeds, scheduling settings and stored Google or Microsoft tokens, and removes upcoming work blocks Optical placed on your calendar. Past blocks stay.

In the hosted trial, you can delete your account yourself:

• ask your assistant to delete your Optical account, or
• email info@optical-scheduler.com and ask us to.

Deletion revokes the Google grant. You can also remove Optical yourself:

• Google: Third-party connections
• Microsoft personal accounts: account consent
• Microsoft work or school accounts: My Apps

Removing it stops Optical’s access, but does not delete your data. That is deleted at the 90-day idle sweep, when you ask us, or when you delete your account as above.

Microsoft has no per-service revoke call, so remove the Microsoft grant yourself. Deletion erases the Microsoft tokens we hold, but the grant they were issued under stays in place at Microsoft until you remove it.

If you don’t sign in or use the hosted trial for 90 days, we delete your data. We send one warning email at least 14 days before we do. Any activity, including API use through your assistant, resets the clock.

The privacy policy sets out what is kept and for how long.

In your deployment, your organisation creates and manages its own OAuth client in its own Google Cloud project, so you control the consent screen and can revoke it at any time. The hosted trial uses its operator’s verified client instead.

Signing in with Google grants Optical four scopes, with offline access so it keeps working when you are not signed in:

• calendar events (read/write, to place and move your blocks)
• calendar free/busy (to check attendee availability for meetings you organise)
• Gmail send (to send replan emails to you, and poll and booking emails to the people involved, from your address)
• your email address (for identity)

A deployment may enable extra diagnostic scopes. If it does, they are added to the scope list you consent to at sign-in.

In your deployment, your organisation creates and manages its own application registration in its own Microsoft Entra tenant, so you control the consent and can revoke it at any time. The hosted trial uses its operator’s registration instead.

Signing in with Microsoft 365 grants Optical:

• your identity (openid, profile, email)
• offline access, so it keeps working when you are not signed in
• calendar read/write, which also covers free/busy
• mail send (to send replan emails to you, and poll and booking emails to the people involved, from your mailbox)

Optical does not request User.Read: your identity comes from the sign-in token, not from a Graph profile lookup. A deployment may enable one extra diagnostic scope. If it does, the scope is added to the permissions requested at sign-in and needs consent like the others.

Optical has no MCP server of its own. Your assistant connects to codemode MCP, a separate Worker in the same Cloudflare account as Optical. It signs in to Optical like any OAuth client, with PKCE, and calls Optical’s REST API (schema/openapi.json) with a bearer token. Through it, the assistant can:

• create, change and delete tasks, templates and projects
• ask for a plan, and accept or discard one
• adjust per-category scheduling preferences and the solver’s weights, including churn against fit
• manage your booking page and busy feeds
• create, edit, nudge, cancel or book meeting polls, which emails the invitees
• set or reset your timezone

A plan reaches your calendar only through an accept or commit call. Outside plans, the API changes your calendar when a task is deleted or marked done (its own blocks are removed or recoloured) and when a meeting poll books.

The API has no write operation for your business hours or your account meeting policy (these are coming soon); the operator sets them. Done-task marking is handled within Optical; the MCP can read task statuses through the API. The API returns the underlying Google access token only to a client the operator has registered with the calendar:raw-token scope (which can be disabled at the OAuth level for security if preferred; it is used only for the automated tests). codemode MCP is registered with scheduler:read and scheduler:write only, so MCP calls can’t directly make arbitrary changes to a calendar.

Optical runs no AI model and sends your data to no AI provider. The assistant you connect receives your scheduling data when you ask it to, under your own account with that assistant’s provider.

In your deployment, Optical reads Google user data through your organisation’s own Google OAuth client, so that data is governed by whatever terms exist between your organisation and Google. Those terms may or may not allow data from Google APIs to be used to train AI models. Check them, and your assistant provider’s training settings, before you connect an assistant to Optical.

In the hosted trial, the data comes through our verified Google OAuth client, so Google’s Limited Use requirements apply, and the terms require that your assistant does not train on what it receives from Optical.

Some things are deployment configuration, not conversation:

• who may sign in (a membership allow-list)
• whether Microsoft 365 sign-in is enabled
• which optional features are on: owned meetings, the booking page, meeting polls, busy feeds, delegated access
• the default business hours, 09:00–17:00 Monday to Friday unless changed; a task with no pin and no hard window is placed inside them
• the default timezone, which each person can then change for themselves
• the done colour (in Outlook, the done category) that a repaint has to match

The operator sets these when the deployment is stood up and changes them later. The API has no write operation for any of them.

A full threat model exists, covering entry points, trust boundaries and mitigations. It isn’t published here — ask us and we’ll share a summary.

Google Workspace and Microsoft 365 are both supported. The calendar provider is chosen per person, not per deployment. Microsoft 365 sign-in is switched on per deployment with a flag, once the deployment is registered in Microsoft Entra; switching it off again freezes calendar sync for existing Microsoft users until it is back on.

Known limitations:

• Cross-provider free/busy. A Google attendee on a Microsoft-organised meeting (or the reverse) can’t be read through the organiser’s API; the meeting is treated as immovable.
• Done-marking is exact-category-name coupled. Renaming or deleting the category in Outlook silently stops done-marking; un-marking clears categories added to that block by hand.
• Only meetings you organise move. Optical won’t move a meeting you’ve been allowed to edit as a guest but don’t organise. The same applies on Google.
• No rich webhook payloads. Every ping triggers a refetch.
• No PKCE on the Microsoft OAuth flow in v1. It is a confidential client; Microsoft recommends but does not require PKCE there.
• No switch-time ghost sweep. A provider switch leaves committed blocks on the old calendar and abandons the old push channel.
• Weekly channel-secret rotation is date-derived, not recorded.

Each person sets their own timezone. A deployment has a default timezone, set by the operator, and anyone who signs in can replace it with their own (an IANA name such as Australia/Sydney or Europe/London) through the API or their assistant, or reset it to the default. Business hours, where each week starts and ends, and the Monday planning run all follow that timezone.

Changing it discards any plan still waiting to be accepted, since that plan was worked out against the old hours. The next plan moves flexible work into the new hours. Pinned times and deadlines stay where they are, and a task’s preferred window keeps the clock time it was written in.

An executive assistant can run an executive’s week in Optical: their tasks, plans, scheduling settings and calendar. The assistant signs in with their own Google or Microsoft account and still uses Optical for their own work.

Optical adds no permission system of its own. It follows the calendar sharing the executive has already set up: in Google, “Make changes to events”; in Outlook, delegate access with editor rights. Before acting for an executive, Optical checks with the assistant’s own account that they can really edit that calendar. The executive’s own Google or Microsoft credentials are never handed to the assistant.

The executive is told:

• by email when an assistant starts acting for them
• at each sign-in, with a list of everyone who can act for them
• by email, as is the assistant, when that access ends

Every change the assistant makes is recorded as made on the executive’s behalf, and mail Optical sends for them says who sent it.

Access ends when the executive stops sharing their calendar, or the assistant removes it from their calendar list. Optical re-checks access daily and whenever Google or Microsoft refuses a request, so a change in sharing can take up to 24 hours to show. Private events stay private: the assistant sees them as Busy unless the executive’s own sharing already shows them private events.

Delegated access is a deployment option the operator turns on (see what’s set once, by the operator). It is not available in the hosted trial.