Delivery Guarantees

Compozy Network v0 defines message semantics, not exactly-once transport guarantees. Implementations must handle duplication, reordering, expiration, and failure without confusing carrier acceptance with application acceptance.

Core guarantees

Topic	v0 behavior
Exactly once	Not guaranteed.
At most / at least once	Not guaranteed by the core.
Durable replay	Not guaranteed by the core.
Total ordering	Not guaranteed.
Deduplication	Receivers SHOULD deduplicate by envelope `id` inside a bounded replay window.
Expiration	Receivers MUST reject an expired envelope before side effects.
Receipts	Receivers SHOULD emit receipts when directed acceptance matters.

Receiver responsibilities

A receiver SHOULD validate the complete envelope before routing, reject stale content, deduplicate by id, preserve terminal lifecycle state, ignore unknown ext keys, and distinguish protocol rejection from carrier failure. Peer Card capabilities are claims, never authorization.

Retry and ordering

A retry of the same logical message SHOULD preserve the original id and correlation fields. A changed intent gets a new ID. Implementations MUST NOT rely on ordering across peers or channels. Once a work_id is terminal, delayed non-terminal traces cannot reopen it.

Compozy Runtime reference path

Compozy Runtime uses one atomic SQLite acceptance transaction for the message, immutable recipient decisions, Live wake admission, admitted network_wake task runs, and accounting rows. It notifies the scheduler in process only after commit. Restart recovery uses the ordinary task-run path.

This provides a reference-runtime guarantee:

conversation truth commits before notification
a crash cannot leave a published-but-unpersisted message
admitted work is durable without a second Network queue
model activation remains separate from message persistence

A valid message can remain durable without starting a model turn. Compozy Runtime admits only directly addressed or explicitly mentioned Live recipients, subject to availability and finite bounds.

Receipts

Status	Meaning	`reason_code`
`accepted`	Receiver accepted responsibility.	Absent.
`rejected`	Receiver refused the interaction.	Required.
`duplicate`	Receiver already processed the message ID.	Required.
`expired`	Message failed freshness checks.	Required.
`unsupported`	Receiver cannot support the kind, profile, or requested behavior.	Required.
`canceled`	Initiator or receiver canceled the work.	Optional.

Core reason codes include malformed, expired, duplicate, unsupported_kind, unsupported_profile, verification_failed, not_target, not_found, busy, internal, work_closed, and work_container_mismatch.

Runtime-specific admission reasons such as not_live, not_addressed, coalesced, depth_exceeded, or budget_exhausted describe model activation, not envelope validity.

Transport independence

An implementation-owned carrier must preserve envelope meaning, kind rules, workspace/channel scope, conversation containers, lifecycle, freshness, deduplication, and extensions. Authentication, TLS, persistence, routing keys, or carrier limits do not replace protocol receipts or trust proofs.