> ## Documentation Index > Fetch the complete documentation index at: https://docs.colacloud.us/llms.txt > Use this file to discover all available pages before exploring further. # Category Taxonomy > How COLA Cloud Taxonomy 2.0 classifies products, represents variable-depth paths, and handles legacy paths. 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 | Field | Public type | Meaning | | ------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `llm_category` | nullable string | Display name of the deepest published category for the record. For reclassified records, this is the deepest category supported by the available evidence. | | `llm_category_path` | nullable string | Canonical path from `Beer`, `Wine`, or `Liquor` to that category, separated by `>`. | | `product_type` | string | The TTB's federal commodity classification. This is a separate source field, not the root of the COLA Cloud category path. | For example: ```json theme={null} { "product_type": "distilled spirits", "llm_category": "Bourbon", "llm_category_path": "Liquor > Whiskey > American Whiskey > Bourbon" } ``` 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](https://app.colacloud.us/static/category_taxonomy.json) 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: ```bash theme={null} curl -H "X-API-Key: your_api_key" \ "https://app.colacloud.us/api/v1/colas?category=Liquor&derived_subcategory=Liquor%20%3E%20Agave%20Spirits" ``` `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](/updates/taxonomy-2-0) for migration impact.