Field note: Technology Readiness Levels provide a shared vocabulary for maturity, but a single number can conceal disagreement about the critical technology, relevant environment, evidence quality, integration, and operational readiness. The value lies in the assessment record behind the level.
Operational question
What specific technology is being assessed, in which intended environment, and what objective evidence demonstrates the claimed maturity?
A workable method
- Identify critical technology elements. Decompose the system and select elements whose immaturity could drive performance, cost, schedule, safety, or integration risk.
- Define the relevant environment. Describe physical, digital, human, regulatory, and operational conditions. “Relevant” should not be inferred from a convenient laboratory setup.
- Build an evidence package. Link tests, configurations, results, anomalies, limitations, independent review, and exit criteria. Record what was demonstrated, not what is planned.
- Assess integration separately. A mature component may create system-level risk when combined with other technologies, users, data, procedures, or supply chains.
What this looks like in practice
A decision-support algorithm may perform well on historical data, while the deployed sensing pipeline, user interface, fallback procedure, and monitoring remain immature. A system-level claim should not inherit the algorithm’s strongest evidence.
Evidence to collect
Choose a small set of measures before implementation. Record the baseline, the source of each measure, the review cadence, and who is authorized to act on the result.
- quality and relevance of readiness evidence
- closure of critical technology gaps
- integration risks not represented by the headline level
Field checklist
- Write the decision, accountable owner, and decision date.
- Describe the current workflow and the conditions that shape performance.
- Confirm the source hierarchy, permissions, and local requirements.
- Test the method under representative—not merely convenient—conditions.
- Review both intended outcomes and burden on the people doing the work.
- Record a change, escalation, and stop rule before results arrive.
Watch-out
Do not average TRLs or use them as schedule percent complete. Readiness is ordinal, evidence-dependent, and specific to a technology and intended application.