Schemas and fields

Your catalogue is schema based. Every product carries a small set of core fields that exist on every schema (sku, title, category, uom, price, currency, stock_qty and lead_time_days) plus the attributes you define for that product family.

Kabaido ships twenty six ready made schemas for the supply chain, a cutting tools schema for example. The library on the Schemas tab offers the ones your presets carry rather than all twenty six, so what you are choosing between is the handful that describe things you actually sell; turn another preset on from Settings, then Presets, and its schemas appear here too. Until your first preset is on, the library shows everything. See Presets overview.

This narrows what is offered and nothing else. The categorisation Kabaido reads requests with is wider than any preset and is never gated: see the Application Engineering Intelligence page in Requests for the full picture. Each schema you take from the library is created as an editable copy in your organisation, so you can change it freely, and you can build a custom schema from scratch instead, adding and reordering fields with a live preview of the product form and facet rail.

Field types

A field has a key (snake_case, for example diameter_mm), a label and a type. The available types are number, text, select, boolean and dimension. Number and dimension fields carry a canonical unit. Select fields carry a list of options. Any field can hold synonyms (for example dia, d1) which feed automatic header mapping on import and attribute mapping in extraction. Mark a field as a facet to show it in the browse facet rail, or as required.

Match roles

Each field can be given a match role that controls how it behaves when an incoming request is matched against your catalogue.

Numeric and dimension fields can also set a tolerance with a toleranceMode of abs or pct, and nearestAbove where a result must meet or exceed the requested value. This is how a requested diameter is matched to the nearest stocked size within an acceptable band. Soft fields carry a weight, defaulting to 5, that sets how much they count in the fit score. Equivalence pairs, such as TiAlN and AlTiN for coating, can be declared so that either value satisfies the other as an acceptable alternative.

Getting the roles right

Match roles are where a catalogue becomes useful rather than merely stored, and the common mistake is to make everything hard. A hard field disqualifies any product that does not satisfy it, so a schema with eight hard fields returns nothing for most real enquiries, and returning nothing looks exactly like a matching engine that does not work.

The rule of thumb is to ask what you would do at the counter. If a customer asked for this attribute and you had it in a different value, would you offer the alternative? If yes, it is soft. If you would say no, we cannot supply that, it is hard. Diameter on a drill is usually hard. Coating is usually soft, because there is a conversation to be had about equivalents. Anything descriptive is usually ignore.

Weights, tolerances and equivalents

Those three are what turn a rough sort into a fit score somebody will trust.

• A weight says how much a soft field counts. Raise it on the attributes your customers genuinely choose on, leave it low on the ones they mention out of habit.
• A tolerance says how close is close enough, as an absolute figure or a percentage. Without one, 12.0 and 12.00001 are a miss.
• nearestAbove says the answer must meet or exceed the request, which is the correct rule for anything you machine down from.
• An equivalence pair says two values satisfy each other. Declaring TiAlN and AlTiN as equivalents is how a real alternative shows as an amber chip rather than a red one.