EXECUTABLE INTENT: WHY A GEMSTONE IS A PROGRAM, NOT A STATIC MESH

If you open a standard 3D graphics file like .obj or .stl, you find thousands of triangles defined by frozen (x, y, z) vertex coordinates. If you open a classic digital faceting file from the desktop CAD era, you find something slightly closer to the workshop: a list of index gear teeth, mast angles, and fixed decimal center-distances telling the software where each cutting plane stopped.

Both representations record what a finished shape looks like. Neither records why any facet stopped where it stopped.

That distinction sounds philosophical until the first time you try to change a single pavilion angle by two degrees, adapt a quartz cut into sapphire, or turn an evolutionary GPU optimizer loose on a design. The moment one angle moves, frozen coordinates shatter. Meetpoints pull apart, girdles turn into uneven zig-zags, and delicate accent tiers get swallowed whole.

Every crystal render, printable cutting diagram, and optical score on OffTheDop and ProFacet is compiled from a tiny domain-specific notation called FSL (Facet Specification Language). There is no hidden binary mesh behind the scenes. The entire sapphire shown above is this plain-text program:

name = "Turquoise Ripple 562"
ri   = 1.76
gear = 96

// Sacrificial CAM preform establishes the mirrored truncated-square girdle
SquareTrMir(angle = 46.94, truncation = 0.50, offset = 4)

// Pavilion: centerpoint + causal girdle meetpoints
P1 1 @ 43.61 : cp() x8
P2 8 @ 59.02 : gp() xx4
P3 0 @ 64.28 : gp() x4
P4 4 @ 44.29 : gp() x2

// Crown: girdle offset, meetpoints, and an angle-free point-to-point tier (C4)
C1 8 @ 24.62 : gp() + girdle xx4
C2 0 @ 31.73 : gp() x4
C3 1 @ 28.16 : gp() xx2
C4 1         : mp(C2) : mp(C1) x2
T  0 @ 0.00  : mp(C3) x1

assert(stone().isGirdleOK)

Before going any further, let's strip away any software-engineering hype about "inventing a new paradigm." We did not invent the mental model in that file. Human meetpoint cutters like Bob Long and Norman Steele, along with pioneering CAD authors Robert Strickland (GemCAD and GemRay) and Rej (Gem Cut Studio), worked out the physical grammar of modern faceting decades ago.

Listen to how an experienced cutter actually talks at the bench: "Set a 96 gear to tooth 3, tilt the mast to 48 degrees, and cut sixteen mirrored crown breaks until they kiss the P1-P2 girdle corner."

Notice what the human cutter never says out loud: nobody says "grind until the plane sits 0.700412 units from the origin of R3." FSL's entire philosophy was simply to stop serializing dead 3D coordinates and write down the cutter's actual spoken causal rules as executable code. Once you do that, four very practical things happen, and each abstraction reveals its own honest breaking point along the way.

One Sentence Of Spoken Lapidary, Three Readers At Once

Designing a notation for physical craft forces an unusual three-way compromise. Almost every programming language serves one reader well at the expense of everyone else: G-code is effortless for stepper motors and unreadable to humans, while prose bench notes are friendly to humans and useless to a physics solver.

In FSL, every single cut line has to satisfy three completely different readers simultaneously:

1. A human cutter peering through a 10× triplet loupe, who needs discrete gear teeth, real mast angles, and visible crystal corners (mp, gp, cp) rather than floating decimals.
2. A 3D half-space geometry and path-tracing engine, which slices an infinite flat plane across a convex polyhedron in strict chronological order, removing all crystal above that plane just like a real diamond lap.
3. A GPU evolutionary optimizer, which needs to know which angles are free to roam without ever detaching the physical meetpoints that hold the stone together.

Because a flat spinning lap cannot reach inside a crystal to move an isolated vertex, line order in FSL is physical causal history. You cannot aim C1 at mp(P1, P2) until P1 and P2 have actually been cut on the lines above it. There are no mutable variables overwriting old facets behind your back and no hidden GUI constraints: the interpreter starts with an uncut block, executes line 1, executes line 2, and hands you the exact convex crystal left standing on the dop.

Dead Coordinates Are Fossils: Why .753 Shatters

To see why storing raw coordinates is a trap, look at how the exact same Round Brilliant behaves when written in Style I (angle plus decimal depth), the static coordinate style emitted when software records numeric plane distances:

// STYLE I: Frozen numeric plane distances (brittle fossil)
name = "Round Brilliant (Dead Coordinates)"
ri   = 2.42
gear = 96

P1 3 @ 41.0 : cp() xx8
G1 3 @ 90.0 : 1.000
P2 0 @ 39.8 : .75309 x8   // Where P2 happened to stop when P1 was 41.0°
C1 3 @ 50.0 : .75275 xx8  // Crown depths recorded for a sturdy 5.39% girdle
C2 0 @ 38.0 : .61140 x8
C3 6 @ 26.0 : .51137 x8
T  0 @ 0.0  : .28700 x1

At a 41.0° pavilion angle, those numbers produce a textbook 73-facet stone (stone().isGirdleOK == true, a sturdy 5.39% girdle, and 57 clean meetpoint vertices). That 0.75309 depth on P2 looks harmless, even reassuringly precise.

In reality, 0.75309 is a fossil. It remembers where the pavilion main stopped when P1 was 41.0°, after throwing away why it stopped there.

Suppose you pick up a piece of Amethyst Quartz (RI 1.54). At 41.0°, quartz leaks light straight out the pavilion (its critical angle is 40.5°), so you steepen P1 by just 3.6° to 44.6°. Watch what happens to the static file versus Style II (angle plus meetpoint), where the decimal depth is replaced by : gp():

Running that single 3.6° edit on the frozen-depth file in the ProFacet CLI tells the whole story in one diagnostic line: GirdleOK flips to false, all sixteen G1 girdle facets vanish completely (leaving a razor knife-edge where crown facets crash straight into P1), all eight P2 pavilion mains detach from the waist into a tiny stub at the culet, and the vertex count jumps from 57 clean meetpoints to 65 ragged, mismatched intersections.

In Style II, you replace every dead decimal depth with the physical landmark the cutter actually watches under the loupe (gp() and mp()):

// STYLE II: Causal meetpoints (what a human cutter actually executes)
P1 3 @ 44.6 : cp() xx8
G1 3 @ 90.0 : size
P2 0 @ 43.2 : gp() x8
C1 3 @ 47.0 : mp(P1, P2) + girdle xx8
C2 0 @ 36.0 : gp() x8
C3 6 @ 24.0 : mp(C1) x8
T  0 @ 0.0  : mp(C2) x1

Now when P1 steepens, gp() automatically rides down with the new pavilion-girdle corner, C1 shifts with mp(P1, P2) + girdle, C3 follows C1, and the table T follows C2. The stone heals itself because the code describes causal relationships, not a dead snapshot.

Where Even Meetpoints Break, And How Edge Ratios Lock Topology

If this were a marketing brochure, we would stop right there and declare victory. In honest engineering, Style II has a nasty breaking point of its own.

Look closely at P1 (44.6°) and P2 (43.2°) in Style II above. For the eight pavilion mains (P2) and sixteen break facets (P1) to coexist cleanly, P2 must stay slightly shallower than P1 so its plane peels back from the girdle toward the culet. What happens during an automated parameter search, or a naive cross-material edit, if P2 accidentally tilts steeper than P1 (say 43.5° versus 41.0°)?

P2 still obeys : gp() to the letter: it touches the girdle corner, dives steeper into the crystal than P1 everywhere underneath, and grinds all sixteen P1 break facets completely out of existence. Meetpoint syntax kept the girdle level, yet the facet topology still collapsed!

Why did Style II break? Because writing an explicit angle on P2 was still hiding our real geometric intent behind a secondary number. What we actually meant was: "I want the pavilion mains (P2) to reach 76% of the way from the culet up to the girdle, leaving 24% break facets along P1's ridge, regardless of how steep the pavilion gets."

FSL expresses that directly in Style III (point-to-point) by omitting the angle altogether and passing two points: gp() at the rim and ep(edge(...), 0.24) partway along the existing ridge:

// STYLE III: Proportion-locked topology (only TWO master angles in the entire stone!)
P1 3 @ p_angle : cp() xx8
G1 3 @ 90.0    : size
P2 0           : ep(edge(P1:3, P1:9), 0.24) : gp() x8

C1 3 @ c_angle : mp(P1, P2) + girdle xx8
C2 0           : ep(edge(C1:3, C1:9), 0.87) : gp() x8
C3 6           : ep(mp(C2), mp(C2, G1), 0.60) : mp(C1) x8
T  0 @ 0.0     : mp(C2) x1

Look at P2, C2, and C3: there is not a single mast angle written on any of them. Given two points and an index tooth, there is only one flat plane in 3D space that slices cleanly through both landmarks, so the interpreter solves for the exact mast angle automatically (and prints those normal mast angles on the human cutter's bench sheet!).

Test that single seven-tier recipe with a generous 5.39% girdle (girdle = Vector(0, 0, 0.11)) across three radically different minerals by changing only ri, p_angle, and c_angle. Below, compare the bidirectional path-traced crystals alongside exact-same-camera-angle 3D SVG facet meshes for both Quartz cuts (with refraction stripped away so every surviving girdle and pavilion facet is exposed):

Across Quartz, Sapphire, and Diamond, the engine locks the table width at exactly 60.00% to fourteen decimal places, locks the girdle thickness, and preserves all 73 facets without a single tier inversion. You are no longer editing one fragile stone; you are steering an invariant geometric family.

OPTIMIZERS ARE SHAMELESS REWARD-HACKERS: WHY assert() MATTERS

Once a gemstone is an executable program whose meetpoints heal themselves, turning it into a continuous search space takes just a tolerance clause after each angle you want the GPU to explore.

And the very first time you do that without physical guardrails, the optimizer will ruthlessly humiliate you.

Numerical optimizers have zero common sense and zero respect for lapidary tradition. An evolutionary algorithm is a literal-minded genie: give it wide ±16° bounds on a Sapphire Brilliant and ask it solely to maximize face-up brightness, and it will happily invent an uncuttable monster if that monster traps two percent more photons.

We ran that exact experiment using ProFacet's Differential Evolution engine (2,420 GPU ray-traced candidates) on the same 73-facet Sapphire Brilliant, once without assert() statements and once with six plain-text assert() guardrails at the bottom of the file:

// Six executable physical laws appended to the bottom of the FSL search script:
assert(stone().isGirdleOK,           "Girdle must stay level")
assert(stone().tablePercentage >= 50, "Table too small for setting")
assert(stone().tablePercentage <= 61, "Table too wide")
assert(stone().depthPercentage <= 65, "Pavilion too deep for standard head")
assert(stone().girdleThickness >= 1.2 && stone().girdleThickness <= 4.5)
assert(stone().facetCount == 73,      "No tier may be cannibalized")

Look at what the optimizer actually did across those 2,420 candidates in both runs:

And here are both winning crystals rendered side by side at the exact same low-profile camera angle in our bidirectional path tracer:

Look closely at the guarded winner's table width: 50.001%, resting right up against our assert(stone().tablePercentage >= 50) wall. That number is a great reminder of why declarative constraints belong inside the design file itself rather than buried in C++ or Rust engine code. Sometimes you want a zero-table dome (like an Origami Crown Sculpture, a rose cut, or a briolette drop!). Putting assert() directly in FSL keeps the physics engine completely neutral while letting the human designer state the non-negotiable physical contract of this particular stone in six readable lines.

Text Is Not A Religion: Why The Visual Slicer Writes Fsl For You

Whenever programmers build a domain-specific language, there is a temptation to get preachy and insist that real designers should type code into a dark terminal instead of using a mouse.

That is nonsense. Almost nobody wants to stare at a blinking cursor on line 1 when sketching a new gemstone shape from scratch. Spatial intuition, symmetry exploration, and seeing how a new facet slices across an existing crown dome are visual, tactile acts that belong to your eyes and hands.

Code shines at a completely different moment: - When you want to know why tier C3 met C1 instead of guessing from a static mesh. - When you want to switch refractive indices, open search tolerances on four tiers, and add assert(stone().isGirdleOK) in ten seconds. - When you want to email a complete, lossless, 15-line stone in a single URL or git diff two versions of a cut line by line.

That is why ProFacet treats visual slicing and FSL text as two views of the exact same object. When you drag a cutting plane visually in the Interactive Slicer, ProFacet does not save a dead decimal depth behind your back; it detects the three-plane meetpoint under your cursor and writes clean mp() and gp() FSL into the editor live as you click. Edit a number or an ep() ratio in the text pane, and the 3D crystal updates on the next frame.

A gemstone on a real dop is not a frozen sculpture cast in a mold. It is the surviving intersection of a sequence of deliberate human choices on a flat lap. Writing those choices down as executable intent means neither the human at the 10× loupe nor the silicon searching ten dimensions ever has to guess what you meant.