How Outlier3D replaced manual CAD work for a high-volume engagement ring product family

At a glance

Client	High-end jewelry manufacturer (collections and custom orders)
Product family	Engagement rings, 70%+ of sales
Before	15 minutes to several hours of manual CAD per order
After	Seconds of compute plus the operator’s input time
Capacity	Partial adoption already matched a full-time designer’s output for this family

1. The situation

A high-end jewelry manufacturer producing both collections and custom orders was scaling quickly. Its engagement ring product family represented the majority of sales (70%+) and had become the operational bottleneck. Every incoming order introduced variations: finger size, stone dimensions, prong and basket configurations, pavé patterns and special requirements. Each one meant a manual rebuild.

Demand was rising and the catalog was growing, but the company did not want to hire more 3D designers. The goal was to automate the engagement ring production cell so the existing designers could focus on higher-value work: custom orders, exceptions and new collections.

2. The starting point

Before automation, the team worked from a reference-based SKU library stored on a local server. When an order arrived, a designer pulled a similar reference model and rebuilt the geometry to match the new specs. That worked at low volume, but became fragile at scale for two reasons.

The standards were not really standards

The manufacturer had strong design intent, but much of it lived as implied rules in designers’ heads, passed on informally to new hires instead of being documented or enforced in CAD. Different designers could interpret the same SKU differently. Over time, small deviations accumulated: proportions, curvature, clearances and manufacturing-critical assumptions.

Order inputs were not always clean

Upstream specs varied in quality and completeness, which increased rework and made scaling with more people even harder.

• Time per SKU ranged from about 15 minutes to several hours, depending on complexity and the clarity of the specs.
• Errors happened at the order level (wrong order numbers, missing specs) and at the geometry level (wrong height, thickness or curvature).
• Files were named consistently, but the geometry standards behind them were not encoded anywhere.

Hiring would only have multiplied interpretation drift. The system needed one shared, enforceable definition.

3. Standardize before you automate

Automation depends on explicit standards. The first phase turned tacit design intent into documented rules. Working directly with the production team, we:

• Identified what must stay consistent across engagement ring variants
• Resolved conflicting reference models into a single authoritative standard
• Defined measurable rules for proportions, tolerances, clearances and component relationships
• Documented edge cases and how exceptions are handled

The result became a design contract for the product family: what may vary, what must stay fixed, and how manufacturing constraints are enforced. Standardization paid off even before rollout, with cleaner and more consistent output from the design team.

4. Turning rules into parametric logic

Once the standards existed, we encoded them into rules that reproduce reliable geometry across every variation:

• Shank curvature behavior across finger sizes
• Prong and basket behavior relative to stone size and cut
• Connection logic so adjacent elements always meet cleanly and stay manufacturable
• Distances and clearances required for casting, setting and assembly
• Aesthetic proportion rules that used to be eyeballed

Real orders need flexibility, so we also defined controlled flexibility: which relationships can stretch for custom stones, which constraints stay strict, and which cases need dedicated parameter sets.

5. How the system is built

Each SKU family has a dedicated parametric definition that regenerates geometry and outputs from structured inputs. Some SKUs need a single input (finger size). Others accept custom stone dimensions, configurable patterns, order-specific controls, or files such as a stone scan in STL.

Definitions are assembled from reusable modules, which shortens iteration time and isolates changes:

• Profile generation
• Shank generation
• Stone adaptation (prongs and basket adapting to stone size and cut)
• Pavé distribution
• Output packaging (geometry, metadata and export rules)

6. From order to production files

Once deployed, every order follows the same deterministic path:

1. The user selects a SKU from the production-ready library.
2. The app shows the inputs that SKU needs.
3. The user enters the parameters.
4. Inputs are validated, and incompatible combinations are rejected early.
5. Outlier3D computes the full geometry, including approved exceptions.
6. Outputs are generated in the formats each team needs: CAD files, STLs, previews and structured data such as stone counts and production notes.
7. Results are named and packaged consistently, tied to the exact inputs that produced them.

Every definition goes through internal testing, extreme-input testing, client review of the standards and final approval before it reaches the client’s Outlier3D account.

7. Adoption

Early adoption had predictable friction. Designers used to manual modeling first saw automation as extra steps. Adoption accelerated once two things became true:

• Standards were enforced. Interpretation drift disappeared and outputs were consistent every time.
• The speed became undeniable. Designers could generate variants dramatically faster and skip rework loops.

At that point Outlier3D stopped feeling like new software and started feeling like the faster way to do production.

8. Before and after

Before Outlier3D, throughput was bounded by manual labor, interpretation and rework.

With Outlier3D, generation time drops to seconds of compute plus the operator’s time to enter parameters. Consistency improves because every variant comes from the same definition.

Failures change nature too. Instead of silent geometry drift, the remaining issues are visible upstream problems: invalid inputs, missing specs, impossible dimensions. Those are detectable early and fixable systematically.

Even partial adoption already covered output comparable to a full-time designer for this product family.

9. Challenges we solved

• Conflicting legacy references: normalized into one enforceable standard per family.
• Standards living in people’s heads: turned into documented rules with the production team.
• Edge-case stones: controlled flexibility within approved bounds, plus flags for extreme inputs.
• Performance on complex geometry: modular design, targeted optimization and isolating expensive operations.

10. Takeaways

• Standardization enables automation by turning intent into enforceable rules.
• Parametric definitions remove interpretation drift across designers.
• Centralized outputs reduce friction between departments.
• Design decisions stop living in people’s heads and become systems: scalable, auditable and repeatable.