Case study: make an omission inspectable

Find an image for a specific task and understand why a search result matches or is missing. Correct one missing tag and see which search problems it solves—and which it leaves open.

The product choice: Make search rules and corrections understandable instead of hiding their limitations. Try the sample · Follow the walkthrough.

Experience and decision

My work at 5th Kind covered enterprise search, and my Oracle work included tagging and metadata. This example connects those areas by asking whether missing information or search policy is causing a failed find task. This is a separate fictional portfolio exercise; its records, rules and results do not reproduce an employer system.

Decision to challenge: Should the next investment improve metadata, vocabulary coverage or ranking? Making a missing asset findable can still leave an irrelevant result, so a higher recall number does not settle the decision.

User and decision

A fictional collection editor knows the intended bicycle scene, yet the asset title Morning commuter and intake tags commute/urban do not match bicycle. The product choice is to show the lexical rules and original evidence beside a controlled one-record correction. A search-first library with a compact metadata drawer keeps the explicit intent visible.

Prioritization and tradeoff

The rejected alternative was semantic ranking. It might improve vocabulary coverage, but a deterministic static sample cannot substantiate that benefit. Another alternative, silently adding inferred tags across the library, would obscure evidence and scope. This prototype keeps eight controlled tags and only one directional bike expansion. Policy changes require before/after review.

Demonstrated outcome and limits

The fixed full-scene label expects A01 and A02. A03 is a wheel detail: it matches bicycle exactly but is not relevant to that task. Original return A01/A03 has usefulness 1/2 and missing 1/2. Adding bicycle to A02 returns A01/A02/A03: usefulness 2/3 and missing 0/2. The imperfect result is deliberate: metadata correction improves recall without pretending it solves intent-level precision. Exact expected IDs and controls are in Sample_Contract.md.

Proposed evaluation

This is software evidence from author-assigned fixtures. No people were recruited and no customer/employer outcome, search-speed benefit or statistical result is claimed. Proposed human evaluation asks whether someone can find the intended scene, correctly explain a match, recover from exclusion, and assess a correction before confirming it. Mo's personal review and comprehension are unobserved. Mo owns product/program direction; AI assists implementation and verification.

S043–S052 traceability is in PRD.md. Current release evidence and publication gates are centralized in Validation.md.

Next investment decision

The next decision is whether metadata correction or a change to the search policy addresses the editor's real intent. Ask collection editors to challenge the full-scene labels and compare the original and corrected results: A02 becomes findable, but A03 remains an unsuitable wheel detail. If editors cannot agree on relevance, resolve the task and labels before expanding synonyms or considering semantic retrieval. If labels hold, compare successful find tasks and correction effort with the current library workflow. Ongoing taxonomy ownership and correction cost must be justified by that benefit; improved fixture recall alone is insufficient.