Architecture
Built on a domain modulith
A modular monolith with event-driven fan-out. Architecture made real — 10 domain modules emitting 60 events across 9 external integrations (7 connected today).
Why a modulith
Single deployment, clean module boundaries
The Playbook ships as one Next.js + Postgres deployable, but every domain — Events, Spend, Vendors, Contracts — lives behind a typed service interface. Internal calls are in-process; cross-module writes go through the bus. We keep the operability of a monolith and the architectural discipline of microservices, without the orchestration tax.
Event-driven communication
When a producer engages a vendor, the Vendors module emits VendorEngaged. Spend writes a PO, Approvals routes a sign-off, Activity logs the actor, AI Orchestrator computes relationship intelligence — all from one published fact. Modules never call each other’s writers directly.
Scale-out path
When a module’s read or write profile diverges (e.g. Spend under heavy charge ingestion, or AI Orchestrator under inference load), it can be promoted to its own service without rewriting consumers. The bus contract is the only commitment. We earn the right to split when the data tells us to.
Domain modules
10 services · 60 events emittedIntegration topology
9 connectorsExternal systems push facts into the bus through dedicated connectors. The Playbook is never the system of record for finance, expense, or CRM data — it is the orchestration layer that joins them.
ERP
Source of truth for vendor records and GL.NetSuite
Last sync 18 min ago
Spend
Card-level transactions tagged by event.Ramp
Last sync 5 min ago
Expense
Per-diems, mileage, expense reports.Nexonia
Last sync 1 hr ago
CRM
Pipeline → events bridge.HubSpot
Last sync 30 min ago
Events
Registration, attendance, NPS.Bizzabo
Last sync 12 min ago
Storage
Asset library + contract docs.Box
Last sync 10 min ago
Productivity
Mail, files, calendar.Google Workspace
Last sync 5 min ago
Comms
Bot DMs and channel alerts.Slack
Last sync 2 min ago
BI
Dashboards and reporting.Domo
Last sync 13 hrs ago
AI orchestration
AI is a first-class citizen in the modulith — its own service, its own bus topic, its own audit trail. Producers stay in control; models surface what they see and the human decides.
Every model call is a tool-using agent: it reads from the same typed services every other module reads from, returns structured output with citations to the underlying records, and emits an event the Activity log captures. There is no shadow path where AI writes to the database.
- Citation grounding. Every number rendered in AI output traces back to a tool result. Models fill labeled commentary slots; numerics come from records.
- AI flags, doesn’t fix. Heads-up reports surface anomalies; producers click push back, escalate, or accept-as-is. No auto-actioning.
- Audit trail by default. Every prompt, tool call, and output is captured by the Activity service — replayable, attributable, reviewable.
Data hierarchy
Every record in the system lives at one of three scopes. Permissions, search, and AI grounding all respect this hierarchy — see Permissions for the full matrix.
Vendors, rate cards, users, integrations, audit trail.
Brand kits, contracts at master-services scope, pipeline.
BOM, budget, work items, engagements, assets, approvals.
Scope
contains
Diagrams
The full technical artifacts live alongside this prototype in the repository. They are the engineering counterpart to the visual story told here.
event-platform-architecture.htmlAvailable in repository.
event-platform-sequence-diagrams.htmlAvailable in repository.
event-platform-domain-catalog.mdAvailable in repository.
Built on a domain modulith · 10 modules · 9 connectors
Read more