Modeling Guide

Knowledge Guides /

How to Separate Product Values, Project Requirements, and Instance Overrides in Engineering Templates

Last updated: · New Horizon Digital Outsourcing Team

Store product properties, project requirements, and instance configuration separately and relate them explicitly. A property template needs types, units, missing-value semantics, provenance, and override rules, not just field names. Trace effective values and derived results to ensure edits neither silently overwrite product baselines nor preserve stale calculations.

Separate Property Values from Requirements

  • The same quantity may have a nominal product value, a project-allowed range, and an instance setting. These answer what the product provides, what the project requires, and what this instance uses; they should not share one freely overwritten cell.
  • Tailor templates to product categories and distinguish inapplicable, missing, and pending-confirmation values. An unconfigured field must not automatically mean zero, and saving a form does not establish compliance with project constraints.

Define Types and Unit Conversion Rules

  • The field dictionary should define stable identifiers, data types, units, allowed values, and coordinate references where needed. Numbers, enumerations, expressions, and object references require different checks; categorical fields such as communication protocols should not inherit physical-unit rules blindly.
  • When a property type changes, specify whether the old value is cleared, converted, or rejected, and show the actual outcome before committing. Unit conversion must update both the value and its unit identifier; reopen the saved model to ensure only the label was not changed.

Make Inheritance and Overrides Traceable

  • Record the source version when an instance uses a template default. For overrides, preserve the override, rationale, and original reference value. Before updating a shared template, distinguish instances following defaults from independently configured ones and assess the impact.
  • Create two generic instances from the same template, edit one, and check the other instance and the template against the agreed behavior. When clearing an override restores a default, specify whether it comes from the frozen baseline or a newer version.

Check Derived Results and Aggregation Scope

  • Changes to materials, dimensions, or ownership may affect mass, aggregates, or validation findings. Mark results that need recomputation and distinguish visible, selected, and whole-project aggregation scopes; hidden elements do not automatically cease to exist.
  • Deliver the field dictionary, override examples, dependency definitions, and recomputation records so the recipient can follow a property from input to output. Keep derived quantities without material evidence or calculation verification marked as unverified rather than treating well-formatted values as measurements.

Have a more specific question?

Tell us your project stage and target domain. We will respond within 1 business day with collaboration options and scope recommendations.