Event contract (event schema)

An event contract is an agreed, versioned schema that defines an event's name, required fields, types and meaning, so producers and consumers can rely on it.

Part of the Learn hub and the customer data glossary.

What it means in practice

A contract turns "we send a purchase event" into a precise agreement. It specifies the event name, required and optional fields, types and allowed values, the meaning of each field, the owner, the version and the compatibility rules for change. Formats vary: JSON Schema, Avro or Protobuf, often held in a schema registry. CloudEvents is a vendor-neutral specification for describing event data, and requires four context attributes: id, source, specversion and type.

Contracts do three jobs. They keep producers and consumers in step as systems change, because a breaking change becomes a new version rather than a surprise. They allow validation at ingestion, so events that fail are rejected or quarantined instead of polluting profiles. And they are a privacy control: each field can be classified (personal, sensitive or neither) and tagged with the purposes it may serve, which supports data minimisation and purpose limitation.

A tight contract rejects unexpected fields. Free text and catch-all "properties" blobs are where unintended health or financial details leak in.

Example (healthcare): the "appointment_booked" contract allows an appointment ID, a service-line category and a timestamp. It has no diagnosis field; any extra field is dropped at the gate and counted in a data-quality report.

Related terms

• Event stream: what contracts govern.
• Event replay: needs versioned schemas.
• Data minimisation: enforced by field limits.
• Destination: consumers of the contract.
• Audit ledger: records rejections and changes.

Where it matters

• Customer data platform architecture: where contracts are enforced.
• How to run a customer data platform proof of concept with synthetic data: testing contracts safely.