# Concepts and vocabulary

> Source: https://whisperer.one/llms/concepts.md · Whisperer machine-readable layer.
> Product overview: https://whisperer.one/llms/product.md · Full corpus: https://whisperer.one/llms-full.txt

A strict vocabulary of the entities Whisperer works with. Several of these words are
generic in other products and mean something specific here; where a wrong reading is likely,
the entry says explicitly what the term does NOT mean.

## Whisperer

The product as a whole: an AI workspace combining meetings, knowledge, tasks, calendar, files
and an AI agent in one context. Not the name of the desktop overlay alone — the overlay is
one surface of it.

## Leo

The built-in AI agent. Leo sees the user's meetings, tasks, calendar and files and acts in
those same places through a declarative tool registry. Leo is a participant in the product,
not a chat window bolted onto it: the tools it calls are the same ones the interface uses.

**Leo is not** a separate chatbot product, and not a model. Which model answers is a setting;
Leo is the agent that decides what to do and which tool to call.

## Meeting

One recorded or imported conversation, with its transcript, speaker labels, timestamps, notes,
decisions and action items. A meeting is the unit of "what was said".

**A meeting is not** a calendar event. An event is a plan; a meeting is a record. They can be
linked — a room lives inside an event, and a recording made there becomes a meeting — but a
meeting can exist with no event, and most events never become meetings.

## Hub

The place a body of work lives: "Acme — rollout", "Hiring a designer", "Release 2.0". A hub
gathers the meetings, obligations and the tracker board that belong to one piece of work, so
that a decision has an address to go to.

A meeting is routed to its hub automatically, by a ladder of signals from strongest to
weakest: an explicit statement by the person, then a calendar series, then the meeting title,
then a live thread already running in the hub, then named things the hub knows, then the
organisation, and only last the participants — who confirm a guess but never create one.
A strong signal overrides a weak one and weak signals never add up to a strong one.

**A hub is not** a folder, and not a group of participants. The same people run two different
pieces of work; an internal review about a client happens without the client present. The
question a hub answers is "what is this about", not "who was there". A hub is never created
automatically — the system may propose one, but the person names it.

## Tracker

The kanban task board: projects, columns, cards with due dates, priorities and labels. It is
where a decision becomes work someone owns.

**The tracker is not** the place obligations are stored. An obligation someone stated on a
call is a Commitment (below) until a person turns it into a task.

## Memory

Leo's long-term memory of the user across sessions: stable facts, preferences and how
recurring things are usually done. Its purpose is that the person does not have to re-explain
what they already said.

**Memory is not** the knowledge base, and not the conversation thread. It holds facts about
the person and their preferences, not their documents; a thread is one conversation and dies
with it.

## Knowledge

The user's own materials — notes with wiki-links, uploaded documents, meeting results saved
deliberately — chunked, embedded and retrieved into answers by RAG. A knowledge graph links
notes to each other.

**Knowledge is not** Memory. Knowledge is content the user put there on purpose and can
browse; Memory is what the agent inferred and keeps about the user. Deleting a note removes
content; forgetting a memory removes an inference.

## File

A stored file in the workspace: folders, search, drag-and-drop upload. Room recordings land
here and become meetings with transcripts. A file becomes Knowledge only when it is sent to
the knowledge base — the two are deliberately separate steps.

## Context

Everything assembled for one answer: the running transcript, the user's profile, retrieved
knowledge, and — inside a hub — that hub's meetings only. Context is computed per answer, not
stored.

**Context is not** Memory and not Knowledge. It is the working set for a single response,
drawn from both. A context window is working memory, not storage.

## Commitment

Something the user or another participant promised, extracted from a meeting with a
mandatory source: which meeting, which moment, who said it. A commitment has a status, a
deadline and participants. Asked "why do you think I promised that?", Leo answers with the
source rather than prose.

**A commitment is not** a task. It becomes a task when a person decides it should be tracked.
Closing a commitment is a decision that belongs to its owner, which is why an external MCP
client cannot resolve one.

## Decision

A conclusion reached in a meeting, recorded with its source the same way a commitment is.
Decisions are what a mind map of a meeting is built from, and what a hub shows when it
reports what is unresolved.

## Task

A card on a tracker board: title, due date, priority, labels, column. Tasks are the work
being tracked. A task created from a meeting suggestion is routed to the board of the
meeting's hub; with no hub and no board chosen, the suggestion honestly declines rather than
filing the task somewhere arbitrary.

## Relationships

```
Calendar event ──may host──▶ Room ──recording──▶ Meeting ──belongs to──▶ Hub
                                                    │                     │
                                                    ├─ Transcript         ├─ Tracker board ──▶ Task
                                                    ├─ Decision           └─ Commitments
                                                    └─ Commitment ──promoted by a person──▶ Task

File ──sent deliberately──▶ Knowledge ──retrieved into──▶ Context ──▶ Answer
Memory ──────────────────────────────────────────────────▶ Context
```