---
title: A Taxonomy for Meetings
author: Matt Prusak
version: "1.0"
published: 2026-07-30
canonical_url: https://www.mattprusak.com/writing/a-taxonomy-for-meetings/
markdown_url: https://www.mattprusak.com/writing/a-taxonomy-for-meetings/standard.md
document_type: meeting-naming-standard
---

# A Taxonomy for Meetings

A practical system for naming meetings, deciding what kind of meeting they are, and making their purpose legible.

By Matt Prusak · July 30, 2026

## Instructions for an AI or scheduling agent

When this document is provided as a policy input:

1. Treat it as the default for **new events**, not permission to bulk-rename existing events.
2. Preserve inbound invitations and explicitly finalized titles unless the user directs otherwise.
3. Apply formal governance and records requirements before display preferences.
4. Classify the event form and primary meeting job before generating a title.
5. Never infer that sensitive information is safe to disclose. Omit it or use an already approved neutral label.
6. Treat the organizer, scheduling assistant, and meeting owner as separate roles. A service account does not become the meeting owner.
7. Keep the document's semantics fixed while adapting punctuation, ordering, language, and approved abbreviations to the user's stated display profile.
8. When changing a scheduling workflow, return the proposed rules, representative examples, ambiguous edge cases, and tests. Do not make live calendar changes without authorization for that scope.

Suggested user instruction:

> Apply this meeting-naming standard to my calendar or scheduling system. Derive a local display profile from my stated preferences, identify conflicts or missing inputs, and then propose the rules, examples, and implementation changes needed. Preserve the safety and governance constraints.

Most calendar titles are bad at their only real job: helping someone recognize the right block of time in a narrow, crowded view.

*Meeting*, *Chat*, and *Sync* say almost nothing. A roster of names repeats information the calendar already stores. Long agendas disappear after a few characters. Sensitive detail can escape onto lock screens, shared calendars, room displays, search results, exports, and forwarded invitations.

A useful title is a **scan key**. It should answer one question immediately:

- **Who?** for a two-person relationship meeting
- **What?** for a one-off group doing a piece of work
- **Which standing system?** for a recurring forum
- **Which legal body?** for a formal governance event
- **Which activity?** for personal time

That produces a small taxonomy that works across executive, legal, sales, product, and operating calendars.

## The five event forms

| Event form | Title pattern | Example |
|----|----|----|
| Two-person meeting | `{Other Person} x {Meeting Owner}: {Purpose}` | `Sam x Alex: Comms Review` |
| Ad hoc group | `{Topic or Outcome}: {Useful Context}` | `Financing Review: Acme` |
| Named recurring series | `{Stable Namespace}: {Series Name}` | `Legal: Entity Review` |
| Formal governance | Exact approved name | `Acme Holdings: Board Meeting` |
| Personal block | Plain-language activity | `Workout` |

Inbound invitations, existing events, and intentionally finalized titles form a separate preservation category: leave them alone.

### 1. Two-person meetings: person first

For a familiar bilateral meeting, the other person is usually the most valuable left-edge scan key:

    Sam x Alex: Comms Review
    Jordan x Alex: Career Advice
    Taylor x Alex: 1:1
    Morgan x Alex

The other participant comes first and the represented meeting owner second. Those are stable event roles, not viewer-relative labels. An assistant, scheduler, or service account that creates the invitation does not become the meeting owner.

Use a lowercase `x` with one space on each side. Use a colon with no preceding space and one following space. The punctuation is a display convention, not a claim of universal standard. Another organization could reasonably choose `<>`, `&`, or natural language. The durable idea is the pair relationship and its purpose.

Do not create chains such as `Sam x Jordan x Alex`. Once more than two people are central to the work, classify it as a group.

A shared title can never be perfectly symmetric: whichever name appears first receives the strongest scan position. For an unfamiliar external meeting, the topic or organizations may therefore be more useful than a person-first title:

    Security Review: Acme & Northstar

### 2. Ad hoc groups: topic first

A one-off group exists to do a piece of work. Lead with that work:

    Entity Structure Decision
    Financing Review: Acme
    Data Center Strategy: Acme & Northstar
    Intro: Jordan & Casey
    VP Finance Interview: Morgan

Do not turn the title into an attendee list. Add an organization, function, project, or person after the colon only when it resolves a real ambiguity or changes how someone should prepare.

Prefer an intended outcome over a topic, and a topic over a format:

    Entity Structure Decision

is better than:

    Legal Meeting

If the outcome is not established, use the supported topic alone. A scheduling system should not invent authority by upgrading “entity structure” into “entity structure decision” unless a decision is actually expected.

### 3. Recurring series: namespace first

A recurring meeting is part of a standing operating system. Its stable namespace should come first:

    Legal: Entity Review
    Finance: Weekly Review
    Leadership: Staff Meeting
    Project Atlas: Risk Review
    Acme: Quarterly Review

This is not inconsistent with topic-first group naming. The two forms answer different questions.

A one-off Legal meeting about entities might be:

    Entity Structure Decision

The recognized recurring forum might be:

    Legal: Entity Review

The first helps someone find the work. The second helps someone find the standing system.

Every recurring series should have an owner and a periodic expiry review. Recurrence is not proof that a meeting still deserves to exist.

### 4. Formal governance: authority over elegance

Board, committee, member, and other formal proceedings may have legal, notice, records, or corporate-secretary requirements. Use the exact approved title:

    Acme Holdings: Board Meeting
    Audit Committee: Quarterly Meeting

The formal-title rule overrides scan optimization. A calendar invitation is not a substitute for required notice, agenda, minutes, consent, or recordkeeping.

### 5. Personal blocks: plain language

Personal time does not need organizational syntax:

    Workout
    Deep Work
    Dinner
    Reading
    Travel

Do not add a meeting-job suffix or participant name when the activity itself is the clearest description.

## The nine jobs meetings perform

Event form determines how a title is rendered. **Meeting job** determines why synchronous time exists and what must be produced. A meeting should have one primary job.

| Primary job | Use it when | Minimum output | Useful title language |
|----|----|----|----|
| Decide | A named choice needs an identified decider | Decision, rationale, owner | `Decision`, `Approval`, `Selection` |
| Review and control | Evidence is compared with a standard | Accepted state, exceptions, actions | `Review`, `Risk Review`, `Pipeline Review` |
| Plan and commit | Constraints must become commitments | Plan, owners, dates, dependencies | `Planning`, `Prioritization`, `Kickoff` |
| Produce | Participants must advance an artifact | Updated artifact and remaining owners | `Working Session`, `Drafting`, `Design` |
| Explore and diagnose | The group must reduce uncertainty | Evidence, hypotheses, open questions | `Discovery`, `Diagnosis`, `Workshop` |
| Learn and improve | A completed cycle should change behavior | Lessons, causes, changes, owners | `Retrospective`, `Debrief`, `Incident Review` |
| Develop and relate | A person or relationship is the object | Shared context, feedback, next step | `1:1`, `Intro`, `Coaching`, `Coffee` |
| Intake and triage | New work must be classified and assigned | Disposition, priority, owner | `Intake`, `Triage` |
| Brief and teach | Shared understanding must be built live | Comprehension and resolved questions | `Briefing`, `Training`, `All Hands` |

Governance is an authority and recordkeeping overlay, not a tenth job. A board meeting can contain briefing, review, and decision work while retaining its formal title.

“Update” by itself is usually a communication mode, not a sufficient reason to meet. A live update should earn synchronous time through questions, interpretation, escalation, relationship work, or a decision. When possible, prefer `Risk Review`, `Market Briefing`, or `Pricing Decision`.

## The title is not the meeting contract

A clean title does not make an unnecessary or poorly run meeting worthwhile. Every consequential meeting should define, in its description or linked document:

1.  The meeting’s job and desired output
2.  One meeting lead
3.  One decider when a decision is expected
4.  Any pre-read or prewrite and its comment deadline
5.  A time-boxed agenda
6.  Required attendees by contribution or authority
7.  Decisions and actions, each with one owner and a due date
8.  For recurring meetings, an owner, cadence, and expiry review

Before scheduling, ask:

> Does this require real-time interaction, or can writing plus comments produce the result?

If writing is enough, the right meeting title is no meeting at all.

## Disclosure comes before specificity

Calendar titles are broadly replicated surfaces. They may be visible to attendees, delegates, room administrators, shared-calendar viewers, mobile notifications, search systems, synced chats, exports, and screenshots.

Every visible token—including names and organizations—must therefore be safe for every expected surface.

Sensitive personnel, health, investigation, litigation, transaction, compensation, termination, allegation, settlement, and legal-strategy details should be omitted unless a responsible owner has approved a truthful neutral label.

Safer patterns include:

    Alex x Morgan
    Project Cedar: Review
    Entity Review: Legal & Finance

Do not automatically invent euphemisms. Do not add “Privileged,” “Attorney-Client,” or “Confidential” as decoration; a title cannot create privilege or replace substantive handling rules.

When specificity and safety conflict, omit the purpose or use an already approved neutral identifier. Inference confidence is not disclosure authorization.

## Vocabulary and compression

A purpose should normally be one to four words and describe the object plus the work:

    Entity Structure Decision
    Finance Review
    Product Demo
    Career Advice
    Policy Working Session
    Quarterly Planning

Avoid generic labels:

    Chat
    Call
    Meeting
    Sync
    Touch Base
    Discussion

There are legitimate exceptions. `Board Meeting`, `Staff Meeting`, and `All Hands` may be formal or canonical names. `Coffee`, `Lunch`, or `Dinner` may honestly describe relationship time.

Do not put dates, times, locations, platforms, attendee counts, recurrence mechanics, or the full roster in the title. The calendar already stores them.

When a title is too long, remove optional right-edge context first, then an optional purpose. Do not shorten a person’s name or invent an abbreviation merely to hit a character count.

## A practical implementation sequence

For each new event:

1.  Apply any formal legal or records requirement.
2.  Preserve inbound, existing, and explicitly finalized titles.
3.  Check whether every proposed name, organization, topic, and purpose is safe on shared surfaces.
4.  Classify the event form.
5.  Identify the primary meeting job and desired output.
6.  Render the appropriate title pattern.
7.  Remove optional right-edge context.
8.  Confirm that the result is truthful, recognizable in a narrow view, and safe everywhere it may appear.

Apply the system prospectively. Do not bulk-rename existing invitations or recurring series.

## What could become a standard

The exact connector should not be the standard. `x` is a local display choice, and neither person-first ordering nor any punctuation mark is universally optimal.

A credible cross-product standard would instead have three layers:

1.  **Safe shared title** — useful and privacy-safe on its own
2.  **Meeting semantics** — form, job, namespace, represented owner, desired output, sensitivity, and title origin
3.  **Display profile** — the organization’s chosen ordering, punctuation, language, and abbreviation rules

That separation would let calendars render titles appropriately while preserving their meaning across Google, Microsoft, Apple, scheduling products, copies, forwards, and recurring exceptions.

> Put the right scan key first, give the meeting one real job, and disclose no more than the calendar surface can safely carry.

This is a proposed operating framework and display profile, not a claim of industry consensus or legal advice.

Version 1.0 · Published July 30, 2026