Privacy here is an architecture, not a policy page.
Avenclave is designed so that most privacy questions have a structural answer rather than a promise. There is no service in the middle to trust, because there is no service in the middle.
Where your information actually goes.
Everything Avenclave knows
The local database, the mapping between events and placeholders, and your signed-in calendar sessions all live in your own Windows user profile.
Placeholder times, to your own calendars
Avenclave acts on your behalf against Microsoft 365 and Google Workspace to write and confirm placeholders. That traffic goes to your own calendar providers, and nowhere else.
An Avenclave cloud
No sync service, no analytics pipeline, no crash-report upload, and no copy of your schedule anywhere we could be compelled to hand over.
What is kept, and why each item has to be.
Avenclave stores the minimum that lets it be correct after a restart. Every item below exists because removing it would force the product to guess.
- Busy intervals inside your window
- Start and end times. Not subjects, not attendees, not bodies.
- A mapping row per placeholder
- Which source event on which calendar produced which placeholder on which other calendar, and what state that placeholder should be in.
- The identity of each placeholder it created
- An opaque identifier issued by the calendar provider, journaled before the write so ownership can be proven afterwards.
- Your signed-in calendar sessions
- Established through each provider’s own authentication and kept on your machine, isolated one account from another, so no connected account can see another’s session.
- An opaque fingerprint of each connected account
- Enough to detect that a different account has been signed in, without storing the account itself in readable form.
Diagnostic logs record privacy-safe counts and fixed labels. Meeting subjects, attendees, bodies, links, and raw provider payloads are deliberately kept out of ordinary logs.
How paying for it stays separate from using it.
Avenclave is a licensed product, and we would rather be straightforward about what that involves than make a promise we would have to walk back. A licence may be confirmed periodically over the network.
What that exchange contains is the part that matters: whether your licence is current. Nothing about your calendars, your meetings, your accounts, or your schedule is part of it, and synchronization itself never travels through us. A licence check confirms you may use the product; it is not a route your data takes.
Avenclave signs in as you, not as an application.
Many integrations require an organization’s administrator to approve tenant-wide application access to calendars. That is a significant thing to ask of a client, and it grants a scope far beyond what availability synchronization needs.
Avenclave instead relies on each provider’s native authentication and security, the same sign-in you already use for Microsoft 365 or Google Workspace, with each account held in a session of its own. It uses the access you already have, requests no elevated permissions on your machine, and needs nothing granted on behalf of an entire organization.
The honest limit of that claim: each organization still governs its own calendar and decides how long your sign-in remains valid. Avenclave avoids needing an administrator to grant it access. It does not override the policies an administrator sets, and it does not try to.
You also stay inside your own permissions. Avenclave can only see and write what your account can already see and write, which is exactly why it never needs a broader grant than you personally hold.
How Avenclave knows a placeholder is its own.
This is the mechanism that lets Avenclave safely change or remove something on a calendar it shares with you. It is worth being precise about, because the alternative, guessing from appearance, is how synchronization tools destroy real meetings.
-
Record the expected identity before writing
The calendar provider issues an identifier for the item about to be created. Avenclave writes that identifier, and the reason it is creating the item, to its local database first.
-
Treat the write response as a hint
A response saying “created” is not accepted as proof. It might be optimistic, partial, or lost entirely.
-
Re-read authoritative state
At each checkpoint, Avenclave asks the calendar for fresh state and looks for the exact identifier it journaled.
-
Accept only an exact, unique match
Ownership is confirmed when the expected identifier appears exactly once. Two matches, a conflicting match, or a view that cannot show identifiers all resolve to Inconclusive, and Avenclave makes no ownership-dependent change.
Resemblance is never ownership. A calendar item with the same subject, the same time, and the same duration as one of Avenclave’s placeholders is still not treated as one.
Words we will not use about our own security.
Security marketing tends to reach for superlatives. We keep an explicit list of terms that are banned from our own copy, because each would imply a property we have not implemented and cannot demonstrate.
- Zero-knowledge
That term describes a specific cryptographic property. Avenclave does not implement it, so using the word would be a false claim.
- Cryptographically verified
Placeholder ownership is established by local journaling, provider-issued identity, and exact re-checking against authoritative state. That is ownership verification. It is not cryptography.
- Instantaneous
Avenclave synchronizes on an interval you choose, from a few minutes to about an hour. Calling that instant would misdescribe how it behaves.
- Military-grade, bank-grade, deeply secure
These phrases have no defined meaning. A claim we cannot point at a mechanism for is a claim we do not make.
The descriptors we do use — privacy-preserving, local-first, provider-independent, data-minimizing, fail-closed, and synchronizes availability rather than meeting content — each describe behaviour the product can be observed doing.
What Avenclave will not do.
These are design constraints rather than current preferences. Breaking any of them would mean building a different product.
- Send your calendar data to a server we operate. Synchronization happens entirely on your machine.
- Put anything about your schedule into a licence check. A licence exchange carries licence status and nothing else.
- Ask your organization’s administrator to grant tenant-wide access to its calendars.
- Copy meeting titles, attendees, notes, locations, links, or attachments between calendars.
- Read a calendar you did not explicitly select, including ones discovered later.
- Sell, share, rent, or monetize anything about your schedule.
- Modify or delete a calendar item it cannot positively prove it created.
- Report an uncertain result as a successful one.
No trackers, no cookies, no third parties.
This site sets no cookies, loads no analytics, and makes no requests to any domain other than the one you are reading. Its fonts are served from here rather than from a font service. That is why there is no consent banner: there is nothing to consent to.
The only way to contact us is email, and an email you send is an email; it does not enter a marketing platform. Questions about any of this are welcome at hello@avenclave.com.
This page describes the product’s design. It is not a legal agreement. Draft formal documents are published for review at Privacy policy and Terms of service. Counsel will review both before Avenclave is available to install.
Want to know when Avenclave is ready?
There is no signup form and no tracking. Send one email and we will reply once there is something real to try. Nothing else happens to your address.
We will not add you to a mailing list, and we will not share your address.