Everythink Studio
Global System Architecture

Six sections, one system

From product vision to real implementation: Rust backend, Next.js frontend, deployment, and roadmap.

The space is the router

Every person has their own personal organization and subscribes to n organizations. Every organization — business · government · union · community — contains n networks; each network contains n communities; each community contains n rooms. Every node has its own multipolygon: containment runs inward (fragmented communities inside the network's polygon) or outward (communities outside the polygon). The topology is fractal in the mathematical sense: each level is a self-similar copy of the previous one — S = ⋃ fᵢ(S), the attractor of the Hutchinson operator (Banach fixed-point theorem). Networks interoperate with each other (federation): one network connects to another by sharing only what is public. When a person joins an organization, they gain access to its n communities and n rooms. The work they do in the organization is tracked in the org and mirrored into their personal org: it generates per-person reputation, is distilled into solved problems, and those are copied to their personal network, which tracks them. From the accumulated answers, HAI builds a per-user context layer.

The four layers of the platform

Each upper layer composes the guarantees of the layers below over typed interfaces. Products (v1 modules): HAI, Matchmaking, Chat, Calendar, Market, Social. On top of the 4 layers, 10 sector instantiations.

Three principles that govern the architecture

Each principle is a verifiable guarantee, not a statement of intent. Together they establish the composition rule (end-to-end), the sector-multiplication rule (inheritance without modification), and the honesty rule (implemented and measured = guarantee).

HAI engine — 13 question types

In production since 2016. A deliberately narrow, composable premise: an interaction is a workflow of typed questions, and the platform is a geolocated topology so that every answer lands in a well-defined context. In v2 the engine runs on two inference layers: the learned network (deterministic, no LLM) and A2A inference, which fills in the nodes that do not exist and collapses the network.

Calendar — sell services and manage the calendar

A seller offers services (type_event) with price, category, and availability; customers book (event) with attendee, date, and location. In white-label mode, any seller in the same network is visible and orderable — "others sell in my network". Payment creates a merchant in the network and looks up products by product_key.

Market — sell products and let others sell in my network

The seller lists products (market_product) with merchant, provider, and price, and attaches offers/coupons to them. The customer builds the cart (market_item) and checks out (merchant_tx) with the network key stamped into json_data. Disputes and ratings on both sides. Merchants are bound to the network by merchant.network — "others sell in my network".

HAI + matchmaking + chat — each user's personal network

HAI fills each user's personal network by understanding what they are looking for: networks are populated automatically from the business/government/community/union website or doc, question flows are generated, and so are the cross-links between matchings from different rooms (same or different community). Matchmaking automates processes: one user intent → a purchase order in the community's dispatch channel, geolocated in the target room. Real-time chat over socket + FCM. The flows are cross-cutting (they cross rooms) and run on the two inference layers: the learned network + A2A, which fills in and collapses.

Social — network promotions and user interaction

The network runs promotions in its space and users interact in a social module: news/stories with likes and comments, categories set by the admin. The social feed lives in the topology — the network publishes, the community fragments, the room receives.

Two inference layers — the collapsing neural network

All modules live in rooms of a network and are cross-cutting: a dataflow (HAI) from a guest room with pre-sales connects to one from a customer with technical support. Unlike v1 (static graphs), here there are neural networks: if the subsequent node does not exist, A2A determines the next steps, saves them, and the network collapses. The scope is finite — what one user asks in a network is saved for everyone — and LLM consumption via A2A decreases over time, never grows.

Verifiable multi-tenant isolation

Businesses, governments, NGOs, and communities have shared a single AI substrate since 2016, keeping what is private provably private. Full mediation by the Reference Monitor; the only allowed channel = public scopes.

Federated networks and stable matchmaking

Networks federate over their public projections. Matchmaking operates only on public scopes within a proximity radius; deferred acceptance → stable matching.

Typed elicitation — learning in a few questions

The system asks, the user answers, and the answer becomes context. Elicitation is typed (the engine computes without surprises), faithful, and efficient. It runs on layer 1 (learned network, deterministic); when a node does not exist, layer 2 (A2A) determines the steps, persists them, and the network collapses — learning in a few questions, and every new question is saved for everyone.

Agentic workflows — the envelope

Some nodes require open-ended work: an LLM agent that interleaves reasoning with tool calls (ReAct-style) until it has an answer of the correct type. This is inference layer 2 (A2A): when the subsequent node does not exist in the learned network, the agent determines the next steps, persists them, and the network collapses — LLM consumption decreases over time, never grows. The envelope bounds the three failure modes.

Proactive assistance — the value of information

The inverse of a reactive chatbot: it initiates instead of waiting. The hard part is containment — speaking only when the expected net value of acting exceeds the value of staying silent.

Bounded authority and provenance

An agent that can act — spend money, contact third parties, move data — must be bounded by what the user consented to, use information only for the given purpose, and leave a trail that makes it possible to explain and undo.

Autonomous networks in the service of human networks

Bounded delegation, contract-net allocation (announce → bid → award), and the honest limit of coordination: liveness only with partial synchrony.

Security and the evidence protocol

Ten sector instantiations

Each sector deployment instantiates layers 1–4 without modifying them and inherits their guarantees.

Production / design / projected

17 crates, hexagonal, one Postgres

Composition root (api) → use-cases ×10 → adapters (ledger, a2a, courier) → domain (core, ZERO I/O). A single Postgres (Timescale pg17 + pgvector) for everything: ledger, events, embeddings, jobs/whisper geo-cache. SQL verified at compile time (.sqlx/ offline cache, 107 queries).

Ports & adapters — domain at the center

The domain (everythink-core) knows no I/O. Adapters implement ports for DB, email, A2A. Use-cases orchestrate. The composition root (everythink-api) wires everything.

Why so many crates — one explicit role per crate

Each crate has a role: composition root (api), client (sdk, cli), use-case ×10, infra-adapter (a2a, courier), ports + persistence (ledger), domain (core).

17 crates flow into core

everythink-api is the hub; everything depends on core (ZERO I/O). The SDK lives inside the workspace (backend/crates/everythink-sdk) because it is coupled to core.

From auth to persistence — one full request

Client → api (auth + rate-limit + validate) → loom (run) → ledger (resolve profile via the repo trait) → sisters (fan out) → oracle (merge → normalized Ensemble) → ledger (persist) → 200 OK.

Six use-cases: orchestration, auth, and data

loom — orchestration: persists via the LoomStore port / LoomPersistence adapter. ingest — signal pipeline: processes incoming signals. scry — sentiment: the reference port SentimentReader / PgSentimentReader. eval — regression harness: continuous evaluation. warden — auth: JWT access/refresh, Google OAuth, IP-binding. whisper — HMAC-signed webhooks with exactly-once delivery.

Middleware chain — trace → timeout → CORS → routing

Incoming request → Trace + request_id → Timeout 60s → 408 → CORS + compression → route subtree with 5 branches.

Three auth regimes coexist on one router

Public (probes/register/login/refresh) · Eye-Key (HMAC, sliding 60s rate limit) · user-JWT (warden, Console) · Atlas WS (self-auth, per-user caps).

RBAC without inheritance — one function, an explicit matrix

can(role, action) as a const fn: Owner → true; Profile Read/Write Self → true; explicit match on (role, action); the rest → Owner-only. AUTHORIZE in the handler → 403 on denial.

One datastore for everything

timescale/timescaledb-ha:pg17 + pgvector (vector(1024) + HNSW). One pool. Six data domains: Ledger, Simulations, Users, Embeddings, geo_signals, Jobs. Health check: pg_isready in docker-compose (service_healthy).

Persistence through a port, never through a concrete

Repository TRAIT · Pg*Repository (all the SQL lives here) · MockRepository (tests without a DB) · AppState: Arc<dyn Repository> · use-cases call the TRAIT.

Compile-time-verified SQL, reversible migrations

Edit .up.sql + .down.sql (paired) → just sqlx-prepare → commit .sqlx/*.json (107 queries) → build/CI with SQLX_OFFLINE=true and no live DB.

Health checks + SQLX offline — precise deploys

docker-compose: postgres (pg_isready, 10s/5s/10) → dragonfly (redis-cli ping, 10s/3s/10) → api (service_healthy). app/admin: health check disabled (distroless/static). CI: SQLX_OFFLINE=true with the .sqlx/ cache committed.

SSE (Tide) + WebSocket (GeoHub) — per-tile fan-out

TideBroker: SSE with composite topics, broadcast 256, keep-alive 15s, Last-Event-ID reconnect. GeoHub: WS with DashMap[Tile → broadcast 64], viewport steering, gzip opt-in.

Six orchestration and data use-cases

everythink-warden — user auth

everythink-whisper — signed webhooks and durable delivery

A2A (protocol) and Courier (email)

everythink-cli and everythink-sdk

Six invariants that are never violated

4 apps, 13 packages, one identity

web (:3000) · app (:3001) · admin (:3002) · mobile (Expo). Packages: types, sdk-core + facades, domain, ui, auth, api-client, telemetry, config.

Four surfaces, one backend, three actors

Actors: end user (guest → authenticated) · developer (Eye-Key) · admin/operator (staff). Surfaces: web/app/admin/mobile. Backend API (REST + SSE under /api/v1).

Containers — the full monorepo

4 apps + SDK layer (6 facades) + services (4) + design system + tooling + types (leaf). Use the zoom to explore.

web, app, admin, mobile — one per audience

Six facades, one core, zero endpoints in the core

sdk-core (HttpClient, consumeSSE, TokenProvider) · sdk-guest · sdk-auth · sdk-atlas · sdk-eye · sdk-admin.

Application services, UI, and build-time

domain (mappers) · telemetry (outbox) · api-client (legacy) · auth (NextAuth v5 + RBAC) · ui (kit + tokens) · config (eslint presets) · types (Zod, leaf).

sdk-core knows HOW, never WHAT

Endpoints live ONLY in the facades; sdk-core validates every response with Zod against @everythink/types; an SdkError tree with ContractViolation on drift.

Feature-Sliced Design + MVVM — imports flow downward

Screen (View) → View-model hook → feature.repository.ts (THE only door to the SDK). ESLint boundary no-restricted-imports (INV-1). FSD layers: shared → entities → features → widgets → app.

One login, one origin, four surfaces

apps/web /auth (one origin) → httpOnly cookie 'everythink_at' → token in memory + localStorage seed → EverythinkAuthGuard + resolveMe (GET /api/v1/auth/me) → role-based gate.

can(role, action) — explicit matrix, no inheritance

3 layers: (1) per-app auth.ts allowedRoles → (2) middleware → (3) can() in the UI + server actions. Mirrors everythink_core::rbac from the backend.

One stylesheet, semantic tokens, Tailwind v4

A single source of truth for design: CSS tokens in :root, semantic mapping via @theme (Tailwind v4), and NativeWind for mobile with mirrored tokens. The apps consume semantic components (bg-accent, text-foreground, font-display/mono), never raw hexes. Cosmic-purple palette: --gold: #d9ab5c, --violet: #9d7df5, --emerald: #10B981.

Zod at the network boundary — a single contract

Wire types are defined once in @everythink/types with Zod. The SDK validates every backend response (z.parse(response)); an invalid payload throws ApiError, never a crash. Components never see raw JSON: *.repository.ts parses, @everythink/domain maps DTO → model, and the view-model exposes typed state to the View.

apps/mobile — Expo, expo-router, NativeWind

React Native with expo-router (file-based routing) and NativeWind (Tailwind for RN). The theme system mirrors the web design-system tokens (tailwind.config.js + src/theme/index.ts). It consumes sdk-guest, sdk-auth, sdk-atlas, domain, and telemetry. Excluded from web CI: --filter=!@everythink/mobile.

Four mechanically enforced rules

Rules verifiable by ESLint + TypeScript, not conventions: (1) INV-1: only *.repository.ts imports an SDK (no-restricted-imports); (2) FSD layers: imports flow DOWN (shared → entities → features → widgets → app), cross-feature only through the public barrel; (3) Shared sign-in: web + app share localStorage('everythink:auth') + resolveMe(); (4) 3-layer RBAC: auth.ts allowedRoles → middleware → can(role, action) in the UI + server actions.

docker-compose.prod.yml — the full stack

ALB (TLS) → nginx :80 → api (:18081, migrations on startup) · web (Next standalone) · app/admin (static distroless) · postgres (timescale/timescaledb-ha:pg17 + pgvector) · dragonfly (Redis-compatible). 7 services: postgres · dragonfly · api · web · app · admin · nginx.

nginx as the single entry point

nginx :80 is the only internal entry point. It routes /api/v1/* → api:18081, / → web:3000, /app/* → static, /admin/* → static. web talks to api via EVERYTHINK_API_INTERNAL_URL (http://api:18081). api depends on postgres and dragonfly with condition: service_healthy.

backend/.env — the only place for secrets

docker-compose.prod.yml mounts backend/.env via env_file on the api and web services. api holds all the secrets (JWT_SECRET, EYE_KEY_HMAC_SECRET, GOOGLE_CLIENT_ID, BREVO_API_KEY). web only receives NEXT_PUBLIC_* variables — it never holds BREVO_API_KEY. app/admin are static distroless with no secrets in the build.

Direct preprod vs the CI/CD gate

Two deploy paths: preprod deploys directly from the working tree (without going through main); prod requires a merge to main and the integrity gate. The rule is critical: do NOT use the deploy workflow for preprod, because it pulls :latest from main and overwrites the direct deploy.

affected on PRs, integrity on main

A 2-tier pipeline: the PR tier runs only what is affected (backend: ci-affected-crates.sh; frontend: turbo --affected), the main tier runs full integrity (complete backend + frontend/mobile + E2E + security). main stays green and deployable.

Federated self-hosted nodes · BYOK · per-network DAO

Roadmap direction for v2. None of the following is an existing capability. Flow: the operator generates a local Ed25519 pair → only the fingerprint goes to the controller (BYOK) → self-hosted node → ledger anchoring → federation over public projections only → network DAO.

Five phases toward v2

Reference architecture of the candidate chain

Architecture reference for notarizing Postgres ledger hash commitments: Solana v0.8.13 (Yakovenko) — PoH as a cryptographic clock, PoS consensus with bonds/slashing, PoRep for storage. Chain selection is an explicit operator decision; this is a reference, not an implementation.