A 3D jewelry configurator needs one dependable configuration state behind every view. The shopper may see a platinum-colored band, an oval stone, a short inscription and a familiar size label. Commerce and production need the exact metal specification, stone record, setting compatibility, normalized engraving, market sizing system, calculated price components and a frozen handoff revision. If those layers drift, a convincing ring on screen can still become an invalid order.
The practical design is a rules-led product system with 3D as one view of its state. It should make only valid choices available, explain why another choice is unavailable, preview details at a useful scale, and send the same configuration identity to cart, order review and production. This article is the jewelry-specific playbook. Use the 3D product configurator for manufacturing for the broader connection between rules, quote data and manufacturing, and use the custom configurator service for direct project help.
Start with a jewelry option and material schema
Do not begin with a list of swatches. Begin with stable identifiers and explicit relationships. A label such as “white gold” is presentation copy; it is not enough to select a model, set a price, disclose composition or tell production what to make. The schema below is an original Double Edged planning framework. Its fields are examples to resolve during discovery, not a universal jewelry data standard.
| Domain | Customer-facing choice | Canonical configuration fields | Rule or evidence needed | Production handoff |
|---|---|---|---|---|
| Base design | Ring family and setting | design_id, setting_id, revision | Setting accepts the chosen stone geometry and size band | Approved CAD or manufacturing model revision |
| Metal | Metal, color and finish | alloy_id, fineness, plating/coating ID, finish ID | Sale region, availability, composition disclosure and compatible process | Alloy specification, finish, plating and quality-mark instruction |
| Center stone | Type, origin, shape and grade | stone_id, natural/lab-created/imitation status, shape, dimensions, weight, grade system, treatment | Setting envelope, inventory, disclosure and certificate linkage | Reserved stone or procurement specification plus certificate ID |
| Accent stones | Layout and stone family | layout_id, count, dimensions, grade band | Layout belongs to the selected setting and ring-size range | Stone map with quantities and calibrated dimensions |
| Engraving | Text, font and position | Original input, normalized value, font ID/version, placement ID, rendered path revision | Allowed characters, grapheme limit, fit envelope and content policy | Approved vector/path or machine instruction plus literal text |
| Size | Market label and fit option | Sizing system, displayed code, internal circumference/diameter, profile, tolerance, resize policy | Design, stone layout and engraving remain manufacturable at that size | Target measurement, profile and tolerance with method named |
| Price | Displayed total and breakdown | Currency, price-list revision, component IDs, taxes/fees state, quote expiry | Server-side eligibility, inventory and pricing authority | Order total, component values and approval timestamp |
| AR | Preview mode and asset | Asset revision, physical units, anchor mode, device/runtime result | Scale, tracking, occlusion, fallback and disclaimer pass | No manufacturing authority; retain as experience evidence only |
This structure separates what the shopper calls an option from what the business must know about it. It also makes dependencies inspectable. A stone can be unavailable because the head does not support its dimensions, a finish can be unavailable for one alloy, and an engraving can fail because the usable inner-band arc shrinks at a particular size. Those are different conditions and should not be collapsed into a generic “not available” message.
Model each rule response with an outcome, reason code, affected fields and recovery path. “Choose a smaller stone for this setting” is actionable; silently clearing the stone is not. Preserve the last valid state while the buyer reviews a conflict, and make a deliberate choice before replacing it. The same rule service should validate saved links, restored sessions and cart submissions so an old or edited payload cannot bypass current catalog constraints.
Use two fixture sets during development. The first covers representative valid products, including boundary sizes and the longest accepted inscriptions. The second contains known-invalid combinations: unavailable alloys, incompatible heads and stones, unsupported characters, expired inventory and stale price revisions. Keep their expected rule responses under version control. When an option graph changes, these fixtures reveal whether the team changed a product policy or merely changed the way it is displayed.
Treat material and stone descriptions as product data
Material labels, filters, swatches, the 3D view, cart line and order confirmation should all resolve to the same canonical record. That record should distinguish solid alloy from plating or coating, identify the represented fineness or composition, and carry any regional disclosure fields required for the sale. Stone data should distinguish the represented product, origin category, treatment, dimensions, weight and grading system rather than relying on a color name alone.
For US-facing marketing, the FTC Jewelry Guides apply to claims made through words and depictions. They warn against misrepresenting material aspects including metallic content, size, weight, treatment, price and value, and they address clear disclosure of certain gemstone treatments.[1] Treat that as a legal-review trigger, not a complete global compliance checklist. The configuration schema needs market-specific copy and approval ownership because another sale region may use different terminology or disclosure rules.
A swatch is navigation, not proof of composition. Keep a visible text label beside it, expose the relevant product detail before purchase, and persist the selected material ID into the order. If a live stone is inventory-backed, store the inventory or certificate reference separately from the reusable visual material. The visual can represent a category while the order selects one physical stone; pretending those are the same record creates avoidable substitutions.
Build macro realism as an acceptance test
Jewelry is examined at close range, so a useful viewer needs deliberate camera stops for the setting, prongs, stone table, band profile, finish and engraving zone. Macro viewing also exposes errors that a distant beauty angle hides: floating stones, intersecting claws, softened edges, incorrect thickness and an inscription that clips into a setting.
The glTF 2.0 specification defines an API-neutral runtime asset format and a metallic-roughness physically based material model.[5] Its ratified transmission extension exists because alpha coverage cannot represent clear transmissive materials in a physically plausible way.[6] Khronos also ratified a dispersion extension that adds wavelength-dependent color separation to the volume transmission model.[7]
Those capabilities do not guarantee a convincing gemstone in the chosen browser, lighting setup or device. Lock the runtime and extension support first, then approve named reference views for metal color, roughness, reflections, transmission, stone color, dispersion restraint and contact between stone and setting. Pair the interactive view with calibrated product photography or approved renders where exact appearance is commercially important. A depiction that enlarges a stone can also create a disclosure problem under the FTC guidance, so show dimensions and scale plainly instead of letting the macro camera imply physical size.[1]
Make engraving a validated production input
An engraving field is part text editor, part geometry tool and part order data. Preserve the shopper's original input for review, but validate a normalized production value. Unicode defines grapheme clusters around user-perceived characters, which is a better basis for a customer-facing limit than counting code units.[3] Unicode normalization forms give canonically equivalent text a consistent representation; NFC is widely recommended for web content interoperability.[4]
The project still needs an explicit supported repertoire. A font may lack a glyph, a combining mark may collide, an emoji may not belong in the production process, or right-to-left text may need shaping the renderer and engraving software do not share. Test the exact font file and version used for preview and path generation. Store the original string, normalized string, grapheme count, font ID, placement, depth or process option, generated path revision and approval image.
Validate both syntax and business meaning. OWASP distinguishes syntactic validation from semantic validation and recommends checking untrusted input early.[10] Here, syntax covers length, characters and control-code rejection; semantics covers whether the inscription fits the selected band, placement and manufacturing method. Recheck on the server even when the browser preview looks correct.
The interaction must work without dragging around the model. WCAG 2.2 requires keyboard-operable functionality, text identification of detected input errors and programmatically determinable status messages.[9] Give the engraving field a visible label, announce fit or validation changes, identify the exact problem in text, and keep the 3D camera as optional confirmation rather than the only way to discover a clipped inscription.
Keep ring size connected to geometry
Size cannot remain a cosmetic dropdown. ISO 8653:2016, which ISO lists as current, specifies a ring-size measurement method using a defined ring stick and a size designation.[2] A commerce catalog may also need market labels outside that designation. Store the displayed system and code alongside the manufacturer's approved metric target, inside profile, tolerance and measurement method. Do not rely on an unversioned conversion table at checkout.
Changing size may affect more than the inner diameter. It can alter band thickness rules, stone spacing, pavé count, engraving arc, setting proportions, weight and price. Decide which dimensions scale, which remain fixed and which require a separate model or production route. For every size family, approve the smallest, middle and largest supported states plus any boundary where a stone layout, inscription limit or process changes.
Give price its own authority
The 3D scene should display a price result, not invent one. Price services should receive canonical option IDs and return the eligible currency, component values, tax or fee state, price-list revision and expiry or revalidation rule. The server must recompute the configuration before cart or quote creation. Never trust a total or hidden option value returned by the browser.
A useful price breakdown mirrors the causes the buyer can control: base design, alloy or weight band, center stone, accent layout, finish, engraving, size adjustment and service options. It should also distinguish an orderable total from a provisional estimate when inventory, stone selection or manual production review is unresolved. The same rule response can explain why a choice is unavailable instead of leaving the 3D layer to guess.
Separate AR placement from virtual try-on
AR has at least two jewelry jobs. Object placement can show a ring or pendant at physical scale on a surface. Virtual try-on must track a finger, wrist, ear or neck, maintain pose, handle occlusion and calibrate apparent size against a moving body. A surface-placement launch is not evidence that try-on works.
Google's Scene Viewer documentation, checked on 31 August 2026, described web-hosted glTF/GLB viewing on supported Android devices, used one glTF unit as one meter for true-scale placement, and allowed AR resizing by default unless the launch disabled it.[8] That default matters for jewelry: an experience that lets a shopper pinch-scale a ring should not be described as a fit check. Lock or clearly signal scale where the runtime permits it, record the asset units, and test a known physical reference.
For body-attached try-on, define device classes, tracking entry, calibration, occlusion, lighting response, left/right handling, lost-tracking behavior and a non-AR fallback. State what the preview can and cannot establish. It may help someone judge style and approximate proportion; ring size still comes from the approved sizing path, and material appearance still needs the product evidence described above.
Freeze a production handoff, not a screenshot
The order needs one immutable configuration ID and revision. At submission, resolve every selected ID, derived rule result, price response and generated artifact into a human-readable review plus a machine-consumable record. A screenshot can help approval, but it cannot carry alloy composition, stone identity, tolerance, normalized inscription or rule provenance.
A minimum handoff should contain:
| Handoff group | Required record | Acceptance owner |
|---|---|---|
| Identity | Configuration ID, schema version, design revision, timestamps and market | Commerce/product owner |
| Materials | Alloy, fineness/composition, finish or plating, stone IDs, treatment/disclosure fields and certificates | Merchandising/compliance |
| Geometry | Approved CAD/manufacturing revision, setting, size target, profile, tolerances and stone map | Jewelry engineering/production |
| Personalization | Original and normalized text, font/version, placement, generated path and signed preview | Customer service and production |
| Commercial | Currency, price components, tax/fee state, price-list revision, payment/quote state | Commerce/finance |
| Evidence | Render thumbnail, selected camera views, rule validation result, exceptions and approver | QA |
Run a preflight that reloads this frozen record into the viewer and compares the reconstructed state with the approval render. Then validate the production export independently. The cabinet configurator playbook owns dimension-heavy module, hardware and BOM logic; the shoe configurator playbook owns panel, colorway and footwear personalization decisions. Jewelry needs its own metal, stone, sizing and inscription contract rather than copying either handoff.
Scope the first release around one accountable product family
Choose a representative family with enough variation to expose the hard rules: several metals, at least two stone shapes, a meaningful size range, one engraving zone and one real production route. Freeze the option graph and exception policy before multiplying assets. Acceptance should cover rule validity, text and keyboard operation, macro reference views, server price recomputation, cart/order reconstruction, sizing boundaries, AR fallback and production readback.
Double Edged's owned Spellexo case study is relevant proof of product strategy, UX, 3D production, engineering, testing, launch and ongoing operation. It is not jewelry-specific outcome evidence, and it does not supply a conversion, returns, rescue or migration claim. A jewelry configurator still needs discovery around its actual catalog, disclosures, manufacturing constraints and commerce stack.
If the rule graph, 3D asset system, price service and production handoff need to be designed together, the custom 3D product configurator service is the commercial route. Bring one representative product family, its option data, sizing method, price ownership and sample production output. That is enough to test whether the first release can stay narrow without hiding the work that makes an order manufacturable.
