FoldForge

FoldForge turns a plain-language brief into a small, bounded flat-sheet design program.

Comment

Inspiration

Paper and cardstock are cheap, accessible, recyclable, and surprisingly capable materials. But designing a useful foldable object is much harder than simply imagining one. A person may know that they want a phone stand, a storage box, or a moving paper mechanism, but translating that idea into panels, folds, tabs, clearances, and a printable cut pattern normally requires specialized design knowledge.

I built FoldForge to explore a simple question:

Can someone describe a physical object in plain English and receive a fabrication-ready paper design that has been checked before they build it?

What it does

FoldForge is an AI-assisted cut-and-fold design system for paper and thin cardstock.

A user describes an object, including its size, material, purpose, and any required motion. FoldForge then:

  1. Interprets the request as a strict fabrication brief.
  2. Identifies the required physical parts and relationships.
  3. Generates possible foldable structures using deterministic code.
  4. Compiles each candidate into exact panels, folds, joints, tabs, and slots.
  5. Simulates the assembled object and any required movement.
  6. Rejects designs with collisions, invalid geometry, poor clearances, or sheet-fit problems.
  7. Displays only a design that passes the hard verification checks.
  8. Produces synchronized 3D and cut-pattern previews.
  9. Exports the verified design as SVG, DXF, GLB, and canonical JSON.

FoldForge is intentionally not an unrestricted text-to-CAD system. It focuses on a bounded class of flat-sheet objects that can be cut, folded, assembled, and checked computationally.

How I built it

FoldForge separates creative interpretation from geometric correctness.

GPT-5.6 Sol first converts the user's request into a structured fabrication intent. It then produces a topology-free semantic design specification containing information such as:

  • required parts and their roles;
  • acceptable dimension ranges;
  • relationships such as fold, open, close, slide, contain, and lock;
  • material and sheet constraints;
  • motion intent;
  • important visual landmarks;
  • priorities and tolerances.

The model is deliberately not allowed to choose exact hinge edges, fold directions, body roots, packing coordinates, connector geometry, or final transforms.

A deterministic TypeScript synthesis engine owns those decisions. It generates bounded candidate structures, chooses connected panel graphs, evaluates attachment edges, creates tabs and slots, compiles the design, and runs the complete verifier.

The verification pipeline checks:

  • schema and reference validity;
  • connected and acyclic structure;
  • sheet and material limits;
  • panel and connector geometry;
  • assembled dimensions;
  • tab-and-slot containment;
  • static clearances;
  • full motion paths;
  • collisions at 201 sampled motion states;
  • adaptive samples near minimum clearance;
  • export consistency.

The frontend is built with Next.js and React. Three.js and React Three Fiber power the interactive 3D visualization. Zod provides strict model and API contracts. Vitest, Fast-check, Playwright, and GitHub Actions are used for unit, property, integration, browser, and regression testing. The application is deployed on Vercel.

I used Codex extensively during development to inspect the repository, implement bounded changes, create regression tests, and run independent verification passes. At runtime, GPT-5.6 Sol interprets new user requests, while deterministic code remains responsible for the final geometry and validity.

Challenges

Preventing plausible but impossible AI designs

The largest challenge was that a language model could describe a structure that sounded correct but contained an impossible hinge, unreachable connector, or panel collision.

Earlier versions allowed the model to choose too much of the physical topology. A design could look reasonable in JSON while failing during assembly or halfway through an opening motion.

The final architecture solves this by letting the model describe what the object needs, while code decides how the object is physically constructed.

Verifying movement, not only the final pose

A lid can appear valid when fully open and fully closed while still passing through a wall halfway between those states. FoldForge therefore verifies the complete motion range rather than checking only endpoints.

Keeping the search useful but bounded

There may be many possible roots, panel graphs, fold directions, connector edges, and attachment layouts. The synthesizer must explore enough alternatives to find a valid design without creating an unbounded search problem.

I added deterministic limits, structural fingerprints, failure-based rejection, and reusable “nogood” states so equivalent invalid structures are not evaluated repeatedly.

Producing trustworthy exports

The 3D preview, cut pattern, SVG, DXF, GLB, and JSON must all represent the same verified design. Export files are generated from the canonical compiled representation rather than from separate approximations.

Accomplishments that I am proud of

  • Replaced model-authored physical topology with deterministic constraint synthesis.
  • Built a strict boundary between AI interpretation and code-owned geometry.
  • Added full motion and collision verification instead of relying on visual plausibility.
  • Created synchronized 3D and fabrication-pattern views.
  • Produced source-equivalent SVG, DXF, GLB, and JSON exports.
  • Built typed failure reporting for invalid, infeasible, and search-budget-exhausted designs.
  • Added more than 550 automated tests, seeded property testing, browser tests, compiler mutation tests, and export validation.
  • Created a complete playing-card-box acceptance test that begins with a topology-free semantic specification and ends with a compiled, verified, downloadable design.

What I learned

The most important lesson was that AI should not be responsible for every layer of a technical system.

Language models are strong at understanding intent, decomposing an idea, naming parts, and interpreting ambiguous requirements. They are much less dependable as the final authority for exact geometry and physical validity.

The strongest system was therefore not “AI generates everything.” It was:

AI interprets the design problem. Deterministic code searches for a solution. The verifier decides whether it is valid.

I also learned that passing a schema is not the same as creating a buildable object. Physical-design software needs measurable invariants, explicit tolerances, adversarial tests, repeatable compilation, and honest failure states.

What's next

The current system focuses on a bounded grammar of paper and cardstock structures. Future work could include:

  • broader dimension-range optimization;
  • stronger containment and payload-fit verification;
  • more complex multi-part assemblies;
  • better global attachment optimization;
  • support for additional materials and thickness models;
  • richer mechanisms and coupled motion;
  • camera-assisted folding instructions;
  • real-world physical testing against printed prototypes;
  • learning from successful and failed fabrication outcomes without weakening deterministic verification.

The long-term goal is for FoldForge to become a practical bridge between natural-language ideas and objects that people can actually print, cut, fold, and use.

Built With

Share this project:

Updates