Release notes · 2026-09-08
What changed. What to check.
A concise reference for developers and their assistants updating an existing integration.
Shared domain model and pure behavior
Use @platform/sdk/domain/core for definition validation, compilation,
binding and aggregate behavior; import definition types from
@platform/sdk/domain/schema. New behavioral definitions use
domain-def@5, as shown in the order example.
Updating an existing integration
- Use defineDomain for typed literals or parseDomainDefinition for unknown JSON, then compileDomain and bindDomain from @platform/sdk/domain/core.
- Existing @platform/sdk/domain/compiler integrations have a different compileDomain signature and result. Do not migrate by changing only an import.
- Model state, commands and events explicitly. Changing schemaVersion alone does not convert an eventStream into an aggregate.
- Preserve authorization, human approval and persistence in adapters. Compilation and binding do not grant permission.
Compatibility and version identifiers
domain-def@4 remains accepted with frozen compatibility behavior. The domain-core@1 normalizer identifier and each domain version are separate from the definition format.
SDK package versions alone may not identify the available source contract. Record the exact source revision used by your application.
Before rollout
- Run the literal, JSON and simulation examples in /sdk against the same workspace SDK source.
- Compare literal and JSON diagnostics; reject invalid references and inputs.
- Verify decide/apply/replay, stale revisions and retry receipts in the consuming service before rollout.
Workspace source only. External package distribution is not open yet. These notes do not announce a registry package or certify a consuming application's deployment.