Product base — design

A single, structured home for every Hai Robotics product and product-level technology: one entry per thing, every published fact cited, comparable side by side, and shaped so a future solution can be assembled from it.

Status: phase 1 built (2026-09-11). There are 57 entries, 265 quotes checked word for word against the corpus, and 179 relations. Browse it at /products/ in the document site. Phase 2 (videos) and phase 3 (solutions) are below.

Why the scraped material was not enough

Specs are sparse and uneven: each page publishes different headline figures and no page is a full spec sheet. "Not published" is therefore shown as a first-class value, and it is often a good question to ask Hai.

The corpus also contradicts itself in places. Each case is recorded in the entry's notes:

The model

Entities

One Markdown file per entity. The folder is its kind and the file name is its id, so products/robots/haipick-a3.md is the robot haipick-a3.

listing records how visible a product is on the site: page (its own product page), section (described on another page, like HaiPort on the HaiStation page) or mentioned (named only in passing). Technologies have no listing.

Family entries ("HaiPick ACRs", "Companion Bots") exist because the site uses those names as families. Looking up "ACR" or "Companion AMR" lands on the family, which lists its members, instead of attaching a vague term to one product. Aliases may still be shared when the site shares them. The K600 and K1000 are both "Heavy-Duty Companion", and the terms page lists both.

Attributes

_attributes.yaml defines every attribute once, with its label, unit, type (number, text or list) and the kinds it may appear on. A number may be a [min, max] range. Its order is the row order on product and compare pages.

Every value carries the verbatim quote it rests on:

max_height_m:
  value: 5.5                       # normalised: comparable across products
  quote: "With up to 5.5m(18 feet) picking height"   # exact text from the page
  source: https://...              # optional; defaults to the entry's url
  note: fork lift speed            # optional short qualifier, shown in grey
  external: true                   # optional; a fact from outside the corpus,
                                   # shown as "unverified", quote not checked

what_it_does is required on every entry, so each one has at least one cited statement. Your own reasoning goes in the Markdown body, under Notes, and never into attributes.

Relations

Store a relation on whichever side has the evidence; the site shows it from both sides. Each relation takes one of three forms:

relations:
  works_with: [haiq]                 # checked: the target's name is on this entry's page
  part_of:
    - {id: haipick-system-1, quote: "The A3 and A42-FW ACRs are launched for HaiPick System 1",
       source: "https://www.hairobotics.com/company"}          # checked: quote on source
  variant_of:
    - {id: haipick-a42, inferred: true, note: "Named as an A42 model"}   # not checked; shown as "inferred"

Case-study mentions

These are computed, not typed. Each product page lists the case studies whose own text names it or one of its aliases. The site's boilerplate "Products" footer is ignored, "HaiPick A42" does not match "A42T" or "A42-E6S", and plurals such as "7 HaiPorts" count. Generic names (WES, Racking, Virtual Warehouse) set case_match: false.

Files and commands

products/
  DESIGN.md             this document
  _attributes.yaml      the attribute dictionary
  <kind>/<id>.md        one entry each
site/productbase.py     loader shared by the site and the checker
scraper/verify_products.py

poetry run python scraper/verify_products.py   # check every entry
poetry run python site/serve.py                 # browse at http://127.0.0.1:8000/products/

The checker enforces: known fields, kinds, families and listings; attributes defined for the entry's kind, with the right value type; every quote verbatim on its source page; every relation pointing to an existing entry, evidenced or marked inferred; and every knowledge link resolving to a real heading. It exits non-zero and lists each problem.

Adding or updating a product

1. Copy a similar entry into the right kind folder; the file name becomes the id.
2. Fill in name, url, listing and what_it_does, then any attributes from the dictionary. Copy each quote exactly from the page text in data/pages.jsonl.
3. For a fact from outside the corpus (a datasheet, a conversation), add external: true and a source.
4. Run the checker, then refresh the site.

Roadmap

Phase 2 — videos. Add videos to the in-scope sections in scraper/discover.py, re-run fetch and extract (cached, one request per second), then add new figures and video links to entries. All three verify_*.py scripts must still pass, since catalog.json is regenerated.

Phase 3 — solutions. A solution is a composition: requirements, a system choice, a bill of materials, and the technologies that make it work. Entry ids are stable and kinds are typed, so a solutions/ collection can reference them without changing anything here:

# solutions/<id>.yaml  (phase 3 — illustrative)
based_on: case:bosideng-hps1        # a reference deployment, or "design" for your own
system: haipick-system-1
requirements: {peak_totes_h: …, skus: …, clear_height_m: …}
bill_of_materials:
  - {product: haipick-a42n, qty: …}
  - {product: haicharger, qty: …}
  - {product: haiport-workstation, qty: …}

The checker would then confirm every product exists, that the robots are ones the system includes, and flag a requirement beyond a product's published figures (for example a clear height above a robot's max height). Case studies become the first reference solutions.

Decisions (2026-09-11)

1. Products without a product page are included. More detail can be added later.
2. Every published attribute needs a verbatim quote; external facts are allowed but marked "unverified".
3. Technologies live in the same base and link to knowledge/.
4. Videos come in phase 2, after this phase.
5. The folder is products/.