Outputs

What to keep in mind

• Artifacts are generated directly from the same evaluated model that drives the drawing.
• Outputs come from realized instances, not from block definitions in isolation.
• Scope, filtering, grouping, and aggregation control which data is exported.
• Raw and resolved views let outputs show authored values, computed values, or both.

Outputs are derived from evaluated instances

Artifacts are structured outputs generated directly from the evaluated model.

They are not a separate reporting layer maintained by hand, and they are not merely exports of already-fixed geometry. The same block definitions, parameters, variables, nesting structure, and resolved values that drive the drawing also drive output generation.

Geometry and outputs are parallel results of the same evaluated system. One is not a manual derivative of the other. Both come from the same runtime state.

Why outputs matter in real workflows

There is no separate BOM to maintain and no synchronization step.

• They eliminate manual BOMs and reduce dependence on separate spreadsheets.
• They prevent mismatches between what is drawn and what is reported.
• They let one system drive both design representation and production-facing data.
• They matter most when repeated assemblies or changing inputs would otherwise force manual reconciliation.

In a traditional workflow, drawings are updated first and schedules or BOMs are corrected later. In LogiDraft, outputs are produced from the same evaluated system, so coordination happens at the source rather than through cleanup work.

How values reach outputs

• Authored in Blocks: block definitions define behavior and output-relevant fields.
• Determined by Logic: logic defines relationships that derive the values outputs will use.
• Executed in Evaluation: evaluation executes those relationships and resolves instance state.
• Extended by Composition: nested systems contribute parent and child data to the realized result.
• Defined here: outputs are derived from evaluated instances after resolved values are applied through realization and injection.

The flow is: logic defines relationships, evaluation executes those relationships, injection applies resolved values during realization, and outputs read from those realized instances.

Artifacts come from what the system actually resolved

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.

Artifact Types

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

Manual reporting versus evaluated reporting

In a traditional workflow, geometry is drafted, then a BOM or schedule is assembled afterward from what someone believes the drawing contains. That often leads to spreadsheets, duplicate entry, and mismatches.

In LogiDraft, the system is evaluated once and both geometry and outputs read from that evaluated state. Reporting is therefore system-derived rather than manually reconciled.

Outputs are another view of the same system

The most reliable mental model is to treat outputs as another view of the system rather than as a downstream document generated from a drawing.

In that model, a BOM, a schedule, a JSON structure, and the drawing itself are all reading the same resolved runtime state. They are different presentations of one evaluated system, not separate sources that need to be reconciled.

Resolved values, raw values, and nested structure all matter

Artifact generation can be scoped to different parts of the model. Outputs can represent the entire document, a sheet or group of sheets, or a targeted system within the model.

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.

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.

Nested data also matters. A parent assembly and its child instances can both contribute meaning to an output, which is why hierarchical exports can represent the system more faithfully than a flat list alone.

Ways outputs are commonly used

• Generate a flat BOM or schedule when production needs summarized instance data.
• Generate hierarchical JSON when downstream systems need assembly structure, not just rows.
• Expose both raw and resolved fields when traceability between authored intent and computed result matters.

An MCP is a concrete example. The same evaluated system that determines motor arrangement, protection, and labeling can also produce coordinated schedule rows and hierarchical output data without maintaining a separate spreadsheet.

For the reuse strategy that keeps outputs consistent across projects, continue to Reuse. For exact artifact export options and field names, use Reference. To see coordinated drawing and output behavior in a working system, use Help or open the MCP example.

Keep exploring