In my experience you have to strike a balance between allowing exploration that unblocks people outside the team to look into data (with a bit of a buyer-beware

In my experience you have to strike a balance between allowing exploration that unblocks people outside the team to look into data (with a bit of a buyer-beware attitude) to help them build intuitions while making sure that core metrics that you use internally and/or share publicly are appropriately vetted. Using Aleph or other shared SQL tools like it allows us to quickly look at a query someone else on another team has built and provide support. Making time to walk through core tables and their pitfalls as part of SQL training can also help. Reporting on core company metrics needs to be curated and owned by people with the right expertise. In some cases we'll build additional views on top of our core BI layer that simplify a lot of this information for some of the examples you're describing (like the number of active customers at different points in time) and use to drive our dashboards, and people can query from those. Aleph also supports tagging and ad hoc parameter setting, so you could fix and build off of more novice users' queries, tag them as "official" and allow them to set parameters like time ranges. But at the end of the day, AFAIK there's no silver bullet here - you have to train people in the pitfalls of your data and expect that they'll make some mistakes but it's part of the data team's responsibility to help them learn. As individuals in different groups gain expertise, they can help each other too. The alternative extreme, where a priesthood owns all data analysis will avoid mistakes, but it won't allow your team to work on activities that are both high leverage for them and provide more value to the company.