A small model with many entry points

Orbit’s structure is intentionally compact. The same personal model powers the web application, assistants, counselor views, integrations, and operational tools.

Product model

User
 ├─ Goal (life category)
 │   ├─ Habit
 │   │   └─ Entry
 │   ├─ Goal target
 │   └─ Assessment
 ├─ Mood
 │   └─ Journal
 ├─ Chat session
 ├─ Counselor access grant
 └─ Integration → mapping → external entry

The balance wheel aggregates goal, habit, entry, and target data for a period. Mood and assessment remain distinct reflective inputs rather than being derived from completion behavior.

Runtime model

Web app ─────────────┐
Remote MCP clients ──┼──> Cloudflare Worker / Hono API ──> D1
Voice realtime ──────┘              │
                                    ├──> Durable Object UI push hub
                                    └──> OpenTelemetry tables

The deployed Worker serves both the API and application assets. The current configuration uses D1 for durable data, a Durable Object for UI push coordination, and Cloudflare observability for traces, spans, and logs.

Deployment boundary

The consumer app deploys as a Cloudflare Worker. This product-definition site is intentionally a separate static deployment so documentation can evolve and publish without coupling to application releases.