In Segment Protocols, what does a tracking plan do to a non-conforming event?

## What a tracking plan is in this product Segment Protocols is the governance layer over the event stream. A **tracking plan** enumerates the events a source is allowed to send, and for each event the properties, their JSON types, and whether they are required. It is expressed as schema rules — JSON Schema underneath — and it can be edited in the UI, managed through the API, or generated from the warehouse of events you already observe. The plan exists because instrumentation rots. Multiple client platforms, several teams, and a year of shipping produce `Order Completed`, `order completed`, `OrderCompleted`, a `revenue` that is sometimes a string, and a `currency` that is sometimes missing. Every one of those becomes a broken dashboard, a mis-mapped destination field, or a warehouse column with the wrong type. ## What happens by default: violations, not blocking The important and frequently-missed fact is that attaching a plan does **not** by itself change delivery. Segment validates each message against the plan and records a **violation** when it does not match — an unplanned event name, an unexpected property, a property of the wrong type, a missing required property. The event still goes to destinations. You get a view of what is violating, how often, and from which source, which is exactly what you want before you touch anything. That report-only period is the whole point. A team that switches on blocking the day the plan is written discovers that the plan was written from an incomplete picture, and starts silently discarding legitimate traffic. ## Enforcement lives in schema controls Enforcement is configured per source, separately from the plan. The available behaviours are, in increasing severity: allow everything and only report; **omit unplanned properties**, which strips fields the plan does not declare but delivers the event; **block unplanned events**, which discards events whose names are not in the plan; and blocking events that violate the declared types or omit required properties. Segment also provides ways to inspect what was blocked rather than losing it entirely, so that a blocking configuration does not become a silent sink. Blocking is a genuine tradeoff. Stripping an undeclared property protects the destination schema and the warehouse from surprise columns, but it also means a developer who ships a new property in good faith sees it vanish with no error at the call site. That is a workflow decision, not a technical one: if you block, the plan-update path must be fast enough that shipping instrumentation is not gated behind a slow approval queue. ## Transformations: fixing what already shipped Protocols also offers transformations, which rewrite messages inside Segment's pipeline — renaming an event, renaming a property, or changing a value's shape — before they reach destinations. The canonical use is a mobile app: an old release is sending `order_completed` and you cannot force every user to upgrade, so a transformation maps it to the planned name and downstream tools see one clean event. Treat this as a stopgap with a review date. A transformation is invisible logic sitting between the code and the data; a new engineer reading the client will not find it. If the mapping outlives the release that needed it, the transformation becomes the real schema and the plan becomes fiction. ## Where this sits relative to the wider practice The general discipline of an agreement between producer and consumer — including its versioning, its owner and what happens when it is broken — is a topic in its own right and is not specific to any vendor. What Protocols contributes is a concrete implementation for a client-side event stream: a machine-readable schema, per-source enforcement, a violations feed you can alert on, and in-flight repair. It is also a paid add-on rather than part of every plan, which is why plenty of teams implement the same idea with a schema registry and their own validation step instead. ## Running it well A workable rollout looks like this. Generate an initial plan from observed traffic rather than from an idealised spec. Leave it report-only and watch the violations for a few weeks. Fix instrumentation for the violations that are real bugs; widen the plan for the ones that were legitimate but undeclared. Put an alert on violation rate per source so a bad release is visible within hours instead of at the next quarterly review. Then enable the mildest enforcement that solves your actual problem — usually omitting unplanned properties — and only escalate to blocking events for sources where junk volume is genuinely expensive. Keep the plan in version control via the API if you want review and history rather than untracked UI edits.