The star template: a CDE born correctly configured

I configured the common data environment for a large scale airport infrastructure program. Dozens of technical decisions later, the most valuable lesson was not a hidden Forma feature. It was a principle: projects are not configured, they are born configured.
What the star template is
We called it the star template: a validated model hub from which every new project in the program is born. Instead of configuring each site from scratch (and trusting that whoever is on duty remembers the forty correct decisions), every project starts as a replica of the template, with everything important already solved.
What lives inside
Folder structure with permissions and inheritance. My honest estimate after this project: 80% of CDE problems are structure problems, not software problems. Folders nobody knows the purpose of, hand granted permissions nobody remembers, broken inheritance. In the template, the structure is solved and permissions are inherited predictably.
Modules activated by role. Enabling everything for everyone kills adoption: people log in, see twenty modules they do not understand, and never come back. In the template, each role sees exactly what they need to work.
ISO 19650 naming and attributes. The standard only works if people actually fill it in. That requires attributes designed for the real workflow: few, clear, and with closed value lists wherever possible.
Review and approval workflows ready to use. The workflows that survive are not the most sophisticated ones: they are the ones that were configured from day one and people learned as a natural part of the project.
Operational modules, ready from day one. Issues, forms, model coordination and cost management with its change orders and contracts: all of that is also part of the template, configured once and replicated into every project instead of reinvented on every site.
The governance that sustains it
A template without governance degrades in months. The program rule is a chain that skips no steps: changes are born in a test hub, get validated there, move to the source of truth and only then are replicated to the production template. Never the other way around, never straight into a live project.
That circuit turns CDE configuration into something very similar to software version control: there is a test environment, there is a stable branch, and there is a process for promoting changes. Improvisation is designed out of the system.
The result
A project born from a validated template cannot be misconfigured. Getting it right stops being a heroic act that depends on one expert's memory and becomes the program default. And the expert stops repeating configurations to focus on what does require judgment: improving the template.
It also changes the conversation with the client. Instead of promising that each project will be set up carefully, you can show the template, walk through what it solves and explain how changes are promoted. Trust stops depending on individual effort and starts depending on a system anyone can inspect.
If you are about to set up or reorganize a CDE in Forma, reviewing the structure before the project grows is the cheapest investment you will make this year.
Is there a process stealing hours inside your Autodesk products?
Tell me about it and I will tell you honestly whether it needs AI, classic automation or something simpler. No hype.