Runtime model
Every manifest declares runtime. Trust picks the runtime; sync/async picks the interface contract.
| runtime | what it means | who | status |
|---|---|---|---|
platform | compiled into Mozaik's workers, full privileges | first-party ONLY (publisher: "mozaik", enforced by the schema) | live — every extension in the catalog |
sandbox | a sealed, content-addressed, store-scoped worker: no ambient DB or network, CPU/subrequest budgets, kill switch | third-party developers, agent-written extensions, per-store custom code | not yet — lands at P2 (ADR 0027); extension.install refuses it until then |
external | a standing service outside Mozaik's infrastructure reached through webhooks | existing SaaS | not yet — M11 |
Because install semantics, admin UI, and dispatch all key off the manifest, moving an extension from platform to sandbox later changes only the runtime field and packaging — no merchant-visible change, no reinstall.
Sync vs async is about contracts
Hot-path contributions (payment sessions, shipping rates) carry timeout + fallback contracts in the manifest (provider.rates for shipping kinds; the checkout hook budgets in limits). Async contributions (cargo labels/tracking, e-invoice issuance, marketplace sync) use webhooks + jobs. A first-party async extension is perfectly fine as platform — the sandbox exists for code Mozaik did not compile.
Generated from the live platform registries at build time — reference pages cannot go stale. Markdown variant: /runtime-model.md