Read straight off the entities and business rules. Evidence: Circle Admin API v2 / Member API schemas and Circle's knowledge base.
| Target | Commentable? | Mechanism (entity) | Threading / reactions |
|---|---|---|---|
| Post in a Posts space | Yes | COMMENT (owned by POST) | Parent comment → one level of replies (parent_comment_id); likes (COMMENT LIKE); can be disabled or closed per post; hidden entirely if space has "hide post settings" |
| Image post in an Images space | Yes | COMMENT — image posts are POST subtypes | Same as posts |
| Event in an Events space | Yes | COMMENT — events are POST subtypes (out of scope here) | Same as posts; can be disabled per event |
| Lesson in a Course space | Yes | LESSON COMMENT — a chat‑room message attached to the lesson (lesson.chat_room_uuid), not a POST comment | Parent + threaded replies; emoji reactions (not likes); pinning; Threads panel; on by default per lesson (is_comments_enabled); admins get "new lesson comment" notifications |
| Quiz (a lesson subtype) | Yes | LESSON COMMENT (same mechanism as lessons) | Same as lessons |
| Section / Module | No | SECTION has no comment child | A section is a grouping container only |
| Space (any type) | No | SPACE has no comment child | You comment on the content inside a space, never on the space. To "discuss a course" you pair it with a Posts space in the same Space Group. |
| Space Group | No | — | Navigation container only |
| Chat space | Messages, not comments | CHAT MESSAGE (out of scope) | Real‑time messages with threads & reactions |
| Members space | No | — | A directory view; no content of its own |
| A comment itself | Reply only | COMMENT → COMMENT (structure entity) | One level: replies cannot have replies |
Design consequence for Upgrade IQ: lesson discussion is siloed inside the course space and surfaces only in the Threads panel and course dashboard — it never reaches the Feed. If you want course conversations to be community‑visible, you need a companion Posts space.
The Feed is not a table — it is a derived view (a query) over POST. Per member it returns posts where:
hide_from_featured_areas), andSorting: Latest · Oldest · Popular · Likes · New activity · Alphabetical · For you (recency × engagement). Side blocks: Trending posts (top 5 by engagement within an admin‑set day threshold) and Upcoming events (from the member's event spaces). Visitors to a public community see only Open‑space posts. Each Posts space also has its own local feed (layout Feed / List / Card) with per‑space default sort and Topic filters.
*Circle's KB names "post and event spaces" as feed sources; image posts are structurally POST subtypes and may surface — treat as unverified.
No shared library entity exists in Circle's schema. Files are owned by the lesson (GET /courses/{course_id}/lessons/{lesson_id}/files → LESSON FILE), plus one optional featured media (video/audio) per lesson and inline attachments in the rich‑text body. So LESSON FILE is a dependent entity, not the intersecting DOCUMENT × LESSON you hypothesised. The same PDF used in three lessons is stored three times, with no single place to update it. Circle's own guidance for a "resource library" is a Posts space used as a library (one post per resource, filtered by Topics) — a modelling choice you make, not a feature they ship.
Tiers are not an entity; they are patterns over two mechanisms:
access_type = access_group). Platinum simply contains a superset of Silver's spaces.Recommended shape: one SPACE GROUP per tier for navigation clarity (their KB explicitly cites "Basic / Premium" space groups as a use case), with each tier's Course spaces, Posts space and resource Posts space inside it.