Applied research: how to distinguish a laboratory result from a validated solution

The term applied research often appears in announcements about new materials, treatments, digital tools or production processes. It can describe work directed at a specific problem, but it does not by itself indicate that a finished product exists, that the solution has been tested with users, or that it is ready to be deployed. To interpret an announcement, it helps to separate two questions: what kind of research is being carried out, and what evidence supports the reported progress?

Minciencias defines applied research in relation to seeking solutions to identified problems and using knowledge to address needs. Its glossary also describes basic research in terms of generating knowledge, without requiring an immediate application. This is a distinction about the purpose of the work, not an automatic classification of its success, quality or proximity to market. (Minciencias: applied research; Minciencias: basic research)

In practice, the two approaches can be related: a basic research finding may provide an explanation or method that later supports an application, while a practical need may reveal scientific questions requiring further research. It is therefore more useful to read the label alongside the project’s objectives, methods and reported results than to treat it as a certification. “Applied” describes an orientation; it does not mean “validated”, “adopted” or “commercially viable”.

A persuasive project should explain what specific need it addresses, who experiences it and what change it expects to bring about. “Improve efficiency” or “solve a technological challenge” are too broad to judge progress unless the announcement clarifies which indicator is expected to improve, against what baseline and under what conditions. The objective need not promise a final solution; it should, however, make clear what result would matter and how it could be recognised.

The intended use matters too. A method that works on a prepared sample may be useful as a proof of principle, but that does not show that it will work with real-world samples, at scale, or under the constraints of the setting where it might be used. For a diagnostic tool, for example, it is worth asking which population and setting it targets; for an industrial process, what inputs, operating rates and controls it assumes. These questions guide the reader; they are not a claim that every project must pass an identical checklist.

Questions that clarify the claim

• What specific problem is the project trying to solve, and for whom?
• What use is proposed for the result: informing a decision, replacing a process or testing an application hypothesis?
• What indicator would make it possible to compare the result with current practice or a relevant alternative?
• Which conditions fall outside the scope of the announcement?

The answers help show whether an announcement describes a research objective, a technical demonstration or a solution with clearly defined users and context. A precisely framed problem prevents a local improvement from being turned, through overgeneralisation, into a promise of broad impact.

Evidence comes next. An announcement may report that a prototype was built, a laboratory result was obtained or an initial test was completed. These milestones can matter, but they do not answer the same questions. Look for what was done, with which materials or data, under what conditions and against what comparison. If an improvement is claimed, the reference point and the indicator need to be identified; if something is said to work, the observation supporting that description should be clear.

Validation conditions are part of the result. A controlled test can isolate variables, but it may differ from the setting in which the solution would be used. It is worth finding out whether the work tested a sample, an integrated prototype or a complete system; whether tests were repeated; and whether the team reported failures, uncertainties or constraints. This is not a merely semantic distinction: each stage answers different questions. A demonstration may show that something is possible under certain conditions without yet establishing that it will be robust, safe or reproducible in other settings.

Look for supporting evidence, not just the headline

Give priority to technical publications, project reports or methodological documentation that allow the result to be traced. Check whether the announcement distinguishes observed data from future objectives, and whether it describes sample size and origin, evaluation criteria and relevant limitations. When these details are unavailable, the prudent conclusion is not that the result is false, but that the published information does not make it possible to assess its scope with confidence.

Technology maturity scales can help organise the path from an idea or demonstrated principle to systems tested in contexts closer to actual use. In an announcement, a reference to a maturity level is interpretable only if the scale is identified, the evidence used to assign the level is explained, and the evaluator is named. Without these elements, an isolated number can sound more conclusive than it is.

Even when a stage is clearly described, technical maturity alone does not answer questions about demand, costs, regulation, safety, manufacturing or maintenance. A technology may work in a test and still face adoption barriers; it may also be useful in a limited setting without being ready for broad deployment. A scale organises evidence about development; it does not certify commercial success or replace an impact assessment.

The materials available for this article do not include a specific official source with which to verify the levels, criteria or equivalences of any particular scale. For that reason, no numbers are attributed here and no thresholds are presented as facts. If a project mentions a scale, readers can consult the document issued by the body or programme that uses it and compare its criteria with the published tests. The absence of that detail limits comparisons between announcements, but does not in itself invalidate the work described.

A prototype gives tangible form to a proposal and makes it possible to observe how a solution behaves, but its mere existence does not demonstrate that it consistently meets its intended use. Validation means relating tests to defined requirements: what the system was supposed to do, under what conditions and according to which criteria it was considered successful. Adoption raises other questions, such as integration into existing processes, user training and ongoing support. Not every project needs to follow an identical path, but these milestones should not be presented as interchangeable.

When reading an announcement, pay attention to the verbs. “Is proposed”, “will be developed” and “is expected to be evaluated” describe objectives; “was built” or “was observed” point to activities or results that still need context; “was validated” requires details of the requirements and tests used. “Was implemented” should specify where, for how long and on what scale. If a report provides none of these details, it is reasonable to limit the conclusion to what is actually documented.

A short checklist

• Problem: Is it defined precisely enough to show whom it affects?
• Result: Is it described as knowledge, a method, a prototype or an integrated system?
• Test: Are the context, comparison and success criterion explained?
• Limitations: Are untested conditions, uncertainties or relevant failures disclosed?
• Next step: Is what has already been achieved distinguished from what is still proposed?

This process does not assign a score to the project. It helps ensure that public communication does not lead readers to infer deployment, effectiveness or impact from a preliminary result.

Applied research connects knowledge with a need for use, but the extent of that connection must be assessed in the details. A well-framed problem and a relevant objective explain why the research is being done; the method, test conditions and verifiable results make it possible to assess what has been demonstrated so far. Published limitations show where that conclusion ends and what work remains.

When comparing projects, there is no need to demand that every one has reached a commercial product. Research can contribute value by showing that an approach merits further testing, identifying an obstacle or producing evidence useful to a later decision. The key is to describe that contribution precisely: an experimental advance can be significant without yet constituting a solution validated for real-world use.

Minciencias’ definitions help distinguish the applied orientation from the basic one, but they do not rate individual projects. To assess a specific announcement, readers need to return to its documents and check whether the evidence supports the verb chosen. When the validation context, scale used or relevant comparison is unknown, the responsible approach is to state that uncertainty rather than fill the gap with a promise of adoption.