Document event specification validation for Micro development environments and good/bad routing

[Patricio (patofp)]

DPS-2329: https://snplow.atlassian.net/browse/DPS-2329

• Development environments now have a section documenting that they validate incoming events against every published version of your event specifications and against the latest draft of each one, so tracking can be tested without publishing the tracking plan or its specifications.
• The validation and inference pages point to development environments as the way to test drafts and inference without affecting production.
• The inference page's list of attributes that matching ignores now names source applications explicitly.
• The validation page gains a "Send invalid events to failed events" section describing the per-tracking-plan routing setting (with a screenshot of the Data quality rules control), and its default-behavior note and warehouse cases are now conditional on that setting.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	documentation	cbb2488	Commit Preview URL Branch Preview URL	Jul 28 2026, 09:03 AM

[claude]

Style review

Overall this is well-structured and reads cleanly — the new sections stay in present tense, mostly use active voice, and terminology (entities, failed events, event specifications, Console, Snowtype) matches the style guide. A few things worth fixing:

1. The configuration section doesn't name the UI it documents

docs/event-studio/tracking-plans/event-specification-validation/index.md, new "Send invalid events to failed events" section:

"Each tracking plan has a setting to send them to failed events instead"

The only place the actual UI element and its options are named is inside the image alt text ("Data quality rules" dialog, Send to valid events and mark as violation, Send to failed events as validation error). Alt text isn't visible to sighted readers, so the prose never says where the setting lives or what to pick. CLAUDE.md structures feature pages as description → when/why → basic example → configuration, and reserves bold for UI elements — the dialog name and option labels belong in the prose.

Suggested fix, e.g.:

Each tracking plan has a Data quality rules setting that controls this. Select Send to failed events as validation error to route events that fail validation to failed events instead of your warehouse events table; the default is Send to valid events and mark as violation.

The alt text can then be shortened to something like "Data quality rules" dialog showing the two routing options for a tracking plan.

2. "latest" is on the banned-words list

Style guide, Writing style: "Stay in the present tense. Never use 'currently', 'now', 'in the future', 'latest', 'Snowplow plans to'."

"they also validate against the latest draft of each specification" — docs/testing/snowplow-micro/console/index.md

Also at the end of that same page ("and the latest drafts") and on the inference page ("the latest draft of each one"). Suggest "the current draft" or just "the draft" throughout.

3. Passive voice

Style guide: "Use active voice: 'the Collector receives events' not 'events are received by the Collector'."

"Events that arrive without an event_specification entity are matched by inference instead" — docs/testing/snowplow-micro/console/index.md

Suggest: "The environment infers a specification for events that arrive without an event_specification entity, matching them against both published specifications and drafts." Same pattern opens the new validation section: "By default, events that fail validation are still delivered as enriched events" → "By default, the pipeline still delivers events that fail validation as enriched events", which is also how the admonition above it is phrased.

4. Vague back-reference

"Routed events appear as enrichment failures and keep both the event_specification and the event_specification_validation entities"

"Routed events" has no clear antecedent — the preceding paragraph is about the setting's scope, not routing. Suggest: "Events sent to failed events appear as enrichment failures and keep both the event_specification and event_specification_validation entities, so you can inspect why each event failed."

Minor

• Two consecutive sentences in the new snowplow-micro/console section use a mid-sentence colon to bolt on an explanation ("...of each specification: you don't need to publish..." and "...Micro dashboard: events that fail validation carry..."). Consider making one a full stop.
• The heading "Send invalid events to failed events" introduces "invalid events", where the rest of the page consistently says "events that fail validation". It mirrors the Console dropdown wording, so it's defensible — just flagging the inconsistency in case you'd prefer one term.

Links and structure check out: both new anchors (#validate-event-specifications and #send-invalid-events-to-failed-events) resolve to the added headings, all internal links end in /index.md, the image sits in an images/ subdirectory with a descriptive filename, and both pages stay within the 3–5 H2 limit. No external URLs were added or modified, so there was nothing to HTTP-check.