Second anti-pattern. When building materialized views from events, teams are tempted to shove UI-only data (e.g. category_id derived from heuristics) into events so the view projector has everything it needs. This inverts the dependency direction: core-domain events are being designed to serve the UI, and adds spurious reasons for the event schema to change (e.g. if the heuristic changes, historical event values become wrong). Events should represent only what occurred; views should be composed from multiple streams and additional aggregation techniques. A related variant is leaking UI's negative/positive dispositions (e.g. Rails-style errors objects) into domain events — an overdraft is not an error to the bank that collects a fee.