Read availability. Write a placeholder. Prove it.
Avenclave runs entirely on your machine and repeats a short loop. The interesting part is not that it can write a placeholder; it is what it refuses to do when it cannot be certain.
Each calendar is both a source and a destination.
There is no primary calendar and no hub. A meeting booked on either side produces a placeholder on the other, carrying the route it came from and nothing else.
- Your real meeting. Stays where you booked it.
- Placeholder on the other calendar. Same time, no title, no attendees, no notes.
Six steps, in order, every time.
- 01
Read availability from each connected calendar
Each account is signed in through its own provider, Microsoft 365 or Google Workspace, using that provider’s native authentication and security, and each one is kept in a session of its own. Avenclave reads the calendar you selected across a rolling window of upcoming days rather than your entire history.
Periods marked Free or Working Elsewhere produce no placeholder by default. Only genuine unavailability travels.
- 02
Normalize it into one plain timeline
What comes back from a calendar is turned into simple busy intervals in absolute time. This is what makes a meeting booked in Arizona land at the right hour on a calendar in New York, and what keeps a recurring series correct when daylight saving shifts underneath it.
From this point on, the same rules apply no matter where a meeting came from. Outlook and Google Calendar are treated identically, so a mixed setup behaves exactly like a single-provider one.
- 03
Decide what each other calendar needs
For every one of your other selected calendars, Avenclave works out whether a placeholder should be created, moved, or removed, and whether the correct answer is to do nothing.
Its own placeholders are never treated as availability to copy onward. Without that rule, two connected calendars would echo placeholders back and forth forever.
- 04
Record the intent before touching anything
Every planned change is recorded locally first, along with the identity Avenclave expects the resulting placeholder to have. Only then does it ask the calendar to make the change.
That ordering is what makes a crash, a lost network, or a laptop going to sleep recoverable. On restart, Avenclave knows exactly what it had started and never blindly repeats it.
- 05
Confirm against fresh calendar state
A success response from a calendar is treated as a hint, not as proof. Avenclave re-reads authoritative state and accepts the placeholder as its own only when it finds exactly the identity it journaled, exactly once.
Duplicates, conflicts, and anything it cannot positively identify are reported as Inconclusive, and no further change is made on that basis.
- 06
Keep going quietly
After the first pass, Avenclave repeats on the schedule you choose: about every five minutes, roughly every fifteen, or about once an hour. It works in the background with nothing to keep open and no elevated permissions on your machine.
How long a sign-in remains valid is decided by your provider and your organization’s policy, and some policies require it as often as once a day. When that happens Avenclave stops writing, brings up that provider’s own sign-in, checks that the restored account is still the same one, and resumes only if it is.
What happens when Avenclave is not sure.
Most synchronization bugs are not dramatic failures. They are quiet wrong answers. The engine is built so that the safe outcome is the default one.
- Inconclusive
It cannot prove the placeholder is its own
No change is made and the state is reported as Inconclusive. Avenclave will not modify or delete a calendar item on a resemblance. Matching subject, time, or location is never treated as proof of ownership.
- Paused
A calendar session is not usable
If an account needs to sign in again, or a required selection is missing, the run stops before recording any change. Existing placeholders are left exactly as they are.
- Recovering
The app or machine stopped mid-change
On restart, Avenclave reads its own journal, works out precisely which stage it reached, and re-establishes the truth from the calendar rather than repeating the write.
- Identity mismatch
A different account was signed in
If the restored account is not the one originally connected, Avenclave refuses to continue on that route rather than writing your availability into a stranger’s calendar.
Nothing is synchronized by default.
- Which calendars participate
- You choose, per account, the one calendar Avenclave may read. A calendar that appears later stays excluded until you say otherwise. Discovery never silently widens what is synchronized.
- How often it runs
- Pick the cadence that suits you: roughly every five minutes when you want changes reflected quickly, about once an hour when you would rather it stay out of the way, or a balanced setting in between. You can also run a pass on demand.
- How far ahead it looks
- A rolling window you configure. Beyond it, nothing is planned; inside it, availability is kept current.
- What the placeholder is called
- You choose the label, per calendar. It is never derived from the real meeting’s subject, so whatever you pick, it cannot leak anything by accident.
- Direction
- Each pairing is a direction of its own. Every selected calendar can be both a source of your real availability and a destination for placeholders from the others.
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.