Platform model
The platform model separates persistent application state from immutable code and mutable routing. Every API, storage key, artifact, cache, subscription, schedule, and operational signal must retain this scope explicitly.
Project and Environment
A Project groups one application. An Environment owns persistent data, identity configuration, application keyrings, Releases, Channels, Workspaces, schedules, and operational state.
Environment identity is included in every storage, cache, artifact, realtime, and invocation key. Production protection is enforced by the server rather than inferred from SDK configuration. The standalone Environment lifecycle registry defines revisioned Product records and materializer observations; its Management/server integration remains a separate source-line step.
Release
A Release is immutable code, contracts, runtime requirements, schema metadata, and content-addressed artifacts. A client that explicitly requests a supported Release is never silently routed to a different incompatible Release.
Channel
A Channel is a mutable pointer to a Release. It provides controlled promotion and rollback without rebuilding artifacts. The resolved Release is pinned for the duration of a request, subscription, or scheduled invocation.
The standalone serving-policy registry models an Environment-wide atomic or
weighted Release set. environment:default selects through its converged policy, while explicit
Channel resolution remains available independently.
Workspace and Dev Revision
A Workspace is a mutable development target. Each accepted source snapshot produces an immutable Dev Revision. Concurrent writers use compare-and-swap revisions, and serving continues with the last valid revision if a new build fails.
Function classes
- Query reads a consistent snapshot and records dependencies for realtime invalidation.
- Mutation validates and commits document and index changes atomically.
- Action performs capability-scoped effects and may call other Functions.
- Scheduled invocation durably executes a Mutation or Action at a pinned code target.
- Cron materializes scheduled invocations from a versioned declaration.
job() is not a separate public primitive. Detached work uses runAfter or runAt until a future
abstraction can provide semantics beyond scheduling.
Code targets and pinning
Clients select environment:default or exactly one workspace:, release:, or channel: target.
Resolution produces an exact Release or Dev Revision before execution. That identity is pinned for
one request and nested calls, one Realtime evaluation/delivery revision, one scheduled invocation,
or one Cron activation. Mutations derive weighted selection from their OperationId, keeping
retries on the same Release. A policy or Channel move affects future resolutions only. There is no
latest fallback.
Identity and consistency
Application identity answers which software client is calling; functional identity answers on whose behalf it acts. Function policy evaluates both, and credential roles cannot be exchanged.
- Query reads one logical snapshot and records dependencies.
- Mutation validates an optimistic read-set and atomically commits documents, indexes, outbox, and schedules.
- Action may perform external effects and is not automatically retried.
- Realtime sees only committed state and reruns the authoritative Query.
- Durable work is at-least-once and must be idempotent or reconcilable.
Lifecycle decisions
| Need | Primitive |
|---|---|
| Live iteration | Workspace + immutable Dev Revisions |
| Stable preview/reproducible client | Explicit Release |
| Traffic promotion/rollback | Channel + compare-and-set |
| Environment-default weighted traffic | Serving policy + environment:default |
| Delayed/detached work | runAfter / runAt |
| Repeated UTC schedule | Cron declaration |
| User identity | External JWT/OIDC + Application Key |
Invariants
- Environment identity is never inferred from hostname, target, or user input alone.
- Changing code creates a new immutable Release/Dev Revision.
- Mutable pointers use compare-and-set and observable conflict.
- Unknown/incompatible targets and versions fail closed.
- Simultaneously served Releases must remain data-contract compatible.
- Rollback changes routing, not data or completed external effects.