System Configuration And Topology — Structural Connections
Placement of Client·Session·Api·Support and undirected structural connections (Location Store is described in the resource table)
Guided views
Explore this system
Step through curated paths without changing the source diagram.
Beat
Next
ReadyChapter 01 / 01
Guided chapter
Diagram guideExplore this system
Inspecting compiled semantics
E ExportT ThemeS Style0 Reset+ Zoom in- Zoom outEsc Close
Find a node
⌕/
No matching nodes
Semantic passport
Verified source
Authored reach
Route probeChoose a start node
Pick two semantic nodes on the diagram
Choose the source, then the destination. Direction matters.
Semantic lensCompare system roles
Choose up to two semantic kinds. One reveals its real traffic; two compare only direct authored relationships.
Choose a kind to inspect its nodes and touching relationships.
Semantic radar
Building overview
Click nodeDrag to pan
Semantic radar needs more MAP space.
How to read the connections
• Every line is the original's `---` undirected structural connection — it expresses peer/ingress connection intent, not request direction (arrowheads are a render constraint, not a directional claim).
• The Customer and Agent Client each connect to Session over STREAM. Only Session provides the client-facing STREAM endpoint.
• The S↔API and SUP↔API solid lines are the supportchat.api ClientServer (an independent channel for API request/reply). Between API↔SUP there are actually two connections — supportchat.api ClientServer and supportchat RouteMesh — but the diagram labels only one pair and routes the second (RouteMesh) around the bottom. S↔SUP is also supportchat RouteMesh.
Roles and boundaries
• Session and Api are object clients, and Support provides object-server capability. No separate peer is created between the two object clients. Session, Api, and Support are each 1+ instances.
• Support provides the SupportEntrySpot, ConversationSpot, the customer actor, the agent roster actor, and the conversation actor. Api handles token validation and the Conversation Spot creation request.
• supportchat.api is an independent ClientServer for API request/reply — Channel Server membership isn't mixed into the object RouteMesh. The Location Store manages peer discovery, Actor/Spot authority, and generation, and the Session binding route is kept by the Session owner; this diagram doesn't cover that — see the resource table.