SportRx Customizer — Mental Model v2

Anchored on Huckson · reflects the 6/4 workshop + 6/5 capability review + 6/5 Logan×Jacob discovery · 2026-06-05

One configurator, two altitudes

The same model has to serve two readers. The bridge between them is this picture: products stay real Shopify products; only the configurator logic is data.

Justin · Architect

The holistic model

A product TYPE defines the shared template (which steps, which options apply: sunglass / eyeglass / lenses-only / goggle). A product inherits that template and overrides where the frame forces it. Edge cases are the rule, not the exception.

Logan · engineer

The build (metaobjects)

Steps are the primary modular entity; options + rules hang off them as JSON. Rules that touch many products become separate referenced objects, not inline copies — so they can be shared and drag-dropped onto product steps in admin.

These two views agreed in the 6/5 discovery: "rules affecting multiple products become separate objects" (Logan) is the same call as the key-route (Justin). The open seam is whether a template is per-type or per-product — see Open Questions.

Panel 1

The five metaobject shapes

all defined — enough to start mapping Monday

rule_template

name
applies_to_product_type
steps → ref[]

configurator_step

key · title
oos_behavior (hide/disable)

configurator_option

step_key · option_sku
title · product_ref
price_delta · dvi_code

rule

key · type
trigger ref[] · effect
targets ref[] · priority

goggle_insert_compatibility

goggle_frame_upc
compatible_insert_upcs[]
⚠ unseeded (no real goggle yet)

Source of truth = the Magento dependency CSV. Numeric IDs are disposable plumbing; the slugs (feat-polarized, material-trivex) carry over and become the keys rules reference.

Panel 2

Worked example — Huckson

template → 8 steps → options

rule_template

huckson-goggle

applies_to_product_type: sunglasses · (label says "goggle"; the real product is a sunglass — see Open Questions)

tap a step to see its options

1Vision Type vision_typeoos: hide4▸

vision-single-digitalvision-progressive-digital vision-singlevision-lined-bifocal

2Lens Material lens_materialoos: hide3▸

material-1.67material-polycarbonatematerial-trivex

3Lens Feature lens_featureoos: disable5▸

SignatureCustomfeat-tint feat-polarizedfeat-transitions

4Activities activitiesoos: hide7▸

baseballcyclinggolfhiking runningsnowpickleball

5Signature Lens signature_lensoos: disable7▸

twenty-six-point-twoa-c-ealtitudeblackout day-and-nightfog-fighter-ithe-closer

6Addon Products addon_productsoos: hide4▸

sportrx-clothsportrx-cloth-large sportrx-rubber-tip-retainersportrx-cleaning-kit

7Lens Color lens_coloroos: disable6▸

lc-tint-greylc-tint-brownlc-tint-clearlc-tint-amber lc-polarized-greylc-transitions-xtractive-grey lc-polarized-greensmoke-2 ⚠ not seeded

8Coating coatingoos: disable8▸

coating-arcoating-ar-backsidecoating-ar-procoating-ar-bluedefense coating-antifogcoating-scratchcoating-nonecoating-included

The full Huckson rule set is ≈ 680 rules (≈113 show + ≈570 hide; bulk lives in coating + signature-lens compatibility). That set is generated from the CSV, not hand-authored — the rows below are the spec the generator follows.

Panel 3

The rule shapes

one rule = one English sentence = one row

A Show / many targets — dependency

"When you pick X, these become available." trigger = the picked option, targets = the permitted list.

B Hide / AND-combo — independence

"When X and Y are both picked, hide Z." trigger = the condition group (AND), target = the option removed.

C Hide / OR-across-rows — independence × N

"Hide Z when (A·B) or (A·C) or (C)." One row per OR-branch, all pointing at the same target.

key	type	trigger (AND-group)	effect	target(s)
`r-show-bifocal-materials`	dependency	`vision-lined-bifocal`	show	`material-polycarbonate`, `material-1.67`
`r-hide-polarized-bifocal-trivex`	independence	`vision-lined-bifocal` AND `material-trivex`	hide	`feat-polarized`
`r-hide-polarized-single-167`	independence	`vision-single` AND `material-1.67`	hide	`feat-polarized`
`r-hide-lc-polarized-greensmoke-2-bifocal-trivex`	independence	`vision-lined-bifocal` AND `material-trivex`	hide	`lc-polarized-greensmoke-2` ⚠
`r-hide-lc-polarized-greensmoke-2-bifocal-167`	independence	`vision-lined-bifocal` AND `material-1.67`	hide	`lc-polarized-greensmoke-2` ⚠
`r-hide-lc-polarized-greensmoke-2-trivex`	independence	`material-trivex`	hide	`lc-polarized-greensmoke-2` ⚠

⚠ Highlighted rows target lc-polarized-greensmoke-2, which isn't in the seeded lens_color options yet — add it (or retarget) so the example is self-consistent. Rows A–C plus the three OR-branches cover all four rule shapes.

Panel 4

Parsing legend — Magento → rules

the cleanest thing to put atop the rule tab

, comma = AND

Stays inside one rule. Within a trigger group, comma-separated keys must all be selected together (the polarized rule needs "both picked").

| pipe = depends on the column

In dependence_value: a list of targets → one rule, many targets. In independence_value: OR → one rule row per branch.

Direction flip — show: trigger = picked option, targets = the list it permits. hide: trigger = the condition group, target = the row's own option. "Hide wins over show" on conflict — lives in priority.

Panel 5

Reconciliation — 6/5 Logan × Jacob (SportRx)

what the latest discovery changes

Confirms

Key-route + steps-as-entity, from the engineering side

Logan: "rules affecting multiple products become separate objects" and "steps as the main entity." Same calls we made — now echoed independently. Strengthens making configurator_step first-class.

Watch — could reshape the rule set

Logan's independency-redundancy thesis

Logan suspects independence (hide) rules are just the inverse of dependency (show) and might collapse to dependency-only to cut admin complexity. That touches ~570 of our ~680 rows. Not decided — pending review of the original architect's rationale for why independency exists. Our both-types model is the safe superset until then.

Incoming data

Full rule-set SQL dump + cleaner dependency sheet

Jacob is pulling the full SQL table of all rule sets and resending the rule-dependencies spreadsheet. Supersedes the single Huckson CSV for sizing — answers Logan's "how many unique permutations?" question (we already have ~680 for Huckson as a first data point).

Open questions

Still to lock

• Template = per-type or per-product? Schema names rule_template after a product (huckson-goggle) yet carries applies_to_product_type. This is the seam between Justin's two-level model and the build.

• "Hide wins" not yet written into the schema (priority is the hook).

• Goggle insert compatibility has no real seed — Huckson is a sunglass despite the label.

• Unique product identifier / SKU — option→real-product join waits on it (proceeding assuming it lands).