Technology Readiness Levels

What are technology readiness levels and why should you care

Technology Readiness Levels (TRLs) are a framework for talking about the maturity of a new technology. They’re widely used at NASA and the various branches of the Department of Defense but not many other places. We should change that.

If we’re going to be building more things, we need a common language around technology maturity. A common language would enable people to swap useful mental models more quickly between domains. At the same time, TRLs can help frame the difference between domains and help you realize when it doesn’t make sense to impose an idea from one domain onto another - for example why MVPs work beautifully in software but much less so in hardware. Adopting TRLs as a common language would have several other practical advantages that I outline in the ‘Upshots and Constraints Section.’

I reformulate the each TRL in a way that’s as technology-agonstic as possible (‘Breadboard’ just wouldn’t go away) and sketch out what each level might look like in different domains. These sketches are meant as a starting point, not a complete illustration.

The Nine Technology Readiness Levels

I’ll go up and down the ladder of abstraction by first listing them, giving an example of how a single technology might go through the nine levels, and then expanding on what each level entails. Broadly, you could put the nine levels into three buckets I’m going to call ‘Tinkering’, ‘Systemization’, and ‘Commercialization.’ Each of these buckets needs a different approach, cost, and management style.¹

Tinkering
TRL1 - Basic Principles Observed and Reported
TRL2 - Possible application formulated
TRL3 - Proof of Concept
Systemization
TRL4 - Breadboard version in lab
TRL5. Breadboard version in relevant environment
TRL6. Prototype version in relevant environment
Commercialization
TRL7 - Prototype version in real environment
TRL8 - Production version tested in real environment
TRL9 - Production version operating in real environment

For a kerosine rocket engine, this might look like

1. Notice that kerosine tends to explode (TRL1)
2. Posit that kerosine could be used to launch rockets (TRL2)
3. Use kerosine to produce enough force to lift something into the air (TRL3)
4. Have a separate pump, compressor, and nozzle that produce force (TRL4)
5. Put the separate pump, compressor, and nozzle in a vacuum chamber (TRL5)
6. Create a one-off assembly of those pieces and show they still work in the vacuum chamber (TRL6)
7. Launch that assembly as a secondary payload and show it still works in space (TRL7)
8. Manufacture the actual rocket and launch something with it for the first time! (TRL8)
9. Launch all the things.

TRL 1 - Basic Principles Observed and Reported

In the world of atoms TRL1 is reporting on an observed phenomenon. In the world of bits TRL1 means showing the properties of an algorithm and maybe writing some pseudocode.

In the world of people, TRL1 may be where you observe singular aspects of human behavior, like “ people have these cognitive biases.” If observational studies are TRL1, it means that people who try to operationalize those studies are literally skipping almost every other TRL. It might suggest that if we actually fleshed out a path through TRLs for people land we would get closer to Psychohistory.

TRL2 - Possible application formulated

TRL2 is where people speculate about the possible uses of a technology. On its surface TRL2 seems like the easy rung of the TRL ladder - you don’t need to do any actual work! You can just sit around and smoke some cigars and come up with these ideas.

This is doing TRL2 terribly. TRL2 is secretly hard because it’s very easy to just check the box and go on. TRL2 is the design step.

To do TRL2 well, you need to talk about the constraints on the applications that you’re formulating. You need to actually break it down into a framework that then informs further work. What are the limitations? What does the roadmap look like?

Without TRL2, TRL3 is worthless because TRL2 needs to precisely define which concepts need to be proved in TR3. Perhaps another way to frame TRL2 is the step where you convert the unknown unknowns into known unknowns. Another possible way to think about TRL2 is that it is the step where you say “X can be used for Y” - essentially describing the effect observed in TRL 1 in the “inventive manner” outlined by Genrich Altshuller in the TRIZ Method.

TRL3 - Proof of Concept

If TRL 2 is saying that you can use X for Y, TRL 3 is showing that you can use X for Y.

A ‘toy’ system would be is at TRL3. Toy systems are usually a system whose entire purpose is to show that X can be used for Y .

If the attempt to create a proof of concept doesn’t work, you might need to go back to TRL2 and form a new application hypotheses. Or evenTRL1 with the knowledge that you now need to know something crucial that you didn’t know before. This is why TRLs are not monotonic.

TRL4 - Breadboard version in lab

This is the first time that you assemble all the components of the ‘real’ system. You need to have at least a simulacra of every piece of the real system. The ‘lab’ part of the description means that every simulacra component of the real system is under your control. The ‘breadboard’ part of the description means that the interfaces between the components can both be hacky (maybe it’s just someone copying over a text file) and completely instrumented - the analogy is that in a breadboard interface you can easily put alligator clips and measure any interface.

To look at TRL4 in software, let’s take a credit card fraud detection algorithm as an example. You need to have at least a simulacra of every part of the customer facing piece, etc. In health focused biotech, the ‘lab’ would be cells in a petri dish.

TRL5 - Breadboard version in relevant environment

The difference between TRL5 and TRL4 is that you’re now in a ‘relevant’ environment. What does it mean to go to a ‘relevant’ environment? It has to do with giving up control over the exact inputs. You still have meta-control over the environment but you can’t control exactly the inputs that the environment creates for the system.

In a software context this could look like the first time you let a real customer or someone not on the dev team use the system. In health-focused biotech, the ‘relevant’ environment would be a mouse or similar animal that’s a proxy for humans.

TRL6 - Prototype version in relevant environment

The difference between TRL6 and TRL5 is that now you’re using a prototype instead of a breadboard. What’s the difference between a prototype and a ‘breadboard version?’ It’s all about the interfaces and the container.

In electronics you would go from a breadboard to a PCB. This transition makes the interfaces between the components clean and automatic. In a software context this would mean that all the interfaces resemble what they would be in the final version - automatic, using an api or something similar to ship data around instead of manually copying text files.

TRL7 - Prototype version in real environment

The difference between TRL7 and TRL6 is that it’s in a ‘real’ environment instead of a ‘relevant’ environment. In traditional NASA TRLs ‘real’ means ‘space’ but it turns out many technologies aren’t intended to be used in space. Yet.

The between a relevant and a real environment is the difference between someone using the system while you’re standing over their shoulder and can guide them through the process or fix something that goes wrong to actually letting your baby fully go. So this means someone using an app on their own phone, installing the software on a customers server etc. In human-focused biotech this is where Human Clincal trials begin ie. Phase 1 trials.

Note that it’s conceivable that trying to go from TRL6 to TRL7 could send you all the way back to TRL4 if there is a fundamental piece of the system that needs to be ripped out and replaced.

TRL8 - Production version tested in real environment

The difference between TRL8 and TRL7 is that now that you’ve upgraded from a ‘prototype’ to a ‘production version’

In software this has a connotation of a lot more testing but it’s possible that the difference is just semantic - merging from master to prod.

For physical technology - both in biology and outside the difference has a lot to do with manufacturability. A prototype technology can be and is often hand-built, while a production version needs to be manufacturable at whatever scale it’s expected to be used. Note that this makes it easier for high-value, low-volume physical goods to make the jump to TRL8 more easily. Many of the components flown in actual space are hand-made. The jump from TRL7 to TRL8 is one that regularly kills kickstarted consumer electronics projects because figuring out how to redesign the product so quality doesn’t drop while still being able to manufacture at scale is really hard and expensive.

TRL9 - Production version operating in real environment

A TRL9 technology is just a TRL8 technology that has been in the field long enough to have operational problems surface and fix them.

Technologies never move beyond TRL9. Instead, the expected number of operational problems just decreases exponentially over time. This is the realm of learning-by-doing improvement and Kaizen.

Upshots and Constraints

Seeing where software cheats can suggest places for atoms to explore

Modern software can push out live updates into a real environment and has low deployment costs so you can bundle TRL6→TRL8 together and skip straight to TRL9. This TRL6→TRL8 bundle is nothing but your classic MVP. The corollary is that if you’re dealing with a technology that can’t bundle together TRL6→TRL8 in a useful way, MVPs are much less useful. I’ve seen this too often where either someone puts pressure on a hardware team to just “get an MVP out!” that ultimately wastes time and doesn’t derisk anything. Or, on the flip side, a team proudly announcing that they have a biotech MVP doesn’t get nearly as much out of it as a software team would have.

This sounds like a dour prognostication, but the MVP example has an actionable bright side. It hints that looking precisely at places where software cheats on the TRL ladder could shine light places where technologies in the world of atoms could aim for so that it could also skip rungs on the ladder. Software updates for electronics is the tame example, but you could start asking questions like “could we make reconfigurable buildings?” “What about live-updating DNA sequences?”

A new light on project and program management

TRLs provide a backdrop to the evolution of software development and why you can’t just port software practices directly to other domains. Through the lens of TRLs, the much-derided waterfall development just looks like planning out how you’re going to proceed through each level. Waterfall makes complete sense for high-capital-cost projects like spacecraft or consumer electronics. The complexity and costs associated with moving from one level to the next also highlights the value of project management, which has become a bit of a lost art outside of the domains that are already using TRLs. Agile development makes complete sense in light of software’s ability to skip levels and cycle between them cheaply. However, it also means that you can’t just port agile to other domains and expect it to work as well. TRLs illustrate that planning and project management are still important and perhaps there is room to create new development methods depending on a domains unique constraints.

Better communication

A common language around technology maturity could enable people to swap useful mental models more quickly between different domains. At the same time, TRLs can help frame the difference between domains and help you realize when it doesn’t make sense to impose an idea from one domain onto another. Finally, the language of TRLs can help set expectations about how developed technologies actually are. Instead of the manic optimism and technological winters of hype cycles, a shared language around technology development could help us smoothly ramp up long term projects to build the future.

Note: This is some ‘intellectual exhaust’ from an ongoing exploration into how we can build new institutions to enable more sweet sci-fi shit.

Thanks to Jason Crawford and Martin Permin for feedback on this essay