Configurix

Parametric product configurator

Let dimensions change the product—not just the picture.

Configurix turns controlled made-to-measure inputs into one valid, revisioned product state. Continuous dimensions, dependent options, generated 3D geometry, calculated quantities, live pricing and downstream quote, BOM or CAD handoffs remain connected to the same configuration.

Made-to-measure system

Bioclimatic pergola · PM-18

Valid state
5,250 mm
2 bays · derived

Width

5,250 mm

Projection

3,500 mm

Bay count

2 · calculated

Finish

Anthracite

Live price

€12,680

Rules

Accepted

Geometry

Regenerated

Output

Revision 07

Typed dimensions

Every value carries a quantity kind, unit, range and increment.

Deterministic rules

Dependencies and derived values resolve one accepted product state.

Bound geometry

3D consumes governed parameters instead of inventing separate product logic.

Revisioned outputs

Price, quote, BOM and CAD results reference the exact saved configuration.

Category definition

Variant, modular and parametric configuration solve different product problems.

A precise category prevents unnecessary geometry work and missing product logic. Many made-to-measure systems are deliberately hybrid: fixed product families, modular components and continuous dimensions in one governed model.

Variant configurator

A user selects from a finite set of predefined products, sizes, colours, finishes or SKUs. The experience can still enforce compatibility and calculate price, but it does not need to generate a new dimensional product state.

Use when every sellable answer already exists as a governed variant or option combination.

Modular configurator

A user composes an assembly from governed modules such as bays, panels, cabinets, posts, machines or accessories. Rules control counts, positions, interfaces, repetition and compatibility between components.

Use when the solution changes by composition more than by unrestricted geometry.

Parametric product configurator

A guided application that converts controlled parameters—such as width, height, depth, pitch, quantity or spacing—into a valid product state. Parameters can drive derived values, geometry, component choice, quantities, price and technical outputs.

Use when made-to-measure values materially change the product rather than only its label.

Parametric CAD configurator

A parametric workflow connected to a CAD model or geometry-generation service. It can rebuild native features, assemblies, drawings or neutral files after the commercial configuration has passed the required validation and review boundary.

Use when sales state must create or control an engineering representation or deliverable.

Interactive architecture classifier

Classify the product before choosing the technology.

Select the real input model, geometry response and required output. The result identifies the likely configurator category and the evidence boundary that the implementation must prove.

Input model
Geometry response
Required output

Recommended category and boundary

Parametric product configurator

1

Use deterministic browser, service or CAD generation. Version the generator and bindings, make asynchronous jobs idempotent and reject results created for an older configuration revision.

2

Map derived state to governed component IDs, quantities and units. Define whether the result is a sales BOM, configured order payload or released manufacturing structure.

3

Test minimum, maximum, increment, unit conversion and just-outside-boundary states.

Architecture rule

Use structured configuration state as the authority. Interface controls, browser 3D, price, BOM and CAD jobs consume that state; none should invent an independent version of the product.

Canonical parameter contract

Ten fields make every made-to-measure input explainable.

A slider is presentation. The parameter contract is product data. It lets interface, rules, geometry, price, saved projects and downstream systems interpret the same value without relying on a translated label or hidden default.

01

Stable parameter ID

A durable machine identifier independent of translated labels and screen order.

overall_width

02

Type and quantity kind

Number, integer, Boolean, enumeration or text plus length, angle, area or another quantity kind.

number · length

03

Canonical unit

The unit used for storage and calculation, separate from the user's display unit.

millimetre

04

Display and input units

Permitted market or user units, decimal convention and conversion behavior.

mm · cm · in

05

Bounds and inclusivity

Minimum, maximum and whether each boundary is allowed for this product context.

2400 ≤ width ≤ 7000

06

Increment and precision

Permitted step, stored precision, displayed precision and rounding responsibility.

step 5 mm · display 0 mm

07

Default and provenance

A deliberate initial value plus its catalogue, rule or market source—not a silent fallback.

4000 mm · catalogue rev 12

08

Dependencies

Parameters, options or contexts that change availability, range, step or calculated meaning.

roof system → max span

09

Bindings

Explicit links to browser geometry, materials, price inputs, BOM fields, CAD parameters and documents.

scene.span_x · CAD.Width

10

Revision and status

The product-model and parameter-definition version used by every saved configuration.

PERGOLA-PM-18 · released

Constraint architecture

A range is only the first layer of product validity.

A useful parametric model explains why a value is accepted, rejected, recalculated or routed to review. These seven layers keep UI feedback, geometry and downstream outputs aligned.

Domain constraints

Type, unit, minimum, maximum, increment, precision and allowed enumeration values for one parameter.

Example: Projection is a length from 2000 to 5000 mm in 50 mm increments.

Conditional constraints

Another choice changes the parameter's allowed range, required state, visibility or default.

Example: A wall-mounted system allows a different maximum projection from a freestanding system.

Compatibility constraints

Options, components or materials can be combined only when their interfaces and catalogue rules agree.

Example: A screen cassette requires the compatible beam and post profile family.

Geometric constraints

Clearance, collision, alignment, spacing, count and topology rules govern how geometry may change.

Example: Intermediate posts are inserted when the supported beam span exceeds the approved interval.

Derived constraints

Calculated values depend on other parameters and may control components, quantities or validation.

Example: Bay count is derived from overall width, maximum bay width and joining policy.

Commercial constraints

Market, price list, customer, quantity, service area or channel can change what may be sold or priced.

Example: A finish is available in one region but requires a surcharge and longer lead-time elsewhere.

Review constraints

A state can be technically possible but outside instant approval, forcing a named review instead of false acceptance.

Example: A large span is captured and visualized, but the quote remains subject to structural review.

Units, precision and rounding

A number without a quantity and unit is not a safe product parameter.

Consistent measurement handling prevents geometry, price, BOM and document mismatches—especially when the same configurator serves metric and imperial markets.

1

Store canonical values

Choose one canonical unit per quantity kind and normalize every accepted input before rules, geometry and price evaluate it.

2

Preserve the entered representation

Where customer communication requires it, retain the original value and unit alongside the normalized value so quotes and revisions remain explainable.

3

Separate precision from tolerance

Displayed decimal places, calculation precision, manufacturing increment and engineering tolerance answer different questions and should not share one field.

4

Define rounding ownership

State whether rounding happens at input, normalized parameter, component quantity, price line or output. Repeating a rounded value through the chain creates drift.

5

Test both unit systems

Metric and imperial views must resolve to the same canonical product state, rule outcome and price policy, including exact boundary and step behavior.

6

Reject ambiguous values

A bare number without a trusted context must not silently become millimetres, inches or degrees in an integration payload.

Geometry architecture

Choose how parameters change geometry—and state the technical boundary.

The correct pattern depends on topology, performance, intellectual property and required outputs. A single product family may combine prepared assets for options with generated geometry for dimensions and native CAD automation for released files.

Prepared assets with controlled transforms

Best fit

Simple made-to-measure products whose geometry changes through bounded scaling, movement, visibility and repetition.

Acceptance boundary

Prove that transformed profiles, textures, joints and accessories remain visually and dimensionally credible at every supported boundary.

Browser-generated parametric geometry

Best fit

Interactive products that can build profiles, panels, paths or assemblies deterministically in the web runtime.

Acceptance boundary

Keep generation performant and deterministic; do not treat a browser mesh as a production or engineering file without an accepted conversion path.

Service-generated geometry

Best fit

Products needing heavier geometry, controlled libraries, asynchronous generation or server-side intellectual-property protection.

Acceptance boundary

Define job identity, timeout, retry, idempotency, storage, generator version, error state and how stale results are rejected.

CAD-connected parametric automation

Best fit

Products whose approved technical output must be rebuilt from a native model, assembly, drawing or engineering-owned template.

Acceptance boundary

Separate commercial configuration validity from CAD generation success and technical release; connect them with revisions and acceptance evidence.

Product patterns

Parametric configuration applies across consumer, building and industrial products.

The product changes, but the architecture remains recognizable: controlled inputs, derived state, generated representation, commercial calculation and a clear review boundary.

Pergolas, verandas and carports

Width, projection, height, bay count, roof pitch, posts, screens and glazing

Frames, spans, infill, repeated roof elements, dimensions, quantities and configured price

Structural loads, foundations, drainage, site interfaces and jurisdictional requirements

Windows, doors and façades

Overall size, sash or panel layout, opening mode, profile, glass and hardware

Frame and leaf geometry, mullions, panels, hardware state, line items and schedules

Performance declarations, wind or impact conditions, egress, fire and installation details

Stairs, railings and balustrades

Rise, run, floor height, width, landing, turns, posts, infill and finish

Step count, tread geometry, strings, rails, infill spacing and component quantities

Building-code, structural, headroom, guarding and site-measurement acceptance

Furniture, kitchens and storage

Envelope, modules, fronts, worktops, appliances, shelves and internal accessories

Cabinet composition, cut dimensions, panels, hardware, price and configured order data

Site conditions, services, appliance clearances, material limitations and installation

Industrial equipment and enclosures

Capacity, duty, dimensions, connections, environment, controls and options

Assembly layout, equipment selection, interfaces, guards, quantities and proposal data

Application sizing, process, electrical, safety, compliance and engineer-to-order exceptions

Fences, gates and linear systems

Run length, height, post spacing, slopes, openings, corners, infill and gate type

Panel count, cut or adjusted bays, posts, gates, transitions, quantities and price

Terrain survey, foundations, automation safety, wind exposure and property boundaries

End-to-end state flow

One accepted configuration should drive every representation and output.

The flow prevents the screen, model, price and downstream systems from becoming competing sources of truth. Each stage consumes explicit state and records its result.

01

Capture context

Identify product family, market, role, project, unit preference, customer or account and applicable catalogue revision.

02

Normalize inputs

Parse type and unit, convert to canonical values, apply precision policy and retain the original representation where required.

03

Resolve constraints

Evaluate ranges, increments, compatibility, dependencies, geometry limits, market rules and review thresholds.

04

Calculate derived state

Compute counts, spans, areas, lengths, quantities, component identities and other values that should not be typed twice.

05

Regenerate representations

Update browser 3D, dimensions, selections and summaries from the accepted structured state—not from unrelated interface values.

06

Calculate commercial state

Pass governed parameters and component quantities into the correct price context, retaining price-list and calculation revisions.

07

Save one revision

Store inputs, normalized values, derived values, selected components, model versions, rule result and status under one configuration revision.

08

Generate controlled outputs

Create the quote, configured order, BOM, drawing, CAD job or review request from that revision and record each output result separately.

Implementation blueprint

Prove one made-to-measure product before scaling the catalogue.

An eight-stage implementation gives product, engineering, 3D, commercial and integration owners shared evidence instead of asking a polished demo to stand in for the working product system.

01Product owner

Choose one representative made-to-measure product

Select a product that includes real continuous dimensions, dependent options, a boundary case, a commercial result and the most important downstream output.

Proof: Representative normal, minimum, maximum, invalid and review-required examples

02Product + engineering

Inventory parameters and their owners

Record stable IDs, types, units, bounds, increments, defaults, dependencies, source revisions and the people authorized to approve each definition.

Proof: Versioned parameter dictionary with no ambiguous units or duplicate meanings

03Rules lead

Model constraints and derived values

Translate catalogue, geometry, compatibility, commercial and review policies into explicit testable rules. Separate user inputs from calculated results.

Proof: Decision table and automated examples for allowed, invalid and review states

043D + CAD lead

Define the geometry strategy

Choose prepared assets, browser generation, service generation, native CAD automation or a hybrid. Map every parameter to the representation it is allowed to drive.

Proof: Geometry-binding map and boundary renders or files

05Commercial owner

Connect quantities and price deliberately

Define which normalized parameters, derived quantities, components, services and contexts enter pricing; make rounding and price revision visible.

Proof: Approved price examples that reconcile with configuration and line items

06Integration lead

Write the saved-state and output contract

Specify configuration identity, revisions, parameter state, selected components, geometry job, quote, BOM, CAD and downstream system mappings.

Proof: Versioned schemas, example payloads and acknowledgement behavior

07QA + domain owner

Test the complete solution space

Cover boundaries, increments, unit systems, product options, repeated edits, historical reopening, generation failure, pricing and downstream reconciliation.

Proof: Signed regression pack against the working product and receiving systems

08Product governance

Govern change after launch

Version parameter definitions, rules, geometry bindings, price mappings and outputs; assess saved projects before releasing catalogue changes.

Proof: Release, migration, deprecation and rollback process with named owners

Working acceptance tests

Twelve tests replace “fully parametric” with evidence.

Run these tests against the real product, both unit systems, boundary geometry, pricing and receiving systems. Record the input and every model or service revision needed to reproduce the result.

  1. 1

    Every input parameter has a stable ID, type, quantity kind, canonical unit, display policy, range, increment, precision and source revision.

  2. 2

    The same entered value in every supported display unit resolves to the same canonical product state and rule outcome.

  3. 3

    Minimum, maximum, exact increment, off-increment, just-below and just-above values produce the documented result.

  4. 4

    Changing a controlling option immediately recalculates dependent ranges, defaults, derived values and invalid selections without leaving hidden stale state.

  5. 5

    Browser geometry, dimension annotations, textual summary and saved parameter values reconcile for normal and boundary configurations.

  6. 6

    Repeated modules, component counts, material quantities and price inputs are derived from one structured state rather than separately re-entered values.

  7. 7

    An invalid or review-required configuration cannot silently become a final quote, order, BOM or released technical file.

  8. 8

    Price results identify currency, market, account or channel where relevant, calculation revision and rounding policy.

  9. 9

    Saving, reopening, duplicating and revising a configuration preserve the correct product model, rules, geometry and price context.

  10. 10

    Asynchronous geometry or CAD generation is idempotent, versioned, retry-safe and cannot attach a stale result to a newer configuration revision.

  11. 11

    Every downstream quote, BOM, configured order or technical output resolves the exact configuration revision that created it.

  12. 12

    Catalogue, parameter, rule and binding changes run an impact assessment and regression tests against current and historical representative configurations.

Failure patterns

Most parametric failures are state, unit and revision failures.

The viewport often reveals the problem last. Strong implementations define the data and evaluation contract before connecting geometry, price or technical automation.

Treating visual scaling as parametric truth

Stretching a mesh can make the viewport look responsive while joints, profile thickness, textures, quantities and technical dimensions become false. Define which transforms are legitimate and when geometry must be rebuilt.

Using labels as parameter identities

Labels change by language and interface design. If price, CAD or saved projects depend on the word Width, a translation or rename can break the workflow. Bind systems through stable IDs.

Mixing units inside formulas

A number is not a dimension. Normalize values and preserve quantity kinds so millimetres, inches, degrees, counts and areas cannot be combined accidentally.

Rounding at several stages

Input controls, geometry, quantities, prices and documents can each round differently, producing mismatched totals and dimensions. Assign one policy to each calculation boundary.

Allowing impossible intermediate states

When dependent values update in the wrong order, the scene, price or saved project can briefly contain an invalid combination. Define deterministic evaluation order and atomic accepted state.

Calling every exception configurable

A product can accept continuous values while still having engineering or site boundaries. Route exceptions to review instead of expanding the instant solution space without evidence.

Generating files without revision identity

A technically correct drawing can still be wrong for the current project if it belongs to an earlier configuration. Every job and result needs product, configuration and generator versions.

Testing only the default product

Most parametric failures appear at boundaries, unit conversions, repeated modules, optional interfaces and reopened historical projects. The regression set must represent the whole governed solution space.

Frequently asked questions

Parametric product configurator questions, answered precisely.

The answers separate continuous product parameters, modular composition, browser 3D, pricing, BOM, CAD automation and engineering review.

From parameter to controlled output

Prove the complete workflow with one real made-to-measure product.

Bring the product dimensions, option rules, source models, price examples and required quote, BOM or CAD handoff. Configurix can map the accepted parametric boundary around evidence your product, sales and technical teams can inspect.

Scope the representative product