Meeting

What It Models

A meeting brings together the committee’s scheduled gathering, expected participants, recorded attendance, agenda and supporting papers. Recurring series are a facet of this object because their purpose is to produce those gatherings. Notice, room and calendar records support participation rather than define another business concept.

Identity and Attributes

The record identity survives rescheduling. A recurring occurrence keeps its original local date even when its start changes. The logical attributes group related values; the table and request schemas remain the detailed field definitions.

Relationships

Each meeting belongs to a committee whose appointments and settings it reads. Its minutes form a revision sequence, and decisions reference the meeting and the agenda item where the motion arose. Continuation and deferral links are optional outgoing references rather than exclusive pairings.

Invariants

Staff actions use the meeting lifecycle and record lock. Uniqueness constrains occurrence and participant duplication. Reopening explicitly permits held attendance corrections, while event, notice and provider work is committed alongside the business change.

How It Is Stored and Shared

The meetings service owns the records and reads CRM addresses through the shared database access contract. Decision code also writes agenda decision links and quorum information inside the shared macroservice. Queries exposes meeting and attendance datasets. Managed file content uses Platform assets, and this concept declares no custom fields.

Open Design Questions

Product’s decisions on draft series timing, live roster membership, proxy defaults and suppressed e-mail differ from the built paths. Calendar descriptions can disclose staff notes. Video registrant and attendance paths have no production delivery, and database append-only enforcement needs its migration evidence.