One Set of Tools. Any Workflow You Configure.
Every Studio application and every custom Enterprise process is built from the same powerful set of reusable tools, assembled by a workflow configuration. This page explains how that works, and how you or your partners can extend it.
The Core Idea
Tools + Workflow Configuration = A Studio
Cloud CAD is built around a focused set of reusable geometry tools — import, align, measure, generate, review, export, and more. A workflow configuration is a JSON document that defines which tools are available, what order they run in, what states they save, and how they're laid out for the end user. A Studio application is simply a workflow configuration rendered through a shared delivery component. Transtibial Studio, AK by Numbers Studio, and AFO Studio are three different workflow configurations running on the exact same engine — not three different codebases.
Reusable, single-purpose operations
The JSON configuration that orders and connects tools
A workflow configuration delivered to end users
Transtibial Studio, AK by Numbers Studio, and AFO Studio are three different workflow configurations running on the exact same engine — not three different codebases. When a new Studio ships, it ships as a new configuration, not new software.
Delivery Model
Every Studio Is a Web Component
Studio applications are delivered as a custom web component. The component accepts a workflow configuration identifier as an attribute, along with tenant and runtime context, and retrieves the actual workflow configuration from the server at runtime. This means the same underlying component can render an entirely different Studio experience just by pointing it at a different workflow configuration — no new client code required.
- One web component, many workflow configurations
- Configuration is retrieved from the server at runtime
- New Studios ship as configuration, not new software
Web Component
<workflow-oandpcad-workspace
workflow-id="transtibial-v2"
workflow-case-id="case-00142"
workflow-user-id="user-8821"
workflow-template-id="tpl-default"
/>
<workflow-oandpcad-workspace
workflow-id="ak-by-numbers-v1"
workflow-case-id="case-00143"
workflow-user-id="user-8821"
workflow-template-id="tpl-ak-standard"
/>
Workflow vs. Template
Defines which tools exist, what order they run in, and how they connect. Set once per Studio.
Defines the starting values a clinician begins from. Saved per-tool, reused across cases.
Reusable Templates
Templates Are Saved States, Not Separate Configuration
Within a workflow, any tool's state can be saved as a reusable template — a default set of values an end user or organization saves for reuse across future cases. Templates are distinct from the workflow itself: the workflow defines what tools exist and how they connect; templates define the starting values a clinician begins from.
Extending the Platform
Two Ways to Build a Tool
Every tool on the platform — ours or a partner's — implements the same tool contract, so it can be dropped into any workflow. There are two supported integration patterns.
JavaScript Tool API
For interactive, client-side tools that need low-latency access to the canvas, geometry state, and UI — alignment, trim lines, measurement, real-time preview. Best suited to anything that needs to feel instant.
REST API Tool
For server-side tools — AI inference, external system integrations, and long-running or asynchronous work. Best suited to anything that requires backend compute, external data, or processing time.
Adapter pattern: A REST API tool can be wrapped in a lightweight JavaScript adapter, so it appears and behaves like an interactive tool in the UI while the actual work runs on the server. This is how AI-powered tools stay responsive without requiring every partner to build client-side code.
Partner & Third-Party Development
Build Your Own Tools on the Platform
Third parties and enterprise customers can build and publish REST API tools today — this is the most open and accessible way to extend the platform. JavaScript tools are available through a sandboxed SDK for approved partners in controlled environments, since they run closer to the core client experience.
- REST API tools — open to any third-party developer
- JavaScript tools — sandboxed SDK, approved partners only
- All tools use the same contract, regardless of who builds them
Access Tiers
Any third-party developer. Standard HTTP — no special SDK required.
Sandboxed SDK. Runs closer to the core client experience — controlled access for approved partners.
All tools — ours or a partner's — implement the same interface and can be dropped into any workflow.
What Gets Built
Real Examples of Platform Tools
AI Model Inference
Call a custom or built-in AI Factory model as a step in any workflow
Scanner Import
Pull a scan directly from a connected 3D scanner
Patient Record Import/Export
Sync case data with an EHR or patient records system
Manufacturing Export
Send a finished design to a print farm or CNC mill
The Payoff
Configuration, Not a Fork
Because Studios and Enterprise workflows share the same tools and the same tool contract, extending the platform never means forking it. Enterprise customers can add their own tools, reconfigure a workflow, or wrap an AI model built in the AI Factory into the same Studio experience their clinicians already use — without a separate codebase to maintain.
See the Architecture in Action
Talk to our team about building a custom tool, workflow, or integration on the platform.