Single SourceStudios Engage SSS
Phase 0, on-device, Windows

An on-device CAD converter for .jt assemblies, built to run on one machine, not a cluster.

CadPal takes DWG and DXF drawings and converts them to JT (Jupiter Tessellation) format, entirely on the local machine, for a client project with a real non-technical acceptance tester on the other end.

Electron + Node/Express
318 tests, run offline
CADPAL-Win7-1.1.5.exe, shipping
What it is

A desktop conversion tool, not a cloud platform.

CadPal is an Electron desktop application wrapped around a Node/Express conversion engine. It reads DWG and DXF drawings and writes JT assemblies, running entirely on-device with no dependency on a remote service to do the actual conversion work.

Verified against the code, August 2026

What's actually true right now, corrected from the project's own marketing README

  • The live, working path is Phase 0: an on-device Windows DWG/DXF to JT converter, with zero OpenCASCADE involved. This is what exists and runs today.
  • The cloud path is dead. The deployed Supabase Edge Function returns HTTP 501 for conversion, because the native tooling it depends on (LibreDWG, ezdxf, OpenCASCADE) cannot run on Deno's runtime.
  • The GitHub org is billing-locked, so Actions cannot run, which rules out the cloud CI/CD build path entirely for now.
  • The shipping artifact is a single portable executable, CADPAL-Win7-1.1.5.exe, cross-built from macOS for a Windows 7 SP1 32-bit workstation. It carries LibreDWG, every DLL LibreDWG imports, and a sha256-pinned 32-bit Python 3.8.10 with ezdxf, so the target machine needs nothing installed.
  • Earlier project documents described a multi-architecture "SimAI" platform with a live cloud demo and four platform "Quests." That was aspirational branding, not the build. This page describes what is actually running.
The on-device architecture. Everything runs inside one workstation: an Electron shell starts a Node engine as a hidden child bound to loopback, health-gates it, and injects the port into the user interface. The engine drives the bundled converter tools, which read and write files on the local disk. To the right, the abandoned cloud path is shown severed: the deployed edge function returns HTTP 501 because native converter tooling cannot run on Deno.
The on-device boundary. The engine binds 127.0.0.1 only; the cloud path was removed, not disabled.
How it runs

One machine, one process, health-gated.

The Electron shell spawns the Express engine as a hidden local child process, waits for it to report healthy, then hands the UI its API base address. No network round trip does the actual CAD work.

01
DWG / DXF in
Source drawing, local file
→
02
dwg2dxf, dxf_extract
LibreDWG, then bundled Python and ezdxf
→
03
jt-writer, jt-verify
writes JT 8.1, then parses it back
→
04
.jt out
Jupiter Tessellation assembly
The conversion pipeline. A DWG or DXF enters on the left. Stage one, dwg2dxf from LibreDWG, produces a DXF. Stage two, dxf_extract on a bundled Python with ezdxf, produces the CIG intermediate model. Stage three, jt-writer, writes JT 8.1. Stage four, jt-verify, parses the file back and checks segments, LODs and geometry counts. The output is a verified .jt. A dashed fallback branch rebuilds damaged DWGs from a dwgread JSON dump.
Four local stages. The last one is a proof: the writer's output is parsed back by an independent reader before it is returned.
Not on the active path

An optional native C++ OpenCASCADE (OCCT) bridge exists in the codebase at src/native/occt-bridge/, and a Supabase Edge Function pipeline exists in supabase/. Neither is part of the working Phase 0 conversion path. The OCCT bridge is reserved for a later phase; the cloud function is currently non-functional for the reasons above.

Architecture

Backend, desktop shell, client, in one repo.

Four layers, cleanly separated: an Express engine, an Electron shell that owns process lifecycle, a React client, and a set of Python helpers for the drawing-format edge cases.

LayerTechnologyLocation
Backend engineNode.js + Expressserver.js, src/routes, src/controllers, src/services
Core JT logicBinary engine, TOC parser, kinematics, property atomssrc/lib/jt-forge/
DWG/DXF pipelineFormat conversion into the JT writersrc/lib/dwg-pipeline/
Desktop shellElectron, contextIsolation on, nodeIntegration offelectron/main.js
ClientReact + Vite + Tailwindclient/ → client/dist
Native bridge (reserved)C++17, OpenCASCADE (OCCT), node-gypsrc/native/occt-bridge/
Format helpersPython, DXF extraction, STL/STEP conversionscripts/dxf-extract, scripts/stl2step.py
Data storeSupabase Postgres (RLS) + Storagesupabase/
Test coverage

318 tests, 25 files, fully offline.

The test suite runs entirely against the local conversion pipeline. It needs no Supabase connection and no network access, which keeps it fast and keeps the result honest about what it is actually checking. It includes real-file integration tests: a binary DWG through dwg2dxf, a damaged DWG through the dwgread JSON rebuild, and block INSERTs becoming named child nodes in the output assembly. The figures below are from a run on 2026-08-18, not from documentation.

25
test files
318 / 318
passing, run 2026-08-18
39.32s
wall clock, no network
Where it stands

Shipping on the target hardware, with a gate behind every field failure.

Phase 0 is built, tested and running on the machine it was written for. Getting there took four rounds of field testing on a Windows 7 SP1 workstation, and produced a specific class of bug: the application failed silently on the target while passing on every developer and CI machine. Five of those landed in four days. Each fix is paired with a check that fails the build rather than the customer.

Five failures that were silent on the Windows 7 target, each paired with the build gate that now blocks it: a mis-hoisted dependency blocked by verify-packaged-deps.js, a blank window blocked by a relative Vite base and a Chromium 108 target, a sandboxed preload blocked by disabling the preload sandbox, a converter exiting 0xC0000135 blocked by verify-bundled-dlls.js reading PE import tables, and an unshippable build solved by staging a pinned 32-bit Python from macOS.
Every silent failure on the target, paired with the gate that now refuses to ship it again.
Shipped
Phase 0, on device

DWG and DXF to JT 8.1 with zero OpenCASCADE, 318 tests passing offline across 25 files, no cloud dependency on the active path.

Shipped
A Windows executable built without a Windows machine

Frozen Python sidecars needed a Windows box or CI, and the organisation account was billing-locked. A staging script downloads a sha256-pinned 32-bit Python 3.8.10 and ezdxf from macOS straight into the build, which is what made a converting executable shippable at all. The executable grew from 62 to 75 MB.

Passed
Viewer acceptance

Written JT files opened and rendered correctly in JT2Go 13.1.0 and Siemens Process Simulate across six review rounds with a named human tester, with exact scale verified in Process Simulate.

Queued
Two requests from acceptance testing

An installer that lets the user choose a location, since the portable executable self-extracts to Temp, and an export-folder picker.

Built for one acceptance tester, one machine, one real drawing.

Not a platform demo. A working converter, proven on the hardware it actually has to run on: 19,210 entities in a single architectural DWG, 0 skipped, 217k triangles, 156 of 156 hatches.

Client project, in acceptance testing

Products

Open source

Deep dives

Whitepapers

Company

Single Source

Every number on the dossier and whitepaper pages traces to a file path or command output in the source tree.

LinkedIn Facebook (c) 2026 Single Source Studios (Pty) Ltd