Rhythm 2.0 Specifications

Appearance

CAP-CMT-MTG-006Maintain meeting notices, calendar feeds and video access

Markdown

CAP-CMT-MTG-006

Maintain meeting notices, calendar feeds and video access

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationInconsistent

Planning

Feature
FEAT-CMT-MTG-01
Key concepts
CON-CMT-MTG-001
Actors
ACT-CMT-002, ACT-CMT-005, ACT-CMT-011
Journeys
JNY-CMT-MTG-001
Depends on
CAP-CMT-MTG-001
Related
CAP-CMT-MTG-020
Open questions
OQ-CMT-MTG-007, OQ-CMT-MTG-008
Proved by
ATS-CMT-MTG-006

KindCapabilityProduct areaCommitteesModuleMeetings, Decisions and RecruitmentRevision1

Read atservices-committees 36129c24react-console baf6dae3

Maintain meeting notices, calendar feeds and video access ​

Purpose ​

Meeting arrangements need to stay understandable when dates or supporting papers change. Notices, calendar subscriptions and video details provide several ways for participants to follow those arrangements.

How It Works ​

The current service submits notices at meeting and publication checkpoints. It chooses addresses from CRM and records successful submissions in a ledger. A recorded submission does not establish that a person received the message. Skipped requests release their keys, but automatic reminder processing does not replay every skipped notice. Staff can download a calendar event, while signed-in members can obtain a secret subscription link. Rotating that link invalidates the earlier token. Calendar descriptions currently include staff notes, leaving a disclosure decision for Product. Video work uses queued requests rather than holding a database transaction open during provider calls. Successful results update the meeting, failed or uncertain results remain eligible for retry, and unavailable-provider results are settled. The approved direction to suppress meeting e-mail and defer automatic video controls still differs from the available backend behaviour.

Relationships ​

Scheduling and publication provide the notice occasions. Member participation supplies calendar-token access; shared communications and video services fulfil the external requests.

The Formal Contract

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

Outcomes
Notification submissions are deduplicated by their occasionCalendar clients receive identified, versioned eventsRoom requests run through committed queued work
Surfaces
apiportaljob
Intent sources
services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#D1services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#D9

Controls

42 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 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-SEC-001 TC-SEC-002 TC-SEC-003 TC-SEC-004 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-CRY-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-AVL-004 TC-AVL-005 TC-MON-001 TC-MON-002 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-VEN-001 TC-VEN-002 TC-VEN-003 TC-PRV-001 TC-PRV-002

Permissions

KeyChecked atScope
committees.meetings.readapitenant
committees.portal.calendarapitenant

Business Rules

13 rules, 11 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.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Calling or moving a scheduled meeting, publishing its agenda or packet, and entering the 48-hour or two-hour reminder window requests notices for participants who have not declined, while cancellation and minutes circulation include every participant.
no proof recorded yet
policyserviceobserved
services-committees:modules/meetings/services/persistence/meeting-notifications.ts:notifyParticipants; services-committees:modules/meetings/services/notifications/reminders.ts:sendDueReminders
02must prove
Proposed
Successful notification submissions reserve a unique purpose, meeting, contact and occasion key, so repeating that occasion does not submit another request.
no proof recorded yet
invariantservice, databasetest
services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#makes every idempotency key once
03must prove
Proposed
Notifications select the lowest-position non-blank CRM e-mail address and log a skipped result when no address is available.
no proof recorded yet
policyservicetest
services-committees:modules/meetings/tests/unit/ports/contact-addresses.spec.ts#is the primary address of a contact with one
04must prove
Proposed
An unavailable communications service leaves the meeting write successful and releases the notification key for explicit retry, without guaranteeing automatic replay of every notice.
no proof recorded yet
policyserviceobserved
services-committees:modules/meetings/services/persistence/meeting-notifications.ts:notifyParticipants
05must prove
Proposed
The product should suppress meeting e-mail until the portal or notifications service arrives and let staff download meeting papers and calendar files in the interim.
origin: CMTE-M3 D1 (Andrew 2026-10-21, services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions)
no proof recorded yet
policydocumented
services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions
06must prove
Proposed
A meeting calendar file uses the meeting identity and saved version and changes from an invitation to a cancellation when the meeting is cancelled.
no proof recorded yet
calculationservicetest
services-committees:modules/meetings/tests/unit/services/ics-calendar.spec.ts#renders an invitation as the golden file
07must prove
Proposed
Issuing a calendar token returns its secret once, stores only its fingerprint and revokes the contact’s earlier live token.
no proof recorded yet
invariantservice, databasetest
services-committees:modules/meetings/tests/integration/services/meetings.integration.spec.ts#stores only the tokens’ hashes, the first revoked by the rotation
08must prove
Proposed
A personal feed accepts a live token without a login, rejects unknown tokens, and includes non-draft meetings linked through current committee participation or a meeting participant row within the feed window.
no proof recorded yet
permissionapi, serviceobserved
services-committees:modules/meetings/services/persistence/calendar-feeds.ts:personalFeed
09must prove
Proposed
Requested video-room work runs after commit under a stable idempotency key, records successful room details, retries failed or unknown outcomes after its claim expires, and settles provider-unavailable outcomes without retry.
no proof recorded yet
lifecycleserviceobserved
services-committees:modules/meetings/services/persistence/meeting-room-requests.ts:drainRoomRequests
10
Proposed
The product should support pasted meeting or series video links and hide automatic room creation until that facility is delivered.
origin: CMTE-M3 D9 (Andrew 2026-10-21, services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions)
policydocumented
services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions
11must prove
Proposed
The product should preserve unchanged video details when staff update another part of the video information.
origin: CMTE-M3 D12 item 10 (Andrew 2026-10-21, services-committees:docs/milestones/CMTE-M3-meetings-and-minutes.md#Decisions)
no proof recorded yet
policydocumented
services-committees:docs/milestones/plans/CMTE-M3-plan.md#D12. Smaller rules to approve as a group
12must prove
Proposed
Meeting calendar descriptions currently include staff notes, both in downloaded files and personal feeds.
no proof recorded yet
policyserviceobserved
services-committees:modules/meetings/services/persistence/calendar-feeds.ts:icsMeetingOf
13
Proposed
Daily and hourly meeting processes run reminder and room work for active workspaces sequentially, with workspace failures reported and the remaining workspaces attempted.
lifecycleserviceobserved
services-committees:modules/meetings/services/jobs/meetings-jobs.ts

Scenarios

IdGivenWhenThenProvenance
01A scheduled meeting has already been called for its original start timeStaff change the start and later restore the original startEach distinct start time has its own call-notice occasion; restoring an already submitted occasion does not submit it againobserved
services-committees:modules/meetings/services/persistence/meeting-notifications.ts:notifyParticipants

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software