Approach
Manufacturing geometry deserves stricter engineering than marketing software. A wrong dimension is wasted plate and machine time, so every system here is built to be checked, repeated and handed over.
How the work is built
-
Requirements and acceptance criteria, written first
Before any code: what goes in, what must come out, and how we will know it is right. Acceptance cases come from your own past jobs with known-good outputs.
- A one-page requirements note you approve.
- Two to five real orders chosen as acceptance cases, with their existing drawings as the expected result.
- The things deliberately out of scope, written down so they cannot drift in later.
-
Rules captured
Every rule the system will apply is inventoried: where it came from, who owns it, what it assumes, and where it contradicts another rule.
- Source: a standard, a spreadsheet cell, a designer’s habit, a shop practice.
- Owner: the person on your side who can say the rule is right.
- Gaps and contradictions are reported, not guessed around.
-
Build
Domain logic is separated from the interface, so the same rules can drive an Inventor add-in, a batch generator or a browser tool. Outputs are deterministic and carry a version tag.
- Same inputs, same file, byte for byte — no timestamps, no randomness in generated geometry.
- A generator-version comment in every exported file, so a part can be traced to the code that made it.
- Assumptions stated next to the geometry they describe, not in a manual nobody reads.
-
Verify
Three independent routes to the same answer: hand-derived golden cases, read-back with software that did not write the file, and — where a real CAD seat is involved — opening the output in it.
- Golden cases derived by hand: the 3-4-5 cone gives exactly 216°; the developed arc equals the true circumference; metric and imperial inputs produce identical millimetre geometry.
- Every DXF fixture read back and audited with ezdxf 1.4.4 — version, units, entity counts, layers, no zero-length or zero-radius entities.
- Renderer-parity suites: the preview and the exported file are produced from the same drawing, so they cannot disagree.
- A second, independent implementation where the geometry is the product (see the fabrication generator study).
- Visual review of generated documents. Automated checks once passed a bend table clipped at row 21 of 23; a person looking at the PDF found it.
-
Hand over
Source, tests, rules documentation, user guide, training, and a release record. The system does not need its author permanently attached to it.
- Your designers can change a rule, re-run the regression suite and release — without calling anyone.
- A release record per delivered version: what changed, how it was tested, how to rebuild it.
-
Support
Rules change; the regression suite stays green. A monthly allocation of hours, a change log, and an annual rules review.
The verification flow, and the reports behind it
The diagram is how every tool on this site is checked. The figures below it are measured from this repository, not typed in.
Measured, from this repository
- 1,193 automated tests across 39 test files — geometry, DXF, contact handling, headers and page content — all passing at the last release (regenerated by
npm run proof, 2026-09-16). - 37 DXF fixtures read back and audited with ezdxf 1.4.4 — full report in the fabrication geometry core study.
- A ten-file acceptance package, one file per tool family, opened in Autodesk Inventor and AutoCAD on 2026-08-10: scale, units, layers, orientation and key dimensions confirmed against the manifest.
- Renderer-parity suites for every tool: preview and DXF are produced from the same drawing.
Read the reports
- Fabrication geometry core — the ezdxf audit and the acceptance package, with the exact commands that regenerate them.
- Fabrication Generator — 1,078 checks across four independent methods, including a second implementation in a different language and eight external calculators.
What is not claimed: that a physical part has been made from any of these files. The validation is mathematical, file-format and real-CAD. Your shop verifies before cutting.
Validation in proportion to what the software is for
Not every tool needs the same evidence. What matters is that the level is chosen on purpose and written down.
| Category | Examples | If it is wrong | Minimum verification | Records |
|---|---|---|---|---|
| Convenience | File renaming, batch export, report formatting | Inconvenience | Unit tests; smoke test | Release note |
| Productivity | Drawing generators, template fillers, BOM assemblers | Rework, wrong quantities | Golden-file tests; regression from past jobs; drawing-standard checks; visual review sample | Acceptance report |
| Calculation | Developed lengths, bend tables, weights, geometry solvers | Wrong dimensions or values relied on | Hand-derived golden cases; invariants; an independent second implementation; stated assumptions and tolerance | Verification report; method note |
| Deliverable-generating | Drawing sets, DXF for cutting, data packages | Scrap, machine time, late delivery | All of the above plus read-back with software that did not write the file; real-CAD acceptance; deterministic-output proof | Verification report; acceptance package; release record |
| Relied on for design decisions | Sizing and selection tools, code checks | Safety or economic harm | All of the above, and the responsible engineer approves the method and the acceptance criteria; usage limits in the tool; version-locked; periodically re-validated | Plus the engineer’s review record |
Where engineering responsibility sits
Ruthen Systems is a design-automation and technical-systems practice, not a licensed professional engineering practice. Engineering decisions — whether a design is adequate, safe or compliant — belong to the responsible engineer on your side or a licensed engineer you retain. Ruthen builds the software and the technical work product, verifies that it does what was agreed, and documents it so that engineer can review it. Nothing produced here is a certification, approval, stamp or sign-off.
In practice that means: outputs from an automation module or production system go through exactly the check and approval step your drawings go through today. Where a rule is an engineering judgment, the rules inventory says so and names its owner on your side. Where a project would need a licensed engineer's approval and you do not have one, that is raised before quoting, not after.
The free tools on this site are planning and fabrication aids; the tool disclaimer applies to everything they produce.
What every project leaves behind
| Record | Contents |
|---|---|
| Requirements note | What goes in, what comes out, what is out of scope. Approved by you. |
| Rules inventory | Rule, source, owner, assumptions, status, test. |
| Acceptance cases | Your past jobs and their known-good outputs. |
| Test and verification reports | What ran, against what, with the results. Regenerated per release. |
| Release record and change log | Version, date, changes, reproduction steps. |
| Handover pack | Source, build instructions, user guide, training notes. |
Want the work done this way?
Send one example of the job you keep redoing. The first reply says whether it is worth automating and, if so, what the acceptance cases would be.