Technology readiness levels explained: the nine steps read for software

A technology readiness level (TRL) is a nine-step scale describing how far a technology has moved from an idea to proven use. NASA created it in the 1970s; the European Commission's research programs use nine definitions, from basic principles observed (TRL 1) to a system proven in operation (TRL 9).

A procurement form asks for your supplier's technology readiness level. The pitch deck answers with a number and no evidence. Both sides are using a scale built for hardware, and neither has said what the number is supposed to prove. After reading this article, you will know where the scale comes from, what each of the nine levels officially means, how to read them for software, and which questions to ask before you accept a claimed level.

What is a technology readiness level, and where does the scale come from?#

A technology readiness level is a nine-step scale that describes how far a technology has moved from an idea to proven use in operation.

NASA states that it invented the system (opens in a new tab): its researcher Stan Sadin conceived the scale in 1974 with seven levels, which were not formally defined until 1989. In the 1990s NASA adopted a nine-level scale that gained wide acceptance across industry and remains in use today, running from TRL 1 to TRL 9 (NASA, Technology Readiness Levels Demystified, 2010, updated 2026). NASA describes each level as a stage in the evolution of an idea from a thought to the full deployment of a product in the marketplace.

The scale was written for hardware: instruments, materials and spacecraft. In that world, the word environment means physical conditions such as vacuum, vibration or temperature. That matters for software buyers, because the hardest judgments on the scale, what counts as a relevant environment and what counts as an operational one, were originally about test chambers, not running systems.

The European Commission uses the same nine definitions where a call or topic requires a TRL, in the Horizon Europe 2026-2027 General Annexes (opens in a new tab), Part 15, section B, and the same wording appeared in the Horizon 2020 annexes (European Commission, General Annexes, 2026). So the definitions you meet in a European funding application are the same ones a supplier may quote at you.

What the scale measures is how much of a technology has been shown, and in what setting. What it does not measure is quality, safety, security, support, price or commercial success. A level is a summary of evidence. Without the evidence behind it, the number is an adjective.

What are the nine technology readiness levels?#

The nine levels run from basic principles observed to a system proven in operation, and the official wording is short enough to quote in full.

The official wording is deliberately terse: each line states what has been demonstrated and where, nothing more. Read the scale as two moving parts. First, what exists: a principle, a concept, a prototype, a complete system. Second, where it was shown: a paper, a lab, a relevant environment, an operation.

The word environment does most of the work in levels 4 to 7, and the difference between relevant and operational is where most vendor claims blur. The annex also keeps a hardware exception in levels 5, 6 and 9 for key enabling technologies, which shows where the scale came from. One more caution: a single product can sit at different levels in different parts. A booking engine, a reporting module and a payment step mature at different speeds, so always ask which component a claim covers.

The software column below is a reading aid written for this article, not an official scale. The official column is the one to quote.

What do levels 1 to 4 mean when the technology is software?#

Levels 1 to 4 are about an idea becoming a tested mechanism, and in software the lab is a controlled machine, not a hotel.

TRL 1, basic principles observed, means someone has written down why the approach could work. For example, the principle that one room inventory can feed a hotel's own website, travel agencies and AI assistants at once. Nothing has been built; the observation is the evidence.

TRL 2, technology concept formulated, means a design exists. A data model, a written specification or a described workflow is enough. No code is required at this level, and a supplier at this stage should say so plainly.

TRL 3, experimental proof of concept, means a short script or a throwaway build shows the mechanism works on made-up data. This is evidence for the team, not a product for a buyer. TRL 4, technology validated in a lab, means working code tested on fixtures in a test environment: no real hotel, no real money, no real guest data, and no legal document leaves the system.

What to ask for at these levels: the design note, the test data, and the engineer who can explain the failure modes without notes. The common error is calling a clickable mock-up TRL 4. A mock-up shows a screen. A level 4 claim is about a mechanism that runs.

What separates levels 5, 6 and 7?#

The difference is the environment: a relevant environment at levels 5 and 6, an operational one at level 7.

TRL 5, validated in a relevant environment, means the component runs against realistic interfaces and realistic data volumes, still outside a customer's live operation. TRL 6, demonstrated in a relevant environment, means a full prototype runs end to end in a setting that resembles the real one. A demo environment with a fictional property is a relevant environment, for example, and it is an honest place to be.

TRL 7, prototype demonstrated in an operational environment, means it runs where the work actually happens, with real records, real staff and real consequences, even if a person confirms every step. A demo environment can reach level 6 and no higher, because nothing in it can fail in a way that costs someone money or breaks a legal duty.

A pilot is not automatically level 7 either. If the pilot runs on copied data in a separate system, it is still a relevant environment, not an operational one. This is the line vendors blur most often, because level 7 sounds like a customer and the honest answer usually sits one step below.

For a hotel, the operational environment includes the steps every stay involves: a payment, a fiscal document, a guest identity notification and personal data. Software that has not met those steps in the real world has not been proven in operation.

What do levels 8 and 9 actually prove?#

Level 8 means the system is complete and qualified, and level 9 means it is proven in operation. Neither says how many customers use it.

TRL 8, system complete and qualified, means every planned part exists and the system has been tested against its requirements, including the unglamorous ones: error handling, access control, backup and restore, and the documents a hotel must issue. Qualified is a testing word. It means someone wrote the pass criteria before running the tests, not that a reviewer liked the result.

TRL 9, actual system proven in an operational environment, means it runs the real work day after day, with real money and real legal records, and the failures that occurred were dealt with. What level 9 does not prove: quality, security, support, price, fit for your property, or that anyone else uses it.

One property running a system for a year is level 9 for that system in that property. It is not evidence that the same system works in a hotel with different rules, languages or reporting duties. The annex again keeps a hardware exception at level 9, competitive manufacturing or space, which is a reminder of what the scale was designed to describe. If you are turning levels into a purchase decision, pair them with a requirements document that makes vendor offers comparable.

Why does a level without evidence mean little?#

A level is a summary of evidence, so the useful question is never which level a supplier claims but what was shown, and where.

Ask for the environment, not the number: whose system, whose data, and who was watching while it ran. Ask what failed and what changed in the product as a result, because every step up the scale produces some failures, and a credible maturity claim includes them. Ask which part of the product the claim covers: a suite has parts at different levels, and the level of the strongest part is not the level of the whole.

Ask whether the pass criteria were written before the test ran, and who wrote them. Ask who outside the company can confirm the claim: a customer who is allowed to be named, an audit, or a published test set with its results. Then keep the answers next to the number in your own evaluation file. A number with a note beside it survives a change of account manager.

For AI-specific claims, these sit well alongside questions to ask an AI vendor before buying for your hotel.

Why AI Otel uses five status words instead of a level#

Because a level is a claim about evidence, AI Otel labels each component with one of five status words and leaves any level to whoever holds the evidence.

The five words are Live (Faaliyette), Built (Geliştirildi), In development (Geliştiriliyor), Architected (Tasarlandı) and Roadmap (Yol haritasında). Only OtelCiro, the ecosystem's hotel growth and consultancy arm, is Live. Each word points at something a reader can check. Built means working software ahead of launch, not software in customers' hands.

A single number would flatten the difference between a component that is designed and one that is working, which is exactly the difference a buyer needs to see. The full definitions sit in Built or live? The five status words AI Otel uses, and the words the company deliberately avoids sit in the words AI Otel does not use.

What to do next#

The next time a vendor document or an application form gives you a technology readiness level, ask one question before you accept it: in which environment was it shown, and who wrote the pass criteria? Write the answer beside the number. The scale is useful exactly to that depth, as a short way of pointing at evidence you have already seen, and misleading the moment it replaces that evidence. If you want to see how a supplier can describe maturity without a number, you can request a briefing.