Project
Where the model context lives. Project name, bound Systems, files and references, notes, version history, validation reports, and export history. Project is the memory of the model.
Docs · StudioThe private workspace
The private workspace
where models become
structured.
Studio is where a model starts as an idea, file, prompt, or imported object — then becomes a structured, configurable CAD model with parts, parameters, materials, validation, outputs, and publishing options.
Studio in contextStudio connects
Studio connects
to the full lifecycle.
Studio is private by default. A project becomes public only when you explicitly share, publish, or connect it to a public surface.
The Studio workflow
Create or import→Structure the model→Configure parameters→Review parts & materials→Validate→Export or publish
The workflow is not always linear. A model may go through several rounds of editing, validation, repair, and review before it is ready to move forward.
Interface
Six workspaces.
Studio is organised into six workspaces — six views of the same project, each covering one stage of the work.
Create
Where the object is authored and shaped. The 3D view, the model's parameters, its parts and materials, and the code that builds it. This is where a model comes into existence and gets refined.
Assemble
Where parts become a whole. Place instances, define constraints and mates between parts, and work on the assembly rather than a single component.
Configure
Where you decide what someone else gets to change. Expose the parameters that matter — width, height, material, count — lock the internals, and preview the configurator a buyer would see.
Motion
Where the model moves. Author assembly sequences frame by frame, show how something goes together, and render it out as animation or video.
Make
Where the project becomes output. Named parts, materials, cut lists and sheet nesting, dimensioned drawings, and fabrication exports. Make does not mean fabrication-approved — it means the model is organised for review and output.
Getting startedFive ways to
Five ways to
start a project.
Start from a System
Every model begins on Open Design — the base knowledge, suited to concepts, one-off objects, and imported model cleanup. Named Systems for specific trades are in development; when one matches your work you'll bind it and inherit its parts, rules, and conventions.
View Systems →Start from a prompt
Describe the object clearly. A strong prompt includes the object type, rough dimensions, material assumptions, important features, constraints, and output goal. Specific prompts produce more useful first drafts than open-ended requests.
Open Studio →Start from an example
Examples show correct System selection, expected structure, useful parameters, part naming, and output format. Use examples from Docs and System pages to learn from real workflows.
Read Docs →Start from uploaded files
Reference images, sketches, PDFs, drawings, manuals, CAD files, imported geometry, or markdown instructions. Assign clear file roles so people and agents know how each file should be used.
Start from an imported model
Real work often begins outside Axle Keys. Import a SketchUp model, STEP file, DAE, OBJ, STL, DXF, or other reference. Imported geometry may need cleanup — the goal is to turn imported information into structured project context.
ParametersThe controls
The controls
that matter.
Parameters allow a model to change without being rebuilt from scratch. They turn a static model into a configurable object.
What makes a good parameter
Good parameters are understandable, named clearly, connected to visible changes, constrained to safe ranges, and appropriate for the user. Internal values can exist — they should not be exposed as public controls unless they are genuinely useful.
Good: Cabinet Width: 36 inBad: internal_offset_x_07: 1.375
Parameter changes before code changes
If a model already has good parameters, change the parameters before changing code. Parameter changes are safer, faster, easier to validate, and easier to undo. Use code changes when the model structure itself needs to change — adding new parts, fixing broken geometry, changing System structure, or exposing new parameters.
Three parameter tiers
- —Internal — Used by the model, agent, or System logic. Construction offsets, hidden clearances, formula values.
- —User — Used by the Studio user. Cabinet width, shelf count, frame height, material thickness.
- —Public — Used by Exhibition or Showroom visitors. Customer-friendly size, finish, layout, visible options.
Parts, materials, and outputsFrom model
From model
to useful output.
A buildable object is more than an outside shape. Studio should expose the parts, materials, and outputs that make a model useful.
Parts review
- —Part names and dimensions
- —Material assignments and quantity
- —Repeated parts and missing components
- —System-specific naming conventions
- —Orientation and spacing
A model can look correct while still having incorrect parts.
Materials
- —Sheet-good thickness, grain direction
- —Extrusion profiles and hardware
- —Finish options, edge banding
- —Material assumptions visible before outputs are used
- —System-specific fabrication assumptions
Outputs
- —Dimensioned shop drawings — SVG, PDF, DXF
- —Cut lists with sheet nesting on real stock
- —3D exports — STEP, STL, DAE
- —Assembly animation and rendered video
- —An embeddable live configurator
Fabrication-aware vs ready
- —Fabrication-aware: model includes useful parts, dimensions, materials, and output structure
- —Fabrication-ready: reviewed and approved for a real fabrication process by someone qualified to build it
- —Studio can help create useful outputs — physical objects still require human review
Don't label a model fabrication-ready unless it has been properly reviewed.
Validation
Validation helps identify problems before a model moves forward. It may include build status, syntax errors, geometry errors, missing parts, invalid parameters, material warnings, System-specific warnings, and fabrication-readiness notes. Validation does not replace professional review — it is one layer of review.
Drafts, versions, and repair
When an agent or user makes a meaningful change, stage it as a draft when possible. The safest workflow:
Draft→Validate→Promote
A good repair process reads the error, inspects the current model, identifies the smallest fix, creates a draft, validates, and promotes only if the fix works. Avoid rebuilding the whole model when a small repair is enough.
AgentsStudio is designed
Studio is designed
for agent workflows.
Every Studio action can be called by an agent through MCP — read project context, create drafts, validate changes, update parameters, and run export jobs.
Read context→Create draft→Validate→Promote→Review→Export
What agents can do
- —Read project context and active model
- —Interpret files and create modeling plans
- —Expose parameters and update model code
- —Validate drafts and repair failures
- —Prepare exports and document changes
- —Publish models
Safe agent permissions
- —Read-only — always available
- —Create draft — recommended default
- —Update parameters — explicit only
- —Run validation — always recommended
- —Promote draft — requires review step
- —Publish content — explicit only
Agent best practices
- —Agents should not blindly overwrite live models
- —Use drafts; validate before promoting
- —Focused changes are easier to verify
- —Ask the agent to explain changes made
- —Roll back if the change is unexpected
- —Review validation before promoting
PublishingPrivate by default.
Private by default.
Public on purpose.
A model can move to public surfaces when the user chooses. Publishing should make visibility, ownership, and file exposure clear.
Exhibition
Public discovery — useful to someone browsing the platform. Review title, description, public preview, System label, public parameters, and whether any private files are hidden.
Showroom
Customer-facing product presentation — more controlled than Exhibition. Review public product name, customer-facing description, public parameters, material options, inquiry workflow, and whether the product is ready for customer interaction.
Best practices
and common fixes.
Work the right way
- —Start simple — one working model beats a complex broken one
- —Use the right System for the object type
- —Give uploaded files clear roles
- —Change parameters before changing code
- —Review parts before exporting outputs
- —Validate before promoting any agent change
- —Keep public controls simple — not internal logic
- —Save versions before major changes, publishing, or agent edits
- —Do not label a model fabrication-ready unless it has been reviewed
Common issues
- —Model doesn't build — check recent code changes, invalid parameters, syntax errors, or validation report
- —Parameter changes break the model — check allowed ranges, formulas, or dependent dimensions
- —Imported geometry is hard to edit — may need cleanup, naming, or rebuild as native parametric geometry
- —Outputs look wrong — check System selection, material thickness, part names, and version number
- —Agent changes are confusing — ask what changed, why, which files were affected, and whether it's staged or live
Keep reading
Ready to
start building?
Open Studio, choose a System, and create a configurable model. Or read the FAQ if you have questions about how the platform works.