An expansion joint comparison matrix puts the project requirement and each proposal’s evidence in the same structured record. It can reveal missing information without pretending that every product is equivalent. Build the matrix from the actual specification and documents supplied. This article describes a review aid, not an independent product test, scorecard or approval.
Make requirements the rows
Start with the project requirements rather than a list of marketing features. Give each row a requirement reference and state the source, such as a specification clause or approved drawing revision. Ask the responsible reviewer to clarify ambiguous wording. Avoid inventing performance thresholds merely to make the table look complete. A row labelled ‘requirement not yet confirmed’ is useful because it makes an unresolved decision visible.
Identify each proposal precisely
Use the exact system name, configuration and proposal revision as the column heading. Keep alternative configurations separate when the documents describe different assemblies. A generic brand column is too broad if several systems are offered. Record who supplied the proposal and when. A manufacturer’s catalogue may help identify a system, but the actual submitted configuration and current supporting documents must remain traceable.
Put document references in the cells
For each requirement, record the evidence reference and relevant scope rather than a tick alone. The previous standards article explains the difference between a citation and evidence of compliance. Use statuses such as ‘document supplied’, ‘clarification requested’ or ‘review pending’ when appropriate. Do not turn a brochure phrase into a verified test result. Where the evidence relates to another configuration, identify that difference for the responsible reviewer.
Keep acceptance separate from completeness
A complete-looking submission still requires technical review against the project requirement. Include a reviewer, review date and recorded outcome rather than calculating an invented overall score. One missing property should not be hidden by a strong result on another property. If a requirement is not applicable, record who confirmed that and why. The matrix should make decisions traceable, not make them automatically.
Maintain the matrix when proposals change
Retain the earlier revision and identify changed products, documents or requirements. Link clarification responses to the affected cells. Dseal’s knowledge bank is an owned-brand reference resource, and the equivalence checklist supports document comparison; neither replaces the project’s review process. Send the unresolved items with an enquiry for the exact proposed system. A useful matrix ends with supported points and named open questions, rather than an unsupported claim of universal equivalence.
A record you can adapt
| Requirement and source | Exact proposal | Evidence reference | Review status |
|---|---|---|---|
| Project requirement to be confirmed | Named system and revision | Document not yet supplied | Open |
| Confirmed requirement reference | Named assembly configuration | Document reference and scope | Reviewer decision pending |
Leave a Reply