How to Hand Off a Naming Convention Without Losing It

AI Strategy 12 min read
Featured image for How to Hand Off a Naming Convention Without Losing It
Illustration: Dan Cumberland Labs with Gemini.

The new project manager saves the deliverable to a folder he created himself. Nobody says anything. That's how it starts.

Not with a crisis. Not with a policy violation. Just one file in the wrong place, organized the way it makes sense to someone who was never told the old logic was load-bearing.

Naming conventions don't die at the project close-out meeting. They die in the first week after the person who built them stops enforcing them— usually quietly, one misnamed file at a time. By the time anyone notices, the taxonomy has two competing logics running inside it, and neither team knows which one is official.

As practitioners working inside AEC firms have documented1, every firm has a naming convention. Almost none can enforce it past the person who built it. That's a structural failure— and understanding why naming conventions fail is the only way to stop rebuilding the same system over and over.

When it breaks, the cost is real: teams spend hours searching rather than building, knowledge that should be findable disappears, and the AI tools firms are investing in have no foundation to stand on. The fix is a different kind of system entirely.

A Naming Convention Is a Social Contract

A naming convention fails when the guard changes because it was never a technical system. It was a social contract— an agreement between the people who designed the logic and the people who agreed to follow it. When the maintainer leaves, the contract expires.

In my experience, this is the mechanism most firms miss when they set up their AI implementation infrastructure— naming systems and knowledge architecture that their human and AI teams can both navigate. As Bloomfire's research on knowledge organization found2, folder structures "make sense to the person who set it up" but create immediate confusion for anyone who wasn't in the room when the logic was built. The rules can be written down. The reasoning behind them usually can't.

That reasoning is what Gartner classifies as tacit knowledge3— the unwritten, unteachable understanding that makes a system work. Per Gartner, 70–80% of enterprise knowledge falls into this category. The logic behind your folder structure is in that category: why 3-digit project numbers, why Phase codes precede Discipline codes, which abbreviations are firm standard and which are someone's personal shorthand.

As our own analysis of AEC naming convention architecture explains1, naming conventions function as "the interface through which knowledge moves: between project phases, between team members, and between the people who built the files and the AI systems that need to read them." The new hire is genuinely unaware the contract existed.

I've watched firms rebuild the same taxonomy three times. They keep doing it because they hand over the rulebook when what actually needs to transfer is the reasoning behind it.

The good news: there's a pattern to when this happens. And patterns can be anticipated.

When Is Taxonomy Most Vulnerable?

Taxonomy is acutely vulnerable at five specific organizational moments— any of which can be anticipated, planned for, and mitigated.

The five predictable failure points:

  1. New hire inherits a project or folder system they didn't build. They organize by their own logic because no one told them the old logic was load-bearing.
  2. Key PM or principal is promoted. No longer in daily file management, the system they maintained starts drifting without its guardian.
  3. Project handoff between phases or teams. Different team, different assumptions, same file system.
  4. Senior staff retirement. Often the longest-tenured person and the deepest repository of "why we do it this way."
  5. M&A or team integration. Two naming systems, no integration plan, two competing logics that nobody has authority to resolve.

For AEC firms specifically, this is a compounding problem. About 40% worry about institutional knowledge loss as veteran employees retire6. Employees in high-turnover environments are 65% more likely to report serious difficulty accessing job-critical information5. Guard changes are scheduled: new hire, handoff, promotion, retirement, M&A. Firms that treat them as surprises will rebuild their taxonomy after every one.

The decay itself is gradual. The first misnamed file appears in week one. The first folder restructuring happens by month two. By the time the original PM is fully off-project, the taxonomy is often unrecognizable.

The institutional knowledge in AEC retirement wave is the most acute version of this pattern— and it's already underway.

What Taxonomy Failure Actually Costs

Knowledge workers spend 1.8 hours every day searching and gathering information (McKinsey Global Institute, 2012— still the most-cited benchmark on this)7. In AEC firms, where 80% of project effort is information management and only 20% is physical construction1, that cost is compounded across every project and every team member.

The downstream numbers are harder to ignore:

ProblemCostSource
Inefficient knowledge sharing$47M/year for large U.S. businessesPanopto, 2018
Recreating existing knowledge5.3 hours/week per workerPanopto, 2018
Proposal preparation33 hours per RFP, much of it searchingDCL analysis

5 8

That last number is the one AEC operations leaders recognize immediately. Proposal teams spend 33 hours per RFP8. AI can automate 40–80% of boilerplate-eligible sections— but only if the underlying library is searchable and structured. Poor AI workflow automation results aren't always a prompt quality problem. Often they're a file organization problem masquerading as an AI problem.

The cost of taxonomy chaos is real. The stakes for fixing it just went up significantly.

Why Training and Policy Don't Fix This

In my experience, the three most common responses to naming convention breakdown are: add a training session, create a stricter schema, or send a reminder email. All three fail for the same structural reason— they put the burden of compliance on human judgment, which is precisely what turnover removes.

Our own documentation of naming convention failure patterns1 records three predictable collapse modes:

  • Delivery pressure collapses discipline. When the deadline arrives, the naming convention is the first thing that gives.
  • Staff turnover resets the system. Every guard change restarts the decay clock.
  • Stricter schemas increase avoidance. More complexity produces more workarounds, not more compliance.

The tech is easy. The change is hard. And the behavioral fix fails because it asks people to maintain a social contract they were never party to signing. ISO 19650 automation research confirms this directly: manual enforcement of naming requirements is "perceived to be time-consuming, error-prone and serves as a barrier to BIM adoption"9— the friction is structural, not a matter of individual discipline.

You can train people on the pattern. You can't train them on reasoning they were never given. That's why training doesn't fix the social contract problem: it addresses the symptom while the contract keeps expiring.

The Three-Layer Fix: From Social Contract to System

Building a taxonomy that survives turnover requires three layers: encoding compliance in the tool, documenting the logic (not just the rules), and running a close-out protocol at every major transition. Together, they replace social enforcement with structural enforcement.

Layer 1: Encode at the Tool Layer

Where the file is created is where the naming convention must be enforced. Per peer-reviewed ISO 19650 automation research9, the most effective approach embeds compliance into the creation workflow itself— so the correct name is either the only option available or applied automatically before files enter the project workflow.

In Revit-native BIM workflows, a naming plugin fills in the standard name at save. There's no discretion to lose. Common data environments (CDEs) are the shared project file systems like SharePoint or Autodesk Construction Cloud (formerly BIM 360), and naming templates there reduce discretion even where enforcement can't be fully automated. This layer works best in tool-native environments; open shared drives require additional measures.

Layer 2: Document the Logic

A rules document says: "Name files like this: [format]." A logic document says: "We use 3-digit project numbers because we cross-reference the ERP; we separate Phase from Revision codes because project handoff timing requires independent tracking of both."

The logic document survives turnover because it teaches the next person the reasoning, not just the pattern. This is the specific handoff failure I see most often: firms document WHAT, but not WHY. The incoming person follows the format and still makes wrong judgment calls because the reasoning never transferred. Knowledge handoff works when it includes active participation in understanding the system, not just receiving the documentation.

Layer 3: The Close-Out Protocol

At every transition moment, run a brief audit. Section 3 lists the five predictable ones. Are files named correctly? Is there a clean logic transfer? Does the incoming person understand the system and the reasoning behind it?

Per APQC research4, 41% of organizations rarely or never attempt to capture knowledge from departing employees. This is a gap that closes with a simple checklist. At a small firm, this is a 30-minute conversation and a walkthrough. At a mid-size firm, it becomes a documented handoff protocol. Either way, the goal is the same— making sure the next person inherits the reasoning, not just the rules.

An AI implementation partner can help architect all three layers, particularly the tool-layer enforcement that most firms don't know they can automate.

Taxonomy Is Your AI Readiness

Every AI tool an AEC firm deploys, from proposal automation to project knowledge search, depends on being able to find, read, and classify files. Inconsistently named files are invisible to AI. The taxonomy problem is a prerequisite for AI to deliver any value at all.

Consider what AI can't do with a disorganized file system:

  • Extract metadata automatically from project files
  • Search across project phases to find comparable work
  • Classify documents for proposal content libraries
  • Run automation workflows that depend on file identification

Naming conventions function as the interface between your team's knowledge and the AI systems processing it1. When that interface is broken, the AI investment is largely wasted. Per Atlan's research10, AI query accuracy improves by 38% when governed institutional context is provided. That 38% represents the real price of a naming convention that doesn't survive turnover.

Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, citing escalating costs, unclear business value, and weak risk controls11. Firms whose teams can't follow the naming convention run into all three. They pay people to fix filenames before the AI can use them, they can't show what the pilot returned for what it cost, and they can't say which documents the system actually drew on.

Building an AI-ready culture starts with the data foundation your team is already producing, organized in a way that AI systems can actually use. Firms that fix taxonomy now are building that foundation. Firms that don't are funding AI tools that will deliver a fraction of their potential.

FAQ

Why do naming conventions always break down?

Because they depend on people who understand them— and when those people leave, the convention's logic goes with them. As Bloomfire documents2 and DCL's naming architecture research confirms1, folder systems make sense to the person who built them and to nobody else who wasn't present when the reasoning was established. Naming conventions are social contracts, not technical systems— and contracts expire when the signatories do.

How much does poor file organization cost AEC firms?

Large U.S. businesses lose $47 million per year from inefficient knowledge sharing, and knowledge workers spend 1.8 hours daily searching57. In AEC, where 80% of project effort is information management1, those costs scale across every project. Proposal teams spend 33 hours per RFP8— much of that time searching for information that already exists, just can't be found.

How do you maintain naming conventions when staff changes?

Three structural layers: embed compliance at the creation layer so the correct name is the default; document the logic behind the rules, not just the format; and run a close-out protocol at every major organizational transition. Per ISO 19650 automation research9, embedding compliance into the creation workflow removes human discretion from the equation— the most durable fix available.

What is ISO 19650 and does it solve this?

ISO 19650 is the international standard for information management in BIM-based AEC projects, requiring a 10-component naming structure9. When enforced through automation rather than manual compliance, it does address the human discretion problem— but primarily in Revit-native workflows. Shared drives and email require additional measures.

Why does taxonomy matter for AI?

AI systems need consistent, structured file names to extract metadata, search, classify content, and run automation. Inconsistent naming blocks all of this. Per Atlan's research10, governed institutional context improves AI query accuracy by 38%— which means the 38% gap represents exactly what disorganized taxonomy costs your AI investment.

Conclusion

Naming conventions are social contracts. Every guard change dissolves them unless you've replaced social enforcement with structural enforcement.

The next guard change at your firm is already scheduled. It might be a promotion, a retirement, a project handoff, or a new hire starting Monday. The question is whether your taxonomy survives it, or whether you spend the next quarter rebuilding something you've already built before.

If you're looking at an upcoming principal retirement, a team expansion, or a significant project handoff and want to make sure your naming system survives the transition, Dan Cumberland Labs works with AEC firms on exactly this kind of knowledge infrastructure.

References

  1. Dan Cumberland Labs, "Why Do We Need Architecture for Naming Conventions in AEC?" (2025)— https://dancumberlandlabs.com/blog/why-do-we-need-architecture/
  2. Bloomfire, "Why a Folder Structure Doesn't Cut It for Organizing Complex Knowledge" (2024)— https://bloomfire.com/blog/folders-complex-knowledge/
  3. Gartner (2024), cited via Atlan, "Institutional Knowledge Loss: Causes, Costs, and Prevention"— https://atlan.com/know/data-for-ai/institutional-knowledge-loss/
  4. APQC (2025), cited via Dan Cumberland Labs, "Master Project List for AEC: Build It Before It Walks Out"— https://dancumberlandlabs.com/blog/master-in-engineering-project-management/
  5. Panopto, "Inefficient Knowledge Sharing Costs Large Businesses $47 Million Per Year" (2018)— https://www.prnewswire.com/news-releases/inefficient-knowledge-sharing-costs-large-businesses-47-million-per-year-300681971.html
  6. Newforma, "Labor Shortages in AEC: The Hidden Impact and How Smart Firms Are Adapting" (2025)— https://www.newforma.com/labor-shortages-in-aec-the-hidden-impact-and-how-smart-firms-are-adapting/
  7. McKinsey Global Institute, "The Social Economy: Unlocking Value and Productivity Through Social Technologies" (2012)— https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-social-economy
  8. Dan Cumberland Labs, "Master Project List for AEC: Build It Before It Walks Out" (2025)— https://dancumberlandlabs.com/blog/master-in-engineering-project-management/
  9. Ajayi, S.O., et al., "Facilitating Compliance with BIM ISO 19650 Naming Convention Through Automation," Journal of Engineering, Design and Technology, Emerald Publishing (2021)— https://eprints.leedsbeckett.ac.uk/id/eprint/7750/1/FacilitatingComplianceWithBIMISO19650NamingConventionThroughAutomationAM-AJAYI.pdf
  10. Atlan, "Institutional Knowledge Loss: Causes, Costs, and Prevention" (2024)— https://atlan.com/know/data-for-ai/institutional-knowledge-loss/
  11. Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027" (2025)— https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

Our blog

Latest blog posts

Tool and strategies modern teams need to help their companies grow.

View all posts
Featured image for Build An AI Champions Network From The Bottom Up