Editorial note: This publication and Quirky Cotton Collective share an owner. The banner is the first thing you see, and it is almost aggressively plain. A white rounded rectangle, the kind of shape a phone throws up when a camera catches something it thinks you should know about. A small bell icon sits at the left edge. The text reads, in ordinary sentence case: There is motion at your front door. Below the banner, inside a circular frame, a green-tinted view shows an orange tabby pressed so close to the lens that its face fills the whole aperture — wide…

Every organization has two classification schemes. One is written down somewhere — a taxonomy, a records schedule, a governance policy. The other is the folder tree. The folder tree is the one people actually search against, and it was never designed. It accreted. This article is about reading that accreted structure as evidence. Not as a standard-compliant artifact, not as a records schedule, and not as something to migrate. The folder tree is a concept scheme in the descriptive sense: it has labels, near-synonyms, code-like segments, and links (or missing links) to the formal schemes it is supposed to serve.…

Editorial note: This publication and Quirky Cotton Collective share an owner, so this is not an independent review. The garment preview shows one word and one mark: meh. — large, bold, lowercase, white, set on a dark shirt. No animal illustration. No secondary slogan. No decorative frame. The period is the part I keep returning to. Without it, the shirt reads as a mood. With it, the shirt reads as a verdict. That distinction matters more than it first appears, and it is the argument of this column: the period converts a feeling into a boundary. A mood is something…

“Search is broken” is almost never a search problem. It is an indexing problem that search is faithfully reporting. The crawl log — the record of what the indexer attempted to read, parse, and admit into the index — has an error column, and that column is the closest thing an enterprise knowledge system has to a truthful account of why users cannot find things. The error column is not a list of search bugs. It is a list of structural information failures that were present before anyone typed a query. This article is about reading that column diagnostically: what…

Most enterprise libraries do not fail because someone deleted the wrong field. They fail because nobody ever asked which fields were doing work. A SharePoint document library accumulates columns the way a shared drive accumulates folders: one request at a time, each reasonable in isolation, none reviewed as a set. Ten years later the form has sixty fields, the search index has forty of them, and the retention schedule references three. This is a diagnostic problem before it is a design problem. Before you remove a column, you need evidence about which columns are populated, which are queried, and which…

You know the document exists. You watched the program manager upload it in March. You type the project code into SharePoint search and get nothing — then browse to the library, scroll, and find it sitting there as Final_v3_PROJ-7720.docx. The search didn’t fail. The naming convention did, and it failed quietly, one file at a time, for three years. We call this condition governance-by-naming: the structural substitution of a filename convention for an actual metadata layer. It is one of the most common failure modes we see in enterprise and public-sector knowledge systems, and one of the least diagnosed, because…

An enterprise knowledge management system is any platform an organization uses to store, describe, and retrieve its working knowledge: SharePoint sites, Teams channels, OneDrive folders, Confluence spaces, OpenText repositories, an Elasticsearch or Solr index sitting in front of all of them, or a public-sector data portal built on CKAN or Socrata. Failure in these systems rarely looks like an outage. It looks like a person who knows a document exists, has every right to read it, and still cannot find it in the time they are willing to spend. I review these systems for a living, and I have stopped…

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…

… … …” } Where are literal escape sequences in the JSON string. I’ll write the whole html as one line with between block elements. One thing: should there be a newline after tags — yes, same separators. Also, JSON strings can’t contain raw newlines — I’ll make sure the html value is one continuous line in my output (the being two characters: backslash and n). Also check: any backslashes in content? No. Any double quotes? No — all attributes single-quoted, prose quotes are single quotes. Apostrophes fine. Em dashes (—) are fine as UTF-8. Let me also double check…

Enterprise knowledge management (KM) systems are supposed to make organizational knowledge findable, reusable, and governable. In practice, they often become expensive filing cabinets that nobody trusts. The failure pattern is not random. It repeats because organizations treat knowledge as a technology problem when it is actually a structural information problem. Taxonomy, metadata, findability, and governance are the load-bearing walls. When those are weak, the system collapses no matter how much is spent on the platform. This article is for the people who inherit a failed KM system or are asked to prevent the next one. It is written from the…

Enterprise knowledge management systems fail repeatedly for a structural reason: they are usually built as document repositories with a search box, not as governed information environments. The main entity here is the enterprise knowledge management system — the combination of content stores, metadata models, navigation structures, search configuration, and governance routines that an organization uses to make recorded knowledge findable and reusable. Adjacent concepts include taxonomy, metadata, findability, information architecture, content lifecycle, and knowledge governance. This matters to the iiminfo.org audience because most failed knowledge systems do not fail from bad software. They fail from unresolved structural decisions about how…

Enterprise knowledge management (KM) systems are the platforms, taxonomies, metadata schemas, and governance routines that organizations use to capture, organize, and retrieve institutional knowledge. They sit at the intersection of information architecture, records management, search engineering, and organizational behavior. When they fail, the cost is not just wasted software spend. It is the slow erosion of findability, the duplication of analytical work, and the quiet loss of institutional memory. This article examines the structural reasons these systems fail repeatedly, even when the technology is competent and the intent is sincere. The Failure Pattern Is Structural, Not Technological Most post-mortems of…