Maintain meeting participation and attendance

Purpose

Attendance distinguishes an expected participant from someone who actually takes part. Staff retain that distinction when making later corrections.

How It Works

A meeting begins with a date-specific roster snapshot. Staff inspect the resulting roles and voting flags, then add people who were not included. A guest, a later appointee and a proxy each need an explicit participant record. Staff can adjust roles, invitation responses, attendance, presence times and notes using the saved participant version. Contact and appointment identity stay fixed during an update. Attendance can be submitted for several participants together, with failed entries leaving the batch unchanged. Video attendance is retained separately from staff-entered attendance. Closing a meeting restricts further participant writes to authorised, audited reopening. Cancellation prevents those writes altogether. Automatic roster refresh, the approved proxy model, removal of mistaken additions and visible correction reasons remain directions for future implementation. Manual additions currently accept some mismatched references, so an accepted record does not establish a verified contact-to-appointment relationship.

Relationships

Scheduling establishes the meeting and initial snapshot. Quorum assessment consumes attendance, while member participation supplies invitation responses.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Expected participants have recorded meeting roles and voting flagsStaff can submit attendance as one complete batchPost-close changes require authorised reopening and retain an audit
Surfaces: api
Preconditions: A meeting record is available.
Intent sources: services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#D4services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#D5services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#D12

Controls

24 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-SEC-001 TC-SEC-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-003 TC-PI-005 TC-PRV-001 TC-PRV-002

Permissions

Key	Checked at	Scope
`committees.meetings.read`	api	tenant
`committees.meetings.manage`	api	tenant

Business Rules

16 rules, 16 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Creation copies the roster for the meeting’s local date, assigning chairs from chair positions, other seat-holders as members, advisers, liaisons and secretaries by participation kind, observers and guests as guests, and voting flags from the roster. no proof recorded yet	calculation	service	test services-committees:modules/meetings/tests/unit/services/snapshot-and-participation.spec.ts#makes a seat-holder in a chair position the chair
`02`must prove Proposed	When several roster entries describe one person, the snapshot selects a chair entry first, otherwise a voting entry, otherwise the first entry encountered. no proof recorded yet	calculation	service	observed services-committees:modules/meetings/services/participants/snapshot-rule.ts:snapshotParticipants
`03`must prove Proposed	The product should refresh roster-derived participants until the call to order or closure, preserve manually added guests, proxies and corrections, and retain the resulting attendance record. origin: CMTE-M3 D4 (Andrew 2026-10-21, services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions) no proof recorded yet	policy		documented services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions
`04`must prove Proposed	Staff can add guests, late appointees and proxies manually, but the same contact cannot be recorded twice for one meeting. no proof recorded yet	validation	service, database	test services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#adds a guest with no appointment, non-voting
`05`must prove Proposed	A proxy must identify an appointment already represented among that meeting’s participants, and a non-proxy cannot identify a represented appointment. no proof recorded yet	validation	service, database	test services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#refuses a proxy for an appointment that is not at the meeting
`06`must prove Proposed	Proxy participation is accepted when no decision-rule document exists or when that document does not explicitly forbid proxies. no proof recorded yet	policy	service	test services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#adds a proxy for an appointment of the meeting when the committee has no rules
`07`must prove Proposed	The product should require explicit committee permission for proxies, record representation against the absent member, preserve the holder’s own role and presence, and prevent multiple proxies for one member. origin: CMTE-M3 D5 (Andrew 2026-10-21, services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions) no proof recorded yet	policy		documented services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions
`08`must prove Proposed	An API attendance batch contains one through 1,000 entries with distinct participant identities, and any invalid entry rolls back the complete batch. no proof recorded yet	validation	api, service	test services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#records attendance for every participant in one write
`09`must prove Proposed	A recorded departure cannot precede the corresponding arrival when both are supplied. no proof recorded yet	validation	database	observed services-committees:modules/meetings/db/meeting-participants.table.ts:meeting_participants_presence_check
`10`must prove Proposed	Held-meeting participant and attendance edits require explicit reopening by a meeting manager, with each successful edit appended to an audit protected from application updates and deletion. no proof recorded yet	invariant	api, service, database	test services-committees:modules/meetings/tests/integration/services/minutes.integration.spec.ts#refuses attendance after the close without reopen
`11`must prove Proposed	The product should require a reason for a post-close attendance correction and display that reason in the meeting history. origin: CMTE-M3 D12 item 8 (Andrew 2026-10-21, services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions) no proof recorded yet	policy		documented services-committees:docs/milestones/plans/CMTE-M3-plan.md#D12. Smaller rules to approve as a group
`12`must prove Proposed	Participant edits are refused for cancelled meetings even when reopening is requested. no proof recorded yet	invariant	service	test services-committees:modules/meetings/tests/unit/services/minutes-rule.spec.ts#refuses every edit of a cancelled meeting, reopened or not
`13`must prove Proposed	The participant’s video attendance stores each provider event once despite repeat delivery. no proof recorded yet	invariant	service	test services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#records a joined event on the participant once, however often it is delivered
`14`must prove Proposed	The product should let staff remove an accidentally added participant before the meeting is called to order. origin: CMTE-M3 D12 item 6 (Andrew 2026-10-21, services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions) no proof recorded yet	policy		documented services-committees:docs/milestones/plans/CMTE-M3-plan.md#D12. Smaller rules to approve as a group
`15`must prove Proposed	Updating a participant requires the current saved version, while contact and appointment identities cannot be changed through that update. no proof recorded yet	validation	api, service	observed services-committees:modules/meetings/services/persistence/meeting-participants.ts:updateParticipant
`16`must prove Proposed	Manual participant creation checks that a supplied appointment exists, but does not verify that it belongs to the supplied contact or committee, and does not validate the contact against CRM. no proof recorded yet	validation	service, database	observed services-committees:modules/meetings/services/persistence/meeting-participants.ts:addParticipant

Scenarios

Id	Given	When	Then	Provenance
`01`	The roster gains a director after the meeting’s participant snapshot was created	Staff retrieve the meeting participants	The later appointment is absent from the snapshot unless staff add the person explicitly	test services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#never re-snapshots: a later appointment does not join the meeting

Planning

Maintain meeting participation and attendance ​

Purpose ​

How It Works ​

Relationships ​