← All projects

05 · Python · FastAPI · React

heating-ring-pipeline

锦珂 (GIENKEE) heating-ring design automation: a customer's layout-diagram JSON goes in, and a full production package — BOM, winding programs, sheet-metal DXF — comes out.

Jinke Energy Co., Ltd. (GIENKEE) · Founder/CEO
Real winding spec and CNC program table rendered by the pipeline
Actual production-package output — the winding-spec and CNC-program table, rendered from a real sample spec (024C302) through the live pipeline, not a mockup.

Jinke Energy (brand name GIENKEE / 锦珂) makes heating rings, and every order used to start from a hand-filled spec sheet. This pipeline takes a layout-diagram JSON ({machine, specs}) and derives everything downstream through deterministic calculation engines: bill of materials, winding parameters and CNC winding programs, and sheet-metal DXF, merged into a single production-package PDF plus DXF. It runs as a web UI (three-step wizard: new project → upload spec JSON → render and download) or a CLI, and the core workflow — layout JSON in, production package out — runs end to end today.

Reading the spec off the customer's own PDF

Customers hand over layout diagrams as PDFs, often scans with no text layer and sometimes password-protected. A newer ingestion module feeds those PDFs to Gemini for structured extraction, producing the same {machine, specs} JSON that a hand-filled spec would — so the result goes through the identical downstream validation and rendering path, with no separate parsing code to maintain. Every extracted JSON is still checked against the same deterministic schema validator that hand-filled specs use. Where Gemini isn't confident about a field — a dimension is obscured, or two layout options are hard to disambiguate — it still fills in a best guess, but records a {"field": ..., "reason": ...} entry in a top-level _review array. Validation and rendering never read that array; it exists purely so a person can scan it before trusting the extraction.

What's deliberately not built yet

The project's own docs are explicit about scope, and I'd rather repeat that here than overstate it: there's no automated .docx intake for the customer information sheet, no independent "rules engine" module (the BOM/winding/sheet-metal derivations are deterministic formulas living directly in their calculation modules), no SolidWorks two-way sync, and no single-file distribution that skips a Python/Node install. The calculation engine itself has been reverse-derived from one machine series so far; other series don't have real parameters yet.

Design principles

The calculation engine is pure deterministic formulas with no model inference, fully overridable and fully offline. PDF extraction is the one place an LLM touches the pipeline, and its output is never trusted directly — it's validated the same way a human-entered spec would be, with uncertainty surfaced rather than hidden.