Scope and versions
Status: draft-01. Working review draft; not a released interoperability contract.
Use this section to implement the contract. For an explanation with messages, start with Follow a command.
Scope and authority
The model, envelope, message definitions, recovery rules, profile and binding requirements, and security/version rules are normative for this draft. The designated JSON Schema defines structural constraints. Prose defines behavior and cross-message rules. Both must agree; a conflict is a specification defect.
Guides, diagrams, examples, and design questions are informative. A proposal does not add a core operation. Tests provide evidence only for the cases they execute; they cannot override a requirement.
The core requires no chat interface, actor runtime, storage engine, or programming language. Profiles provide application meaning. Bindings provide transport behavior. No production binding, profile, host, or DASP client is released.
Conventions
Uppercase requirement terms, including MUST, MUST NOT, SHOULD, and MAY, use the meanings in BCP 14, RFC 2119 and RFC 8174. Lowercase words have their ordinary meanings.
Each normative section has a stable requirement or requirement-group ID. A group identifies all constraints in that section, including its field tables. The coverage index links those IDs to executed artifact checks and planned runtime cases. An ID alone does not imply that a runtime test exists.
Layers
| Layer | Responsibility |
|---|---|
| CloudEvents 1.0 | Event identity, source, type, and metadata |
| DASP core | Sessions, commands, admission, updates, outcomes, views, and recovery |
| Application profile | Inputs, outputs, state, completion, concurrency, and domain rules |
| Transport binding | Selection, authentication, connection, routing, and delivery |
| Implementation | Runtime, storage, scheduling, and execution |
DASP uses CloudEvents 1.0.2 and its JSON event format. The wire value of specversion is "1.0". CloudEvents does not supply DASP's retry, ordering, or durability rules.
Read the contract
- Model and lifecycle
- CloudEvents envelope
- Message shapes
- Admission and recovery
- Profiles and bindings
- Security and versions
Then inspect the counter example and conformance coverage. Use the source commit with draft-01 when citing this evolving draft. See release preparation for fixed-artifact packaging.
Conformance
Read what is tested, run the checks, and inspect the runtime test cases. Passing the artifact suite alone does not establish host conformance.