HandiProducts Photo Tagger — Tag System FAQ

Decisions, rationale, and guidelines for the AI photo tagging taxonomy

No results found Try different keywords, or clear the search.

No. Brand is already encoded in the tag prefix — the two-letter namespace before the colon.

hr: ht: ps: ft:

Every ht: tag is a HandiTreads product. Every hr: tag is HandiRamp. You can filter the entire HandiTreads catalog just by searching for ht: — no extra tag needed.

Brand names do belong in the Description column of the worksheet — that's what the AI reads to understand context. For example: "HandiTreads-branded non-slip tread — same product as hr:stair-tread but sold under the HandiTreads brand." This helps the AI distinguish between identical-looking products from different brands.

Adopted rule Tag prefix = brand. Description column = where brand names go to guide the AI. Never put brand names inside the tag slug itself — ht:stair-tread is correct; ht:handitreads-stair-tread is not.

These are two distinct dimensions and they're handled differently:

1. Star rating (1–5) → native XMP:Rating field
Star ratings are a universal XMP standard, not a tag. The tagger writes them directly into the image file via exiftool alongside the product tags. Every DAM tool — Lightroom, Bridge, even macOS Finder — reads and writes XMP:Rating natively. No scene: tag needed.

2. Usability / quality → scene: tags
Image quality is a judgment the AI makes visually — blur, poor exposure, bad cropping, compression artifacts. Standard star ratings don't capture this well. Two tags cover it:

scene:quality-high scene:quality-low

The useful searches are "give me only the marketing-ready ones" or "flag the bad ones for culling." A middle tier isn't worth the noise.

Where to edit ratings:

  • Lightroom / Bridge — best for bulk culling and final editorial decisions (keyboard shortcuts, side-by-side view)
  • Tag review UI — shows the AI's proposed rating so you can correct obvious errors before accepting a batch; not a full rating workflow
  • macOS Finder — quick one-off edits via Get Info or column view

Practical flow:

  1. AI writes initial XMP:Rating + tags during processing
  2. Tag review UI shows the proposed rating — correct it if obviously wrong
  3. Final editorial rating pass happens in Lightroom/Bridge where you can see images full-size
Adopted rule Star ratings → XMP:Rating native field (not a tag). Usability flags → scene:quality-high / scene:quality-low. Don't encode "excellent / good / poor" as tags — that reinvents star ratings with worse tooling support. The tag review UI handles quick AI rating corrections; Lightroom/Bridge handles real editorial decisions.

Weather and environmental context are a different dimension than product type — they describe the scene, not the product. We handle these with a separate scene: prefix.

For example, the AI might want to describe a stair tread in snowy conditions as "snow safety" — accurate, but not searchable as a tag. Instead, two clean tags cover it:

hr:stair-tread scene:snow

Both are independently searchable. You can find every snow-condition photo across all product lines just by searching scene:snow.

Current scene: weather tags

scene:snow scene:wet

Current scene: setting tags

scene:outdoor scene:indoor scene:low-light

Current scene: usage context tags

scene:in-use scene:install
Adopted rule Weather and environmental context → scene: prefix, never freeform labels. Keep the scene vocabulary tight. The full list is in the Product Tags Worksheet under the Scene / Environment filter.

Historical photos are valuable for reference but need to be findable and distinguishable from current product shots. We use two scene: era tags:

scene:archival scene:modern

Why not decade tags (like scene:decade-1990s)? The AI can detect that a photo looks old — film grain, color cast, image quality, dated product styling — but it can't reliably pin the decade. A 1994 and a 2001 photo look nearly identical. Decade-level tagging creates false precision in the data.

The practical search need is binary: "old photos for historical context" vs. "current photos for marketing." Two tags cover that cleanly.

Example — 1990s installation photo
hr:modular-ramp-residential scene:outdoor scene:archival scene:in-use
Adopted rule Use scene:archival for pre-digital or clearly dated photos (film grain, old styling, low resolution). Use scene:modern for clean digital photos that look recent. Skip decade-level tags — the AI can't reliably distinguish them, and the search value doesn't justify the noise.

Color is handled as part of the variant tag — but only where color is a real product differentiator (i.e. a separate SKU that customers choose). The AI is reliable at distinguishing colors visually, so this works well in practice.

HandiTreads come in 4 colors, each a real purchase decision. Color is encoded directly in the tag alongside size:

ht:stair-tread-48-chestnut ht:stair-tread-48-java ht:stair-tread-48-gray ht:stair-tread-48-black

The four HandiTreads colors and their visual character:

  • Chestnut Brown — warm medium brown
  • Java Brown — dark espresso brown
  • New England Gray — medium cool gray
  • Obsidian Black — deep matte black

This applies to all three HandiTreads product types: stair treads (30"/36"/48"), ramp & deck treads (48" only), and nosings (30"/36"/48").

PetStep comes in two colors across both the folding ramp and pool ramp:

ps:folding-dog-ramp-graphite ps:folding-dog-ramp-khaki ps:pool-ramp-std-graphite ps:pool-ramp-long-khaki

For pool ramps, color and leg length combine into the variant tag (standard 23" legs vs. long 30" legs × Graphite/Khaki = 4 combinations).

HandiRamp van ramps and modular ramps are always bare aluminum — no color variants, no color tag needed.

What about generic color as a scene tag? We don't use scene:color-* tags. Scene color (a gray deck, brown stairs) would create false matches with product color. Color belongs in the variant tag, not the scene namespace.

Adopted rule Color → variant tag, only where it's a real SKU differentiator. HandiTreads: size + color in one tag (e.g. ht:stair-tread-36-java). PetStep: product + leg length + color (e.g. ps:pool-ramp-long-graphite). HandiRamp metal products: no color tag — always aluminum. No scene:color-* tags.

Last updated: June 2026  ·  Maintained by the HandiProducts marketing team. To suggest additions, contact Nathan.