How Treviko uses AI on the catalog

Treviko is our AI-assisted e-commerce platform. Its demo store, at treviko.kairn.in, sells home essentials: kitchenware, storage, linen, lighting and the small things a house needs. A catalog like that looks easy until you maintain it. Hundreds of products, each needing a clear description, correct attributes and a place in search, all kept consistent as stock changes.

This post describes how Treviko applies AI to three catalog jobs: writing product copy, tagging attributes and powering search. It also covers the part we care about most, which is how people stay in control.

The model proposes, a person approves, and the catalog only ever contains approved text.

The catalog problem

Small stores usually run on spreadsheets and supplier data. Titles come in shouting capitals. Descriptions are copied from a manufacturer’s page. A steel water jug has its capacity in the title, in the description, and nowhere in a field a filter can use.

Three things suffer:

• Copy is inconsistent or thin, which hurts both shoppers and search engines.
• Attributes are missing or free-text, so filters like “stainless steel” or “under 1 litre” cannot work.
• Search matches keywords, so someone typing “something to keep bread fresh” finds nothing when the product is titled “Ceramic Bread Bin”.

Each is a language problem on top of structured data, which is where current models do useful work, as long as their output is checked.

Writing product copy

For each product, Treviko’s copy assistant receives only what we know to be true: the supplier fields, the attributes already on record, the product images’ extracted details, and the store’s style guide. It does not browse the web for claims, and it is told to use only supplied facts.

The prompt asks for a fixed set of outputs: a clean title, a short summary, a few feature bullets and a longer description. It follows the store’s voice rules, which are part of the configuration: plain language, no inflated claims, consistent units.

Three safeguards matter here:

1. Grounding. Every factual claim in the copy must trace back to a supplied field. Capacity, material and dimensions come from data, not from the model’s imagination.
2. A forbidden-claims list. Phrases like “dishwasher safe”, “BPA-free” or “food safe” are only allowed if the matching attribute is present and confirmed. Anything touching safety or certification is checked by rule, not by trust.
3. A diff view. Reviewers see the existing text and the proposed text side by side, with changes highlighted.

When the supplier data is thin, the assistant says so instead of padding. A flagged “not enough information to describe the finish” is more useful than a confident guess.

Tagging attributes

Attributes power filters, comparisons and search. Treviko extracts them from titles, descriptions and images into a fixed schema, so the output is structured data and not loose tags.

Here is a simplified version of the JSON schema we ask the model to fill:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ProductAttributes",
  "type": "object",
  "required": ["category", "material", "confidence"],
  "additionalProperties": false,
  "properties": {
    "category": {
      "type": "string",
      "enum": ["kitchen", "storage", "linen", "lighting", "bath", "decor"]
    },
    "material": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": ["stainless_steel", "ceramic", "glass", "cotton", "wood", "bamboo", "plastic", "other"]
      },
      "minItems": 1
    },
    "capacity_ml": { "type": ["integer", "null"], "minimum": 1 },
    "dimensions_cm": {
      "type": ["object", "null"],
      "properties": {
        "length": { "type": "number" },
        "width": { "type": "number" },
        "height": { "type": "number" }
      }
    },
    "colour": { "type": ["string", "null"] },
    "care": {
      "type": "array",
      "items": { "type": "string", "enum": ["machine_washable", "hand_wash_only", "dishwasher_safe", "wipe_clean"] }
    },
    "evidence": {
      "type": "object",
      "description": "For each attribute, the source text or image region that supports it.",
      "additionalProperties": { "type": "string" }
    },
    "confidence": {
      "type": "object",
      "additionalProperties": { "type": "number", "minimum": 0, "maximum": 1 }
    }
  }
}

The design choices are worth spelling out.

Enums over free text. A closed list keeps “stainless steel”, “SS” and “steel” from becoming three filter options. Values outside the list map to other and get flagged for a human to decide whether the list needs to grow.

Null is allowed. Fields such as capacity can be null. We want the model to leave a field empty rather than invent a number to satisfy the schema.

Evidence per attribute. Each extracted value points to the text or image detail behind it. A reviewer can check a claim in seconds.

Confidence scores. These help sort the review queue. They are not a promise of correctness, and we treat them as a hint for ordering work.

Structured output is validated against this schema in code. Anything that fails validation never reaches a reviewer; it is retried or discarded.

Search that understands intent

Keyword search works when shoppers use the store’s words. They often do not. Treviko combines two approaches.

Traditional text search handles exact and near matches: product names, SKUs, brand terms, typos. It is fast and predictable.

Semantic search handles meaning. Product text and attributes are turned into embeddings, and a query is matched by closeness of meaning. “Something to keep bread fresh” lands near the bread bin. “Gift for a new flat” surfaces a sensible set of home basics.

The two result lists are blended, and the structured attributes then act as filters and boosters. If a query includes “steel” and “1 litre”, the extracted material and capacity fields narrow results without relying on lucky wording. This is why attribute quality matters so much: good tagging improves search directly.

We keep search results explainable. For tuning, we log which queries returned nothing useful, and those become new test cases and new synonyms.

People approve every change

None of this would be acceptable if the model wrote straight into the live catalog. In Treviko, AI output is always a proposal.

The flow looks like this:

1. The assistant drafts copy and attributes for a product or a batch.
2. Proposals land in a review queue, ordered by what most needs attention: low confidence, missing evidence, flagged claims.
3. A reviewer approves, edits or rejects each one. Edits are saved as corrections.
4. Only approved content is published to the storefront. Every change records who approved it and when, and can be rolled back.

Rejections and edits feed back into the system. Repeated corrections show where the style guide or the schema needs adjusting, and they become examples in our test set, which we run before changing any prompt. Our post on writing evals first covers that practice in detail.

Reviewing is faster than writing from scratch, and it keeps accountability with the store owner. The AI removes the blank page; it does not remove the editor.

Where it fits

Treviko is available as a platform and as a ready-made template, so teams can run the demo store’s structure as a starting point and swap in their own products, schema and voice. The approach we have described is deliberately modest: constrained inputs, structured outputs, validation in code and a person at the gate. It is the version of AI in e-commerce we are comfortable putting in front of customers.

#treviko#ecommerce#ai#search