The proposal, running.
This is the XPYRYA architecture as working code: the shared kernel and six module engines, wired together through domain events. A simulated runtime stands in for the database and the vendors, so you can step through one customer's journey across every module and watch each event, job and record appear.
Golden thread
Sara goes from website form to WhatsApp booking, quote, Stripe payment, project and a testimonial on the site. Run it native, or with HubSpot as the CRM. Switch her language to Arabic.
6 built · 2 plannedArchitecture
Modules, the tables they own, the 25 events they produce and consume, and the ports connectors plug into. Read live from the code.
26 diagramsData model
Every ERD, flow and state machine from the proposal docs, rendered from the same source the docs use.
What is real here and what is simulated
| Part | In R0 | Where |
|---|---|---|
| Kernel types and rules (ids, money, capabilities, events, system of record) | Real | packages/kernel |
| Module engines: Relate, Engage, Schedule, Commerce, Work, Experience | Real | packages/modules/* |
| Customer-facing text in English and Arabic | Real | packages/i18n |
| Database, RLS, transactions | Simulated in memory | packages/sim/runtime.ts (Postgres in M0) |
| Outbox relay and job queue | Simulated in memory | packages/sim/runtime.ts (pg-boss in M0) |
| HubSpot, Stripe, Google Meet, WhatsApp | Mocked | packages/sim/connectors.ts (real connectors in M3–M7) |
R0 decides nothing that Phase 0 has to decide. The engines are the production design and will carry over. The runtime is throwaway, and its replacement is M0: Postgres with RLS, the outbox and pg-boss.