Cohort.software · The whole series
Different views. The same series.
A facilitator needs to organize a group; a participant needs to understand the commitment. These are requirements for planned Cohort surfaces, not screenshots of a running service. Start with what each person must be able to explain after a change, and the missing decisions become easier to see.
The facilitator needs the arc and its exceptions together
The planned facilitator view starts with the series: its purpose, cadence, span and capacity. A list of unrelated calendar entries would make the organizer reconstruct the program every time they look at it. For a fictional adult workshop, place the intended eight meetings beside the start and finish, then mark the holiday exception. The useful output is an understandable relationship between the rule and the dates. It should be possible to explain why there are eight meetings even when the series stretches across nine calendar weeks.
That view also needs to keep a calendar decision distinct from an enrollment decision. Moving one evening should prompt a review of the occurrence change, while admitting a late joiner raises a question about the person's place in the series. The site does not provide either control today. In an evaluation, ask the facilitator to describe the two actions without using a screen. If both are called simply editing the course, the proposed surface needs clearer language before anyone could safely infer what a save action means.
The participant needs to know what they are joining
A participant considering the fictional series needs more than the first date. They need the shape of the arc, the expected meetings and the distinction between the whole program and an individual session. The planned output should answer a plain question: if I join this, what have I committed to? A headline about an eight-week workshop is useful, but it is incomplete when a holiday skip changes the finish. The relevant details should be understandable before a person is asked to make an enrollment decision.
After a moved week, the participant needs to understand the revised dates and whether their series membership continues. That does not amount to agreement with the new schedule. A planned continuity feature should not overwrite the person's practical objection or pretend a missed meeting has no consequence. Use the exercise to identify the explanation a facilitator would give through their existing process. Do not send real participant communications from an evaluation or treat a static example as a confirmation. There is no live participant enrollment surface on this website.
The roster should describe membership, not a collection of bookings
The product plan binds the roster to a series identifier rather than recreating it from each dated occurrence. In human terms, the same group continues to belong to the workshop when the calendar changes. A proposed roster view therefore needs to make membership legible across the arc. In the fictional exercise, compare the group before and after the holiday skip. The output you are looking for is continuity of enrollment, not a new list assembled from people who happened to book a replacement evening.
A roster is also a record about people, so it is the wrong attachment for an initial marketing conversation. Use invented labels or simply counts to explore the view. Describe whether a facilitator needs to distinguish an initial intake from a later join, but keep actual participants and private circumstances out of the example. This page does not define a working access-control model or a records retention service for the planned product. Those operational questions need their own evidence before a real roster could become part of a deployment.
The next intake deserves its own decision
A completion view should help a facilitator close the arc they actually ran. The planned next-intake step is opt-in and distinct; it is not a reason to make the current series endless. In a walkthrough, show a finished fictional workshop beside a possible later offering. Ask what someone would need to know to decide whether to join again. A changed schedule, different learning goal or revised size may make the second series a different commitment even when many of the same adults are interested.
The output of that exercise is a clear boundary between finishing and starting again. Avoid a design that treats the old roster as permission to create a new commitment for everyone. This site does not perform rollover, issue invitations or enroll people into another intake. If a prospective program needs an ongoing membership with independently selectable meetings, say so. That may be a different product shape. Good surfaces make this mismatch visible early, before calendar repetition is mistaken for proof that a whole-series model fits.
A useful design can still be an unfinished product
The recurrence rule, series enrollment and roster continuity described here are planned. The shared capacity-N engine is a narrower built component; it does not establish that a facilitator can publish a Cohort series, accept an enrollment or change an occurrence through this website. There is no live checkout and no card is charged here. Examples describe decisions a future product must make legible, not records being created in the background. A polished explanation should make that boundary easier to see, not harder.
For an evaluation, keep your existing calendar and enrollment process in charge. Choose one fictional adult series and work through what a facilitator and participant would need to understand at each step. If the proposed behavior does not fit, that is a useful result. A conversation is not an enrollment, a displayed price is not a bill, and a related product link is not evidence of an integration. Read the help guide for the existing capability ledger and the starting guide for the scope of a conversation today.