Understand how LogiDraft works

Overview

LogiDraft is a rule-driven system. A drawing is not authored as a collection of isolated manual edits. It is produced from a defined system of inputs, formulas, reusable blocks, and composition rules.

The core model is inputs to logic to outputs. Parameters and other inputs describe the variation you want. Logic inside blocks determines what values are computed, which state is active, which geometry is visible, and how repeated or transformed content is generated. The drawing updates from that evaluated model.

This makes drawings a result of system definition rather than repeated redrafting. A single block definition can drive many block references, each with different inputs but the same underlying behavior.

The same evaluated model also drives artifacts. Bills of materials, schedules, flat table exports, and hierarchical JSON exports are generated from the same block data used to render the drawing. Geometry and output data therefore stay aligned because they come from one system instead of separate manual processes. The same inputs flow through logic into both drawing results and output data.

Core Concepts

LogiDraft is built from a small number of connected concepts. Understanding how they relate is more useful than memorizing individual tools.

Documents and Sheets

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 logic and reusable geometry. The document ties both together.

Blocks

A block definition is a reusable component. It contains states, parameters, variables, selection logic, optional lookup tables, and the primitives that belong to each state. A block can represent a part, an assembly, or a larger system fragment.

Blocks are where system behavior is authored. They are not just geometry containers. They are the units that encapsulate logic and reuse.

Block References

A block reference is an instance of a block definition placed on a sheet or nested inside another block. It points back to one definition but can carry its own parameter values, insertion point, scale, rotation, and chosen state.

Multiple references can use the same definition while producing different results because each instance can resolve different inputs.

Parameters

Parameters are the primary authored inputs on a block definition. They define the values a user or parent system can supply for each instance. Parameters can be free values or option-constrained values, and they are typed as number, string, or boolean.

At the block-reference level, parameter values can be literal values, inherited values, direct references, or formula expressions. They are resolved before block logic is fully applied.

Variables

Variables are derived values defined by formulas. They compute secondary values from parameters and other variables and are used to drive geometry, state selection, text, directives, and outputs.

Variables let a block describe behavior such as calculated dimensions, classification, sizing, and output fields without requiring the user to enter every value manually.

How The Concepts Relate

• Documents contain sheets and definitions.
• Sheets place block references and other primitives into the visible drawing.
• Block definitions contain the reusable logic that references evaluate.
• Parameters provide instance-specific inputs.
• Variables derive additional values from those inputs.
• Block references turn one definition into many concrete variations.

Together, these concepts let a system be authored once, instantiated many times, and evaluated consistently across both drawings and structured outputs.

Definitions vs Execution

Block definitions store the reusable system. They contain the parameters, variables, states, lookup tables, and geometry that describe how a block behaves.

Block references execute that system. When a reference is placed on a sheet or nested inside another block, the engine resolves its inputs and evaluates the definition in that instance context.

Definitions describe behavior. References are where that behavior runs.

This is why one definition can produce many different results. The authored behavior stays the same, but the evaluated result changes with the inputs and surrounding context of each reference.

Evaluation Lifecycle

Evaluation follows a deterministic runtime flow. Parameters on a block reference resolve first, including explicit values, inherited values, defaults, and any valid parameter-to-parameter dependencies.

Variables evaluate next from those resolved inputs. After the values for the instance are resolved, the active state is determined.

The engine then realizes the visible geometry, directives, and any nested block references in that evaluated context. Artifacts are generated from those realized instances, which is why one input change can propagate through the drawing and the outputs without creating separate sources of truth.

Logic System

The logic system combines parameters, variables, formulas, injection, and lookup tables so that block behavior responds deterministically to inputs.

Variables and Formulas

Variables are defined by formulas and evaluated in block scope. Formulas can reference parameters, variables, and supported helper functions. They are used for derived dimensions, calculated labels, selection logic, and any other computed behavior.

Variable resolution is dependency-based rather than sequential. The engine resolves references between variables, evaluates what each variable depends on, and detects circular dependency cases. This means a variable does not have to appear earlier in the authored list to be usable.

State Selection

Blocks can define multiple states. A selection formula can choose the active state for a given evaluation, while authored defaults or instance-level state choices provide fallback when needed. The active state controls which geometry and behaviors are used for that instance.

Parameter Resolution

Parameter values on a block reference are not limited to raw literals. They can resolve from direct values, inherited parent values, direct token references, or evaluated expressions. When a parameter is missing on a nested reference, the engine can inherit a same-named value from parent scope before falling back to the parameter default.

This parameter resolution happens before block logic executes, so variables and state selection operate on resolved inputs rather than raw authored values.

Parameter dependencies are also resolved by relationship, not by authoring order. Sibling parameters can reference each other when the dependency graph is valid.

Defaults, Overrides, and Fallbacks

Parameter precedence follows a consistent order: an explicit value on the block reference wins first, then an inherited same-named value from parent scope, and finally the default defined on the block.

Variables and parameter expressions also evaluate defensively. When formulas are missing, invalid, or circular, the engine falls back to safe default values so the system can continue resolving in a predictable way instead of leaving behavior undefined.

Injection

Injection is the mechanism that allows evaluated values from block scope to flow into text, properties, transforms, directives, and output fields.

Conceptually, injection is how resolved parameters and variables are applied to authored content. It lets the same evaluated system drive both visible geometry and structured outputs instead of treating those fields as disconnected manual values.

Lookup Tables

Lookup tables provide data-driven logic inside blocks. Instead of encoding every branch as nested formulas, a block can query table data using exact-match or numeric-range lookup behavior.

This supports patterns such as size charts, option mapping, product-family selection, and rule tables where authored data is easier to maintain than long formula chains. They are preferred when rules are easier to manage as tabular data than as deeply nested formulas, especially for sizing tables and maintainable selection logic.

In other words, inputs still flow into logic and outputs, but lookup tables let part of that logic live in structured data instead of only in formulas.

For exact function signatures, injection syntax, and lookup syntax, see Reference.

Composition

Composition is how small authored blocks become larger assemblies. A block can contain nested block references, and those nested references are resolved using the same logic system as top-level references.

Nested Blocks

When a block contains another block reference, the child does not evaluate in isolation. It evaluates within a merged scope that includes parent-resolved parameters and variables plus the child's own resolved inputs.

This is what makes assembly behavior possible. A parent block can compute values once and pass them into multiple nested children without duplicating logic in every child instance.

In practice, parent values propagate downward unless the child supplies or computes its own replacement. Child blocks can therefore inherit shared system inputs while still overriding local behavior, and the final result is always resolved in one merged evaluation context rather than in disconnected pieces.

Parameter Propagation

Parameter propagation happens by name and by authored reference values. A child parameter can receive a raw literal, a direct token such as {Width}, an expression, or an inherited same-named value from parent scope when the child instance leaves that parameter unspecified.

This allows nested blocks to remain reusable while still participating in larger assemblies.

Merged Scope Behavior

During realization, the engine merges parent context with child-resolved values. Geometry, directives, and injectable fields inside the nested block are then resolved against that merged context before the result is transformed into its final position.

The result is not simple insertion. It is evaluated composition.

Building Assemblies

Assemblies are built by chaining definitions together. One block can represent a product family, another can represent a subsystem, and another can represent a repeated detail. Nested composition lets those pieces stay modular while still acting as one system at evaluation time.

How Systems Scale

Systems scale because logic is authored at the definition level and reused through references. Instead of creating disconnected variants, you create more instances, more nesting, and more scoped inputs. The engine resolves the same behavioral model through each level of composition.

Composition is what carries inputs into nested logic and turns the resolved result into larger system outputs.

For exact directive properties and command behavior, see Reference.

Artifacts from Realized Instances

Artifacts are generated from evaluated block instances, not from block definitions alone. A definition describes what can happen, but an artifact row or output record comes from a specific resolved instance in a specific context.

That means each row reflects the values, state, and nesting context that were actually realized during evaluation. Because drawings and artifacts are produced from the same realized instances, BOMs, tables, and geometry stay aligned when inputs change.

Outputs (Artifacts)

Artifacts are structured outputs generated directly from the evaluated model.

They are not a separate reporting layer maintained by hand. The same block definitions, parameters, variables, nesting structure, and resolved values that drive the drawing also drive output generation.

This matters because it keeps visual and non-visual outputs aligned. If inputs change, both the drawing and the exported system data change from the same source of truth.

Artifact Types

• Flat table exports such as BOMs, parts lists, and schedules.
• Hierarchical JSON exports built from realized block instances.

Scoping

Artifact generation can be scoped to different parts of the model. Depending on the workflow, outputs can be generated for the entire document, for a sheet or group of sheets, or for a targeted selection of modeled systems. In practice this means one model can produce broad document-level reports or narrowly targeted outputs.

Grouping, Filtering, and Aggregation

Artifacts support grouping and aggregation so rows can be combined into schedules or BOM-style summaries. Filtering allows outputs to target only the instances that match the current need, such as specific sheets, families, ids, or fields.

This turns artifact generation into part of system authoring rather than a post-processing task.

Raw and Resolved Views

Outputs can expose raw authored values, resolved evaluated values, or both. Raw values show what was entered or inherited. Resolved values show what the system computed after formulas, propagation, and lookups were applied.

That distinction is important when a model uses inherited parameters, variable-driven values, or lookup-based logic. It lets users inspect either the authored inputs or the final computed result.

A single LogiDraft model therefore drives both the drawing and the production-facing data derived from it. Inputs pass through the same logic into both visual and structured outputs.

For exact artifact export options, modes, and field names, see Reference.

Reuse System

Reuse in LogiDraft is built around block definitions. A reusable block can stay local to one document or be managed as part of a broader global library.

Local Blocks

Local blocks live inside a document. They are appropriate when the reusable logic belongs to a single project or when a system is still being developed in document scope.

Global Blocks

Global blocks live in the shared library and can be inserted across documents. When used this way, a common system component does not need to be recreated in every file.

Library Structure

The global library is organized as a reusable catalog rather than a flat list of copied geometry. That structure makes repeated insertion and standardization practical across many documents.

Consistency Benefits

Reuse keeps logic consistent because changes happen at the definition level. Instead of fixing the same rule in many disconnected instances, the authored behavior stays centralized and instance variation happens through inputs.

This is the main reason LogiDraft scales beyond one-off drafting. Reuse turns recurring systems into shared authored components.