Context
The service questionnaires used service-prefixed event names (identity.user.created.v1, tenancy.tenant.<state>.v1). The owner’s
answer C27 (mem L855, 2026-10-20) fixes the form as <aggregate>.<verb>.v<n>, with no service prefix, and it wins over the earlier names
(contradiction C-12). On 2026-10-20 the owner confirmed the final form (mem L930): the name starts with the module key, so billing.invoice.paid.v1
and identity.user.created.v1. The module key is the one of 0131.
Decision
- Events are named
<module-key>.<aggregate>.<verb>.v<n>:module-keyis the module’s key from 0131, for examplebillingoridentity;aggregateis the entity the event is about, for exampleinvoiceoruser;verbis the event, for examplepaidorcreated;v<n>is the version. Names are globally unique through the registry (C27). The module key replaces the service prefix that the questionnaires used.
- The envelope fields are
id,type,version,occurredAt,tenant,actor,onBehalfOf,correlationandcausation,traceId, anddata. The envelope lives incontracts. - An in-process event maps one-to-one to an integration event at the outbox.
Consequences
- An event name says which module owns it, and the registry still enforces uniqueness.
- Consumers depend on
contracts, not on another service’s source. - Names in the service questionnaires that carry a service prefix must be renamed to the module-key form before they are published.
Enforcement
planned — the registry rejects a duplicate event name, and the validator rejects a name whose first segment is not a registered module key.Alternatives
- Service-prefixed names (I10, T2, T10): superseded by C27 (C-12).
<aggregate>.<verb>.v<n>with no module key (C27 as first written): amended by the 2026-10-20 confirmation.
Supersedes and sources
Supersedes: none. Amends: 0078 decision 3, 0117 decision C1. Sources: owner answer C27 (stackra-decisions-2026-10-19.md L855, 2026-10-20; fixes STA-149); the owner’s confirmed naming
(stackra-decisions-2026-10-19.md L930, 2026-10-20: module-key prefix); contradiction C-12.