Category: Uncategorized

A missing test report means the requested evidence has not been established in the review record. It is not, by itself, a failed test result. Keeping those states separate helps a technical team ask precise questions and avoids unsupported claims about either a proposed system or an alternative manufacturer.

State exactly what is unavailable

Identify the project requirement and the document requested to support it. Record whether no document was supplied, an extract was supplied or a cited document could not be obtained. For example, report requested; not yet received is a clear status. It should not be rewritten as untested or failed without evidence supporting that different statement.

Distinguish receipt from relevance

A received document can still leave the requirement unresolved if its named assembly or scope does not match the proposal. Record the reason the evidence does not yet establish the requested claim. Keep that status separate from the test outcome described in the document. A report about another configuration is a relevance gap, not proof that the proposed arrangement failed the same test.

Reserve outcome statements for actual evidence

If a document reports a result, cite the exact document and relevant section in the review record. Ask the responsible reviewer to interpret it within the test and project scope. Do not turn an incomplete comparison table into a pass or fail verdict. Avoid marketing conclusions about a competitor from an empty evidence field or an unanswered enquiry.

Ask a question that resolves the gap

Request the complete report, correct revision, assembly identification or clarification needed for the stated requirement. Identify who is following up and the date of the request. Keep the supplier response linked to the same evidence item. If the response remains unavailable, retain the unresolved status and refer the decision to the responsible project reviewer.

Preserve the final review decision

Record which evidence was eventually accepted, which differences remain and the conditions of any project decision. Keep evidence supplied, claimed performance and project acceptance as separate fields. A missing document can prevent a claim being substantiated without proving an adverse test outcome. A complete record explains what was known when the decision was made.

Working checklist

Example fields illustrate a record format; they are not a documented project, an approval or an installation instruction.

Related information

• Review the tested assembly
• Standard citations and evidence
• Request supporting evidence

A technical report is most useful when the assembly it describes can be compared with the assembly proposed for the project. Start with identity and scope before quoting a result. This checklist helps organize the review; it does not verify a particular Dseal product or replace the project reviewer's decision.

Establish the document identity

Record the issuing organisation, report number, date, revision and the named applicant or product. Obtain the complete document with referenced drawings and appendices where they are part of the report. If only a cover page or extract is available, state that limitation. Ask the issuer or supplier to resolve uncertain authenticity or missing information before relying on the result.

Find the assembly description

Identify the exact model, components and configuration described in the report. Compare the dimensions, orientation, supporting construction and installation details with the proposed assembly using the report's own terminology. Record differences rather than treating a shared product-family name as a match. An isolated material certificate cannot by itself describe every component in an installed system.

Read the test scope before the result

Note the test method and edition actually cited and the conditions covered by the report. A movement result should not be relabelled as proof of unrelated performance. For example, ASTM's public E1399/E1399M scope describes cyclic movement assessment and expressly limits what that method establishes. Follow the source link for its scope; the complete standard was not used to approve any product here.

Keep project differences explicit

Prepare a comparison with separate fields for the tested arrangement and the proposed arrangement. Ask the responsible reviewer what further evidence is required when substrates, transitions, sizes or other conditions differ. Mark an unanswered field unknown. Do not invent an allowable variation or transfer a result between assemblies simply because a supplier describes them as similar.

Retain the decision and evidence

Link each claimed requirement to its supporting report section and record the reviewer's decision, date and qualifications. Keep outstanding evidence separate from accepted information. A report citation is an input to review, not automatic project acceptance. Preserve the complete document and the actual proposed drawing revision so later changes can be evaluated against the same evidence.

Working checklist

Example fields illustrate a review record; they are not a documented project, a technical approval or an installation instruction.

Related information and sources

• ASTM E1399/E1399M public scope
• Build a comparison matrix
• Cross-reference finder limitations
• Request supporting documents

A cross-reference finder can help a reader locate a candidate for further comparison. It should be used as the start of a document review, especially when a project specification names a particular expansion joint model. A search result, family name or dimension is not evidence that two complete systems meet the same project requirements.

Start with an exact source reference

Record the manufacturer and full model designation from the specification or current document. Include the document date and relevant drawing or schedule reference. If the reference is incomplete, preserve it as incomplete rather than selecting the closest-looking name. A search using a partial family name may narrow the enquiry without identifying the intended assembly.

Treat a result as a candidate

Record the finder result and the date you accessed it, then request current documents for that exact proposed system. Do not label a candidate approved equivalent before the project review. The finder is part of Dseal's own information portal; it does not represent independent approval by another manufacturer or by a testing body.

Compare the actual assembly and conditions

Place the candidate documents beside the specified requirements. Identify the movement requirement, opening dimensions, installation substrate, traffic or loading conditions and relevant interfaces as defined by the project team. Record which items are supported, which differ and which remain unknown. Avoid inferring assembly performance from a material property or from an isolated matching dimension.

Ask for evidence tied to the claim

When a requirement calls for a test, rating or certificate, ask for the actual document and check the named assembly and scope. A standard number on a page does not establish tested compliance. If a document is missing or applies to another variant, record the gap and refer it to the responsible reviewer. Do not fill a comparison matrix with assumptions simply to make every cell look complete.

Keep the approval decision traceable

Retain the source reference, candidate, comparison documents, unresolved differences and reviewer decision together. Use the comparison matrix as a working record with revision dates. An accepted substitution is a project decision made through the applicable review process; a finder result cannot make it on its own. Request a documented response to material differences before changing the specified item.

Working record

Example entries illustrate the record format and are not a documented project or an approved technical specification.

Related information

• Dseal cross-reference finder
• Build a comparison matrix
• Standard citations and evidence
• Request supporting documents

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

References and next steps

• Standard citations and compliance evidence
• Equivalence document review checklist
• Dseal knowledge bank
• Contact Dseal about supporting documents

A standard citation names a reference; evidence of compliance shows what was assessed, how it was assessed and what the result covers. When reviewing an expansion joint submission, keep those two ideas separate. A brochure can help identify a proposed system, but a standard number printed beside it is not enough to establish that your project’s requirement has been met.

Start with the exact requirement

Record the standard designation, edition and the particular requirement stated in the project specification. Ask the responsible reviewer to clarify incomplete references. A hypothetical note such as ‘movement test required; report pending’ makes the gap visible without asserting a result. Different references can concern different properties, so avoid treating every standard citation as interchangeable evidence of movement, fire, water or loading performance.

Identify the type of evidence supplied

List each document as a technical data sheet, test report, declaration, certificate or design calculation, using the issuer’s own description. These documents have different purposes. ISO explains that it develops standards and does not provide certification or conformity assessment. When a submission refers to ISO certification, identify the actual issuing body and the certificate’s scope. Do not imply that ISO issued a product approval merely because an ISO standard is named.

Match the assessed item to the proposed system

Compare the exact product identity and configuration in the evidence with the proposal. Record any differences and ask for an explanation from the supplier and appropriate review by the project professional. For example, a report for one assembly should not silently be applied to another assembly. A document review can reveal a mismatch, but it does not itself establish the technical significance of that mismatch or approve the proposed alternative.

Record scope, conditions and unresolved points

Create a brief evidence register: claimed property, document reference, assessed item, stated conditions, reviewer and outcome. Mark ‘not supplied’ or ‘clarification required’ where needed. Keep report dates and revisions alongside the proposal revision. If an assessment covers only one property, do not broaden its conclusion into a claim about every project requirement. Refer acceptance questions to the responsible reviewer rather than filling a missing result with marketing language.

Use reference portals as starting points

The Dseal knowledge bank and standards page can help organise terminology and identify questions. They are owned-brand resources, not independent certification bodies. The earlier equivalence checklist helps compare an alternative against the actual project requirement and available documents. Request the complete supporting evidence for the exact proposed system and keep the review decision traceable. The useful output is a clear list of supported points and open questions, not an unsupported blanket statement of compliance.

References and next steps

• Dseal standards and codes reference
• Dseal expansion joint knowledge bank
• Expansion joint equivalence document checklist
• ISO explanation of conformity assessment

Expansion joint equivalence should be assessed against a project’s requirements, not inferred from a cross-reference name. A finder can identify a possible alternative for review, but the proposed assembly still needs supporting documents. This checklist helps architects, engineers and procurement teams organise that review without treating different products as automatically interchangeable.

Write the requirement before comparing products

Record the application, nominal opening, movement directions and required movement range. Add the installation geometry, adjoining finishes and service conditions. The selected criteria should come from the project’s approved design and specification. If a requirement is unclear, flag it for the responsible designer. Comparing two brochures before defining the requirement can lead to a persuasive-looking table that answers the wrong question.

Compare the complete assembly

Check the actual profiles, seals, fixings, accessories and transitions proposed. A similar cover width or material name does not show that two assemblies function alike. Ask how the system interfaces with waterproofing and other required components. If the proposal depends on a separate barrier or accessory, include that component in both the technical and commercial comparison rather than leaving it outside the schedule.

Trace performance claims to evidence

Request the current technical data sheet and applicable test or assessment documents for the exact assembly. Check the issuer, date, tested configuration and stated limits. Distinguish a cited standard from demonstrated compliance, and distinguish a planned certification from an issued certificate. For fire or other safety-critical requirements, have the appropriate project professional review the evidence and the installation conditions before approval.

Record differences and the approval decision

Use a comparison sheet with columns for the project requirement, original proposal, alternative proposal, document reference and unresolved question. Keep price and delivery information separate from technical acceptance. If a condition is not supported, record it as unresolved rather than filling the cell with an assumption. The reviewer should be able to see precisely which differences were accepted and who approved them.

Next step

Use the Dseal cross-reference finder to begin a document review, then work through the project’s requirements with the responsible team. The knowledge bank and standards guide can help explain the terms appearing in submissions. Third-party brand names identify products for comparison and do not imply endorsement or affiliation. An alternative should be accepted only through the project’s documented approval process, with the relevant conditions and supporting evidence retained.

• Start a cross-reference review
• Review standards terminology
• Explore the knowledge bank