Alavida Platform Architecture

13 knowledge files · 22 platform decisions · 23 mesh decisions · 6 quantums

The Platform domain is the engineering backbone of Alavida. It decides how software gets built, maintains architecture standards, provides skill authoring guides, and owns the external repos where code ships. Two parallel tracks converge on shared infrastructure: a GTM workflow registry (5 phases, consumer-facing) and an agentic mesh (4 phases, internal-only).

Three runtimes serve different purposes, connected by the Inngest event bus. Railway hosts compute, n8n bridges the external world, and Inngest provides durable event-driven execution with step-level fault tolerance.

Six quantums across two domains. Each satisfies the quantum contract: /run, /health, /data endpoints, Inngest events, and a consumer skill published to the registry. Identity deploys first (deterministic, no LLM), proving the pattern for everything that follows.

Events flow across quantums through Inngest, carrying trace_id and polyseme UUIDs. The prospect scoring pipeline cascades through three quantums. Phase 3 adds cross-domain flow from operations into prospect-discovery.

graph LR
  subgraph OPS["Operations Domain"]
    MS["meeting-sync
(n8n)"]
    MA["meeting-analysis"]
  end

  subgraph PD["Prospect-Discovery Domain"]
    ICP["icp-discovery"]
    LD["lead-discovery"]
    BS["buying-signals"]
  end

  subgraph PLAT["Platform Domain"]
    ID["identity"]
  end

  MS -->|"meeting/transcript.added"| MA
  MA -->|"meeting/company.mentioned"| ICP
  ICP -->|"icp/company.qualified"| LD
  LD -->|"lead/company.completed"| BS
  BS -->|"signal/company.scored"| OUT["Future consumers"]

  ICP -.->|"resolve-company"| ID
  LD -.->|"resolve-person"| ID
  MA -.->|"resolve entities"| ID
      

Single Neon PostgreSQL with schema-per-component isolation. The platform owns public (users, teams, credits, jobs, registry). Components own their schemas with no cross-schema FK constraints. Polysemes (company, person) are resolved through the identity quantum.

erDiagram
  USERS ||--o{ TEAM_MEMBERS : belongs
  TEAMS ||--o{ TEAM_MEMBERS : has
  TEAMS ||--|| CREDIT_ACCOUNTS : "1:1 billing"
  TEAMS ||--o{ JOBS : creates
  TEAMS ||--o{ API_KEYS : owns
  USERS ||--o{ JOBS : submits
  JOBS ||--o| CREDIT_USAGE : charges
  TEAMS ||--o{ CREDIT_PURCHASES : buys

  USERS {
    uuid id PK
    text email
    text name
  }
  TEAMS {
    uuid id PK
    text name
    text stripe_customer_id
  }
  JOBS {
    uuid id PK
    text component_slug
    text status
    jsonb result_payload
    jsonb usage_metrics
  }
  CREDIT_ACCOUNTS {
    uuid team_id PK
    int balance
    int lifetime_used
  }
      

Four phases, each proving a specific capability. Strict dependency ordering — each phase validates the pattern before the next adds complexity. 23 architecture decisions total. 12 features explicitly deferred.

A GTM workflow registry inspired by shadcn-ui — npx alavida add buying-signals. Components are living services, not static code. The platform manages execution, billing, API keys, updates, and data persistence. Three interfaces to the same backend: CLI, MCP, and Dashboard.

Four observability concerns, each with its own tooling. The critical requirement: LLM tracing tool's trace_id MUST equal the event trace_id for seamless cross-system navigation.

Workbenches are persona-scoped environments (skills, hooks, settings) that give different roles the right surface area. The dev workbench implements compound engineering: Plan → Work → Review → Compound. Two skill templates: CLI/API (13 sections) and knowledge processing (8 sections).

All 13 knowledge files in domains/platform/knowledge/ and when to consult each one.