Authors turn approved engineering knowledge into an explicit family model. Prepare the engineering source before opening Product families. Do not use a plausible generated rule or a passing fixture as proof that a real customer family is qualified for manufacture.
Define the family completely
Create the family name and engineering scope. In Engineering model, define Inputs, Components, Calculations, Component list, Blocking conditions and Tables as needed. Use meaningful stable keys and exact component revisions. Bounds, units, decimal precision and option keys are part of the engineering meaning.
State when an input applies and when a component line is included. A calculation should reference declared values and produce the intended type. A blocking condition needs the explanation a user should see when the configuration is unsuitable.
Prepare independent expectations
Under Independent cases, enter a case key, name and Independent engineering basis. Supply the inputs, expected outcome, expected named values and complete expected component list. Calculate those expectations from the engineering source independently of the model's output.
Include boundary and refusal cases as well as ordinary successful configurations. If a dependency table changes, inspect the typed differences and add a case demonstrating the intended effect. A saved proof can establish only the cases and checks it contains.
Save and hand over the exact version
Use Save draft. Saving records a version and checks its model and cases. Submit the saved draft for independent review only when the proof passes. Everyone who changed its model or expectations is excluded from approving that candidate.
Assisted authoring is a preparation aid when available. Review its exact proposal and context before adoption. It neither qualifies a family nor releases or activates engineering rules. Versions enrolled in SmartFACT Automation retain their applicable independent workflow there.
Follow Build an engineering family, Write independent cases and Review a candidate. Explain what should change and what should be refused so the reviewer can challenge the model instead of merely confirming its author's intention.