Skip to main content
COLA Cloud Taxonomy 2.0 is a consumer- and trade-oriented hierarchy for the products represented by COLA records. It powers the llm_category and llm_category_path fields, category filters in the web application and API, and the corresponding columns in bulk data products.

​
Field contract

For example:
The two public category field names and types have not changed in 2.0. Either category field can be null when no category is available. When populated, llm_category is the final segment of llm_category_path. Their values can change when a record is reclassified or a path is reorganized. The current machine-readable taxonomy publishes its exact taxonomy_version, semantic taxonomy_sha256, nodes, and legacy-path aliases. Treat that URL as a current-version pointer; persist the version and checksum if your mapping must be reproducible across future taxonomy releases.

​
Classification principles

​
Trade-first, not regulation-first

The hierarchy prioritizes distinctions that are useful to buyers, sellers, analysts, and consumer applications. TTB class and type metadata remains useful evidence, but it does not dictate placement. For example, a TTB wine record may be placed under Beer > Cider / Apple Wine, and sake is represented under Liquor > Sake.

​
Label-first evidence

When a COLA is reclassified, the classifier evaluates the submitted label imagery, OCR text, and metadata available on the COLA record at processing time. These are complementary evidence channels: visible design or typography can clarify imperfect OCR, while OCR and structured metadata make explicit label claims easier to verify consistently. Origin can support a determination, but the classifier does not require external provenance research to assign an ordinary category. A clear label claim such as Champagne or Baijiu can support that category when the rest of the record does not contradict it.

​
Deepest defensible node

Every classification may stop at a non-leaf node. If the evidence supports Liquor > Whiskey but not a specific whiskey family, that is a complete and valid result. A more specific path is not preferred unless the label evidence supports it.
Do not treat path depth as a quality score, assume that every record ends at a leaf, or require the same number of path segments across products.

​
Browse hierarchy, not a strict ontology

Some intermediate nodes organize related products, while others are categories where products can be placed directly. The levels therefore do not all represent the same semantic type. For example, Liquor > Agave Spirits > Mezcal uses an organizational family, while Liquor > Baijiu is direct. Applications should treat the full path as a browse and filtering hierarchy rather than infer a universal meaning for “level 2” or “level 3.”

​
Filtering

Use category for a root and derived_subcategory for a path-prefix filter:
product_type and the COLA Cloud Category filters are independent and can be combined. A root mismatch is not automatically an invalid query because a trade-oriented placement can cross a TTB commodity boundary.

​
Legacy path aliases

Taxonomy 2.0 reorganizes some existing paths. During the transition, API and web filter inputs that match a published legacy-path alias (case-insensitively) are resolved to the corresponding canonical 2.0 path. For example, the legacy filter Liquor > Mezcal resolves to Liquor > Agave Spirits > Mezcal. Aliases affect filter input only:
  • API responses and current bulk data contain canonical 2.0 values.
  • The API does not return the legacy value supplied by a client.
  • Prefixes or application-specific variants that are not published aliases are not rewritten.
  • Aliases are a migration aid, not a substitute for updating customer-owned mappings.

​
Guidance for customer mappings

  • Treat llm_category_path as the authoritative category value and llm_category as its final segment.
  • Accept a valid non-leaf path and variable depth.
  • Keep product_type and llm_category_path as separate dimensions.
  • Match a branch with the full path or a deliberate prefix, not a fixed path index.
  • Expect occasional value changes as label evidence is reprocessed or the taxonomy evolves.
  • Review exact-path mappings when a taxonomy release is announced, even though the field names and data types remain stable.
  • Pin the taxonomy version and checksum alongside any exported mapping that must remain reproducible.
See the Taxonomy 2.0 release note for migration impact.