Message is an open one-to-one thread owned by messages.elonn.local. A reply extends a conversation or event's discussion (social.elonn.local). A Social DM is a private one-to-one thread that starts from Social context and stays owned by Social. None of these three are interchangeable, and none of them is a generic "message". Event, unqualified, always means a social event (social.elonn.local): a scheduled gathering with participants, RSVPs, and an attached conversation. A calendar event / time event is a time.elonn.local calendar entry. Social pushes event data to Time to mirror it as a calendar entry; Time does not own social events. Discovery is the social graph traversal (social.elonn.local) that determines which members and Social objects are reachable at each circle depth. Find (find.elonn.local) is the search and discovery service; a finding is a single candidate result it produces. Discovery is about who you can see. Find is about what content you can search. Do not conflate them. Activity is an append-only public feed record of a verb performed on an object. Notification is a targeted, recipient-scoped alert. Presence is a member's real-time availability signal. All three are distinct social.elonn.local objects and must not be used for one another. A card previews or launches an object and is renderer-level. Window is a reserved (not yet implemented) independently managed spatial container with z-order, resizing, and overlap. Do not use window as a synonym for card, workspace, or panel. Carry is the personal, member-anchored layer that travels with the member. Field is the shared spatial panorama fixed to the world, visible to all members. Anchor mode (carry / field / object) determines which layer an object belongs to. Field is the persistent world layer anchored to reality. Workspace is the transient manifestation of the member's current intent. Carry is the member-following layer for personal objects and controls. Do not use Findings as a runtime layer name; findings are Find-owned domain results that may be composed into Workspace. The field is the spatial layer within the world; the world is the full composed experience (identity, maps, social, messages, and time data assembled into the canonical model). The world contains the field — the field is not the world. World runtime is the platform adapter / execution environment (web, android, desktop, xr) that consumes translated World contracts. Presence runtime is the string identifier (e.g. web.elonn) recorded on a presence record to show which client a member is using. "Runtime" alone is ambiguous between these and must be qualified. Session alone is ambiguous and must always be qualified: auth session (api.elonn.local, a token-linked record that expires), runtime session (world.elonn.local, the composed world state returned at boot, not stored), or find session (find.elonn.local, a query-grouping session). In runtime contracts, object means a renderable data entity originating from a service (place, member, message, etc.). Elsewhere, "carry object", "field object", and "world object" use "object" as a generic noun. Prefer the domain noun (place, member, message) over bare "object" when referring to a specific type. Member is the API-owned identity record (api.elonn.local) — the person. Identity refers to that same API record and its identity_user_id, and must not be used to mean a profile. Profile is the social-layer representation a member authors for social context (social.elonn.local) and is a distinct record from both. Circle is a derived set of members computed by traversal (depth: inner / trusted / extended); it is never stored or manually managed. Relationship is an explicit, directional, stored record (currently only "block"). Discovery is the traversal mechanism that computes circles. Circle membership is not a relationship. Visibility controls read access — who can see a social object (public / community / circle / private, depending on object type). Permissions control write access. Do not use the two interchangeably. Conversation is a titled, threaded discussion anchored to a visibility scope (public / community / private). Thread is reserved for message and Social DM containers, which are strictly one-to-one. One-to-one communication uses a thread, not a conversation.

The identity and authentication authority for Elonn. Owns members, auth sessions, and tokens. API issues signed access tokens after member authentication.

Owns: - member identity records - auth sessions - auth tokens - member directory

api service api base URL API token api auth auth service (not its product name) identity service (not its product name) user service (deprecated; "user" is not a product term) account service (account is the login area, not the service name) The service hostname is `api.elonn.local` / `api.elonn.com`. Refer to the service by this name or simply "the API." All other services reference members by `identity_user_id`, which comes from the API service. The API service issues signed access tokens, including the `elonn_api_token` cookie used in browser contexts. World validates signed access tokens locally at the Runtime-World boundary. Downstream services receive authenticated member identity through service-authenticated internal calls. member token session (auth session) identity The named, versioned agreement that defines a World model, runtime payload, or service payload and its behavior. Runtime contracts tell runtimes what primitives, capabilities, services, actions, controls, and objects they can expect.

Fields: - `name` — canonical contract name (e.g. `elonn.home.runtime`) - `version` — integer version; breaking changes increment this

runtime contract service contract translator contract World model contract contract name contract version schema (describes data shape; a contract is broader — it includes capabilities and behavioral expectations) API spec (contracts are runtime payloads, not API documentation) manifest (too generic) The current runtime compatibility contract is `elonn.home.runtime` at version 2. Runtime adapters read the contract name and version to determine how to execute a translated World payload. Version changes are breaking. Runtime contracts are produced by World translators and consumed by runtime adapters. No runtime and no other service produces the runtime contract. When a runtime contract version changes, World, the relevant translator, and affected runtime adapters must be updated together. runtime world translator web session (runtime session) The search and discovery service. Find owns query records, findings (search results), and heads (classifications). It is distinct from the social discovery graph.

Owns: - finding (a single search result) - findings (a result set) - finding head (a classification/category label for a finding) - finding query (a search query record) - find session

find service finding finding head search results (UI prose only) discovery service (discovery refers to the social graph traversal, not search results) search service (not its product name) results (too generic without "findings" qualifier in technical context) **Discovery** is a social graph concept (traversal through circle memberships). Find is a search service. Do not conflate them. Findings are ranked by `ai_score` and have a `source_url` and `source_domain`. The find service is not currently exposed in the world runtime. finding head (finding head) social (discovery graph; distinct concept) The spatial data service. Maps is the authority for field layout, field width, and markers. It provides the shared visual environment that all members inhabit.

Owns: - field layout - field width - markers - marker sets

maps service maps objects maps authority geography service location service map (the singular noun; the service is "maps" and the object is "field") navigation service The service is named "maps" (plural). Avoid using "map" as a product noun — the output is a **field**, not a map. World fetches field data from maps and includes it in the runtime contract. Maps does not interact with the web runtime directly. field marker world A complete executable presentation environment. Runtimes consume translated World contracts. They are responsible for rendering, input handling, lifecycle, performance, accessibility implementation, and platform adaptation.

Runtime instances: - `web runtime` — the browser-based Elonn experience - `android runtime` — the Android-based Elonn experience - `desktop runtime` — the desktop-based Elonn experience - `xr runtime` — the extended reality Elonn experience "Runtime" has two additional distinct uses within the existing system and must be qualified when context is ambiguous: **World runtime** (`world.elonn.local`) A platform adapter that renders a translated World runtime contract. Existing Web, Android, iPad, XR, desktop, and future device runtimes consume translated primitives according to their capabilities. **Presence runtime** (`social.elonn.local`) The `runtime` field on a presence record identifying which client the member is currently using (e.g. `web.elonn`, `mobile.elonn`). This is a string identifier, not the execution environment itself.

web runtime android runtime desktop runtime xr runtime world runtime browser runtime runtime contract (the payload from World that bootstraps every runtime) runtime authority (the world service's designation as the session authority) presence runtime (the client identifier in a presence record) runtime alone when the meaning is ambiguous between world runtime and presence runtime backend (describes infrastructure; not a product term) server-side runtime (too technical; not a product term) client (too generic; use the specific runtime name) The world service declares itself `runtime_authority: true` in its service response. This means it is the canonical source of the World model and translated runtime contracts. Runtimes execute translated contracts. They do not own translator logic or consume service payloads directly. contract world translator web presence (presence runtime field) An independently deployed Elonn application boundary with its own routes, data ownership, and domain logic.

Owns: - its own routes - its own database or backing store - its own domain logic

service product service service boundary service contract app (too generic without context) backend (too generic) server (too generic) subsystem (implies internal implementation rather than a product boundary) Use the product name when the specific service is known: API, Time, Social, Find, Maps, World, or Docs. A service is a deployment and ownership boundary, not a runtime. When a sentence already names the product, prefer that product name over the bare word "service." Examples include API, Time, Social, Find, Maps, World, and Docs. api time world The social object authority. Social owns conversations, communities, events, profiles, presence, activity, notifications, relationships, circles, discovery graph behavior, and Social DMs.

Social's key model is circles and discovery. Circles come from shared private communities, not followers, friends, or manual connection lists. Owns: - profile - conversation - reply (conversation and event replies) - community - membership - event (social gathering with participants and RSVP) - participant - presence - activity - notification - relationship (block only) - circle (derived; not stored) - discovery graph - social-dm

social service social objects social panel social carry object network (overloaded; not the product noun) feed service (the activity feed is one feature, not the whole service) community service (communities are one object type, not the whole service) "Social event" is the canonical qualifier when disambiguation with time events is required. In social-only context, **event** alone is sufficient. Social does not own calendars — time.elonn.local does. Social pushes event data to time; it does not render calendar UI. Social DMs are private one-to-one communications inside Social context. Open platform Messages are a separate bounded context owned by `messages.elonn.local`. Public social objects are visible because they are public. Public visibility does not expand circle membership. conversation community event presence social-dm circle world (consumer) The calendar and scheduling service. Time owns calendars and time events. It accepts ingested events from the social service to mirror them as calendar entries.

Owns: - calendar - time event (a calendar entry; not to be confused with social event) - calendar slots / time boundaries

time service calendar event (a time-owned event) time event time panel scheduling service (not its product name) events service (ambiguous with social events) agenda (UI prose acceptable; not a product noun) "Event" without qualification is a **social event** (see: social). When referring to a time service entry, say **calendar event** or **time event**. The social service pushes event data to time via `syncSocialEventToTime`. Time does not pull from social. CalDAV integration uses the member's normal API-owned account credentials through `services.elonn.com/caldav/`. calendar social (event source) world Conversion from one canonical representation to another while preserving domain meaning, provenance, permissions, and action semantics. Translation does not imply ownership by a separate presentation/container service. A platform component that converts the canonical World model into a runtime-specific contract for a declared capability class.

Translators preserve object identity, action meaning, permissions, focus, workspace state, field state, findings, context targets, and fallbacks while adapting presentation shape for runtime capabilities.

translator runtime translator translator contract capability-class translator renderer (rendering belongs to runtime adapters) runtime (a runtime executes a translated contract) service adapter (services own domain state; translators do not call services) layout engine (too narrow; translators preserve semantics, not just layout) Translators receive the canonical World model, member/runtime context, and a capability declaration. Translators emit named, versioned runtime contracts. Translators are first-class platform components, not private logic hidden inside runtime adapters. Existing Web, Android, iPad, and Cardboard behavior is not translator precedent. world runtime contract The browser runtime application. Web renders the World Dataset through Field, Workspace, and Carry layers and delivers the Elonn experience in a browser.

Owns: - browser rendering of Field, Workspace, and Carry - client-side runtime state - UI interactions and navigation

web runtime web.elonn (the client identifier used in presence) browser runtime frontend (acceptable in engineering conversation; not a product noun) client (too generic; acceptable in technical docs) app (too ambiguous across platforms) SPA (single-page application; technical descriptor, not a product term) The web runtime reads the world contract from `world.elonn.local` and does not directly call social, maps, or time services. All service access routes through world. "web.elonn" is the presence runtime identifier — the string that appears in `runtime` field of presence records when a member is using the browser runtime. world runtime contract carry workspace field panel The composition and aggregation service. World assembles identity, maps, social, messages, and time data into the canonical World model and translated runtime contracts consumed by runtimes. World is also the product noun for the whole experience.

Owns: - runtime contract (the composed session payload) - layout (carry + field composition) - world session - service composition payloads - relay and rewrite of social, time, and maps endpoints - canonical World model - translator input model

world service world session world layout world objects world runtime (informal; the running experience) backend (too generic) server (too generic) aggregator (internal; not a product term) gateway (implies API gateway pattern; not the model) BFF (backend-for-frontend; acceptable in architecture discussions but not as a product term) "World" is both the product noun (the experience the member inhabits) and the service name. The field is not the world. The world contains the field. World proxies and rewrites service routes for runtime adapters but is not an authority for service-owned data. World composes platform state. Translators project that state into runtime-specific contracts. runtime contract translator carry field social time maps

An executable interaction exposed by an object, workspace, or runtime affordance. Actions connect user intent to service behavior.

Examples: - open - join - navigate - message - save - launch - share - pin Sub-concepts: - **action target** — the destination or system affected by the action (object, workspace, service, route, external runtime) - **action provider** — the service executing the action

action [verb] action (e.g., join action, save action) action target action provider command (implies CLI or OS context) operation (too technical) function (engineering term) button (UI implementation detail; not a model noun) event (avoid — event has a canonical social meaning; see: event) Actions belong to objects, workspaces, services, or runtime affordances, not to visual wrappers. A card may expose an object's actions, but the action is the object's. Do not use "event" to mean a user interaction or UI action. "Event" means a social event (see: event). object workspace event (distinct; social event — not a UI action) The placement mode of a world object, determining whether it belongs to the personal carry layer or the shared field layer.

Values: - `carry` — the object travels with the member (also: user anchored) - `field` — the object is fixed in the shared spatial panorama (also: world anchored) - `object` — the object is anchored to another object in the field; moves with that object rather than the member or the fixed environment (future; XR-relevant)

anchor mode anchor_mode (API field name) carry anchor field anchor placement mode (acceptable in technical docs prose; not the canonical noun) attachment type position type slot `anchor_mode` is the canonical API field name. Use it in code and payloads. Do not expose "anchor" as a product-facing noun in UI copy. In UI, present the distinction as the carry layer vs. the field. carry field layout A structured content group within a workspace or runtime view. Blocks organize objects, cards, controls, and findings into logical groups.

Examples: - nearby block - friends block - actions block - calendar block - notification block Block types: - `list_block` — ordered item list - `card_block` — visual card grid or row - `hero_block` — single prominent object - `action_block` — interactive controls - `map_block` — spatial field view - `media_block` — visual or audio content

block [name] block (e.g., nearby block) block type section (implies document model) widget (implies embeddable third-party component) component (engineering term; not a product noun) module (ambiguous) panel (a runtime presentation area, not a data model) Blocks are organizational groups for runtime presentation. They are not durable platform containers. Block type defines rendering semantics; the runtime selects the appropriate renderer based on block type. A block does not represent a context or workspace on its own. card object finding A visual presentation wrapper for an object within a block. A card is presentation-only — the object exists independently of its card representation.

A card: - previews, launches, expands, or links to an object - is temporary and replaceable - is renderer-level - scales across web, mobile, XR, and desktop runtimes A card is NOT: - a runtime container - a navigation state - a workspace - a panel Examples: - place card - member card - gathering card - message card - calendar card Card variants: - `compact` — minimal summary - `expanded` — detailed with more fields visible - `hero` — single large-format presentation - `stacked` — overlapping stack of cards - `floating` — detached from block flow - `minimal` — icon or indicator only

card [object] card (e.g., place card, member card) card variant widget (implies third-party embeddable) tile (implies fixed-grid layout) cell (implies table model) item (too generic) window (distinct; see: window) Cards are presentation wrappers for objects. A card never becomes the environment itself. Card rendering is runtime-specific, but the card abstraction is platform-neutral. object block panel (distinct) window (distinct; future) Objects anchored to a member and carried with them through the world. The carry layer is personal and persistent — it moves with the member, not with the field. carry layer carry object carry panel (runtime presentation only) toolbar dock HUD (heads-up display) inventory sidebar tray Carry is the primary member-following region in the runtime. Carry objects have `anchor_mode = 'carry'` in the layout. A carry panel is runtime presentation, not a Service or World data primitive. Contrast with **field**: field objects are spatial and shared; carry objects are personal. Do not call the social carry object a "social widget" or "social sidebar." It is the **social carry object** or **social panel**. field anchor panel world layout The transient manifestation of the member's current intent. Workspace exists in world space until replaced or updated by a new intent.

Workspace may contain objects, collections, actions, resources, and placements. Examples: - search results - conversations - documents - dashboards - navigation - collaborative spaces - editors - immersive rooms

workspace workspace layer workspace object workspace collection workspace placement findings layer finding overlay result dock search panel Workspace is not limited to Find results. Find may still produce findings as domain results. Those findings may be composed into Workspace. Contrast with Field, which is persistent and world-anchored. Contrast with Carry, which follows the member. field carry world mind finding The shared spatial panorama visible to all members of the world. Field objects are placed at coordinates within the field and are not attached to any individual member. field layer field object field width (the panoramic width dimension) place an object in the field map (the maps service generates field data, but "map" implies cartography; the field is not a map) environment scene stage world (the world is the composed experience; the field is the spatial layer within it) Field is the primary world-anchored region in the runtime. The field region contains spatially fixed objects and markers tied to locations in the world. Field objects have `anchor_mode = 'field'` in the layout. The maps service (`maps.elonn.local`) is the authority for field content. World composes field data into the runtime contract but does not own it. `field_width` is the panoramic width in abstract units, used by the web runtime for layout. carry marker anchor maps world A candidate informational result discovered or computed by Find. A finding is not yet normalized runtime content.

Examples: - recommended restaurant - nearby friend - active gathering - traffic alert - calendar conflict - suggested route A finding: - is produced by Find from a provider - is contextual and time-bounded - is distinct from a **notification** (which is targeted and recipient-scoped) - is distinct from **activity** (which is an append-only feed record) Sub-concepts: - **finding provider** — an internal or external source queried by Find

finding findings findings provider [type] finding (e.g., nearby finding) result (implies a response to an explicit search query; findings may be proactive) recommendation (too specific; findings include alerts and computed results) suggestion (same) "Finding" is the product noun for what a provider discovers or computes. "Find" is the service. Do not use "find" as a noun for an individual result. Findings are distinct from discovery (the Social graph traversal). find (service) discovery (distinct; social graph traversal) block object notification (distinct) activity (distinct) A visual point-of-interest placed at a position in the field. Markers are authored by the maps service and rendered by the web runtime. field marker place marker marker set (a grouped category of markers) pin (generic mapping term; not the internal noun) waypoint (connotes navigation; not the model) location (a property, not an object) poi (acceptable as internal shorthand in code; not a product term) landmark (too specific) icon (describes rendering, not the object) Markers belong to a `marker_set` which groups them by category (e.g. restaurant, transit, park). Markers are field objects; they have coordinates but are not carry objects. field maps anchor The model governing how a member moves through runtime space. Navigation in Elonn is spatial and contextual, not traversal of a document or menu hierarchy.

Elonn currently trends toward: spatial stack navigation. Navigation models: - `stack` — linear push/pop - `spatial` — positional movement through space - `radial` — arc-based arrangement - `hierarchical` — tree structure - `linear` — single axis Sub-concepts: - **focus** — the currently targeted interactive entity within the runtime - **context shift** — movement between conceptually distinct states (e.g., messages → maps, calendar → navigation) Interaction primitives: - **gesture** — continuous user movement input (drag, swipe, pinch, rotate, hold) - **gesture capture** — system ownership of input during an active gesture - **commit** — finalize a state transition after the snap threshold is met - **settle** — animated stabilization after interaction ends - **rebound** — return to previous state after a failed threshold crossing

navigation navigation model context shift gesture routing (implies URL or page model) page navigation (implies a document or website model) back / forward (implies browser history model) menu navigation (implies command-list traversal) Navigation describes spatial movement, not document traversal. Do not import browser or filesystem navigation metaphors. Gesture interaction is the primary input model; programmatic, voice, gaze, and keyboard transitions are also valid. runtime region A renderable entity originating from a service. Objects are runtime data primitives composed by World.

Examples by provider: - place (maps.elonn.local) - member (api.elonn.local) - gathering (social.elonn.local) - message (messages.elonn.local) - social-dm (social.elonn.local) - route (maps.elonn.local) - calendar item (time.elonn.local) - notification (social.elonn.local) Sub-concepts: - **object provider** — the service responsible for producing the object - **object state** — current live state of an object (online, active, busy, joined, saved, muted)

[name] object (e.g., place object, member object) object provider object state item (too generic; use the domain noun where possible) entity (database term; not a product noun) record (implies a database row) In runtime contracts, object means a renderable data entity. This is distinct from informal uses such as carry object, field object, or world object. Always prefer the domain noun (place, member, message) over bare "object" when referring to a specific type. Objects may expose actions. Cards are the visual presentation of objects. card (object's visual presentation) block (object's container) action (object may expose actions) finding (objects may be findings) A persistent spatial zone within a runtime. Regions divide the runtime into distinct spatial zones with different interaction characteristics and anchor behaviors.

Primary regions: - **carry** — user-following interface space; anchored to the member; high interaction density; persists during movement - **field** — world-anchored environmental space; spatially fixed; tied to locations; lower interaction density

carry region field region [name] region zone (too generic; use region) layer (acceptable in technical prose; not the product noun) area (too vague) pane (implies flat document layout) Regions are the top structural division within a runtime. Carry and field are the canonical region names. Do not introduce additional region names without extending this definition. "Carry region" and "field region" are the qualified forms when disambiguation with other carry/field usages is needed. carry field runtime anchor A physical, geometric, or domain-specific working area. In Elonn, use this term only when the ordinary meaning is intended, such as a Paint drawing surface.

Valid examples: - Paint drawing surface - canvas surface - touchscreen surface - geometric surface Invalid platform meanings: - persistent runtime container - service-backed presentation unit - panel parent - World or Runtime object carrier - replacement for workspace, object, card, panel, or window

drawing surface painting surface canvas surface touch surface geometric surface surface.elonn.local Surface service Surface Object surface object surface session surface schema surface state surface renderer surface as a panel/container/workspace/card/window synonym Do not use surface as an Elonn platform primitive. Do not use surface to refer to the removed `surface.elonn.local` service or any of its former responsibilities. When the intended meaning is a member's current work area, use workspace. When the intended meaning is service-produced runtime content, use object or the domain noun. paint workspace object An independently managed spatial container with z-order, resizing, overlap, focus management, and independent lifecycle.

**Window is reserved. It is not a current Elonn primitive.** "Window" implies a desktop OS model (macOS, Windows, visionOS, X11, Wayland). Using it prematurely commits Elonn to desktop window-manager behavior. When window becomes valid: - Elonn supports multiple simultaneous movable containers - Independent positioning exists - Containers can overlap - Persistent spatial placement per container is supported - Simultaneous focus across containers is possible Future evolution path: Window should be introduced only when runtime behavior supports independent placement, overlap, resizing, and focus. Example of correct future usage: ``` Map context opened in a floating map window ```

window [name] window (e.g., map window, chat window) floating window Do not use window as a synonym for workspace, object, card, panel, or any current Elonn spatial primitive. Do not use window to describe any current runtime container. The moment "window" appears in product copy or architecture diagrams, users expect macOS/Windows/visionOS behavior: z-order, resizing, overlap. Reserve it until the runtime genuinely supports that model. Do not introduce window language until the runtime genuinely supports window behavior. workspace panel region (distinct; persistent spatial zone)

A feed record capturing that a member performed a verb on an object. Activity is append-only and drives the public social feed.

Structure: - `actor_identity_user_id` — who did the action - `verb` — what they did (created, replied, rsvped) - `object_type` — what kind of thing they acted on (conversation, community, event, message, profile) - `object_id` — which specific object - `visibility` — public / circle / private

activity feed activity record activity verb post (a post implies authored content; activity records are derivative of actions, not primary content) event (ambiguous with social event; activity records are not events) log (implies system/infrastructure logging; activity is a product-facing feed) presence (distinct; see: presence) Activity is written automatically by the social service when members perform actions. Members do not directly create activity records. The visibility enum uses `circle` (not `followers`). The `followers` value was removed in migration 004. `verb` values should be past-tense action words: `created`, `replied`, `rsvped`. Do not use gerunds (creating, replying). presence (distinct real-time signal; see: presence) notification (activity can trigger notifications) visibility A derived set of members reachable from a given member through shared private community co-membership. Circles are computed by traversal; they are not stored as tables and are not manually managed by members.

Depth labels: - **inner circle** — depth 1: members sharing a private community directly - **trusted** — BFS depth 2: inner circle members' inner circle - **extended** — BFS depth 3: trusted members' inner circle

inner circle trusted extended discovery graph (the full traversal structure across all depths) circle depth social circle (ambiguous; use "inner circle" for depth 1) followers, following (removed; not the model) friends (not the model) network (too generic) circle as a stored entity (the `social_circles` and `social_circle_memberships` tables were dropped in migration 004) The mechanism that creates circle bonds is **private community co-membership**. Public communities and public events do not affect circle membership. Private event co-participation is not part of the current circle contract. Use "discovery graph" when referring to the full traversal structure. Use depth labels (inner, trusted, extended) when referring to specific scopes. In UI copy, the navigation tabs should be: Inner / Trusted / Extended / All. community (private) relationship discovery visibility A named, visibility-scoped group of members. Communities are the primary organizational unit of the social layer and the mechanism that creates inner circle relationships. public community (open membership by invitation; conversations visible to all members) private community (membership by invitation only; creates inner circle bonds) community membership community conversations community visibility group (ambiguous; do not use) channel (connotes real-time chat; not the model here) room (same as channel) team (implies work/productivity context) club (too casual) network (overloaded) Membership in a **private** community establishes an inner circle relationship (depth 1) between co-members. This is the primary mechanism for circle derivation. Public communities do not affect circle membership. Members are not self-joining; they are invited. The owner and moderators manage membership. Each member gets a default public community and a default private community seeded on first login. membership circle conversation visibility event A titled, threaded discussion anchored to a visibility scope. Conversations are the primary social object for group discourse. Every conversation has a creator, a visibility setting, and zero or more replies.

Visibility scopes: - `public` — visible to any member within the discovery graph - `community` — visible to members of the linked community - `private` — visible only to named participants

public conversation community conversation private conversation conversation thread (informal; acceptable in UI copy only) reply to a conversation thread (reserved for message and Social DM containers; qualify it) chat (implies real-time; not the model) post (connotes a feed item; not the model) topic (ambiguous) discussion (acceptable in UI prose but not as a technical noun) Events have an attached conversation for their discussion. This is an **event conversation**, not a standalone conversation. One-to-one communication uses a **thread**, not a conversation. Open Messages belong to Messages; Social DMs belong to Social. reply message social-dm community event visibility The traversal of circle reach, built from private community co-membership. Discovery determines which members and Social objects are reachable at each circle depth.

Depth labels: - depth 0 — self only - depth 1 — inner circle (direct private community co-membership) - depth 2 — trusted (inner circle's inner circle) - depth 3 — extended (trusted's inner circle)

discovery graph discovery depth reachable members discovery scope search (that is find.elonn.local; see: find) network (too generic) social graph (acceptable in technical discussion; not the product term) connections (LinkedIn-connoted) followers (removed from the model; see: relationship) Discovery is not a stored structure. It is computed on demand from private community co-membership. The `GET /social/discovery/graph` endpoint exposes the computed graph for the current member. Discovery filters apply to conversations, communities, events, and presence when a `depth` parameter is supplied. **Do not conflate discovery with the find service.** Discovery is about who you can see. Find is about what content you can search. circle community (private, the source of inner circle bonds) find (distinct search service; see: find) visibility A scheduled social gathering with a title, optional time bounds, visibility, and an attached conversation. Events have participants who RSVP and can link to communities.

Visibility scopes: - `public` — visible to any member within the discovery graph - `private` — visible only to the owner and active/invited participants

event social event (when disambiguation with time events is required) event conversation (the conversation attached to an event) event participant event RSVP calendar event (that belongs to the time service; see: time) time event (same) meeting (implies productivity/work context) appointment (same) happening (too informal) Every event has an attached conversation created at the same time as the event. Replies to an event go into this conversation. Private event co-participation is not part of the current circle contract. "Event" unqualified always means a social event. When referring to a time service calendar entry, always qualify: **calendar event**. The social service pushes event data to the time service via sync. Time does not own social events. Each member gets a default public event and a default private event seeded on first login. conversation (event conversation) reply (event reply) participant community circle time (calendar event recipient) An open one-to-one member communication outside Social context. Messages live in two-participant threads owned by `messages.elonn.local`. message thread message inbox send a message new message open message using "message" to mean a reply in a conversation using "message" to mean an event reply using "message" interchangeably with "conversation" using "message" to mean a Social DM adding a third member to a message thread Message threads are strictly one-to-one. If communication needs more than two members, create or use a Social community, conversation, or event instead. A **reply** is not a message. Replies go into conversations or events. A **Social DM** is not a platform Message. Social DMs start from Social context and remain owned by Social. The message inbox aggregates all threads where the current member is a participant. social-dm reply conversation inbox An alert delivered to a specific member about something that happened and is relevant to them. Notifications are targeted and recipient-scoped, unlike activity which is feed-oriented.

Fields: - `recipient_identity_user_id` — who receives it - `actor_identity_user_id` — who caused it (optional) - `object_type` / `object_id` — what it is about (optional) - `title` — short human-readable label - `body` — optional longer description - `read_at` — null until the member reads it

notification unread notification mark notification as read alert (acceptable in UI prose; not the technical noun) message (notifications are not messages; see: message) ping (too informal) push (describes delivery mechanism, not the object) Currently notifications are generated for conversation replies. Event RSVPs, event invitations, and community invitations do not yet generate notifications — this is a known gap. A notification is not an activity record. Activity is a public feed; notifications are private and recipient-specific. Notifications are marked read via `POST /social/notifications/{id}/read`. activity (distinct public feed; see: activity) conversation event member A member's real-time availability signal. Presence records the member's current status, availability, and the runtime they are using.

Fields: - `status` — online / away / offline - `availability` — open / busy / focus / invisible - `visibility` — public / circle / private - `context` — optional free-text string describing current activity - `runtime` — the client environment the member is using (e.g. `web.elonn`)

presence signal presence status presence record online presence online status (acceptable in UI prose; not the technical noun) activity status (activity is a separate object; see: activity) indicator (describes UI rendering, not the object) A member with `visibility = 'circle'` is only visible to their inner circle members. A member with `visibility = 'private'` is only visible to themselves. Presence is updated by the client via `POST /social/presence`. It is not derived. `availability = 'invisible'` does not mean `status = 'offline'` — a member can be invisible while online. The `runtime` field identifies which client the member is present in, not a world runtime contract. activity (distinct; see: activity) circle (visibility scoping) visibility runtime (client identifier; see: runtime) A member's social-layer identity. Profile is distinct from the API identity record — it is the social representation of a member, authored by that member for the social context.

Fields: - `identity_user_id` — foreign key to the API identity record - `display_name` — the name shown to other members - `handle` — URL-friendly unique identifier (e.g. @handle) - `bio` — optional free-text self-description

profile social profile member profile display name handle account (that is the login area at elonn.local) user profile (user is not a product term; see: member) identity (that is the API service record; distinct) avatar (a display property, not the object) A profile is created automatically on first social service interaction via `ensureProfile()`. A member always has exactly one profile per social service instance. `display_name` can be null; fall back to the member's email from the identity record for display purposes. `handle` must be unique across all profiles and is optional. When set, it becomes the member's social URL segment. member identity handle An explicit, directional record from one member to another expressing a social stance. Currently only the `block` type is supported. block (the only active relationship type) blocking a member blocked member follow (removed; was a relationship type; do not reintroduce) follower (removed along with follow) friend, friendship (not part of the model) connection (LinkedIn-connoted; not the model) subscribe (not the model) The `follow` relationship type was removed in migration 004_authorization.sql. Do not reintroduce it. Circle membership is **not** a relationship. Circles are derived from private community co-membership, not stored as relationship records. Block is bidirectional in effect: if A blocks B, B cannot appear in A's discovery graph and vice versa. circle block community discovery A post added to an existing conversation or event by any member who can view it. Replies extend a conversation or event's discussion. They do not create new threads or branches. reply to a conversation reply to an event event reply conversation reply comment (connotes a secondary or subordinate voice; replies are first-class) response (acceptable in error copy; not a domain noun) answer (implies Q&A structure) post (ambiguous with social feed semantics) message (a reply is not the same as an open message) Social DM (a reply is not private) The API action for posting a reply is `POST /social/conversations/{id}/messages` or `POST /social/events/{id}/messages`. The path segment `/messages` is a legacy payload route segment, not the product term — the user action is always called a **reply**. Replying to a public conversation automatically adds the replier as a participant. conversation event message social-dm participant A private one-to-one communication initiated from Social context. Social DMs belong to `social.elonn.local` because their meaning comes from profiles, conversations, communities, events, replies, presence, activity, circles, discovery, or relationship rules. Social DM DM member Social DM thread Social DM inbox calling a Social DM a platform Message placing Social DMs in the member dashboard or global service launcher adding a third member to a Social DM thread Social DMs are contextual Social behavior, not a separate platform Message. If a private thread needs more than two members, create or use a Social community, conversation, or event instead. Social DMs may appear in Social context, Social object detail, member/profile cards, Social notifications, activity, or Social runtime presentation. message reply social community The access scope of a social object. Visibility determines which members can see a given conversation, community, event, presence record, or activity entry.

Values (social service): - `public` — visible to any member within discovery reach - `community` — visible to members of the linked community (conversations only) - `circle` — visible to inner circle members (presence and activity only) - `private` — visible only to named participants or the owner

conversation: public / community / private community: public / private event: public / private presence: public / circle / private activity: public / circle / private `followers` (removed in migration 004; replaced by `circle`) `friends` (never existed in this system) `unlisted` (not a supported scope) Applying `circle` to conversations or communities (not supported) Applying `community` to events or presence (not supported) Using visibility interchangeably with permissions (visibility controls read access; permissions control write access) The `followers` visibility value was removed in migration 004_authorization.sql. Any code or migration referencing `followers` as a visibility value is incorrect. Find has its own visibility concepts (`public`/`private`) that do not include `circle` or `community`. Those are social-specific. circle community discovery relationship (block affects visibility indirectly)

A person with a registered account in the Elonn identity system. Members are the human actors across all services. The API service is the single authority for membership. member directory member count invite a member member_id (alias for identity_user_id in external-facing contexts) user (deprecated; internal DB column only) account (UI copy for login only; not a domain noun) person, human, individual (too generic) Internally, the database column is `identity_user_id`. External API responses expose `member_id` or reference the member via their `identity_user_id`. Do not expose `identity_user` as a product term. A member always has one profile per social service instance. profile identity token session (auth session) A bounded interaction context. "Session" alone is ambiguous across services and must always be qualified.

Qualified forms: **Auth session** (`api.elonn.local`) A time-bounded record linking a member to an issued token. Expires. Stored in `identity_sessions`. **Runtime session** (`world.elonn.local`) The composed world state returned to the web runtime at boot. Contains the member's layout, services, and contract version. Not stored — computed on each request. **Find session** (`find.elonn.local`) A query session grouping a member's search activity. Stored in `finding_sessions`.

auth session runtime session find session session alone (must be qualified in all code, routes, payload keys, and UI copy) In the world runtime contract, the `session` key refers to the **runtime session** — the member's current world context. It is not the auth session. Auth sessions are managed entirely by the API service. Other services do not store or extend auth sessions. token (auth credential; see: token) runtime (world runtime session) contract A credential issued by the API service after successful authentication. Tokens authenticate Runtime-World requests and identify the authenticated member represented by those requests. API token auth token signed access token elonn_api_token (the cookie name) Bearer token (when transmitted via Authorization header) key (too generic) password (a token is not a password) secret (describes storage requirement, not the object) JWT (the token format is an implementation detail; not a product term) The token is transmitted as the `elonn_api_token` HTTP cookie in browser contexts. Runtime requests may also transmit the token as a Bearer token when the runtime contract permits it. World validates signed access tokens locally at the Runtime-World boundary. Normal runtime requests do not call API for token validation. Internal component boundaries use service authentication and authenticated member identity rather than member credentials. CalDAV clients use the member's normal account identifier and password; no separate DAV token is issued. session (auth session; see: session) member api