What the coverage engine actually resolves against

A coverage rule reads well in the dashboard: "12 months on all Category: Electric bikes." What actually decides whether a specific unit is covered is a match against a line item on a real order — not the rule's prose, the data behind it.

Matching happens at the line-item level

A three-item order can produce three registrations with three different coverage lengths, because a rule matches on sku, product_type, category, and vendor — fields that live on the product, not the order. Ingest orders without products and no rule can match, which means no coverage term at all.

{
  "line_item_id": "oli_9f2a",
  "sku": "EB-500-BLK",
  "product_type": "electric_bike",
  "matched_rule": "wru_01hxyz",
  "coverage_months": 12
}

The one field that has to survive a platform swap

Registrations bind to the upstream platform's own line-item identifier — sourceLineItemId — never a synthetic ID a connector invents. Coverage is resolved against that identifier for the life of the warranty, which can run a decade. An identifier that changes when you swap ERPs orphans every warranty behind it, with no error anywhere to catch it.

• Direct connectors (Shopify) and connector-platform syncs both anchor to the source system's own ID.
• A merchant pushing orders through POST /v1/orders supplies that same anchor themselves.
• Nothing about switching commerce platforms should touch coverage that already exists.

Why rules stay dashboard-only

Warranty rules are read-only over the API on purpose. A rule change silently re-terms future coverage, and that's a decision a merchant should make with their eyes open in the dashboard — not something an integration drifts into by writing the wrong value.