The Inventory Looked Organized. 32 Apps Were in the Wrong Place.
On the difference between complete and correct.
In early June I finalized the category architecture for a 327-app active inventory: twelve top-level categories, roughly sixty subcategories. The architecture forced a single placement decision for every app: one primary category, one primary subcategory, no dual filing. I locked it on June 5.
Three days later, I ran an audit.
Not because something looked wrong. Because I hadn’t yet checked it.
Friction
The inventory looked organized. Every app had a category. Every app had a subcategory. No blank cells, no missing assignments. The spreadsheet passed every completeness check.
Completeness hid the failure. Medication Reminder was not a pet app. The spreadsheet only knew the cell was filled.
Build
The audit was manual: app name, description, current category, current subcategory, checked against the locked reference.
Every documented app in the active set: 327 records. One primary assignment per app. Clear mismatches were counted as errors. Ambiguous cases were flagged separately.
Clear errors were corrected against the reference; ambiguous cases stayed out of the error count.
Insight
32 errors. 295 of 327 apps correct.
The person looking for a relationship repair tool finds it filed under Home > Home Maintenance. A child’s homework assistant was filed under Home > Home Maintenance alongside the renovation tools. A human Medication Reminder is in Pets > Pet Behavior.
The 32 errors were not one kind of mistake. They split into three different classification failures: placement, defaulting, and granularity.
Placement errors — 7 apps. These were not close calls. A care package planning tool in Travel > Packing rather than Relationships > Friendship. An event preparation tool in Travel > Trip Planning rather than Work > Productivity. A relationship app called “Repair Plan” in Home > Home Maintenance — description: making amends after conflict. The pattern did not look like semantic confusion. It looked like workflow residue: the app had been left near the work being done, not where the locked architecture said it belonged.
Default-bucket errors — 12 apps. Every Pets app had defaulted to Pets > Pet Behavior. The architecture has six Pets subcategories: Choosing a Pet, Pet Health, Pet Behavior, Training & Daily Life, Traveling With Pets, Aging & Loss. Pet Travel Checklist was in Pet Behavior. Breed Selection was in Pet Behavior. Loss of Pet was in Pet Behavior. The subcategory had been used as a catch-all rather than a classification.
Granularity errors — 13 apps. Blood Pressure Tracker was in Health > Healthy Living. Four Plain English apps — fitness, nutrition, sleep, sex — were all filed under Health > Health Conditions. Three of the four are lifestyle topics, not medical ones. These were harder to catch because the top-level label looked plausible. The failure moved down a level.
Most errors were not edge cases. They were filing-process failures: each app had been categorized once, at build time, against a best-guess reading of the category list. The architecture defined the expected state. It did not verify the inventory against it.
Implication
A category architecture and a verified inventory are different artifacts.
The architecture existed. The errors existed inside it. The audit converted the architecture from a declared structure into a tested one.
The Pets cluster showed the compounding risk. Once Pet Behavior became the default bucket, Pet Travel Checklist, Breed Selection, and Loss of Pet all inherited the same wrong convention. The error was no longer isolated. It had become precedent.
The honest part: the audit proved the inventory did not match the architecture. It did not prove the architecture was right. A clean baseline is only clean relative to the structure being used to judge it.
It also did not prevent future drift. That requires changing the filing process, not running a one-time check.
The 8 debatable entries raised the harder question: whether the architecture needs refinement at the edges, or whether deliberate ambiguity is the right policy for apps that span categories. The unresolved cases were no longer filing errors. They were architecture decisions.
The audit was a bounded manual pass. Skipping it would have let the error rate compound with every new app.
Case Study Insight: A filled cell is not a verified decision.
Robert Ford builds products, writes stories and essays, and publishes The Intelligence Engine — a Substack about building AI practices that compound. His other writing lives at Brittle Views.