From Import to Edit: Linkoteq’s 3D Editor Update
A code-level update to Linkoteq’s 3D structural editor connects model creation, import, editing, and export through a native Core 0.6 boundary. Here is what changed, what remains unverified, and why it matters for practical workflows.
When a structural model needs to move beyond its first draft
Creating a model is one step. Importing an existing project, editing it without silently discarding information, and exporting it again are different challenges. Structural engineering teams need to know which parts of that journey are supported, which parts are still under development, and what evidence supports each claim.
This week, Linkoteq committed a focused change to the 3D Model editor: a native Core 0.6 exchange boundary for creating starter models, importing compatible model data, applying editor changes, and exporting model JSON. This is an implementation milestone, not a claim that every import format or production editing workflow has passed acceptance testing.
What actually changed in the repository
On November 5, 2026, the 3D Model repository introduced lib/core-v06.ts, an explicit validator and reader for models carrying schemaVersion: "0.6". The validator checks that project metadata and expected model collections exist and that records within those collections have nonempty, unique identifiers. The helper accepts a directly supplied model or one wrapped in a Linkoteq project envelope, and returns the validated native model without discarding optional fields. These are structural data checks, not engineering design verification.
Another change made the starter-model factory return a model labeled Core schema 0.6. A subsequent editor change switched initialization, JSON import, edit validation, and JSON export to the Core 0.6 boundary. Together, these commits establish a more consistent path through the editor's data lifecycle.
Evidence: native editor exchange boundary, starter model schema update, and editor integration for create, import, edit, and export.
An example from concept design
Consider an engineer reviewing the early structural layout of a proposed building. At the proposal or concept stage, a working geometry model may help organize grids, levels, and frame members before detailed analysis and code checks begin. If model creation and subsequent editing use inconsistent data assumptions, even a small change can become harder to trace. A shared exchange boundary is useful because the same basic data contract is checked as the editor imports or changes the model.
The practical opportunity is smoother iteration: a designer can develop an early model, consider alternative layouts, and prepare the next engineering review. However, the present commits do not demonstrate a measured reduction in drafting cost, a verified quantity optimization, or automatic preliminary section sizing. Those outcomes require working features, appropriate calculations, and independent tests before they can be promoted as achieved benefits.
What the update does—and does not—verify
The implementation specifically accepts native Core 0.6 model structure. It does not establish a general-purpose conversion path for arbitrary older models or for SAP2000, ETABS, or STAAD.Pro source files. Separate importers and their mappings have their own development and verification requirements. Model-format compatibility and successful round trips should be verified with representative files, including coordinate units, member identifiers, local axes, releases, load data, and any preserved source metadata that a particular importer promises to retain.
One important limitation is documented by the team itself. A separate November 5 status commit records owner acceptance of this editor migration without new runtime tests. It also identifies deployment verification, production smoke testing, and auditing other application paths as remaining work. That distinction matters: repository changes are evidence that code was written and committed, not proof that the complete feature is working for every user in the live application.
Evidence: owner acceptance and outstanding verification status.
Why an accessible online workflow matters
Linkoteq is developing an online platform for structural engineering calculations and modeling, with a longer-term ambition to make parts of the early design process easier for engineers, architects, project managers, and other AEC professionals. A concept-stage tool could eventually help teams compare structural options and discuss material implications sooner, reducing friction before a fully detailed design is commissioned. That is a product direction, not an already demonstrated engineering or financial result.
The goal is not to claim complete replacement of established analysis software. Detailed structural analysis, code compliance, load assumptions, member verification, and final design decisions remain the responsibility of appropriately qualified engineering professionals. Early-stage convenience and professional verification must work together.
Next verification checkpoints
The next credible milestones are straightforward: complete production build and deployment verification; test native 0.6 import-edit-export round trips with representative models; verify that editor operations preserve relevant geometry and identifiers; and document any unsupported inputs or data-loss risks. Results should be reported with test artifacts and reproducible cases, rather than inferred from a merge alone.
Follow Linkoteq's engineering updates for evidence-backed progress on model creation, structural analysis workflows, and accessible tools for better-informed proposal-stage decisions.