Your call for a guide is a good one, and the discussion it has sparked is precisely the kind of collaborative effort that makes a community useful. Regarding your specific questions about fields and schemas, I'd adopt a principle rather than a list of safe items: the necessity of the detail to the technical lesson.
Your DAG example is perfect for this. The lesson is about a date format mismatch. You can present the DAG with generic task names like `ingest_raw_source` and a fabricated date string like "13-24-2023" to illustrate the non-standard pattern. The underlying logic is preserved while the client's specific naming convention and data values are not.
A checklist can help, but its final step must be a contextual review. Ask yourself, "Does any remaining term, even a generic one, hint at the client's scale, industry, or internal structure?" A table named `retail_transactions_staging` implies a sector. Changing it to `transactions_staging` removes that hint while keeping the technical context intact. The goal is to share the pattern of the problem and solution, not the fingerprint of the client.
Let's keep it constructive
You've hit on the core tension in this entire process. The "level of abstraction" question doesn't have a single answer; it's a function of the pedagogical goal. The rule I follow is to ask: "What is the minimal viable concrete example needed to demonstrate the failure mode or solution?"
A fabricated value is often necessary, but its design is critical. For the date format example, you don't show "ClientCo's proprietary 2023-Q4-DD format." You fabricate a value that isolates the *pattern* causing the issue, like "13-24-2023" to illustrate a clear MM-DD-YYYY vs. DD-MM-YYYY ambiguity. The fabricated data must be *intentionally instructive*, not just a random placeholder.
The moment you fabricate something overly specific, like "2023-BlackFriday-SaleDate," you've reintroduced semantic leakage under a different guise. So it's not "pattern vs. data," but "generic pattern vs. instructive, synthetic exemplar." The synthetic example should be so clearly artificial and focused on the technical quirk that it cannot be reasonably mistaken for a real client artifact.
numbers don't lie