Skip to main content

Terminology & Execution Model

This document defines how key technical terms are used within the ClassCAD documentation and explains the execution model and behavioral assumptions of the system.

Its purpose is to establish clear expectations, ensure consistent language, and avoid misunderstandings when discussing architectural and technical properties of ClassCAD.

Deterministic Execution​

Meaning in ClassCAD

Deterministic execution refers to the predictable and reproducible execution of CAD logic within the ClassCAD runtime.

Given:

  • the same API calls
  • the same input parameters
  • the same model state
  • the same ClassCAD version and plugins

ClassCAD will:

  • execute the same code paths
  • apply the same model state transitions
  • produce equivalent CAD model states

Determinism applies to:

  • API behavior
  • execution order
  • model history and structure
  • business and CAD logic implemented in cclasses

Determinism and Geometric Behavior​

Deterministic execution does not imply mathematically exact or perfectly robust geometric computation.

Like all solid modeling systems, ClassCAD relies on an underlying solid kernel that operates with:

  • floating-point arithmetic
  • numerical tolerances
  • kernel-specific robustness strategies

In rare or extreme geometric edge cases (e.g. degenerate geometry, near-coincident faces, tolerance limits), geometric results may be affected by these numerical constraints.

This behavior is inherent to solid modeling and does not contradict ClassCAD’s deterministic execution model.

Reproducible Model State​

Reproducibility means that a CAD model can be recreated reliably by re-executing the same sequence of API calls or CAD logic.

ClassCAD supports reproducibility through:

  • deterministic execution
  • explicit model state management
  • persistent storage formats (e.g. OFB)

Reproducibility is a core architectural goal of ClassCAD and applies across:

  • backend services
  • automation pipelines
  • interactive client applications

CAD as Code​

When ClassCAD documentation refers to CAD as code, it means:

  • CAD logic is expressed as executable, versionable code
  • design intent and rules live in cclasses
  • CAD behavior can be tested, reviewed, and evolved like software

This does not exclude file-based workflows.

ClassCAD fully supports persistent CAD models that can be:

  • stored
  • loaded
  • modified
  • exchanged

Files are used for persistence and exchange, while code defines how models are created and modified.

API Stability​

ClassCAD exposes stable, long-lived APIs.

This means:

  • external integrations rely only on public API methods
  • internal model representations may evolve
  • API contracts remain stable over time

API stability is a key requirement for enterprise and long-term solutions.

Controlled Execution Environment​

All CAD logic in ClassCAD runs inside a controlled runtime environment.

This execution model ensures:

  • predictable system behavior
  • isolation from client environments
  • protection of intellectual property
  • safe deployment in cloud and enterprise contexts

What ClassCAD Provides​

Within its defined execution model, ClassCAD provides:

  • deterministic execution of CAD logic
  • predictable API behavior
  • reproducible model state transitions
  • controlled and isolated execution
  • stable public APIs

What Is Outside the Execution Model​

The ClassCAD execution model does not include guarantees for:

  • mathematically exact geometry in all edge cases
  • infinite numerical precision
  • interactive user experience (this is the client’s responsibility)
  • geometric robustness beyond the capabilities of the underlying solid kernel

Summary​

ClassCAD is designed around a well-defined execution model that emphasizes:

  • determinism
  • reproducibility
  • predictability
  • automation-first behavior

At the same time, it explicitly acknowledges the practical realities of numerical geometry and solid modeling.

This balance between clear architectural semantics and technical honesty is fundamental to ClassCAD’s design.

Plugin vs. Service Library​

In ClassCAD, the term plugin refers to an internal, system-level extension of the ClassCAD runtime.

Plugins extend the runtime with domain-specific capabilities such as solid modeling, constraint solving, or import/export functionality. Technically, these plugins are implemented as native service libraries that register service functions with the runtime.

Important clarifications:

  • Plugins are developed and maintained exclusively by the ClassCAD team
  • Plugins are not a third-party extension or scripting mechanism
  • Application developers do not write or deploy plugins themselves
  • From the perspective of ClassCAD applications, plugins are accessed only indirectly via the runtime and cclasses

The term plugin is used because it accurately reflects the architectural role of these components: optional, replaceable, and runtime-bound extensions of the core system.

The alternative term service library appears in some technical contexts to emphasize that plugins provide well-defined, internal services rather than user-facing extension points.