Open designs can make instruments inspectable and adaptable. The harder achievement is transferring a trustworthy measurement, not merely a printable shape.
The second instrument is the real test
A research group can publish a beautiful instrument and still leave another laboratory unable to reproduce the measurement. The drawings may download perfectly. The printed enclosure may fit. The software may launch. An image may appear on the screen. None of those achievements, separately or together, establishes that the second machine answers the same scientific question with comparable reliability. The difficult transfer is not a collection of files. It is a relationship between an object, an operating procedure, an observation and an interpretation.
That is the public-interest promise of open scientific hardware: more people can inspect how a measurement is made, adapt the apparatus to local needs and challenge assumptions that would otherwise remain inside a sealed product. It is also the promise most easily oversold. An open design does not eliminate scarce skills, unreliable suppliers, calibration work or the need to pay somebody to maintain a system after the original student graduates.
Recent projects make the question concrete. The TWINKLE two-photon microscope paper, published on February 13, 2025, presents an instrument alongside design and implementation resources rather than treating construction as an undisclosed preliminary. Its supporting approach includes computer-aided designs, parts information, optical modeling and instructions. That makes it a useful example of an inspectable research platform, not evidence that every reader can safely reproduce its optical performance or that its historical cost estimates remain current procurement quotes. TWINKLE original research.
This article examines what should travel with an open instrument if another laboratory is expected to use it responsibly. The proposed acceptance tests and handoff practices below are editorial recommendations, not a claim that every cited project already implements them. They focus on reproducible measurement, maintenance and accountable adaptation. They are not construction instructions for lasers, electrical equipment or clinical devices.
Open is a permission structure, not a performance grade
The Open Source Hardware Association's definition distinguishes editable design sources from the intermediate files used to manufacture something. It calls for the preferred form for making changes and a clear statement of which parts of a design are covered. It also recognizes that physical production still consumes resources. These distinctions matter because a downloadable object is not automatically an open design: access to a printable output may not provide the information needed to modify its underlying geometry. OSHWA definition.
Permission answers one question: what may another person do with the design? Measurement evidence answers another: what happened when a particular implementation was tested? A project can be generous about rights yet immature in validation. A proprietary instrument can have excellent performance evidence while offering little opportunity for inspection. Neither distinction disappears merely because one model is politically or economically more attractive to a particular laboratory.
CERN's Open Hardware Licence illustrates the legal side without resolving the scientific one. Its current version offers strongly reciprocal, weakly reciprocal and permissive variants. The existence of those choices does not certify the accuracy of an instrument carrying a licence notice, nor does it settle which licence fits every collaboration. The relevant documents must be evaluated for the intended distribution arrangement, separately from laboratory qualification. CERN Open Hardware Licence.
For an editor, funder or purchasing committee, the practical consequence is to maintain two columns. One records rights, accessible source files and dependencies. The other records demonstrated capability, test conditions and limitations. Combining them into a single openness score would conceal important tradeoffs. A laboratory needs both enough permission to act and enough evidence to know whether acting will produce a useful result.
Define the scientific job before comparing machines
Imagine a fictional network of teaching laboratories considering a shared open microscope. One instructor wants students to understand how an image forms. Another wants to compare the apparent dimensions of prepared specimens. A third hopes to monitor a changing sample over time. These are related activities, but they create different acceptance criteria. A machine that is excellent for revealing the optical path may be awkward for unattended imaging. An automated stage may help the third instructor while adding needless complexity for the first.
The network should therefore write its scientific job as a sentence before it selects a design. What is being observed? Over what range? Under which environmental and operating conditions? What distinction must the result support? What failure would change the conclusion? A sentence such as “students should see small structures clearly” is an educational aspiration, not yet a measurement specification. It does not say whether the same structure must be recognizable across machines or whether any numerical comparison will be attempted.
The CubEd paper, published on March 21, 2025, describes a modular fluorescence microscope developed for classroom use, with an educational emphasis on connecting optical theory and practical construction. Its authors frame visibility and accessibility of the system as teaching advantages. That is a different design goal from demonstrating that an instrument is interchangeable with every research microscope. The paper's stated purpose should guide how the project is evaluated. CubEd original article and author abstract.
In the fictional network, separating those goals prevents a familiar procurement mistake: buying or building the most elaborate system and then discovering that its complexity interferes with the actual lesson. Scientific suitability begins with the question, not the length of the features list.
The design release should describe an actual machine
A repository is often a moving target. One file may reflect an improved mount, another the previous motor, and an assembly photograph a prototype that was never released. Even if every file is individually useful, the collection may not describe a configuration that ever existed. The second laboratory then becomes an unacknowledged integration team, discovering compatibility problems that the original authors already solved elsewhere.
A stronger handoff identifies a release that corresponds to a tested physical build. Its design files, software, firmware, parts list and assembly documentation are connected by explicit version identifiers. The release explains whether the published measurements came from that exact configuration or from an earlier prototype. If differences exist, it names them rather than relying on the reader to infer them from photographs.
The point is not to freeze development permanently. It is to give change a reference. A laboratory should be able to improve a component while retaining a clear account of what changed and which earlier conclusions remain applicable. Without a reference build, a later disagreement can dissolve into speculation: perhaps the optics differed, perhaps the firmware changed, perhaps somebody used another material. Each possibility may be reasonable, but together they make the disagreement expensive to resolve.
A useful release also distinguishes required components from optional ones. A decorative enclosure, a protective housing and a structural support can look similar in a rendered image while having very different roles. Documentation should make those roles legible. Otherwise, a builder may replace something that appears cosmetic but actually controls alignment or environmental exposure. The file package should reduce the number of hidden judgments demanded of the next person.
Editable geometry and manufacturing evidence are different assets
An editable model allows a builder to change dimensions. It does not tell that builder which dimensions may change without affecting the experiment. Conversely, a manufacturing file can specify a shape precisely while concealing the design decisions behind it. Both kinds of information can be valuable, but they serve different users and should not be treated as substitutes.
Consider a hypothetical instrument bracket. Its visible outline might be unimportant, while the relationship between two mounting surfaces determines whether a component can be adjusted reliably. A builder working with a different local manufacturing process may need to alter the outline but preserve that relationship. A purely visual imitation could look faithful and behave poorly. A documented functional constraint would make a more substantial local redesign possible without losing the purpose of the part.
The proposed documentation should therefore pair geometry with intent. Which surfaces locate a component? Which features permit adjustment? Which regions carry loads? Which dimensions were actually inspected on the tested build? These are conceptual questions, not a request to publish hazardous operating procedures. They help distinguish design knowledge from the mere possession of a shape.
Manufacturing evidence should remain attached to the implementation that generated it. If a laboratory changes the material, fabrication method or finishing process, that alteration belongs in the build record. The original design may remain a valuable starting point, but its validation should not silently migrate to a materially different object. Open adaptation becomes scientifically useful when it makes differences easier to examine rather than easier to overlook.
A substitute part is a hypothesis
Parts lists age. A supplier changes a product, a component becomes unavailable, shipping becomes impractical or a local workshop offers a different fabrication route. An open project that assumes permanent access to one exact commercial item can become difficult to reproduce even while its files remain online. This is a reason to document function and interfaces, not a reason to pretend every replacement is equivalent.
The fictional teaching network should classify substitutions by what they could affect. Some changes may influence only appearance. Others may alter positioning, signal response, thermal behavior, software compatibility or protection against hazards. The category determines the evidence needed before the modified machine is used for its intended task. A replacement should enter the record as a proposed equivalence, then acquire a narrower or stronger status through testing.
This does not require every builder to repeat every experiment in a paper. It requires a defensible connection between the change and the test. If the alteration concerns repeatable positioning, a successful startup screen is irrelevant evidence. If it concerns a data interface, a mechanical inspection cannot establish that records are complete. The test should challenge the property that the substitution could plausibly disturb.
An especially useful contribution from a second laboratory is a documented substitution that works within a stated scope. Such a contribution expands the practical design space for future builders. An undocumented replacement does the opposite: it may rescue one machine locally while leaving the community with a misleading impression that the original configuration has been reproduced. The difference is not generosity of intention. It is whether the adaptation creates transferable knowledge.
The software is part of the instrument
Scientific hardware is sometimes photographed as if the apparatus ends at the cable. In practice, control and analysis software can determine which observation is collected, when it is collected and how it is represented. A reproducible mechanical assembly paired with an unspecified software environment is an incomplete handoff. The machine may still run, but the relationship between its settings and its output can become difficult to reconstruct.
Collins and colleagues' OpenFlexure software work, first posted in January 2021 and revised that September, describes a client-server architecture using a web interface consistent with the Web of Things approach. The author abstract emphasizes cross-platform control and integration rather than requiring one proprietary control environment. The architectural contribution is useful evidence about how access can be organized; it is not a guarantee that every connected deployment has identical timing, security or maintenance characteristics. OpenFlexure software-stack research.
For the fictional network, a software manifest should identify the release used to acquire the teaching data, the relevant configuration and the route by which settings enter the saved record. It should also explain what happens when an operation fails. A silent retry, a skipped frame and an explicit stop can produce very different datasets even if the interface eventually displays a reassuring completion message.
The crucial distinction is between being able to issue a command and knowing what actually occurred. A documented control interface supports the first. Event records, output validation and tests of failure behavior support the second. Rebuilding a measurement requires attention to both, especially when a later user will analyze the data without having watched the apparatus operate.
Coordination can matter as much as individual components
A collection of individually functional parts does not automatically form a reliable experiment. The stage can move, the detector can record and the illumination can respond, yet their coordination may still be wrong for the scientific question. A system-level test asks whether those components act together in the intended order and whether the record preserves enough information to recognize a departure from that order.
The UC2-ESP preprint, submitted on October 26, 2025, presents a general-purpose electronics and firmware framework for controlling microscopy components. Its author abstract describes multiple interfaces and integration with microscopy software. That establishes the authors' proposed control approach, not independently verified performance for every device combination. This article relies on the abstract for that limited description and does not infer timing benchmarks from the presence of supported interfaces. UC2-ESP author preprint.
In the hypothetical network, the transfer package could include a benign coordination test with expected event ordering and a clear definition of an incomplete run. The exact test would depend on the intended experiment. A teaching demonstration that acquires a static image has different needs from an experiment that relates observations to a changing process. The important editorial recommendation is that coordination assumptions should be testable rather than buried in a script.
This also changes how upgrades are evaluated. A software improvement that makes one component faster might alter the assumptions of the overall sequence. The desirable question is not simply whether the new version has more features. It is whether the combination still supports the measurement claim for which the instrument is being used.
An attractive image is not an uncertainty statement
The most persuasive demonstration of a new microscope is often a striking image. Images are valuable evidence, but they can invite conclusions that their production record does not support. A selected image may show that a configuration achieved something under particular conditions. It does not by itself characterize repeatability, variation across the field of view or differences between independently built machines.
Zehrer and colleagues' automated fluorescence microscope work reached its version of record in March 2024, after earlier reviewed preprints. It provides an example of a modular open instrument evaluated in a specific research configuration. Its evidence should be connected to that tested arrangement rather than promoted into a universal performance claim about any system assembled from related parts. Automated fluorescence microscope original research.
For the teaching network, the relevant question is what information students are expected to extract. If the lesson concerns recognizing structures, the evaluation should reflect that task. If students will compare dimensions, the evaluation needs to address how those dimensions are obtained. If they will compare image intensity, the package must explain which settings and processing choices affect the comparison. A single demonstration image cannot stand in for all three purposes.
A good gallery therefore includes the less glamorous material that makes interpretation possible: acquisition conditions, processing descriptions and an explanation of how examples were selected. It may also include failed or borderline observations with commentary. Showing the edge of a system's capability can be more useful to a new laboratory than another image taken comfortably within its best operating range. The goal is not to diminish the achievement. It is to make the achievement usable.
Traceability belongs to a result
NIST's metrological guidance makes a distinction that is especially important in discussions of inexpensive instrumentation: traceability is a property of a measurement result, not an automatic badge attached to an instrument or laboratory. It depends on a documented calibration chain and associated uncertainty. NIST also distinguishes traceability from fitness for a particular purpose; a result can have a traceable basis while remaining too uncertain for the decision at hand. NIST metrological traceability policy and questions.
That distinction prevents two opposite mistakes. The first is to dismiss an open instrument because its appearance does not resemble a costly commercial system. The second is to assume that including a calibrated component makes every downstream result trustworthy. Neither appearance nor component pedigree supplies the missing account of how a particular result was produced.
The fictional network can translate this into a simple communication practice. Every numerical result used for comparison should travel with an explanation of what was measured, how the reported value was obtained and what limits the confidence placed in it. The level of detail can match the teaching purpose. A classroom exercise need not pretend to be an accredited service, but it should not teach students to erase uncertainty merely because the interface presents a precise-looking number.
A useful educational instrument may therefore be one that makes uncertainty discussable. Students can learn why two apparently identical machines disagree, which differences matter and what further evidence would resolve the disagreement. That learning opportunity is lost when a project markets openness as freedom from the ordinary obligations of measurement. Open access should expose those obligations, not abolish them.
Test the documentation with somebody who did not write it
The original designer knows things the documentation may never say. A slightly awkward connector is familiar. An ambiguous drawing is interpreted correctly because the designer remembers the prototype. A software warning is ignored because its harmless origin is known. When that person demonstrates a successful rebuild, they may unknowingly supply the missing instructions through memory and intuition.
The second-builder test is intended to reveal those omissions. A person outside the design team attempts the defined, appropriately supervised task using the released package. Questions and interventions are recorded. The result is not a competition in which the builder must struggle silently. It is a structured investigation of what the documentation assumes. An intervention can be entirely appropriate while still showing that the written handoff needs improvement.
The fictional network should distinguish three outcomes. A documented step may be followed successfully. A step may succeed only after clarification. Or the builder may find that the package cannot support the intended action. Treating all three as a completed build would discard the most useful information from the exercise. The clarifications are precisely what future laboratories need.
This method also improves credit. The second builder contributes knowledge about reproducibility, not just free labor. Their observations can become a versioned improvement to the release, with acknowledgement and a clear account of what changed. That creates a healthier collaboration than presenting replication as a one-way test of whether another laboratory is sufficiently competent to follow instructions that have never been tested independently.
Separate building success from measurement agreement
Suppose each laboratory in the fictional network completes its instrument. The network now has several working machines, but it has not yet established how their results compare. A common evaluation can help distinguish local construction problems from differences in operating practice or interpretation. The design of that evaluation should follow the scientific job rather than the desire to produce a flattering agreement plot.
One possible exercise would use shared, stable teaching materials and a predeclared acquisition plan. Each laboratory would retain its raw observations and record departures from the plan. A central comparison could examine whether differences follow the machine, the operator or the analysis choices. This is an illustrative proposal, not a report of a completed study or a claim that one test can validate every use of a microscope.
The network should decide in advance what counts as a meaningful disagreement. If the acceptance rule is invented after seeing the results, the exercise risks becoming a search for a favorable description. If the rule is so strict that it has no relationship to the teaching purpose, the evaluation may reject perfectly useful equipment. The acceptance threshold should serve the intended conclusion, not the project's reputation.
Disagreement is not necessarily a failure of openness. It can be the first visible evidence of a problem that would otherwise remain hidden inside separate laboratories. The value of the shared design is that investigators may have enough information to trace the discrepancy. Reproducibility improves when a disagreement becomes diagnosable, not when every report is required to look harmonious.
Electrochemistry shows why the principle is broader than microscopy
Open scientific hardware is not limited to instruments that produce images. Dryden and Wheeler's DStat paper, published in October 2015, presents an open-source potentiostat and reports its design and evaluation. It is an example of making an electronic measurement platform inspectable and adaptable. Its existence does not establish that any homemade circuit is suitable for every electrochemical task, or that a published comparison remains valid after arbitrary substitutions. DStat original research.
The broader lesson is about where interpretation enters the chain. A microscope turns an interaction with light into an image that a person or program interprets. An electronic instrument produces a signal that also depends on settings, interfaces and processing. Different physical mechanisms create different failure modes, but the handoff problem is recognizable: another laboratory needs to know what the apparatus did, not merely what its enclosure looks like.
This comparison should not flatten the disciplines into a generic checklist. A test appropriate for one measurement system may be irrelevant to another. Instead, the shared framework can organize the questions while leaving technical acceptance criteria to qualified domain expertise. Identify the claimed result, identify the implementation, identify the observations that support it and identify the changes that would require renewed evaluation.
That separation is important for public communication. A story about open instruments should not imply that successful work in one field proves universal affordability or readiness elsewhere. It should show how a particular project made a previously opaque process easier to inspect, and where inspection still leaves substantial work to be done.
Clinical ambitions require a different conversation
Knapper and colleagues' 2024 account of developing the OpenFlexure microscope toward medical use explicitly addresses both technical and social challenges. The paper describes an ongoing development and validation effort, not a universal authorization to use any locally assembled version for diagnosis. The distinction is central to reading the project responsibly. A research platform, a useful educational device and a clinically qualified implementation are not interchangeable categories. OpenFlexure development toward medical use.
The fictional teaching network should keep its own scope equally clear. If an instrument is intended only for supervised education, its documentation should not drift into claims about patient care because the underlying technology has medical associations. A photograph of a familiar kind of specimen can create that implication even when the accompanying text avoids it. Captions and demonstrations deserve the same discipline as formal specifications.
A useful public-interest question is who bears responsibility when the intended use changes. A designer may publish a platform for research. A local group may adapt it. Another organization may incorporate it into a service. Each step can introduce new obligations and risks. Openness makes the chain more visible only if participants document their roles rather than treating the original authors as an unlimited source of implied assurance.
This article does not provide regulatory or clinical advice. Its recommendation is organizational: mark boundaries of intended use, preserve the evidence that supports each claim and seek the relevant qualified review before moving into higher-stakes applications. An accessible design can be an important starting point without being the final answer to every institutional requirement.
Count the cost of a usable instrument
A parts total is not the same as the cost of a functioning capability. The latter can include assembly labor, training, tools, unsuccessful iterations, test materials, documentation and maintenance. The balance varies between institutions. A workshop that already has appropriate expertise faces a different project from a school that must create that capacity from scratch. A meaningful comparison states the starting conditions instead of presenting one universal savings figure.
The fictional network should produce two budgets. The first records the additional resources needed to create the first accepted instrument. The second records what is needed to keep it useful over an agreed period. Neither budget requires invented precision. Ranges and explicit exclusions are more honest than a narrow total that omits the work most likely to consume staff time.
There is also a distribution question. An open design may reduce dependence on a distant vendor while increasing dependence on one local expert. That can still be a worthwhile trade, but it should be recognized. If only one person knows how to restore the system, the organization has exchanged one form of fragility for another. Documentation and cross-training are part of the economic model, not optional acts of community spirit.
The strongest case for open hardware may therefore differ by setting. One laboratory values modification. Another values repairability. A teaching group values visibility of the mechanism. A regional collaboration values local production and shared expertise. These are legitimate benefits even when the lowest quoted parts price is not the decisive advantage. Evaluating the whole capability makes the argument more credible, not less ambitious.
Maintenance needs an owner and a record
A project can be open and abandoned. The files may remain downloadable while the software dependencies become difficult to install and the named components disappear from suppliers. The original authors may have moved on for perfectly understandable reasons. The institution adopting the instrument should therefore distinguish access to a design from a promise of continuing support.
For the fictional network, the maintenance agreement would identify who can approve changes, who keeps a known-working configuration and who records problems that affect results. A repair log would connect an intervention to the tests performed afterward. The point is not to create paperwork for every cosmetic adjustment. It is to prevent a substantive change from becoming invisible to the next person interpreting the data.
The network should also plan for departure. A student or technician who built the instrument may leave. Before that happens, another person should demonstrate that they can locate the relevant documentation, identify the installed version and carry out the authorized routine checks. This is a continuity exercise, not a demand that every staff member become a designer.
A mature handoff includes a retirement condition as well as a maintenance plan. Some systems will cease to be worth supporting. Keeping them in service merely because their construction was a point of pride can expose users to confusing or unreliable results. Openness includes the freedom to stop using a design when its evidence or support no longer fits the task. A well-documented retirement can be as responsible as an enthusiastic new release.
Preserve the failures that teach another builder something
A polished project page naturally foregrounds success. A useful technical record also retains problems that have explanatory value. Not every failed experiment belongs in a public repository, and sensitive information may need protection. But a recurring incompatibility, a misleading assembly instruction or a substitution that changed behavior can save another laboratory substantial effort if described accurately.
The best failure report separates observation from diagnosis. What happened? Under which configuration? What was expected? Which tests were performed? What explanation remains uncertain? A confident but incorrect diagnosis can spread more confusion than an honest unresolved report. The record should make room for later correction without erasing the original observation.
The fictional network could use a small set of issue categories: documentation ambiguity, component compatibility, software behavior, measurement discrepancy and maintenance difficulty. These categories are proposed organizational tools, not a claim that all projects should adopt the same tracking system. Their purpose is to help future users find relevant experience rather than searching through an unstructured discussion for a familiar symptom.
There is a cultural benefit as well. When competent builders publicly describe difficulties, newcomers are less likely to interpret every problem as personal failure. That can improve participation without lowering scientific standards. The appropriate message is not that every build will succeed. It is that an honest account of why a build did not meet its intended purpose can still be a valuable contribution to the shared instrument.
Decide what remains local and what should travel
Openness about an instrument does not require indiscriminate publication of everything it encounters. A shared design may be used with confidential research samples, identifiable participant information or commercially sensitive material. The fictional network should distinguish the instrument's reproducibility record from the contents of any particular experiment. Conflating the two could create an unnecessary choice between protecting people and documenting the machine.
For a public demonstration, the network could use non-sensitive teaching material and publish the resulting validation record. For restricted work, it could retain the relevant operating and configuration information under appropriate access controls while making clear which evidence an outside reader cannot inspect. This is an editorial proposal for organizing disclosure, not a claim that a particular privacy rule applies uniformly across institutions. Decisions about actual restricted data require the relevant institutional expertise.
The same distinction applies to remote access. A browser interface may make an instrument easier to share, but convenient access is not equivalent to a decision about who should be allowed to operate it or view its outputs. The organization should assign those permissions deliberately. A visitor who can inspect a public design need not receive authority over a live machine. A collaborator who can run an approved experiment need not see every other user's records.
Good public documentation can explain the boundary without publishing secrets. It can state which functions are available, how responsibility is assigned and where restricted evidence is retained. That is more informative than presenting the instrument as either completely open or completely closed. Different layers can have different disclosure requirements while the scientific claims remain precisely stated.
A final question is whether a future user can distinguish a missing file from an intentionally withheld one. An explicit inventory helps. It can identify a public calibration example, a restricted experimental dataset and an unavailable historical record as three different things. Without that distinction, outsiders may mistake an access limitation for evidence that the work was never performed, or mistake an attractive public example for a complete archive. Clear boundaries preserve trust while avoiding the false promise that every aspect of every experiment can or should be downloadable.
The handoff package is a scientific product
Conceptual editorial framework: access, rebuilding, testing and fitness for use are distinct achievements. No observed quantities. Context: OSHWA and NIST sources linked in article.
At the end of the fictional network's pilot, the most important deliverable would not be a photograph of several matching microscopes. It would be a package connecting a defined use to a reproducible configuration and a defensible evaluation. The photograph can communicate participation. The package communicates what another laboratory can reasonably expect to learn, reproduce or change.
That package would contain the release identifiers, editable design sources, manufacturing outputs, parts information and software configuration. It would explain the intended task, the relevant checks, the known limitations and the changes made locally. It would preserve representative raw observations and the analysis needed to understand the reported result. Where some material cannot be shared, the omission and its consequences should be stated rather than hidden behind a general claim of openness.
The acceptance summary should be readable without reconstructing the entire development history. It should distinguish what was demonstrated from what remains an aspiration. A visitor should be able to tell whether the instrument was independently rebuilt, whether its measurement behavior was compared and whether the comparison addressed the visitor's own intended use. Those are different achievements, each worth reporting accurately.
The deeper opportunity is to treat the instrument's reproducibility record as part of the scientific output. A design that another laboratory can inspect is useful. A design that another laboratory can adapt responsibly is more useful. A design whose results can be challenged, explained and renewed after change is the stronger achievement. Open scientific hardware earns its promise when the next builder receives not only the freedom to make a machine, but the means to understand what that machine can honestly say.
Evidence and publication notes
Evidence checked November 1, 2026. This is an original analytical longread, not a newly announced experimental result. The newest research hooks discussed are from 2025; older works are explicitly dated. Ten distinct primary institutional or original-research sources are linked in the body. UC2-ESP, the OpenFlexure software stack and CubEd are described only within the author abstracts and metadata inspected; no inaccessible benchmark details are asserted. The original OpenFlexure 2020 article route encountered a browser challenge and is not used as evidence. The fictional teaching-laboratory network and its proposed evaluation are illustrative, not a reported deployment. No independent clinical approval, current price, safety certification or universal performance claim is made.