System model

What to keep in mind

• LogiDraft generates project outputs from evaluated block logic rather than manually authored geometry.
• The core flow is inputs to logic to outputs, with one evaluated model driving everything.
• Projects open in the Document Workspace, where Sheets and Local Definitions hold visible instances and project-scoped behavior.
• The Library opens in the Engineering Library, where Global Blocks are managed for reuse across projects.
• Blocks, parameters, variables, and block references stay connected throughout evaluation.

Why the model comes first

LogiDraft is a system where project outputs are generated from reusable block logic rather than manually authored geometry. It is not CAD with automation added afterward. The visible result is generated from evaluated logic.

The core model is inputs to logic to outputs. Parameters describe variation. Logic inside blocks determines computed values, active state, visible geometry, and repeated or transformed content. Project outputs update from that evaluated model.

A useful way to think about the system is:

• Block definitions define behavior.
• Block references execute behavior.
• Logic defines relationships.
• Evaluation executes those relationships.
• Outputs are derived from evaluated instances.

Blocks are the core unit of the system. They are where logic, parameters, states, lookup tables, directives, and reusable geometry live. A single block definition can drive many block references, each with different inputs but the same underlying behavior.

The same evaluated model also drives outputs. Geometry, bills of materials, schedules, flat table exports, and hierarchical JSON all come from the same resolved block data. Visible results and output data stay aligned because they come from one system rather than separate manual processes.

Why this becomes important in real systems

• It creates a single source of truth for both geometry and production-facing data.
• It removes duplication between drawings, schedules, and external spreadsheets.
• It makes system-wide changes predictable because the evaluation engine resolves one shared model.
• It matters most when a design has repeated subsystems, variant-driven behavior, or generated outputs.

In practice, this is what prevents a model from drifting into separate drawing logic and reporting logic. A control panel, part family, or repeated assembly can remain coherent because the system is authored once and evaluated consistently.

Where Projects and Library fit

The Dashboard is the top-level management surface. It contains Projects and Library. Projects are the user-facing work items users organize and open. A Project currently corresponds to a .ldoc document for import, export, and storage.

Projects open in the Document Workspace. The Document Workspace contains Home, Sheets, and Local Definitions. Home is the control center for opening sheets, opening definitions, and using project-level actions.

Library opens in the Engineering Library. The Engineering Library contains Home and Global Blocks. Global Blocks are Library-scoped reusable assets that can be inserted into projects.

How data flows through the system

A Project is the top-level user-facing work item. It contains Sheets, Local Definitions, project settings, and output-related metadata. Sheets are the drawing spaces where geometry and block references are placed.

Sheets hold visible instances of the system. Local Definitions and Global Blocks hold reusable behavior. The Project ties those pieces together in the Document Workspace.

• Defined in Blocks: block definitions define behavior and parameters accept inputs.
• Related by Logic: logic defines relationships between inputs, derived values, states, and injected fields.
• Executed in Evaluation: evaluation executes those relationships inside each block reference.
• Scaled through Composition: nested references let whole systems be built from smaller systems.
• Exposed through Outputs: geometry and data are parallel results of the same evaluated system.
• Sustained through Reuse: Global Blocks keep the same system model consistent across many projects.

The important bridge is that the evaluation engine sits between authored behavior and realized results. Inputs enter through parameters and reference context. Logic resolves meaning. Evaluation turns that meaning into geometry and outputs.

The drawing is the result, not the source

The most useful mental model is to treat LogiDraft as a system engine that happens to produce drawings, not as a manual drawing surface that happens to contain some formulas.

In that model, the authored source of truth is the block logic and the evaluated instance data. The drawing is one manifestation of that system. Artifacts are structured outputs generated from the same model. Neither is the master copy on its own.

This perspective helps explain why a change to one input can update visible geometry, labels, classifications, and output rows all at once. The system is being reevaluated, not partially patched.

Geometry and data resolve from the same evaluated state

The important subtlety is that geometry does not resolve first and outputs second as separate processes. Both depend on the same resolved parameters, variables, selected state, and nested evaluation context.

This means the engine can keep geometry and data aligned even when logic becomes layered. A block can compute dimensions, select a state, pass values into nested blocks, and then expose those same resolved values to output generation without translating between disconnected representations.

It also means errors and fallbacks affect the whole system consistently. If a value falls back to a default, that fallback influences both the visible result and the structured outputs generated from that result.

Ways to think about a complete system

• Use one block definition to describe a part family, then vary instances by parameter input.
• Let nested assemblies push shared logic downward instead of copying formulas into many places.
• Drive outputs from the same resolved model so schedules and drawings stay synchronized.

A mounting plate is a concrete example. Width, hole spacing, and accessory choices enter as inputs. Logic derives actual dimensions and placements. Evaluation realizes the drawing, and outputs can expose the same resolved values as structured data.

To use this model in the workspace, start with Getting Around the Workspace. To see it applied, open the Mounting Plate example. For exact field and expression syntax, use Injection Syntax.

Related pages