Skip to main content
A topic is an L0 declaration: it defines a logical message channel (which messages it may carry, and what identifies one of them). It carries no grouping or ordering fact. How a transport groups a topic’s messages, and what precedence it establishes among them, are properties of the realization rather than of the logical channel. Those facts live in L1, at one of two mutually exclusive scopes.

​
Topic declaration

​
messages

messages is the set of schemas that may be published to the topic. Membership means the topic is allowed to carry that schema. It does not assert that such a message is ever published.

​
message_identity

Message identity is a guarantee provided by the topic’s producers, declaring where the identity of one logical message lives in the payload.
  • unspecified : No fact relates two carried messages sharing any field values.
  • keyed : For each mapped message schema, the mapping gives the ordered tuple of fields holding that schema’s message identity. The guarantee is: any two messages carried by the topic, each of a mapped schema, whose identity tuples are equal are the same logical message (hence of the same schema, with equal payloads).
Three consequences are deliberate:
  1. Two publications sharing an identity are attempts at publishing one logical message. The declaration says nothing about how often that message is delivered; delivery is a realization fact.
  2. Because equal identity implies same schema, cross-schema identity collisions are excluded.
  3. The mapping may cover a subset of the carried schemas. This is a deliberate asymmetry with the transport’s grouping key, which must place every carried message in some group.
The message identity is not the transport’s grouping key, and it is not object identity. On an order-events topic, order_id correctly orders the messages of one order and identifies the order; it does not identify the message, because OrderCreated and OrderPaid for one order share it while being different logical messages. The message identity of such a topic is an event_id.

​
Grouping and ordering are L1, not L0

For a given topic, grouping and ordering are declared either once at the topic runtime or independently at each subscription runtime, and never at both.
Topic-scoped is the shape of a runtime that imposes one domain on the topic as a whole (a partitioned log). Every subscription observes those semantics. Subscription-scoped is the shape where a publication fans out into independently configured queues or transport paths. Two subscribers of one logical channel may then group differently. The two are not a default and an override. They are different declaration modes, and validation rejects a model that uses both for one topic. There is deliberately no inheritance, no override, and no fallback chain.
For the full runtime vocabulary, see Topic and subscription runtime.

​
Transport order is not execution serialization

A transport ordering guarantee describes the order in which messages are logically observed by the subscription abstraction. It does not imply:
  • that two consumer invocations cannot overlap
  • that the consumer executes one message at a time
  • that effects produced by the consumer cannot overtake one another
  • or that independent producers had a meaningful business-level happens-before relationship
To carry transport ordering through operation execution, routing and member-concurrency facts must also support it.

​
Ordered transport does not invent business order

If two independent upstream producers concurrently publish messages for the same logical key, a keyed transport may impose a sequence between them. That sequence is a real transport order, but it does not prove that either message was semantically required to precede the other. The verifier distinguishes:
  1. an order that merely exists because a transport serialized concurrent inputs, and
  2. an upstream semantic or causal precedence that the architecture is required to preserve.

​
Subscription input

A subscription input has topic, messages (all or only [...]), and optional acknowledge_on_success. It does not carry delivery or dispatch; those are L1 facts declared in a SubscriptionRuntime. acknowledge_on_success means: when an invocation triggered through this input reaches successful logical completion, the triggering logical source item is acknowledged for this consumer. It does not close an idempotency proof nor prove duplicate collapse.