# 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](/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`](/reference/commands/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](/reference/hooks)) carry timeout + fallback contracts in the manifest (`provider.rates` for shipping kinds; the checkout hook budgets in [limits](/reference/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.