White Paper and Roadmap

Abstract

Computer-aided design is a foundation of modern engineering, yet creating geometry is only one part of the job. Real work also needs requirements, component relationships, validation, revisions, manufacturing considerations and traceability across a product's life.

AI is changing how engineers use design software. Natural-language interfaces lower the effort of creating a model, and agents may coordinate larger tasks. A plausible model does not prove that a design meets its requirements, that an analysis survives a change, or that the surrounding engineering information is complete.

NitoCAD starts with AI-assisted CAD generation: describe a supported design in plain English and get parametric geometry. The architectural direction goes further, toward a persistent, revision-aware engineering state that links designs to requirements, components, interfaces, validation evidence and change dependencies. AI should work on that structured, traceable state instead of treating the CAD model as the whole project.

This paper covers the problem, the proposed solution, the architecture, the operating principles, the development plan and the long-term vision. It separates what exists today from what is still being built.

The problem

Geometry is not the complete deliverable

A 3D model describes shape. An engineering deliverable usually carries much more:

Functional requirements, dimensions and tolerances
Material specifications and component interfaces
Assembly relationships and design configurations
Drawings and manufacturing information
Analysis inputs, results and verification evidence
Revision history, manufacturing and inspection records

These pieces depend on each other. A model can be geometrically valid and still fail a functional requirement. A drawing goes out of date when the model changes. An analysis stops applying when its geometry or material assumptions move.

Fragmented engineering information

Information lives across CAD files, simulation tools, spreadsheets, documents, databases and PLM systems. That causes five recurring problems.

Disconnected information: Requirements and decisions are not linked to the components they govern.
Revision uncertainty: Teams cannot easily tell which evidence belongs to which version.
Change propagation: A change in one component needs updates elsewhere, but the full set of dependencies is hidden.
Interoperability limits: Moving between CAD tools keeps geometry but weakens design intent, object identity and relationships.
Manual coordination: Engineers hunt for affected documents, rerun analyses and confirm downstream status by hand.

The limits of AI-generated CAD

An AI system can misread a requirement, pick the wrong parameter, produce an incomplete model, or return something that looks right and misses the constraints. A success message from a generator is not engineering verification. A geometric validity check does not show that a part can carry its loads or be made by a given process.

For AI to support consequential work, the system has to separate proposed actions, executed operations, validated results and unresolved questions.

The missing connection

The core gap is a dependable link between geometry and the information that gives it meaning. NitoCAD's thesis is that an engineering platform should keep an authoritative, revision-aware record of:

What the design contains
What it is meant to satisfy
How its components and interfaces relate
What has been verified
Which evidence applies to the current revision
What a proposed change affects
What is still uncertain or needs human approval

The NitoCAD approach

NitoCAD combines natural-language input, computational CAD, structured engineering data, validation tools and change intelligence in one architecture. It works on three levels.

Geometry generation

Describe a supported design in plain English. NitoCAD finds the parameters, builds parametric geometry, runs applicable checks and offers supported exports. The geometry layer uses CadQuery on the OpenCASCADE kernel.

Engineering state

A design becomes part of a project that holds requirements, components, interfaces, revisions, validation records and dependencies, with the relationships between them preserved as the project changes.

Agent-driven execution

Over time, an engineering agent can take a high-level goal, plan the work, call supported tools, record results, flag affected dependencies and ask for approval where needed. Its autonomy stays bounded by tools, permissions, policy and the evidence it can obtain.

The aim is controlled automation inside a traceable engineering system, with no promise of unrestricted automation.

Product principles

One engineering state: AI workflows, manual design operations and supported integrations all act on the same project representation, so there are never two inconsistent versions of the truth.
Explicit uncertainty: Missing information stays missing until it is supplied, derived by a proper process or settled by a documented decision. User-specified, confirmed, derived, inferred, missing and ambiguous values stay distinct. Inference never silently becomes authoritative data.
Evidence before claims: If an analysis was not run, the system does not imply it passed. A requirement with no verification evidence stays unresolved.
Controlled changes: Proposing, executing, validating and accepting a change are separate steps. Released revisions are immutable, and later changes become new revisions or controlled proposals.
Interoperability without false equivalence: External tools do not all represent or preserve information the same way. Where something cannot be read or mapped reliably, NitoCAD says so.
Human responsibility: Consequential approvals follow proper review and authorization. Automation should make project state easier to understand and should not hide uncertainty behind a confident interface.

Architecture

NitoCAD is organized in connected layers that form one engineering system.

Experience layer

Web for projects, AI interaction, design workflows, reports and collaboration. Desktop-oriented tools for precise geometry work and assemblies. Mobile for monitoring, voice input, review and approvals. Extensions for connecting outside tools. The immediate priority is improving the existing web experience.

AI and agent interface

Turns instructions into explicit engineering tasks: interpretation, planning, tool selection, execution, progress reporting and error handling. A language model may propose actions, and the engineering runtime controls execution.

Engineering Semantic Core

Shared definitions for requirements, components, parts, assemblies, geometry, features, materials, interfaces, configurations, drawings, manufacturing information, validation evidence, provenance and revisions.

Engineering State Graph

Records relationships between those objects. A requirement applies to a component, the component sits in an assembly, the assembly appears in a drawing and is analyzed under a simulation setup. That makes it possible to trace from requirement to evidence and to find what a change touches.

Interoperability and fidelity contracts

Separates three questions. R (representation): what geometry is available and what changes can be detected. N (native read): what an external system or adapter can actually retrieve. S (semantic binding): which external objects match which NitoCAD entities. Geometric similarity does not prove identity or design intent, so each relationship is recorded as confirmed, inferred or unresolved.

Impact and change intelligence

Finds affected requirements, components, drawings, analyses and manufacturing records, and decides whether existing evidence still applies to the current revision. The practical question it answers: if this design changes, what else must be reviewed, updated or verified?

Validation, policy and commit

Governs the move from proposed action to accepted state through permission checks, controlled tool execution, validation, evidence recording, revision management, approvals, release controls and audit trails.

Release and external systems

Controlled exchange with CAD, PDM, PLM, ERP and manufacturing systems such as Teamcenter, Windchill and Arena. Each integration needs its own build, testing, permissions and fidelity assessment. Intent to support a system does not mean its connector is in production.

The LLM proposes. The runtime permits. Engineering tools determine truth. Evidence records it. Humans approve when required.

How a design moves through NitoCAD

Take a user asking for a mechanical mounting component. A supported workflow runs in seven stages. How far a given release gets through them depends on what is implemented and enabled.

Interpret the request
Extract the stated requirements, flag missing or ambiguous details, and keep user-specified values apart from assumptions and derived parameters.
Construct the design
Generate geometry through the supported CAD pipeline and tie the model to its project and parameters.
Validate the geometry
Run the implemented geometric checks, such as invalid solids or missing geometry. Passing them does not establish mechanical safety.
Evaluate requirements
Where a suitable, validated analysis workflow exists, evaluate the requirement under defined loads, materials, boundary conditions and acceptance criteria, and record what was actually evaluated. If the tool or evidence is missing, report the limitation.
Record the engineering state
Connect the design, requirements, validation results and revision into a traceable record.
Export the deliverable
Produce supported files. File created, file integrity verified and engineering accepted are three separate outcomes.
Evaluate later changes
Identify affected dependencies and which evidence needs refreshing, so an old result is never assumed to apply to a new revision.

Engineering evidence and change management

Requirements and verification

A requirement has a status and a link to the objects and evidence that verify it. It is not satisfied because a model exists or a task finished. Closure depends on evidence for the relevant revision and on confirmation where policy requires it.

Evidence freshness

Evidence carries one of five states, so uncertainty is never shown as success.

State	Meaning
FRESH	The evidence applies to the current revision.
STALE	A change means the evidence may no longer apply.
UNAFFECTED	The change was evaluated and the evidence still applies.
UNKNOWN	The system cannot confidently tell whether it applies.
MISSING	Required evidence is not available.

Change-impact analysis

If a component's mounting interface changes, the system may need to examine connected interfaces, assembly relationships, drawings of that interface, analyses using the geometry, requirements on the component and manufacturing steps tied to the feature. Not everything related is automatically invalid. The impact engine sorts dependencies into affected, unaffected and needs further investigation.

Revision integrity

Evidence names the revision and inputs it applies to. Changes to the current design never silently rewrite the history of a released revision. That supports reproducibility, review and accountability.

Cross-CAD interoperability

NitoCAD aims to complement the CAD and data-management tools organizations already use, so nobody has to replace them.

External geometry and metadata

An adapter may expose geometry, object identifiers, parameters and metadata. What is available depends on the external system, its API, permissions, file format and the adapter. NitoCAD publishes capability limits and does not assume full access.

Identity and semantic relationships

Stable native identifiers can support identification. Without them, geometric correspondence offers a candidate match, and a candidate match alone never becomes a confirmed binding. Ambiguous relationships stay unresolved until confirmed.

Operating modes

The external CAD tool is authoritative for geometry while NitoCAD manages requirements, dependencies, evidence freshness and change-impact reports.
NitoCAD is authoritative for the relevant engineering state.
A dual-authority arrangement, which needs explicit rules for ownership, sync, conflicts and release.

Implementation strategy

Build one production-quality external CAD integration before attempting broad coverage. It should show access to supported native information, reliable revision comparison, object binding, change-impact reporting, evidence freshness and documented limitations. More adapters follow when users ask for them and a maintainable path exists.

The AI-native engineering agent

The long-term vision moves from single components to whole engineering workflows, with the agent coordinating several tools against one consistent state.

Task decomposition: Break a high-level goal into explicit steps, find the dependencies and decide which steps need user input or outside tools.
Tool-grounded execution: Describing how to run an analysis is different from running it. Generating a drawing is different from verifying its dimensions. The execution record lists what was done and what came back.
Human approval: Explicit review stays in place for accepting changes to released designs, resolving important ambiguities, approving consequential requirements, releasing safety-critical deliverables, confirming uncertain external bindings and authorizing sensitive external operations.

Bounded autonomy

Level	What the agent does
Assistive	Interprets requests and proposes actions.
Supervised execution	Carries out supported tasks and presents results for review.
Controlled automation	Runs predefined workflows within explicit permissions and policies.

Higher autonomy depends on shown reliability, tool coverage and risk controls.

Domain expansion

Mechanical engineering comes first. Other disciplines arrive as explicit domain packs, each providing the objects, relationships, rules, adapters and validation workflows that discipline needs.

Mechanical: Parts and features, materials, assemblies, interfaces, drawings, mechanical requirements, geometry validation, and applicable simulation and manufacturing checks.
Electrical and electronics: Components, connections, schematics, PCB relationships and matching verification. These need their own representations and tools, beyond extending mechanical geometry generation.
Architecture, engineering and construction: Buildings, spaces, walls, doors, windows, levels, roofs, stairs, site information, drawings and compliance workflows. Any code or structural-compliance claim needs authoritative rules, project inputs and proper verification.
Other candidates: Civil and structural, robotics, aerospace, automotive, manufacturing systems, and systems and controls. Each is judged on technical feasibility, demand, standards and validation needs.

Roadmap

These are planning targets set in October 2026. Dates are targets and not guarantees.

Oct to Nov 2026

Product foundation and reliability

Make geometry generation more dependable, improve STEP, STL, DXF, IGES and PDF exports, strengthen regression testing, improve error reporting, verify current capabilities, and set up release and rollback procedures.
Nov to Dec 2026

Engineering state and Semantic Core integration

Connect designs to structured projects, link requirements to supported objects, add dependable revision records, tie validation evidence to revisions, and bring the existing Semantic Core into real user workflows.
Dec 2026 to Jan 2027

End-to-end engineering agent

Task planning, tool orchestration, multi-step workflows, controlled execution, reviewable proposals, engineering reports, and explicit handling of failed and incomplete tasks.
Jan to Mar 2027

Assemblies, drawings and change intelligence

Assembly workflows, drawing generation and revision management, engineering dependencies, evidence freshness and change-impact reports.
Mar to May 2027

Production cross-CAD integration

One real external CAD adapter with native capability discovery, object identity and binding, revision comparison and cross-CAD impact analysis.
May to Sep 2027

Broader engineering workflows

More complete agent workflows, wider analysis and manufacturing integrations, selected domain packs, mobile and collaboration improvements, and broader lifecycle evidence.

A feature counts as shipped only when it has been implemented, tested, checked for engineering correctness where relevant, verified for state integrity, made accessible to users, verified in deployment and documented. Having code or passing unit tests is not enough.

Current product status

This section keeps public claims honest. Capabilities fall into five tiers, and only the first is a statement about the live product.

Tier	What it covers
Live	Natural-language parsing, a library of 25 CAD templates, geometry generation with geometry-focused validation, and export to STEP, IGES, DXF, PDF and STL, built on CadQuery and OpenCASCADE.
Built and tested internally	Agent runtime and validation foundations, the Semantic Core, the engineering-state architecture, and cross-CAD contracts with a mock adapter used for testing.
Integrating or verifying	Connecting the engineering-state work to real user workflows, as laid out in roadmap phases 1 and 2.
Planned	Assemblies, drawings, change-impact reports, the end-to-end agent and a production cross-CAD adapter.
Research	Additional domains, broad PLM integration and higher levels of agent autonomy.

A mock external CAD adapter is not a production integration with a commercial CAD system. An analysis framework does not mean every type of analysis is implemented, validated or ready for production use. Internal milestones should not be read as proof that every advanced capability is in the public app.

Adoption strategy

The plan is to grow from an accessible design-generation entry point into a fuller engineering workflow.

Initial value: natural-language generation removes the friction of creating supported geometry and lets people start with an idea.
Expansion: once a design exists, NitoCAD adds persistent project records, requirement relationships, revision management, validation evidence, change-impact analysis, assemblies and drawings, and external CAD interoperability.
Professional workflows: teams that need traceability, controlled changes, reliable evidence and integration with existing systems.
Distribution: the website, engineering communities, technical content and demos, partnerships, open-source components where they fit, CAD integrations and team deployments.

The commercial opportunity depends on delivering this with enough quality and reliability to earn trust. Business model and pricing should come from customer research and product usage and should not be assumed in advance.

Differentiation

AI geometry generation is an entry point. The intended difference lies in the relationship between geometry and engineering state, in four parts.

A common engineering state, where geometry, requirements, revisions and evidence are connected objects.
Revision-aware evidence, with validation records tied to the revisions and inputs they apply to.
Change-impact intelligence that finds which dependencies a change may affect.
Controlled AI execution through bounded tools and policies, never treating the agent's own explanation as proof.

This is a product thesis. It has to be shown through implementation, customer adoption and measurable performance, and it is not an established competitive advantage until then.

Safety, security and trust

Engineering software can influence physical products and infrastructure, so reliability and safety are architectural concerns.

Validation limits: Every validation workflow states what was tested, which inputs were used, which acceptance criteria applied and what remains unresolved.
Access control: Project access and sensitive operations are governed by permissions. As collaboration grows, ownership, roles, approvals and organizational boundaries need clear rules.
Data protection: Users may submit proprietary models. Data handling, storage, retention, deletion and third-party processing are documented in the Privacy Policy and must match what the application actually does.
Provenance: A record that an action happened does not prove the action produced a correct result.
Responsible autonomy: AI-generated changes stay reviewable, and autonomy follows tool reliability, task type and the cost of failure.

Long-term vision

NitoCAD's goal is an AI-native engineering environment where users describe increasingly complex objectives and the system coordinates supported workflows from requirements through design, verification and controlled release.

In a future workflow, a user might request a complete mechanical product. The agent would find the requirements, plan the work, create supported engineering objects, coordinate specialized tools, record validation results and produce documentation. The engineering state would keep the links between the original request, design decisions, geometry, revisions and evidence, and would point out unresolved requirements and where expert review or outside validation is needed.

Reaching that point takes continued work on geometry, engineering semantics, tool integrations, evidence management, change intelligence, usability and safety controls. The path is evolutionary: build on the current product, integrate the engineering architecture, and widen the set of tasks NitoCAD can reliably perform.

The future of AI-native engineering includes maintaining authoritative engineering state and letting AI operate on it responsibly. NitoCAD is being built toward that.

Links and contact

Document status: product and architecture white paper. Roadmap items are forward-looking plans and not guarantees of delivery. This document describes NitoCAD's product direction and intended architecture. It is not an engineering certification, investment recommendation, guarantee of product performance or commitment to deliver every proposed feature. Confirm current functionality against the deployed product.

From geometry generation to authoritative engineering state