# Name the owner of an event's meaning

The platform team can run the broker, but domain teams must resolve what published facts mean. Make that responsibility visible before a disputed change reaches production.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Separate platform and domain responsibility

A broker operator can investigate delivery, storage and access. They usually cannot decide whether an invoice issued event means a draft was saved, a number was allocated or the document was sent to the customer.

Assign the event's business meaning to a team with authority over that process. Name a maintained team contact and escalation route rather than relying on one person's memory.

Consumer teams remain responsible for their own effects. Ownership of the producer contract does not make the producer team accountable for every undocumented assumption a downstream service introduces.

## Hand over examples that settle questions

Provide a normal payload and a few examples that expose important distinctions. For an invoice event, these might include a correction, a cancellation and a replay of the original occurrence.

Explain when the fact becomes true, which identifiers remain stable and what ordering is promised. Identify fields that are snapshots of historical information and fields that merely reference current records.

A useful handover includes a consumer example with an expected result. A large field dictionary can still leave a new engineer unsure whether to send a notification again after replay.

## Establish a small change process

Require proposed changes to explain their effect on existing consumers and retained history. Structural compatibility checks belong in automation. Semantic questions need the domain owner and affected consumer owners.

Keep the consumer inventory close to the contract. Include scheduled jobs and recovery tools, with their owners and contact routes. A team should be able to discover who depends on an event without searching production logs for familiar service names.

For disputed changes, record the decision and the example that motivated it. This prevents the same uncertainty returning when people change roles.

## Practise an operational question

Ask the receiving team to trace one event from source transition to consumer outcome. Then give them an unsupported version or a message that failed interpretation. They should be able to find the contract, identify the responsible team and locate the recovery procedure.

Record gaps found during the exercise and fix the underlying documentation or access. A handover meeting alone does not show that the next on-call engineer can recover the service.

Review ownership when a producer is retired or a domain moves between teams. Event history often outlives the code that created it, so responsibility for reading that history must transfer explicitly as well.

## Sources

- [CloudEvents project](https://cloudevents.io/)