Product development / One-page working checklist
Use these rules while drawing, testing and reviewing module boundaries.
VFAB internal standard
Every VFAB component must have a defined identity, boundary, interface, permitted variation, invariants and verification method.
Every panel code contains exactly 10 characters:
| D | Large door | S | Small door |
| L | Sliding door | W | Large window |
| V | Small window | u | Service or utility box |
| C | Column | x | Ordinary wall |
| - | Continuation of a multi-slot component | ||
01CS--V--x
P1 = Column
P2–P4 = Small door
P5–P7 = Small window
P8 = Ordinary wall
Prohibited symbols: d, w, A and c
No declared interface = not approved as a module
Every physical component must be traceable through this complete information chain.
VFAB 2.0 is an internal project system and does not replace statutory requirements.
If this sheet conflicts with an approved drawing, specification or statutory requirement, stop work and request clarification.
Use these rules while drawing, testing and reviewing module boundaries.
Based on the original PDF ↗. Tick each box after checking the rule.
Define the technical requirements that vary before drawing module boundaries.
DetailBuild the architecture from recurring technical differences, not existing part names.
WhatA variation map: what varies and what stays common.
WhyPrevents arbitrary boundaries and hidden variants.
WhenConcept design, before architecture freeze.
WhereRequirements list and family matrix.
HowUse two columns, then link each variation to the function it changes.
ExampleTorque varies; frame mounting points stay common.
Parts repeatedly changed by the same technical driver are one module candidate.
DetailRecurring co-change shows real coupling; one accidental case does not.
WhatA cluster of components that change together.
WhyKeeps coordinated redesign inside one boundary.
WhenAfter comparing variants and change scenarios.
WhereFunction map, bill of materials and layout.
HowChange one part on paper; mark every forced neighbour. Group recurring clusters.
ExampleHigher-power motor, matching gearbox and cooling unit.
Parts driven by different requirements should have separate boundaries.
DetailIndependent change drivers need independent modules unless safety or physics requires coupling.
WhatSeparate modules for independently changing parts.
WhyStops one choice multiplying another.
WhenParts vary for different requirements or replacement cycles.
WhereProduct structure, assembly definition and option matrix.
HowAsk: Can A change while B stays fixed? If yes, separate them.
ExampleBattery capacity and cover colour vary independently.
Keep each variable technical requirement inside one bounded module.
DetailLocalise the effect across parts, software, drawings and tests.
WhatOne variable requirement assigned to one module.
WhyStops small differences spreading through unrelated systems.
WhenDuring variant allocation and module scoping.
WhereBOM, drawings, software configuration and tests.
HowTrace every affected item. Move the boundary or standardise the connection if the change spreads.
ExampleA sensor option changes the sensor module and setting only.
Reuse a module only when function, load and environment remain within verified limits.
DetailCommon appearance is insufficient; verified technical fit controls reuse.
WhatOne unchanged module used in several products.
WhyReduces parts, drawings, tests, tools and spares.
WhenA new model needs a function already provided.
WhereAcross the family and suitable adjacent families.
HowCheck function, load, environment and interface against module limits.
ExampleOne controller serves several machine sizes within its ratings.
A reusable module needs one stable interface across all intended uses.
DetailDifferent neighbour connections destroy interchangeability.
WhatA controlled specification for every boundary connection.
WhyLets the module change without neighbour redesign.
WhenBefore approving common use or interchange.
WhereMechanical, electrical, fluid, software and data boundaries.
HowSpecify fit, tolerance, load, power, data, safety and tests; verify every use.
ExampleControllers share one mount, connector and communication protocol.
A useful module can be replaced, resized or upgraded without redesigning its neighbours.
DetailIndependent change is the practical test of modularity.
WhatA paper-based change test for each boundary.
WhyExposes hidden dependencies before release.
WhenArchitecture review and before change approval.
WhereModule, neighbours, drawings, software, tools and tests.
HowMake the change on paper and list all outside changes. Redraw if the list is long.
ExampleA larger battery keeps the same space, mount, connector, cooling and control interface.
Move from variation requirements to proof of independent change.
What must change and what must remain common?
Group dependent elements; separate independently changing elements.
Control geometry, load, power, data, safety and verification.
Replace, upgrade or resize without affecting neighbours.
Each rule should change how we group, separate, reuse or standardise components.
Rule 01
Define the technical requirements that will vary across the product family before drawing or dividing modules. Boundaries must come from recurring technical differences, not existing part names or habits inherited from an earlier project.
A short variation map that clearly separates “must vary” from “must stay common”.
Prevents arbitrary module boundaries and exposes hidden variants early.
During concept design, before the product architecture is frozen.
The product-family requirements list and comparison matrix.
Create two columns—“must vary” and “must stay common”—then link each variation to the function it affects.
Output torque may vary while the frame mounting points must remain common.
Rule 02
Components that repeatedly change together because of the same technical driver are candidates for one module. A single coincidental case is not enough evidence.
A module candidate containing components with a recurring co-change relationship.
Keeps redesign effects inside one boundary instead of allowing them to spread across the product.
After comparing variants or simulating likely change scenarios.
The function–component map, BOQ/BOM and physical layout.
Change one component on paper and mark every component forced to change with it; group them if the relationship keeps recurring.
If a higher-power motor always requires a matching gearbox and cooling unit, the three may form one drive module.
Rule 03
Components that change for different reasons or at different times should not be locked into one module unless a strong physical or safety constraint requires coupling.
Separate boundaries for components with independent change drivers.
Stops one choice from generating unnecessary combinations for another choice.
When two components vary by different requirements, users or replacement cycles.
The product structure, assembly definition and option matrix.
Ask: “Can A change while B stays fixed?” If yes, separate them unless a documented technical constraint requires them to remain together.
Battery capacity and cover colour vary independently, so the battery and cover should not become one assembly variant.
Rule 04
Each variable technical requirement should affect only one small, clearly bounded area of the product structure wherever practical.
One variable requirement allocated to one clearly identified module.
Stops a small difference from spreading into unrelated systems.
During variant allocation and when defining the scope of each module.
The BOQ/BOM, drawings, software configuration and verification plan.
Trace the variation through every affected item; if it crosses several modules, move the boundary or standardise the connection.
A sensor option should change only the sensor module and its setting, not the enclosure, controller and complete wiring system.
Rule 05
Reuse a module only when the required function, loads and operating conditions remain within verified limits. Similar appearance is not sufficient technical justification for reuse.
One verified module reused unchanged across several products.
Reduces the parts, drawings, tests, tools and spares that must be managed.
When a new model or size needs a function already provided by an existing module.
Across models in the same family and, where suitable, adjacent product families.
Compare the required function, load, environment and interface with the module limits; reuse it only when every condition is satisfied.
Use one controller across several machine sizes when its I/O capacity, safety rating and environmental rating remain suitable.
Rule 06
A common module must have consistent mechanical, electrical, software and information interfaces across every intended use. If each neighbouring system connects differently, the module is no longer interchangeable.
A controlled specification for every connection that crosses the module boundary.
Allows the module to change without redesigning the surrounding product.
Before approving the module for common use or interchange between products.
At every mechanical, electrical, fluid, software and information boundary.
Specify fit, tolerance, load, power, data, safety and verification conditions, then confirm that the same specification suits every intended use.
Several controllers can share one mounting pattern, connector and communication protocol without changing the surrounding machine.
Rule 07
A boundary is useful only when the module can be replaced, resized or upgraded without redesigning neighbouring modules. A line on an architecture diagram is not enough to prove modularity.
A paper-based change test for every proposed module boundary.
Exposes hidden dependencies before detailed release, tooling manufacture or verification planning.
During architecture review and before design release or approval of a major change.
The candidate module, neighbouring modules, drawings, software, tools and related tests.
Simulate replacing, upgrading or resizing the module and list every external change. If the list is long, review the boundary.
A battery module passes when a higher-capacity battery keeps the same space, mounts, connector, cooling and control interface.
Check before approval
Tick each statement during the review. Your progress is stored in this browser so you can return and continue later.