Your five interview answers, recorded, plus the structural model they add up to. Updated 2026-08-14: the "does buying grant membership" question is now answered — see below. Two other answers still overturn a settled decision — that's called out, not buried.
A product is one thing a creator sells — once, or on a recurring schedule — and it needs no community to exist. A cohort is a time-bound, multi-event experience any creator can run, optionally linked to a community, never required to be. A community is the only structure that gives someone standing access to a creator's whole space — chat, multiple cohorts, ongoing belonging — and today only JoyOS admins can create one. Buying a product does NOT by itself make you a community member. A community subscription bundles access to everything a creator makes; an a la carte purchase never needs a community; and a creator can OPTIONALLY attach temporary community access to a single purchase. Three distinct paths to the same content — see "The access model" below.
Admin-only stands. New: a permissions system admins can manage is planned (not built) — see below. Recorded as REQ-025.
Not one answer but three coexisting paths — a subscription-driven bundle, an open a la carte purchase, and an optional creator-controlled temporary bridge between them. See "The access model" below for the full breakdown. Recorded as REQ-031.
Community is optional, never mandatory. Confirmed again by the 2026-08-14 access-model answer: a la carte purchases never require a community. Recorded as REQ-027.
One level, not two. This narrows REQ-005's earlier "badge + toggle" model down to toggle-only. REQ-005's original text stays on record; REQ-028 supersedes it.
This reaffirms, not reverses, the 2026-08-07 agreement. The call already settled optional association (Ethan, ~12:17: "A cohort can be a part of a community"; Kristin, ~12:18, restating one case: "you can have cohorts within the community"). No prior decision was overturned. Recorded as REQ-029 (withdrawn as a supersession, correction dated 2026-08-14).
1. Community subscription. Grants access to that creator's products, events, AND cohorts, for as long as the subscription holds. This is the bundle: one payment relationship, everything the creator makes.
2. A la carte purchase. Anyone can buy a single product directly, with no community involvement at all. This is the un-bundled path — one thing, one payment, no ongoing relationship implied.
3. Creator-granted temporary community access. A creator MAY optionally attach time-bounded community access to a single purchase — per-product, the creator's choice, never automatic. This is the bridge between the two: a taste of the community triggered by an a la carte buy, that expires.
Why a subscription and a product aren't redundant even though both imply ongoing access and payment: the social layer is the reason a community exists — connecting with others, working on things together, channels to talk in. A recurring product can never be that, no matter how many things it bundles. Bundling access is a side effect of a community; the social layer is the point.
Diagram: the three access paths, side by side — what each grants, to whom, and for how long, converging on the same underlying content.
| Question | Answer |
|---|---|
| Who controls it | The creator, per product — a setting on that product, not a platform-wide rule |
| What it grants | Community access, time-bounded |
| Default | OFF — a creator must deliberately turn it on for a given product |
| Duration | OPEN — Ethan did not state a duration rule. Not invented here. |
| What happens at expiry | OPEN — must be a real, observable state change, never silent removal. |
Recommendation (not a decision): a per-product duration field the creator sets when enabling the toggle (e.g. 7/14/30 days from purchase), defaulting to a short window (7 days) if left unset, with the member seeing a visible "temporary access — N days left" state throughout and an explicit "your temporary access has ended" state at expiry rather than the community simply disappearing from their view. Recorded as an open gap with this recommendation at REQ-032 — routes to Ethan for confirmation, not assumed.
Diagram: the gap itself, drawn honestly — a dotted window of unknown length ending at an unknown state, not a confident 7-day box. The 7-day figure two paragraphs up is a recommendation for Ethan to confirm, not what this picture shows as settled.
The same product can now be reached through more than one grant at once. A member's access to a piece of content must be derived from any active grant, never from a single "owner" field:
Diagram: subscription grant lapses, purchase grant survives, the member's access to the product never breaks — because entitlement is checked as "any active grant," never a single owner field.
Recorded as REQ-033: entitlement is modeled as "does at least one active grant exist for this member and this content", not as a single ownership pointer. This is a data-model constraint on whatever schema eventually lands, not a UI nicety.
What each one is, what it gives someone a product doesn't, and where your four named examples land.
A creator's whole space — chat, gratitude toggle, and a shelf of whatever cohorts/products the creator links into it. What it gives someone a product doesn't: standing belonging to a creator's ongoing output, not access to one thing — plus the social layer (connecting with others, working together, channels to talk in) a subscription bundle alone cannot provide.
A time-bound, multi-event experience with one focus — a book club, not an open-ended space. Runs an event series for a defined group. Can exist entirely on its own or be linked into a community, and is one of the things a community subscription bundles access to.
One thing sold once or on a recurring schedule — digital download, 1:1 session, physical good. Buyable a la carte by anyone. Recurring ≠ community: a recurring product is ongoing payment for one thing; a community is ongoing payment for everything the creator runs, plus the social layer.
| Named example | Maps to | Why |
|---|---|---|
| Digital product | Product, one-off or recurring | One thing, no community needed; buyable a la carte |
| 1:1 coaching session | Product | A single service, bought directly |
| Physical product | Product, one-off or recurring (subscription box) | Fulfillment is the creator's job either way |
| Cohort | Cohort, standalone by default | Time-bound, single focus, multi-event; can optionally link to a community, or be reached via a community subscription |
Diagram: cardinality across creator, community, cohort, product, member. The community-cohort link is optional (dashed, red) in both directions — an orphan cohort and a community-less product are both legal states, not errors, shown here rather than asserted in prose.
Creation rights are now split by structure type — the builder and the admin panel are not interchangeable doors.
| Structure | Who creates it | Where |
|---|---|---|
| Product (any offer type) | Any creator | The Offer Builder (offer-builder's surface — unchanged); creator sets the optional temp-community-access toggle here per product |
| Cohort | Any creator | Its own creation flow — not the offer picker (per the standing 2026-08-07 note that a cohort is not an offer type); may optionally attach to a community |
| Community | Admin only, today | Admin-provisioned; creator self-serve is future work, gated by the permissions system below |
Diagram: the permissions layer is one band over both doors, not three separate rules — it happens to leave Cohort and Product open today and Community closed, and that can change without redesigning the layer itself.
| Structure | Who holds membership | What it grants |
|---|---|---|
| Product | The buyer, via an entitlement record for that one product (permanent, independent of any subscription) | Access to that one thing only — plus, if the creator opted in, time-bounded community access |
| Cohort | Enrolled participants, scoped to that cohort's run | Access to that cohort's events, for its duration — reachable directly, or via a community subscription that bundles it in |
| Community | Explorer members, via a per-community subscription (separate from the creator's own platform tier) | Standing access to the community's chat, gratitude space, the social layer, and whatever cohorts/products the creator links in |
Question 2 is answered: a product purchase, by itself, grants only that product. A community subscription grants the bundle. A creator can optionally bridge the two with a time-bounded community-access grant on a specific product. Three grant types, tracked independently, composing per member per piece of content.
What Ethan asked for directly: a system admins can manage, deny-by-default, enforced server-side.
| Capability | Default | Granted to | Granularity |
|---|---|---|---|
community.create | Closed to everyone but admins | Named individual creators, by admin grant | Per-creator, not per-tier — a Pro creator gets nothing extra here until an admin grants it directly |
community.gratitude_toggle | Open to the creator who owns that community (unchanged) | Automatic on community ownership | Per-community |
cohort.create | Open to any creator (unchanged) | Automatic on creator tier | Global, not per-community |
product.temp_community_access | OFF by default per product | The creator who owns that product, toggled per product | Per-product, time-bounded (duration itself still open — see REQ-032) |
community.create to a specific creator identity — never a tier-wide unlock, never a self-serve toggle.This deliberately does not answer the Standard/Pro feature-list fork (REQ-006/030) or presume that Pro tier alone unlocks anything here — that boundary belongs to joyos-labs-creator-lab-tier-gating, and this permissions system is built so either answer can slot in later without a redesign.
Ethan's own words: "not all that is built out right now, but we can build the mockup to show placeholders until the functionality exists." So a community mockup CAN show channels, members, and working-together as placeholders. Two constraints on that, stated plainly so they aren't lost between here and a mockup pass:
An earlier version of this page claimed the 2026-08-14 answer below SUPERSEDED a 2026-08-07 Kristin-call decision described as strict containment ("communities containing cohorts"). That claim was wrong and has been withdrawn. The meeting record was checked and it outranks the earlier claim.
2026-08-07 (Kristin call), verbatim, ~12:17-12:18: Ethan: "A cohort isn't necessarily just a community. A cohort can be a community. A cohort can be a part of a community." Kristin: "Yes. Okay. So the community is bigger. You can have cohorts within the community." And ~12:51:39, on creation rights: Ethan: "Communities gated by JoyOS team, cohorts are open to any creator."
2026-08-14 (Ethan, today): "not community bound, but can be part of it" — the same optional-association model, restated.
Kristin's "cohorts within the community" line on the 2026-08-07 call restated ONE CASE, not the rule — "communities containing cohorts" never appeared on that call. It was a downstream paraphrase in an earlier requirements write-up that collapsed "can be / can be part of" into strict containment, then hardened into a decision nobody made. The model was right all along: a cohort may stand alone, may belong to a community, and may itself be a community. The data-model consequence (a join/link table, not a required parent foreign key — already what the schema seam landed 2026-08-11) and the orphan-cohort-is-legal callout below remain correct; only the "this reversed a prior decision" framing is withdrawn.
WITHDRAWN 2026-08-14: this box previously warned that Kristin might not know the cohort/community model "changed." That flag is withdrawn — nothing changed. The 2026-08-07 call already settled optional association; see the correction above. No confusing conversation about a reversal is needed because no reversal happened.
Second: REQ-005's gratitude answer ("badge + toggle, both levels") was recorded 2026-08-08 as resolving an earlier open question. The 2026-08-14 answer drops the badge half entirely without addressing it — it may be an intentional simplification, or the badge may have simply been forgotten when re-answering. Worth a one-line confirmation before the badge work is dropped from anyone's backlog.
Third, new: the temp-access duration and expiry behavior (REQ-032) is a genuine gap, not a design choice made here. A recommendation is offered above, but nothing about it should be treated as decided until Ethan confirms it — it is exactly the kind of small unstated detail that becomes a real support problem ("why did my community access just disappear") if guessed wrong.