A knowledge manager at a legal services organization — I’ll call her Dana — pulled me into a consulting debrief in October with a screenshot she couldn’t explain. Her organization’s matter-type taxonomy, designed in 2021 with 40 carefully chosen terms aligned to their practice areas, now contained 1,703 terms. Nobody on her team had approved any of them. The SharePoint term store, configured to serve managed metadata columns across 14 document libraries and two matter intake forms, had been quietly accumulating entries for three years. Search relevance across their Elasticsearch index — which ingested SharePoint metadata via a Graph API connector — had degraded to the point where attorneys were bypassing the intranet entirely and emailing colleagues to locate matter documents.
The condition has a name. I call it taxonomy drift through unguarded term set expansion, and it is one of the most common structural failures I encounter in enterprise SharePoint environments. Unlike a corrupted index or a broken connector, it produces no error messages, triggers no alerts, and generates no support tickets until the downstream damage is already severe. By the time Dana noticed, the taxonomy had become functionally useless as a faceted search filter, and the metadata values stored against thousands of documents no longer corresponded to any governed vocabulary.
What Taxonomy Drift Through Unguarded Term Set Expansion Looks Like
SharePoint’s managed metadata service is designed to enforce controlled vocabulary usage through term sets — hierarchical collections of terms stored in a central term store and referenced by site columns. When a site column is configured as a managed metadata field, it can be set to allow or disallow free-text entry when a user types a value that doesn’t exist in the term set. The setting is called Allow fill-in choices, and it is enabled by default in many SharePoint Online column configurations.
This default is the structural crack. When fill-in choices are enabled, any user typing into a managed metadata field can create a new term in the term set without going through a term store administrator or a governance board. The new term is added to the term set’s keywords sub-tree or to the root of the term set, depending on the configuration, and it immediately becomes available to every other site column that references that term set. There is no approval workflow, no notification to the taxonomy owner, and no audit log entry beyond the standard SharePoint change log, which most organizations do not monitor at the term-store level.
In Dana’s organization, the matter-type term set had been configured with fill-in choices enabled during the initial SharePoint rollout. The rationale at the time was reasonable: the legal services team wanted to avoid frustrating attorneys who encountered a matter type that didn’t fit the initial 40-term taxonomy. The trade-off was explicit — user flexibility against vocabulary control — and the decision was documented in the project’s information architecture specification. What was not documented was any process for reviewing fill-in terms, promoting useful ones into the governed hierarchy, or retiring duplicates and near-duplicates. The term set became a write-once, never-curated namespace.
The Observable Symptoms
By the time Dana’s organization called me in, the symptoms had cascaded across three layers of their information system. Here is what each layer looked like when inspected:
In the SharePoint term store: The original 40 terms sat in a hierarchy under a root node called Matter Types. Beneath them, a flat list of 1,663 additional terms had accumulated at the root level, many of which were variations of existing governed terms. Employment Discrimination, Employment Discrimination — Federal, Emp Discrimination, Workplace Discrimination, and Discrimination — Employment all existed as separate terms. No term had been deprecated. No term had a description, a label synonym, or a cross-reference to another term. The term set had no custom properties, no submission guidelines, and no assigned owner after the original taxonomy consultant’s contract ended in 2022.
In the Elasticsearch index: The Graph API connector mapped the managed metadata field to an Elasticsearch keyword field called matter_type. Because SharePoint stored each term as a GUID-label pair, the connector ingested both the GUID and the label text. But the 1,663 fill-in terms had been assigned GUIDs by SharePoint’s term store service, and the connector faithfully indexed all of them. A faceted search for Employment Discrimination returned only documents tagged with that exact GUID — not documents tagged with Employment Discrimination — Federal or any of the other four variants. The facet panel displayed all 1,703 terms in an alphabetical list with no grouping, no hierarchy, and no synonym collapsing. Users saw a wall of nearly identical labels and either picked the first one that looked right or abandoned the facet entirely.
In the search relevance layer: The organization had configured Elasticsearch to boost results where the query text matched the matter_type field. This relevance tuning was designed when 40 clean, distinct terms occupied that field. With 1,703 terms — many of which shared common words like discrimination, housing, or benefits — the boost logic fragmented relevance scores across dozens of near-identical term matches. A query for housing discrimination matter might boost a document tagged Housing Discrimination (the governed term) but not one tagged Housing Discrim — Section 8 (a fill-in term created by a paralegal in 2023). The result set was technically correct but structurally inconsistent with what the user expected.
Why This Happens: The Governance Gap, Not the Technology
The instinct is to blame SharePoint’s default configuration, and there’s some justice in that — the Allow fill-in choices default is a usability decision that trades long-term vocabulary integrity for short-term user satisfaction. But the deeper failure is governance-by-convention: the organization treated the term set as a one-time design artifact rather than a living controlled vocabulary requiring ongoing stewardship. The original taxonomy consultant built a clean 40-term hierarchy aligned to the organization’s practice areas, documented it thoroughly, and handed it off. No one was assigned to own it after handoff. No one was responsible for reviewing the fill-in terms that accumulated. No one was notified when the term count crossed 100, 500, or 1,000.
This pattern is not unique to SharePoint. I’ve seen the same structural condition in Confluence space labels, in OpenText classification categories, and in Solr-based enterprise search deployments where managed synonym lists grew through ad hoc additions until they contradicted each other. The common thread is a controlled vocabulary that was designed but never governed — a namespace with a creation path but no curation path. Google’s Site Reliability Engineering book frames this precisely in its chapter on data integrity: the principle that what you read is what you wrote — that a system should faithfully preserve the data commitments it was designed to enforce. When SharePoint’s managed metadata service silently accepts a free-text fallback value and stores it as a term, it violates the integrity guarantee that the field was configured to provide. The field looks like a controlled vocabulary to the schema designer, but it behaves like a free-text field to the end user. That gap between appearance and behavior is where the drift lives. Google’s SRE book treats this class of failure as a reliability incident deserving of a postmortem — silent data integrity degradation in a managed metadata store is no different in kind from a distributed system that silently drops writes.
The NIST Cybersecurity Framework 2.0 offers a parallel governance lens. Its structured approach to category hierarchies, profile templates, and continuous evaluation mirrors what enterprise term sets need: not a one-time design but an ongoing governance discipline with defined ownership, review cycles, and promotion criteria. The framework’s emphasis on continuous evaluation and improvement of categorization schemas applies directly to the argument that a term set is not a deliverable but a maintained system. The NIST CSF 2.0 treats uncontrolled expansion of a categorization system as a degradation of its utility for risk assessment and retrieval — which is exactly what happened to Dana’s matter-type taxonomy.
Tracing the Drift: A Three-Year Timeline
To make this diagnosis concrete, here is the timeline I reconstructed from SharePoint’s term store change log and the organization’s IT support ticket history:
Month 1 (March 2021): Term set created with 40 terms. Allow fill-in choices enabled on the managed metadata site column. No term store owner assigned after consultant departure. Term set configured with open creation rights for all authenticated users.
Months 2–8: Fill-in terms accumulate at a rate of 3–5 per month. Most are legitimate practice-area refinements that the original taxonomy didn’t anticipate — Unemployment Insurance Appeal, HUD Fair Housing Complaint, SSI Overpayment Reconsideration. These are useful terms that a governance process would have promoted into the hierarchy. Without one, they sit at the root level, flat and unstructured.
Months 9–18: Fill-in rate increases to 12–18 per month as more attorneys use the matter intake form. Duplicate and near-duplicate terms begin appearing. Eviction Defense and Eviction Defence both appear (the organization serves both US and Canadian clients). Family Law — Custody and Custody — Family Law appear within two weeks of each other, created by different paralegals in different offices.
Months 19–30: Fill-in rate stabilizes at 20–30 per month. The Elasticsearch connector is configured, and the first faceted search interface goes live. Initial user feedback mentions the facet panel is hard to use but the issue is attributed to UI design rather than term-set condition. No one on the search team inspects the term store because the connector is returning data successfully.
Month 36 (October 2024): Dana discovers the term count during a routine content-type audit. She exports the term set to CSV, sorts alphabetically, and finds 1,703 terms. She counts 47 terms containing the word discrimination, 31 containing eviction, and 24 containing custody. She emails me.
The Anatomy of the Drift
The following sketch shows the structural condition as I diagrammed it for Dana’s leadership team:
TERM STORE (SharePoint Managed Metadata Service)
│
├── Matter Types [root — governed, designed 2021]
│ ├── Consumer Protection (original term)
│ ├── Employment Law (original term)
│ ├── Family Law (original term)
│ ├── Housing Law (original term)
│ └── ... (36 more original terms)
│
├── [fill-in terms — ungoverned, created 2021–2024]
│ ├── Employment Discrimination
│ ├── Employment Discrimination — Federal
│ ├── Employment Discrimination — State
│ ├── Emp Discrimination
│ ├── Workplace Discrimination
│ ├── Discrimination — Employment
│ ├── Eviction Defense
│ ├── Eviction Defence
│ ├── Eviction — Defense
│ ├── Eviction Defense (Non-Payment)
│ └── ... (1,693 more fill-in terms)
│
└── [no owner assigned since 2022]
[no review cycle defined]
[no promotion process defined]
[no deprecation process defined]
ELASTICSEARCH INDEX
│
├── matter_type (keyword field)
│ ├── indexed values: 1,703 distinct GUID-label pairs
│ ├── facet panel: displays all 1,703 as flat list
│ ├── synonym configuration: none (original 40 terms had no synonyms either)
│ └── relevance boost: applied to all 1,703 values equally
│
└── user experience: attorneys abandon facets, revert to email
The diagram makes the failure visible in a way that a term count alone doesn’t. The governed hierarchy and the fill-in terms occupy the same term set, but they have different structural properties: the governed terms have descriptions, hierarchical positions, and an intended relationship to the organization’s practice areas. The fill-in terms have none of these. To the Elasticsearch connector, they are indistinguishable — all are valid terms with valid GUIDs. To the user, they are noise that obscures the signal.
Prototyping a Namespace Before Committing to It
The broader principle here extends beyond enterprise taxonomy. Any act of naming — whether you’re designing a term set for matter types or naming characters in a novel — is an act of taxonomy design. You’re defining a namespace, establishing boundaries between members, and creating a structure that subsequent work will depend on. The discipline of prototyping a namespace before committing to it applies whether the namespace is a SharePoint term store or a character cast for a fiction project. A character name generator from the Unsloppy AI Novel Writing App lets a writer explore a naming space before locking in choices that will propagate through hundreds of pages. An information architect should prototype a term set against real content samples before promoting it to enterprise-wide managed metadata. The cost of exploring a namespace early is minutes. The cost of repairing a namespace that has drifted for three years is months.
In Dana’s case, the original 40-term taxonomy was prototyped — the consultant tested it against a sample of 200 matter files and refined the hierarchy before publishing. What was never prototyped was the fill-in behavior: no one tested what would happen when 50 attorneys typed free-text values into a managed metadata field over three years. If they had, the fill-in terms would have appeared in the prototype within days, and the governance gap would have been visible before it became structural.
The Lightweight, Reversible Fix
Dana’s organization needed a fix that respected three constraints: no budget for a taxonomy redesign project, no appetite for a six-month migration, and no tolerance for breaking existing documents that were already tagged with fill-in terms. The fix I recommended had four steps, each reversible:
Step 1: Disable fill-in choices on the managed metadata site column. This is a single configuration change in SharePoint Online. It prevents new fill-in terms from being created while preserving all existing terms and their associations with documents. The change takes effect immediately on new edits but does not alter existing document metadata. If the organization later decides to re-enable fill-in choices, the change is equally trivial to reverse. The trade-off is that users who encounter a matter type not in the term set will need to request an addition through a governance process — which doesn’t yet exist, but which Step 2 creates.
What to Inspect on Monday
- Export every managed metadata term set to CSV. In SharePoint Online, use the
Copy-SPTermSetToXmlPowerShell cmdlet (via PnP PowerShell) or the term store management UI’s export function. For each term set, record the term count, the number of terms with descriptions, and the number of terms at the root level versus inside the designed hierarchy. A term set where more than 30% of terms sit at the root level is likely experiencing drift. - Check the Allow fill-in choices setting on every managed metadata site column. Use
Get-PnPFieldfor each site column configured as managed metadata. Record which columns have fill-in enabled. Any column with fill-in enabled and no documented review process is a drift candidate. - Identify the term set owner for each term set. In the term store management UI, check the Contributors and Managers fields for each term set group. A term set with no manager listed, or with a manager who has left the organization, has no governance owner. Record the gap.
- Pull the SharePoint change log for term store modifications over the past 90 days. Use the Unified Audit Log in the Microsoft Purview compliance portal. Filter for TermStoreModified events. The volume of events tells you whether the term store is actively changing and whether those changes are coming from a small number of governance accounts or a broad range of end-user accounts.
- Cross-reference the term count against your search index. If you use Elasticsearch, Solr, or a SharePoint search connector, query the
matter_typefield (or equivalent) for distinct values. The count should match the term store’s term count. If the search index shows fewer values than the term store, your connector may be filtering or failing to ingest certain terms — a different but related problem. If it shows more, you may have orphaned terms from a previous term set configuration. - Document the gap between designed terms and fill-in terms. For each term set, count the terms that were part of the original design (usually identifiable by their hierarchical position, creation date, or the presence of descriptions) versus terms added later. Express this as a ratio. Dana’s organization had a 40:1,663 ratio — roughly 2.4% governed terms, 97.6% ungoverned. Any ratio below 50% governed terms indicates a term set that has been substantially hollowed out by drift.
