← Just Build It — the deck · evidence document

3D Fork — Visual Intent → Editable Geometry → Engineering Handoff

Not "AI generates production-ready shoe CAD from an image." The fork studies where AI-generated 3D actually has value inside a footwear design process, when the representation must change, and when the geometry must be handed back to a designer or an engineer.

One-sentence definition

The 3D Fork carries an approved 2D design state into space in staged, gated steps — concept mesh for volume judgment, editable geometry for design correction, and an explicit handoff to real footwear engineering — while measuring at every conversion how much of the approved design intent survived.

The three questions this fork must answer

1. Does the 2D design intent actually enter the 3D? Not "does the mesh look like a shoe" — does the mesh preserve the views, proportions and part relationships a designer already approved?
2. Does the AI mesh help a designer judge volume, or does it merely look cool? A mesh that lets a designer reject a direction in thirty seconds is a success even if the topology is garbage.
3. How much human labor sits between disposable mesh and editable design geometry? Measured in minutes per region, not asserted.

If these three are answered with documented runs, the fork stands as an independent case. Everything else in this document is scaffolding for answering them.

Position in the system

The fork branches off the approved 2D design state — the same state the F-battery produces and the harness measures. It is a tool-side extension (left loop): new workflows, new nodes, same contracts. The Log Node discipline, human gates, and lineage rules carry over unchanged.

What already exists in this repo (the fork is not starting from zero):

The ladder: four levels, four different product questions

L1, L2, L3 are three different product problems, not three quality settings of one problem. Naming the level names the question, the representation, and the judge.

Each representation is only useful for a specific design decision — the verb column is the on-screen vocabulary; the L-numbers stay in the technical layer.

L3 is an explicit non-goal. Real footwear engineering starts from a digital last and proceeds through on-last design, flattening, 2D patterns, grading, and tooling — a different domain with its own systems (Shoemaster, Romans CAD class). The fork's last stage is a handoff package, not a manufactured shoe. This is not a weakness; it is the boundary statement: I know where my tool should stop.

Stage map

                 APPROVED 2D DESIGN STATE
                          │
                ┌─────────▼──────────┐
                │ 3D-00 Prepare      │  locks / preserves / interpretation
                │ 3D Design State    │  freedoms, scale reference, lineage
                └─────────┬──────────┘
                          │
                ┌─────────▼──────────┐
                │ 3D-01 View Pack    │  consistent views, not six pretty
                │ (consistency, not  │  images — cross-view agreement is
                │  generation)       │  the deliverable
                └─────────┬──────────┘
                          │
                ┌─────────▼──────────┐
                │ 3D-02 Scale /      │  known length, width/height ranges;
                │ Volume Envelope    │  generation is not free-form
                └─────────┬──────────┘
                          │
                ┌─────────▼──────────┐
                │ L1 Concept Mesh    │  provider-agnostic:
                │ GenerateConceptMesh│  Tripo / Hunyuan / Rodin / future
                └─────────┬──────────┘
                          │
                ┌─────────▼──────────┐
                │ ProjectionCheck    │  deterministic fidelity report —
                │ (triage, not veto) │  runs BEFORE the human gate
                └─────────┬──────────┘
                          │
                ╔═════════▼══════════╗
                ║ HUMAN PROPORTION   ║  reject → back to 2D. A fast,
                ║ GATE               ║  confident reject is a SUCCESS.
                ╚═════════╤══════════╝  No mesh repair before this gate.
                          │ approve
                ┌─────────▼──────────┐
                │ L2 Region          │  2D semantic regions → coarse 3D
                │ Separation + SubD  │  regions; QuadRemesh → SubD cage →
                │ rebuild            │  designer edit → selective NURBS
                └─────────┬──────────┘
                          │
                ┌─────────▼──────────┐
                │ L3 Handoff Package │  mesh + regions + view pack +
                │ (non-goal beyond)  │  design state + known limits
                └────────────────────┘

Two rules the diagram encodes:

• No mesh repair before the proportion gate. Retopo, cleanup and surface fitting are only spent on geometry a designer has approved. If the heel is wrong, every minute of cleanup was waste.
• ProjectionCheck triages, the designer decides. The number shows where the mesh drifted from the approved views; approve/reject remains a human judgment. The check never vetoes.

3D-00 — the 3D Design State

This is where the fork separates from one-click image-to-3D. Before any generation, the approved 2D state is compiled into an explicit contract:

DesignState3D {
    approved_views          // the identity-locked pack
    semantic_regions        // from F04 layer manifest (SAM3)
    locked_regions          // must not change
    preserved_regions       // approximately held
    editable_regions        // interpretation allowed
    design_intent           // translated feedback, with provenance
    scale_reference         // known length; width/height ranges
    last_reference?         // future: digital last envelope
    parent_iteration        // lineage
}

Example, in designer terms:

LOCK:                collar opening · outsole footprint · eyestay position
PRESERVE ≈:          toe volume · heel proportion · panel boundaries
ALLOW INTERPRETATION: medial secondary details · surface transitions

3D-01 — a consistent View Pack, not six generated images

Six individually attractive views are not a three-dimensional object. The deliverable is cross-view agreement: outsole width agrees between bottom and front; collar opening agrees between top and rear; a named point on the lateral view has a counterpart on the medial view.

Honesty line (enforced in code, must survive into any narrative): six views for review and validation, four for generation. The multiview endpoint takes at most four slots in order [front, left, back, right]; top and bottom are review-only and never feed generation (tripo-view-rules.js:12,24,30).

3D-02 — Scale / Volume Envelope

The common failure of AI 3D is not "can't make a shoe" — it is "made an arbitrary object that resembles a shoe." The envelope is the cheap, deterministic fix: length is known; overall width, sole height and heel height carry known ranges. The mesh is normalized to length and the rest is checked against range. Later, a digital last can replace the box envelope. (Autodesk's canvas-to-mesh work in automotive uses the same logic: multi-view input plus a controlled dimensional envelope, targeted at proportion and volume judgment — not surfacing.)

ProjectionCheck — the fidelity instrument

The fork's own measurement. It extends the project's evaluation philosophy from 2D into 3D, and it is fully deterministic — no VLM judgment anywhere in the loop.

Generated mesh ──→ orthographic renders ──┐
                                          ├──→ per-view, per-region drift report
Approved view pack ───────────────────────┘

Three layers, cheapest first:

1. Registration. Normalize by length, align. Without this every downstream number is noise.
2. Silhouette layer. Mesh projection outline vs approved view outline — IoU plus maximum contour deviation, per view.
3. Region layer. Reuse the F04 SAM3 masks directly: per component (heel, toe, quarter, midsole, outsole, tongue…), how far did position and area drift in each projection? No 3D segmentation needed — the comparison lives in the projection plane.

The question it answers is never "does it look like a shoe" but "how much of the approved 2D design intent does this 3D hypothesis preserve?"

Two instruments, one philosophy

The project now carries two rulers. They must never be conflated.

Shared philosophy: both produce a boundary read as a work order, both refuse to collapse into a single score, and both keep the designer as the final judge. The harness finds where generation stops being useful; ProjectionCheck finds where conversion starts losing intent.

L2 — the deliverable is a labor ledger

The realistic path (Rhino 8): QuadRemesh → SubD cage → designer edits → selective ToNURBS. Not everything is rebuilt, and nothing is rebuilt uniformly — the shoe is partitioned by geometry requirement:

The research output of L2 is not an automated retopo pipeline. It is a ledger: minutes of human work per region, which regions QuadRemesh handles, where the cage must be rebuilt by hand, where SubD is never enough. The ledger is the evidence that the stage was done, not diagrammed. (Mesh→BRep conversion is deliberately not the default path: converting succeeds technically and still yields thousands of unusable faces — "editable" is a property of the rebuild, not of the conversion.)

Agents: one, and only one

No "3D Agent — fix my shoe." The single agent seat in this fork is interpretation — and it is the existing translate node (LLM + guardrails) aimed at the 3D region schema, not a new component:

"heel feels too bulky, but keep the tension here"
        ↓  interpretation (existing translate node)
{ region: heel, preserve: [collar_connection, midsole_transition_front],
  modify: rear_volume, direction: reduce, amount: moderate }
        ↓  deterministic node / CAD command executes

Geometry operations are performed by deterministic nodes or the designer — never by the agent.

3D-P — Physical Reference Fork (deferred)

Gaussian splatting belongs in a separate fork: physical prototype → phone capture → splat → free-viewpoint review → compare against the approved digital concept. It closes the loop design intent → geometry → physical sample → digital feedback. It is appearance, not CAD — a particle/radiance representation with no surface, edge or component semantics — and it enters this project only when a physical sample exists to capture. Until then it is a named slot, not a page.

MVP — one documented run

The MVP is a single chain, run once, end to end, on one shoe, fully logged:

approved side concept → consistent view pack → scale envelope → concept mesh
→ ProjectionCheck report → human approve/reject → region separation
→ editable SubD → manual adjustment → handoff package

Evidence discipline (same as the F-battery): every step writes a LogRun sidecar — prompt, seed, model, workflow id, source-asset ids; only designer-approved assets feed the next stage. The run must produce, at minimum:

• the ProjectionCheck report (numbers, not adjectives) — answers question 1;
• the gate decision with time-to-decision — answers question 2;
• the L2 labor ledger (minutes per region) — answers question 3;
• the handoff package: mesh + region manifest + view pack + design state JSON + a known-limits statement.

Honesty block

Unproven until the MVP run exists: ProjectionCheck thresholds are unset (what drift is "acceptable" must come from designer gate decisions, not be invented); the L2 ledger has no numbers; region separation is spec only; no claim is made that any current provider's mesh survives the proportion gate. The one measured fact today: three backends given the same six views produce three different boundaries (deck 14.8). Everything else in this document is a plan wearing its status labels.

Next documents

• 01-mesh-to-subd.md — the L2 deep-dive. Must answer: QuadRemesh failure modes on footwear forms (thin outsole walls, collar opening, tongue gap); the decision rule for region-wise vs whole-mesh rebuild; expected human minutes per step (ledger columns defined before the run); handoff package contents in full.
• 02-projection-check.md — registration procedure, metrics, report format, and the rule that keeps the number from becoming a judge.