System model

What to keep in mind

• LogiDraft generates drawings from evaluated block logic rather than manually authored geometry.
• The core flow is inputs to logic to outputs, with one evaluated model driving everything.
• Documents contain sheets and block definitions, while sheets place visible instances into drawing space.
• Blocks, parameters, variables, and block references stay connected throughout evaluation.

Why the model comes first

LogiDraft is a system where drawings are generated from reusable block logic rather than manually authored geometry. It is not CAD with automation added afterward. The drawing is the result of 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. The drawing updates 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. Drawing 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.

How data flows through the system

A document is the top-level model. It contains sheet definitions, block definitions, document settings, and artifact-related metadata. Sheets are the drawing spaces where geometry and block references are placed.

Sheets hold visible instances of the system. Block definitions hold reusable behavior. The document ties both together.

• 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: shared definitions keep the same system model consistent across many documents.

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 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 another manifestation. 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 see this system model play out in a real document, use Help or open the Mounting Plate example. For exact field and expression syntax, use Reference.

Keep exploring