---
title: Glossary
description: What Calendite means by event series, inner and variant events, tags, alerts, visibility and the rest of its vocabulary.
order: 1
---

# Glossary

Calendite uses a handful of words in a specific way. This page says what each one means and
points at the page that covers it properly.

---

## Events

### Event series

Everything that shares the same details but can land on many different dates. All your
"Yoga" events are one **event series**. A one-off event is still a series; it has a
single [instance](#event-instance).

### Event instance

One occurrence of an [event series](#event-series) on a particular day. The series is
"Work"; the instance is Work on Tuesday the 14th. Deleting an instance removes one date and
leaves the series running. See
[Editing and deleting](/docs/everyday-use/editing-and-deleting.html).

### Inner event

A smaller event that lives inside a bigger one and can only happen on days the bigger one
happens. A "Stand-up" inner event only fires on the days its "Work" parent fires.

- An inner event with **no rule of its own** rides every occurrence of its parent.
- An inner event **with** a rule is worked out on its own and then trimmed down to the days
  the parent falls on. You never have to write the "…and only when Work is on"
  part yourself.

Unlike a [variant event](#variant-event), an inner event **does not inherit its parent's
[alerts](#alert)**. The parent's alerts shown on the inner event's detail screen are there
for context; nothing is scheduled from them.

See [Inner and variant events](/docs/everyday-use/inner-and-variant-events.html).

### Outer event

The event that contains an [inner event](#inner-event): the parent.

### Inner event timing

How an [inner event](#inner-event) places itself inside its parent's occurrence.

- **Absolute**: a fixed clock time. 09:30 is 09:30 whatever the parent does.
- **Relative**: an offset from the parent, either after it starts or before it ends. Move
  the parent and the inner event moves with it.

### Variant event

A version of an [event series](#event-series) with something changed. Most often the start
and end time, but it can be the location, the [alerts](#alert), the
[tag](#tag) or anything else. "Early Shift", "Late Shift" and "Night Shift" are three variants of
one "Work" series.

Two points about variants:

**A variant only supersedes its base on the days the variant itself falls on.** On every
other date the base carries on as normal. So a base that repeats on weekdays, with a variant
on the last Saturday of the month, gives you weekdays **and** that last Saturday. The
variant adds a day; it doesn't replace the pattern.

**Most of what a variant borrows from its base is copied when you save it, not looked up
later.** Change the base's title, times, duration, tag, colour or location afterwards and
variants that already exist keep what they had. Three things are the exception and do stay
live:

- **[Alerts](#alert)**: an alert added to the base later does reach existing variants. A
  variant can also drop an alert it inherited, and add alerts of its own.
- **[Tags](#tag)**: a variant with no tags of its own shows its base's tags.
- **[Visibility](#event-visibility)**: a variant set to inherit follows its base every time
  a view is drawn.

See [Inner and variant events](/docs/everyday-use/inner-and-variant-events.html).

### Base event

The event a [variant event](#variant-event) is based on: the original "Work" behind "Early
Shift".

### Calendar item

What a row on the calendar *is*: an event, a [reminder](#reminder), a [deadline](#deadline)
or a [time period](#time-period). You choose which on the **Choose a Calendar Item** step
when you tap NEW, and it isn't a field you edit afterwards — what something *is* isn't
something that changes.

Every kind is stored as an ordinary event row underneath; the kind only changes behaviour
where it has to.

### Deadline

A moment something is **due by**. Like a [reminder](#reminder) it is a point in time and can
be ticked off, but its [alerts](#alert) are optional, because the countdown is the nag. Its
detail screen shows how long is left — and once the moment passes without being marked done,
how long it has been **overdue**, counting up in the danger colour.

### Time period

A span of **whole days** — a holiday, or time off work. It has a start **date** and an end
**date** rather than a start and end time, is always all-day, and measures its length in
days. It can't be completed and doesn't count down. On the calendar it draws as one
continuous band across every day it covers.

See [Calendar items](/docs/everyday-use/calendar-items.html).

### Span end date

The last day a [time period](#time-period) covers — the end of the holiday.

Not the same thing as the date a repeat stops. A time period running 24 December to 2
January *and* recurring every year until 2030 has both: the span end date is 2 January, and
the repeat ends in 2030. Each occurrence runs the same number of days from its own start.

---

## Repeats and rules

### Rule

The pattern that decides which dates an [event series](#event-series) lands on, such as
`WD, !BankHolidays`. You can build one with the pickers or type it directly. Full syntax is
in the [rule reference](/docs/rules-reference.html); the gentler introduction is
[Building repeats](/docs/everyday-use/building-repeats.html).

### Category

A named group of dates you can use inside a [rule](#rule), written in PascalCase, for
example `WD, !BankHolidays` for every weekday except bank holidays. Unlike a [tag](#tag), a
category isn't for display or colour. It's a set of dates, resolved from a [feed](#feed) or
a small built-in set when the rule is worked out.

### Tag, event and feed selectors

The three ways a [rule](#rule) can point at dates belonging to something else, written with
the kind spelled out so there's no ambiguity:

- `Tag(X)`: the dates of every event carrying the [tag](#tag) `X`.
- `Event(X)`: the dates of the [event series](#event-series) `X`.
- `Feed(X)`: the dates supplied by the [feed](#feed) `X`.

`Tag(Work)` and `Event(Work)` are deliberately different sets of dates, which is why the
kind has to be explicit. See the [rule reference](/docs/rules-reference.html).

### Feed

An external data source you point Calendite at: a URL plus a little configuration saying
which bits of the response are the dates. Bank holidays from gov.uk are the usual example.
A feed supplies the dates behind a [category](#category) or a `Feed(X)` selector.

See [Data sources and feeds](/docs/everyday-use/data-sources-and-feeds.html).

### Computed rule

A rule whose dates come from a calculation rather than from data you supply: `MOON(...)` for
lunar phases and `EASTER(...)` for Easter Sunday and the days that move with it. Spelled in
capitals to set it apart from a [category](#category), which is PascalCase and needs a feed
or a built-in set behind it. A computed rule needs nothing and works offline. It has no
iCalendar `RRULE` form, so an export writes its dates out to the export horizon instead.

### Occurrence limit

The "After N occurrences" option in an event's *Ends* control: a cap on how many times the
event fires. Not the same as `LIMIT(...)` in the rule language, which restricts which
*months* a rule applies to.

### Region

The country you pick in setup. It decides which days count as weekend and which as weekday
for `WE` and `WD`, how dates are ordered, and which bank-holiday [feed](#feed) you're
offered. The UK default is a week starting Monday, with England & Wales holidays.

---

## Alerts and reminders

### Alert

A single reminder attached to an [event series](#event-series), either an [alarm](#alarm) or
a [notification](#notification). It fires at an exact date and time, or relative to the
event: "10 minutes before it starts", "5 minutes after it ends".

See [Reminders and alerts](/docs/everyday-use/reminders-and-alerts.html).

### Alarm

An [alert](#alert) that rings and takes over the screen even when the device is locked, like
a phone alarm clock. For the things you cannot afford to scroll past.

### Notification

An [alert](#alert) delivered as an ordinary notification. No ringing, no full-screen
takeover.

### Alert template

The `%<letter>` codes you can put in an alert's title or body to pull in values from the
event it belongs to: `%t` for the title, `%tm` for the minutes until or since the event.
The same codes work whether the alert fires before, during or after.

Full list: [Alert template syntax](/docs/reference/alert-template-syntax.html).

### App launch action

An app attached to an [alert](#alert), shown on the [alarm](#alarm) ringing screen as a
"TAP TO OPEN" badge. For an alarm that exists to make you do something somewhere else. If
the app has since been uninstalled the badge says so rather than failing.

### Reminder

A task you need to do, rather than a block of time. A reminder is stored like any other
event but behaves differently: it has **no duration**, is **never all-day**, and its
[alert](#alert) is **mandatory**; a reminder that never fires is pointless. When one
rings you can **defer** it to a time you choose, rather than snoozing a fixed interval.

### Recurrence anchor

How a repeating [reminder](#reminder) works out its next occurrence:

- **On schedule**: occurrences come from the [rule](#rule). Completing late, or deferring,
  never moves the ones after it.
- **After completion**: the next one is counted from when you finished, so the
  schedule drifts along with real life.

Reminders default to **On schedule**.

### Do not interrupt

A per-[reminder](#reminder) setting. When it's on, a reminder that would fire in the middle
of an event you're currently in defers itself until that event ends instead of ringing over
it. All-day events don't count as "in progress" for this.

---

## Organising and appearance

### Tag

An optional label attached to an [event series](#event-series), used for filtering and
colour. An event can carry several; the first is the primary tag shown on the calendar when
no tag filter is narrowing things down.

See [Tags, colours and filtering](/docs/everyday-use/tags-colours-and-filtering.html).

### Tag colour

The colour belonging to a [tag](#tag). It's what you normally see on the calendar and in the
event view.

### Event colour

A colour unique to one [event series](#event-series). You often won't see it at first,
because the calendar shows the [tag colour](#tag-colour) instead. Once you filter by tag,
the event's own colour comes through.

### Display colour

Whichever of the two above is being drawn for an event at the moment.

### Event visibility

Whether an [event series](#event-series) is drawn, decided **separately for each view**:
Month, Week, Day and Events. Each can be set to visible, hidden, or inherited from the event
above it.

It exists for the daily repeat that's useful in Day view but turns the Month grid into
noise. Ordinary events start out visible everywhere; [variants](#variant-event) start out
inheriting from their [base](#base-event); [inner events](#inner-event) always inherit from
their parent.

**Not to be confused with [event audience](#event-audience)**, which decides who an event is
published *to* when you share a calendar. Visibility is about your own screen; audience is
about someone else's device.

### Location

A single place attached to an event: an address, plus two optional details a map can't know
for you, **room** and **floor**. "Meeting Room 3", "4th floor".

See [Location and places](/docs/everyday-use/location-and-places.html).

### Home region

The point address search is biased toward, so typing "the crown" surfaces the one near you
rather than one three counties away. It's learned from where you schedule things;
you're never asked for it, and it's only a ranking hint.

### Note

A Markdown file attached to an event, or to one of its occurrences. Notes aren't rows in a
database; they're `.md` files in a folder you choose, so you can point an Obsidian vault
straight at them. A note can cover the whole event, one occurrence, or be a recurring
template seeded fresh into each future occurrence.

Distinct from the **description**, which is the single piece of prose attached to the event
itself and shared by every occurrence.

> **Android only for now.** On iOS and the web the notes interface doesn't appear.

See [Notes and descriptions](/docs/everyday-use/notes-and-descriptions.html).

---

## Sharing

### Partner event

An event belonging to someone you share calendars with, drawn on your calendar alongside
your own. A partner event is **read-only** to you and carries a marker showing whose it is.
Your own events have no owner.

> Owner markers aren't drawn in the calendar views yet.

See [Sharing your calendar](/docs/privacy/sharing-your-calendar.html).

### Busy block

How a [partner event](#partner-event) appears when its creator has hidden it. Only the
timing (start, end, duration) was ever shared. The title, location and everything else
were never encrypted under the shared keys, so no app on your device could reveal them even
if it wanted to. Hiding is enforced by the cryptography, not by the viewing app being
polite.

> Busy blocks aren't drawn in the calendar views yet.

### Event audience

Who an event is published to when you share calendars. The default is to inherit. Anything
created **before** you paired with someone has an audience that excludes them, which is why
pairing doesn't retroactively hand over your back catalogue.

Distinct from [event visibility](#event-visibility), which decides which of *your own* views
an event appears in.

### Sharing member

A person you share a calendar with. The name you give them is **stored on your device and
never transmitted**; it's yours alone.

### Sync server

The relay a shared calendar uses to pass sealed events between phones that aren't on the
same network. Chosen at More → Settings → Sync Server: the Calendite relay, your own
deployment, or none at all, which means same-network syncing only. A sync server only ever
holds ciphertext it cannot open, and only until the other phone collects it.

See [What leaves your device](/docs/privacy/what-leaves-your-device.html).