Foundation architecture · kernel v1.0.0
A platform kernel built to outlive its features.
Marvia ships a small, frozen core and nothing else. Connectors, AI agents, reports and marketplace packages attach through the SDK — so the foundation can stand for years without a rewrite.
- Packages
- 17
- Workers
- 6
- Kernel events
- 78
- Queues
- 5
Core principles
Six rules the kernel never breaks
Every module in the tree is checkable against this list. If a change violates one, the design is wrong — not the rule.
Open core
The kernel knows nothing about features. Everything else is an extension.
Extension-first
SEO, analytics, marketplace, AI, reports and connectors live outside core.
Provider agnostic
Database, storage, auth, AI and payments arrive as adapters — never SDK calls.
Schema-driven
Reports, content, forms and dashboards are generated from schemas.
Component reuse
One design token set, one registry, zero duplicated UI.
AI-friendly
Single-responsibility modules, literal naming, no hidden logic.
Subsystems
What the kernel actually contains
Contracts, schemas and registries — no feature logic, no crawler, no payment processing, no official extensions.
Workspace surfaces
The tenant boundary. Extensions attach to these surfaces; they never replace them.
Kernel events
Frozen names, versioned envelopes, zero business logic.
Queues
Typed payloads with workspace, request id and attempt on every message.
Content types
One renderer, one editor. Behaviour is a data table, not a component per type.
Non-goals
Deliberately absent
Leaving these out is the point. Each one belongs to an extension, an adapter implementation, or a later deployment concern.
- —Feature implementations (SEO, analytics, marketplace logic)
- —Extension development — only the loading architecture
- —Payment processing — only adapter interfaces
- —Crawler implementation — only the snapshot pipeline
- —Hardcoded layouts or duplicated UI
- —Supabase Auth or direct Supabase client usage