A design change is a relationship problem

“Can we widen that window?”

It is a reasonable question and it takes about four seconds to answer badly. In a project delivered as a one-off design, the answer is worked out by the design team and coordinated outward. In a project delivered from a repeatable product, the same question has a hidden first step that determines everything after it: is this a choice the product already permits, an exception this project will carry alone, or a request to change the product?

Answer that wrong and nothing appears to go wrong for a while. A permitted selection treated as an exception generates unnecessary engineering. An exception treated as a permitted selection reaches fabrication without the review it needed. And a project fix quietly absorbed into the shared definition changes homes that nobody was thinking about at the time.

This report describes how K&K frames change control for repeatable residential construction: a product definition separated from project configuration, interfaces treated as the real product boundary, propagation classes with different response rules, freeze points that change what a change costs, and version evidence that closes the loop. It is the third of a series. The series hub sets out which parts of this can be delegated to software and which cannot, and the BIM-to-structural-analysis report covers what happens when a change reaches the engineering model.

Three layers, and the routing decision between them

Repeatability produces value only when variation is deliberate. That requires the project team to be able to say, for any proposed change, which of three layers it belongs to.

The product definition is what is the same across every instance: the structural logic, the panel and module grammar, the interface rules, the standard details, the qualified assemblies, and the parameters within which all of it has been engineered. It is versioned as a product, not as a project.

The project configuration is a set of choices made within the product definition for one property and one client — dimensions selected from permitted increments, options selected from a qualified list, arrangements assembled from a defined set of modules. A configuration change consumes no new engineering because the envelope it moves within was engineered in advance.

The project deviation is anything outside that envelope. It is not forbidden — sites and clients are legitimately varied — but it is engineered for this project, carried by this project, and does not become part of the product unless someone deliberately promotes it later, under review.

The routing decision is therefore a boundary test, not a taste judgment: does the request stay inside the declared configuration envelope? If yes, it is configuration and the response is a selection. If no, someone has to decide whether this project absorbs a deviation or the product itself should move. Those are different decisions with different owners, different evidence, and very different blast radii.

Interfaces are where the product is actually defined

Ask what a panelized housing product is and the intuitive answer is a set of components. The more useful answer is a set of interfaces. Components can be substituted, resized, and improved without disturbing anything else, as long as the interface they present stays the same. Move an interface and everything that was designed against it becomes a question.

In permanent panelized steel residential construction, the interfaces that carry the most weight are typically these:

• Panel-to-panel joints, including the alignment, fastening, and continuity conditions along vertical seams.
• The anchorage interface where the superstructure meets the foundation, which is also the interface between factory-controlled work and site-controlled work.
• Opening modules within a panel — the permitted positions and sizes for doors and windows, and the framing that supports them.
• Bearing lines, where floor and roof assemblies transfer load into wall panels.
• Service routing zones — the chases, cavities, and penetration areas where mechanical, electrical, and plumbing work is permitted to pass without a separate structural review.
• The transport envelope, which bounds panel dimension and weight, and the lifting and handling points designed with it.
• Finish and cladding attachment, which determines what can change in appearance without touching structure.

A change that stays inside an interface is usually cheap and local. A change that moves an interface is expensive regardless of how small the visible edit is, because the interface is what every other decision was designed against. This is the single most useful predictor of change cost in a product-based housing program, and it is knowable long before anyone estimates the work.

Two conceptual examples

These examples are illustrative and generic. They describe how the routing works, not the parameters of any particular K&K product.

Example one: a client asks to widen a living-room window by one permitted increment. Route it: the requested width is inside the declared opening-module envelope, so this is configuration. The consequences are real but contained. The opening framing within that panel changes to its corresponding qualified arrangement. The remaining solid length on that wall line is checked against the minimum the product requires. Glazing procurement changes to a different qualified unit with its own lead time. Cladding and trim quantities change. An electrical device on that wall may need to shift within its permitted zone. The fabrication information for one panel changes; every other panel is untouched. The transport envelope does not move. Field installation instructions change for one panel. Nothing crossed an interface, so nothing outside that panel had to be reconsidered.

Example two: a client asks to move the main service chase to the opposite side of the plan. Route it: service routing zones are an interface, so this crosses one. Now the question is no longer about one panel. Panels on both walls change their permitted penetration conditions. The floor and roof assemblies that carry service runs change. The structural check on the wall lines involved has to be revisited, because a routing zone and a bracing element are competing for the same wall length. Mechanical and electrical layouts change together, not independently. Fabrication information changes for a set of panels rather than one. And a question appears that example one never raised: is this a better arrangement that the product should adopt, or a project-specific accommodation? That question has to be answered explicitly by whoever owns the product definition — not settled by whoever is fastest to update a file.

The two requests take the same amount of time to say. They differ by roughly an order of magnitude in what has to be reviewed, and the difference was determined entirely by whether an interface moved.

Four propagation classes, four different response rules

Once a change is routed and its interface impact is known, it falls into one of four classes. Each has a different owner, a different evidence requirement, and — critically — a different rule about what must not propagate automatically.

1. Contained in configuration. The change stays inside the envelope and inside its interfaces. Response: apply it, regenerate the affected project outputs, and confirm by readback that the model now matches the configuration. It does not touch the product definition, and nothing about it should be inherited by other projects.
2. Interface-crossing, project-scoped. The change moves an interface for this project only. Response: engineering review before it is applied, an explicit record that this project now carries a deviation, and a list of every downstream artifact that has become stale. The deviation must be visible in the project record for the life of the building, because a future maintainer will otherwise assume the product’s standard condition applies.
3. Platform-affecting. The change modifies the product definition itself. Response: it is a product decision, owned by whoever owns the product, with engineering review against every instance the product supports — not just the project that prompted it. Its effective date matters more than its approval date, because projects already in progress were configured against the prior version.
4. Field-originated. A site condition, an access constraint, a supplier substitution, or a discovered discrepancy forces a change upward from the field. Response: capture the actual condition before it is concealed, route it through the same three classes rather than resolving it verbally, and distinguish clearly between an approved revision and an undocumented deviation. Our note on project records and operating handover covers what has to be captured for this to work, and site preparation planning covers the conditions that generate these changes most often.

A single request can produce more than one class at once. That is normal and worth naming explicitly, because a change that is contained for the client and platform-affecting for the product will otherwise be tracked only in the half that someone happened to notice.

The two directions of unmanaged propagation

Both of the serious failures in product-based change control involve a change travelling somewhere nobody decided to send it.

Upward, by accident. A clever project-specific fix is applied to a shared detail, a standard assembly, or a template because that was the most convenient place to put it. It is now the product’s behavior. It was reviewed against one site, one configuration, and one set of conditions, and it will be reproduced in situations that were never considered. This is the failure mode that makes a product line gradually stop being a product line.

Downward, without notice. A legitimate improvement is made to the product definition while several projects are mid-flight. Some of those projects have already released panels to fabrication. If the product update reaches their outputs silently, a project can end up with components produced against two different versions of the same definition — a condition that is very difficult to detect on paper and very easy to detect during installation.

The mechanism that prevents both is the same: a change has an effective version and a scope, projects are pinned to a stated version of the product definition, and moving a project onto a newer version is itself an explicit, recorded decision rather than a side effect of regenerating a file.

Version evidence: what actually closes a change

A change is not closed when someone approves it. It is closed when there is evidence that the systems of record now reflect it and that everything made stale by it has been dealt with. That evidence has five parts.

• Stable identity. The affected components keep the identifiers they had, or their replacement is recorded as a replacement. Recreating a component under a new identifier makes it look new to every downstream system; reusing an identifier for a different component makes old approvals appear to still apply. Both destroy the audit trail quietly.
• Dual authorization reference. The change names both the product-definition version and the project-configuration version it was made against. One without the other cannot answer the question that matters later: which combination produced this building?
• A difference set. An explicit statement of what changed between the prior accepted state and the new one — including things that kept their identifier but changed meaning, which is the category that ordinary comparison misses.
• Readback confirmation. Evidence retrieved from the receiving systems that they now contain the intended state: the expected objects exist, hosts and relationships survived, nothing unexpected duplicated or disappeared, and the outputs reference the new state rather than the old one. Applying an edit and confirming an edit are separate acts, as described in the native model readback report.
• A staleness list with dispositions. Every downstream artifact potentially invalidated — calculations, drawings, quantities, purchase records, fabrication releases, work packages, installation instructions — each marked as regenerated, reviewed and still valid, or accepted as an open item with an owner.

The staleness list is the part most often skipped and the part that most often causes trouble months later, because an obsolete artifact does not announce itself. It looks exactly like a current one.

What a practical change record has to answer

• What changed, in whose words, and why?
• Which layer does it belong to — configuration, project deviation, or product definition?
• Which interfaces does it cross, and which stay intact?
• Which product-definition version and which project-configuration version authorized it?
• Which freeze points had already passed when it was requested?
• Which downstream artifacts are now stale, and what is the disposition of each?
• What readback evidence confirms that the receiving systems reflect the new state?
• Is this a deviation this project carries, or a candidate for promotion into the product?
• Who accepted the remaining impact, and what did that acceptance cover?

Why this discipline is the point of repeatable housing

K&K’s residential work is organized around permanent panelized steel homes, subject to project-specific design and approvals. A project can define work for off-site preparation so that less has to be resolved from scratch in the field — but that benefit is entirely contingent on the definition being right and staying right between the moment it is approved and the moment components arrive at a property. Repetition is a multiplier, and it multiplies control failures as faithfully as it multiplies good decisions.

That is why change control in a product-based housing program is not administrative overhead sitting beside the engineering. It is the mechanism that makes the engineering reusable. K&K coordinates design and delivery interfaces with the required project professionals, and licensed roles remain specific to the jurisdiction. The wider delivery context — procurement, logistics, site readiness, installation, and handover — is described under our integrated project delivery capabilities, and the research connecting design geometry to production decisions is covered in our floor-plan-to-steel-frame research note.

Public boundary

This report describes an information-management and configuration-control method at a conceptual level. The examples are generic illustrations of routing logic; they do not describe the parameters, options, dimensions, or engineering of any specific K&K product, and no internal product identifiers, counts, or released engineering data are published here. Nothing in this report constitutes a design, an engineering opinion, a specification, or a statement of cost, schedule, or performance.

Project-specific design, engineering review, contractual notice, supplier approval, permitting, inspection, and field acceptance remain governed by the applicable agreements, professionals, and authorities. See our compliance and documentation practices, or contact us with the requirements and property conditions for a specific residential project.