How Technology Readiness Works | From Proof of Concept to Operational Capability — TRL, Integration, Manufacturing and Deployment Evidence

A technology can work brilliantly in a laboratory and still be nowhere near ready for the world that has to depend on it.

That gap is the reason technology readiness exists as a serious engineering question.

At the beginning, the question is simple: is the underlying idea real? Later, the questions multiply. Can the technology work outside the laboratory? Can it survive the intended environment? Can it integrate with the rest of the system? Can it be manufactured repeatedly? Can technicians maintain it? Can the supply chain support it? Can users operate it safely? Can institutions approve it? Can failures be detected and recovered from? Can the capability still work when the original inventors are no longer standing beside it?

Technology Readiness Levels—usually shortened to TRLs—provide one well-established way to describe technical maturity. NASA uses a nine-level scale from basic principles observed at TRL 1 to an actual system proven through successful mission operations at TRL 9. ESA also uses a nine-level framework and states that its scale follows ISO 16290. Those systems are enormously useful because they force evidence to become progressively more representative as a technology matures.

But one number cannot answer every readiness question.

A technology can be technically mature and still have weak manufacturing readiness. A subsystem can work and still integrate poorly. A product can be fully engineered and still lack training, maintenance, regulatory approval, supply-chain depth or operational support. A technology proven in one environment can still require adaptation before transfer to another society or use case.

Readiness is not “does the technology work?” Readiness is “what evidence exists that the capability can work, repeatedly, inside the system and environment that will actually carry the consequence?”

This article belongs to eduKateSG’s How Technology Works spine. Its owner job is technology readiness as a decision system: how evidence should progress from principle to prototype to representative environment to operational capability, and how technical readiness must align with integration, manufacturing, operations, people, supply, maintenance and governance before deployment. It does not replace How Engineering Prototypes Work, which owns prototype fidelity and learning; How Technological Maturity Works, which owns the wider evolution of established technological trajectories; or the specialist engineering owners for verification, validation, integration, failure and reviews.

1. Readiness is evidence about the next commitment

Technology development becomes more expensive as it moves toward real systems.

Early research can test an idea with limited equipment. Later stages may require integrated prototypes, representative facilities, manufacturing tooling, field trials, certification, training, operational support and large capital commitments.

Readiness assessment exists partly to answer a practical management question:

Has enough uncertainty been retired to justify the next, more expensive step?

That makes readiness a bridge between engineering evidence and resource commitment.

2. Technology Readiness Levels are a maturity scale, not a victory ladder

TRLs are often spoken about as though higher always means better.

That is too simple.

A low TRL can be perfectly appropriate for exploratory research. A high TRL is valuable when deployment requires demonstrated maturity. The number does not describe quality in the abstract. It describes how far evidence has progressed relative to a maturity framework.

The right TRL depends on the decision being made.

3. NASA’s nine-level scale begins with observed principles

NASA’s current public Technology Readiness Level guidance describes TRL 1 as the point where basic scientific research is beginning to be translated toward possible applications.

At this stage, there may be no working technology yet.

The evidence is about principles: does the underlying science exist, and can a plausible technological direction be formulated from it?

4. TRL 2 turns principles into a technology concept

At TRL 2, practical applications are formulated from the basic principles.

The concept may still be speculative. The important shift is that the research now points toward a possible technological use.

There is an idea worth investigating, but not yet strong experimental proof that the critical mechanism will work as required.

5. TRL 3 asks for proof of concept

NASA describes TRL 3 around analytical and experimental proof of critical function or characteristic.

This is the point where the project begins moving from plausible explanation toward demonstrated feasibility.

The correct question is narrow: does the critical idea work at all?

The engineering-prototype owner explores this learning stage in much greater depth: How Engineering Prototypes Work.

6. TRL 4 begins integrating components in the laboratory

At TRL 4, the question expands.

Individual principles are no longer enough. Components must begin working together.

This is a crucial change because integration creates new failure modes. Timing, interfaces, power, heat, data and mechanical compatibility can fail even when each component works independently.

7. TRL 5 moves toward a relevant environment

NASA’s public descriptions associate TRL 5 with more rigorous validation in conditions that are increasingly representative of reality.

The phrase relevant environment matters enormously.

A laboratory can prove many things while removing temperature variation, vibration, network latency, contamination, operator variation, real loads, supply interruptions or other conditions that define actual performance.

Readiness grows when the evidence begins to include the parts of reality capable of overturning the laboratory conclusion.

8. TRL 6 demonstrates a representative model or prototype

By TRL 6, NASA describes a system or subsystem model or prototype being demonstrated in a relevant environment.

The project is no longer asking only whether the principle works. It is asking whether a sufficiently representative configuration can perform under sufficiently representative conditions.

This is one reason TRL 6 often becomes an important decision point: the evidence is beginning to resemble the real system rather than the isolated mechanism.

9. TRL 7 enters an operational environment

At TRL 7, the prototype is demonstrated in an operational environment.

Now the technology must face real interfaces, real users, real operating constraints and real environmental interactions.

Operational demonstration is powerful because it reveals the difference between a system engineered to work and a system that actually works inside the world around it.

10. TRL 8 completes and qualifies the actual system

NASA describes TRL 8 as the actual system completed and qualified through test and demonstration.

The significance is configuration.

The evidence is no longer primarily about a representative prototype. It is about the actual system in the configuration intended for use.

11. TRL 9 requires successful operational use

At TRL 9, NASA describes the actual system as proven through successful mission operations.

This final step matters because there is always a difference between qualification before operation and evidence accumulated during operation.

The world remains the final environment.

12. ESA also uses a nine-level TRL framework

The European Space Agency publishes a nine-level Technology Readiness Level framework and states that its implementation follows the ISO 16290 TRL scale.

This matters because it shows how the TRL idea has travelled beyond one agency while still requiring precise definitions within the organisation applying it.

TRL labels look universal. Their operational interpretation still depends on the adopted standard, domain and evidence rules.

13. Do not compare TRLs without comparing definitions

A TRL 6 reported by one organisation should not automatically be assumed equivalent to a TRL 6 elsewhere.

Ask:

Which TRL standard or organisational definition is being used?
What hardware or software configuration was assessed?
What environment was considered relevant?
What evidence was required?
Who performed the assessment?
Was the technology assessed alone or inside the intended system?

The number is shorthand. The evidence record is the real substance.

14. TRL is about maturity, not total programme readiness

This is the most important distinction in the article.

A technology can achieve strong technical maturity while the programme remains unready to deploy it.

Manufacturing may be immature. Supply may be fragile. Training may be unfinished. Integration may be incomplete. Regulation may be unresolved. Cybersecurity may be inadequate. Maintenance capacity may not exist.

TRL answers a vital question. It does not answer every readiness question.

15. GAO treats readiness assessment as an evidence discipline

The U.S. Government Accountability Office’s Technology Readiness Assessment Guide describes Technology Readiness Assessments as systematic ways to evaluate whether critical technologies are mature enough for integration into larger systems and acquisition programmes.

GAO emphasises not only maturity but the quality of the assessment itself: credible, objective, reliable and useful evidence.

This is a crucial upgrade from treating readiness as a label.

A readiness claim is only as good as the process that produced it.

16. A self-awarded readiness level is weak evidence

Development teams naturally know their technology best.

They are also exposed to schedule pressure, sunk cost and optimism.

Strong readiness processes separate evidence from enthusiasm. They define criteria before assessment, preserve configuration identity, state the environment, document gaps and make uncertainty visible.

17. Critical technologies deserve separate readiness attention

Large systems contain many technologies.

Not every one deserves the same readiness scrutiny.

The important targets are technologies whose immaturity can materially threaten system performance, cost, schedule, safety or mission outcome.

This concentrates assessment effort where uncertainty has consequence.

18. Readiness is configuration-specific

A technology is not simply “TRL 6” forever.

Change the material, software version, architecture, scale, operating temperature, manufacturing process or intended environment and some previous evidence may no longer travel completely.

Readiness belongs to a defined technology configuration under defined conditions.

19. Readiness is environment-specific

A system proven indoors is not automatically ready outdoors.

A system proven at low traffic is not automatically ready at national scale. A sensor proven in a mild climate is not automatically ready in salt, heat or humidity. A software service proven with test data is not automatically ready for real privacy, identity and security constraints.

Environment is part of the readiness claim.

20. Readiness is use-case-specific

The same technology can be ready for one application and unready for another.

A camera system may be adequate for counting objects and inadequate for a safety-critical control decision. A battery may be suitable for stationary storage and unsuitable for an application with extreme weight constraints.

The consequence level changes the evidence burden.

21. The readiness vector: one number is rarely enough for deployment

For reader clarity, this article uses a readiness vector rather than pretending there is one universal official multi-axis standard.

The vector asks teams to inspect several dimensions separately:

technical readiness;
integration readiness;
manufacturing readiness;
operational readiness;
human readiness;
supply-chain readiness;
maintenance readiness;
data and cybersecurity readiness;
regulatory and institutional readiness;
financial and scaling readiness;
context-transfer readiness.

This is an explanatory systems map, not a replacement for NASA, ESA, ISO, DOD, GAO or any organisation’s formal readiness framework.

22. Technical readiness asks whether the technology itself works

Technical readiness is the closest dimension to the classic TRL question.

Has the core mechanism been demonstrated? Are performance claims measured? Has behaviour been observed under relevant conditions? Is the configuration representative enough for the decision?

This is necessary.

It is not sufficient for deployment.

23. Integration readiness asks whether the technology works with everything else

Systems fail at joins.

A technically mature component may draw too much power, produce data in the wrong format, create thermal problems, conflict with existing software or behave unpredictably when several subsystems respond simultaneously.

Integration readiness asks whether the technology can live inside the intended architecture.

The specialist owner is How Engineering Integration Works.

24. Manufacturing readiness asks whether one success can become repeatable production

A prototype can be assembled by expert engineers using selected components and hand tuning.

Production asks a different question:

Can many units be produced consistently, at the required quality, rate and cost?

GAO has discussed Manufacturing Readiness Levels as a complementary way of assessing manufacturing maturity and risk, including design stability, materials, process capability, quality management, tooling, facilities, workforce and supply-chain readiness.

This makes an important point: technology readiness and manufacturing readiness can move at different speeds.

25. A hand-built prototype can hide production difficulty

Engineers can sometimes make one unit work by selecting the best parts, adjusting tolerances manually and correcting defects as they appear.

A factory cannot depend on heroic adjustment at every station.

Manufacturing readiness requires a process capable of producing acceptable variation repeatedly.

26. Production rate is part of readiness

A process that can produce ten units per month may not be ready for a requirement of ten thousand.

Rate changes equipment, staffing, quality control, supplier capacity, inventory and defect-detection needs.

Manufacturing readiness therefore includes the intended scale of production, not merely the existence of a manufacturable design.

27. Supply-chain readiness asks whether the required inputs actually exist when needed

A technology can be mature while its supply chain is fragile.

Critical materials may have long lead times. A single supplier may control a component. Specialised tooling may exist in only one facility. Export controls, transport constraints or quality variation may threaten continuity.

Deployment readiness therefore needs a supply map.

The general owner is How Supply Chains Work.

28. Supplier qualification is readiness evidence

Knowing that a component can be produced is weaker than knowing that approved suppliers can produce it consistently.

Readiness grows when suppliers, specifications, inspection methods, acceptance criteria and alternate sources are understood.

Supply is part of capability.

29. Operational readiness asks whether the organisation can actually run the system

An engineered system does not operate itself simply because testing is complete.

Operations need procedures, staffing, monitoring, escalation, incident response, spare capacity, maintenance windows, permissions and decision authority.

Operational readiness asks whether these surrounding arrangements exist before dependence begins.

30. The operator is part of the technology system

If normal operation requires expert intuition that only the development team possesses, the system is not ready for ordinary operation.

The knowledge must move into procedures, training, interfaces, alarms, diagnostics and support systems.

Readiness grows when exceptional expertise is converted into repeatable organisational capability.

31. Human readiness asks whether users and maintainers can carry their part of the system

Technology can be technically ready and socially unusable.

Users may not understand the interface. Operators may experience excessive workload. Maintainers may lack diagnostic skills. Managers may not know when to escalate. Training may exist but fail to cover abnormal situations.

Human readiness converts technical capability into usable capability.

32. Training completion is not the same as human readiness

A training course can be completed without competence being demonstrated.

Readiness evidence should ask whether people can perform representative tasks, recognise failures, recover safely and know the limits of their authority.

Attendance is an input. Performance is stronger evidence.

33. Maintenance readiness asks whether the technology can stay ready

Deployment is an event.

Sustainment is a life.

Maintenance readiness asks whether faults can be diagnosed, parts can be replaced, calibration can be maintained, software can be updated, technical documentation is current and service capacity exists at the locations where failures will occur.

A technology that cannot be maintained is temporarily ready.

34. Spare parts are readiness inventory

Spare parts look like logistics.

They are also uptime.

If a predictable failure disables the system for six months because one replacement component must be custom manufactured overseas, operational readiness was overstated.

35. Data readiness matters when technology depends on information

Modern systems increasingly depend on data quality, availability, permissions and continuity.

A technically mature algorithm can be unready if the deployment environment cannot supply reliable input data. A sensor network can be unready if timestamps are inconsistent. A forecasting service can be unready if key records arrive too late.

Data is an operational input, not an afterthought.

36. Cybersecurity readiness grows when attack paths become part of engineering evidence

Connectivity creates capability and exposure together.

Authentication, access control, software update mechanisms, dependency management, logging, incident response and recovery should be considered before a connected technology becomes operationally essential.

A system can be functionally ready and security-unready.

37. Regulatory readiness asks whether the capability is permitted to operate

Some technologies require licences, certifications, safety cases, privacy controls, professional approvals or environmental permissions.

Technical completion does not create legal permission automatically.

Regulatory readiness therefore belongs in the deployment path from the beginning rather than appearing as a late administrative surprise.

The general owner is How Technology Is Governed.

38. Institutional readiness asks who owns the decisions

Who may approve deployment?

Who may stop operation? Who owns maintenance? Who handles incidents? Who pays for renewal? Who decides whether a failed subsystem can continue in degraded mode?

If these questions have no clear owner, the technology may be technically mature and institutionally immature.

39. Financial readiness asks whether the capability can survive its own economics

A technology may be affordable to buy and unaffordable to operate.

Licences, energy, consumables, maintenance, replacement parts, specialist staff and insurance can dominate lifecycle cost.

Deployment readiness therefore needs an honest total-cost model.

40. Scaling readiness asks whether the system survives multiplication

A pilot with twenty users can work because experts watch every interaction.

A national service cannot.

Scale changes queueing, support demand, supplier capacity, network load, storage, governance, cybersecurity and failure consequence.

The scaling owner is How Technology Scales.

41. Context-transfer readiness asks whether evidence survives the move

Technology proven in one organisation or society may face different climate, infrastructure, language, law, labour skill, supply chains and user expectations elsewhere.

The receiving context can invalidate assumptions that were invisible in the source environment.

The specialist owner is How Technology Transfers Between Societies.

42. The weakest critical readiness dimension sets the real deployment risk

Suppose a technology is excellent technically but poor on manufacturing readiness.

Or fully manufacturable but dependent on one unavailable material.

Or operationally sound but impossible to maintain locally.

The programme is not rescued by averaging the scores.

For critical dependencies, readiness behaves more like a weakest-link system than a school report card.

43. Readiness should not be averaged across hard blockers

Imagine ten readiness dimensions scored from one to ten.

Nine dimensions score ten. Safety readiness scores two.

An average of 9.2 does not make the system ready.

Some dimensions are non-compensatory. A severe blocker cannot be offset by excellence elsewhere.

44. Readiness alignment matters more than the highest individual score

Programmes sometimes over-mature one dimension while neglecting another.

The technology may continue improving in the laboratory while manufacturing remains uncertain. Software may become feature-rich while operational monitoring remains weak. A pilot may expand while maintenance procedures are still improvised.

Readiness alignment means maturing dimensions together enough that the next system-level step is coherent.

45. Over-maturity can waste resources

More technical refinement is not always the best next investment.

If the critical blocker is manufacturing, another laboratory performance improvement may add little deployment value.

The readiness map helps move resources toward the limiting uncertainty.

46. Readiness debt accumulates when deployment moves faster than support capability

A programme can push a technology into use before all support systems are mature.

Sometimes this is deliberate and justified.

But the missing training, documentation, monitoring, spare parts, security hardening or maintenance capacity does not disappear. It becomes readiness debt.

Like technical debt, readiness debt creates future work and risk.

47. Emergency deployment can accept readiness debt—but should name it

There are situations where waiting for ideal readiness creates greater harm than deploying an imperfect capability.

The disciplined approach is not to pretend the gaps do not exist.

Name the temporary controls, operating restrictions, additional monitoring, fallback systems and conditions that must be completed later.

Urgency changes the risk trade-off. It should not erase the evidence record.

48. Prototype success is not deployment readiness

A prototype can answer a question without being ready for production.

It may use temporary parts, expert operators, ideal environmental conditions and manually cleaned data.

The prototype has succeeded if it reduced the intended uncertainty.

The mistake is allowing its success to support a larger claim than its configuration deserves.

49. A polished demonstration can be readiness theatre

Demos are designed to reveal capability.

They are often run under conditions selected to reduce failure.

Readiness requires the opposite instinct: deliberately search for the conditions under which the technology stops being dependable.

Readiness is not theatre. It is adversarial curiosity about the boundary of performance.

50. Representative environments should be chosen from failure mechanisms

“Realistic” is too vague.

A relevant environment should contain the conditions capable of changing the conclusion.

If temperature drives failure, represent temperature. If vibration matters, represent vibration. If user workload matters, use representative users and tasks. If network interruption matters, test it. If supply latency matters, include it in the operating scenario.

Environment design should follow the causal model of failure.

51. Operational environments expose hidden compensations

Laboratory teams often compensate unconsciously for weak design.

They restart services manually, adjust equipment, interpret unclear signals and repair faults immediately.

Real operations reveal whether the system can function without constant expert rescue.

52. Readiness evidence should become harder to fake as maturity rises

Early evidence can be analytical and experimental.

Later evidence should increasingly come from representative hardware, software, environments, users and operations.

The evidence burden grows because the claim grows.

53. Readiness claims need an evidence pedigree

For every major readiness claim, ask:

What exact configuration was tested?
Which requirements were represented?
Which environment was used?
What was simulated?
What was manually supported?
Which users or operators participated?
What data was collected?
Which limitations remain?
Which future change would invalidate the conclusion?

This turns “we tested it” into a traceable engineering statement.

54. Readiness should be attached to claims, not adjectives

Words such as mature, proven, production-ready, field-ready and deployable sound precise and often are not.

A stronger statement says exactly what has been demonstrated.

For example: “The subsystem maintained required output for 500 hours under the defined temperature and load profile.”

Evidence-rich sentences travel better than readiness adjectives.

55. Verification and readiness answer different questions

Verification asks whether specified requirements have been satisfied.

Readiness asks whether the accumulated evidence is sufficient for the next commitment or operational use.

A verified component may still be unready for integration if surrounding systems are unstable.

The specialist owner is How Verification Works.

56. Validation and readiness answer different questions

Validation asks whether the realised system is suitable for the intended use and stakeholder need.

Readiness includes that concern but also asks whether production, operations, support, institutions and other dependencies can carry the system into sustained use.

The specialist owner is How Engineering Validation Works.

57. Technological maturity and technology readiness are not the same

Technological maturity describes how an established technology has evolved: dominant designs, accumulated process knowledge, slowing architectural change, reliability and performance ceilings.

Technology readiness is decision-relative: is this configuration ready enough for this next use, integration or deployment?

A mature technology can be unready for a new context. An immature technology can be ready enough for a bounded experiment.

See How Technological Maturity Works.

58. Scale readiness can regress after a design change

A redesign can improve performance and reduce readiness.

New components may require new suppliers. New software may need revalidation. New materials may change manufacturing. New interfaces may break compatibility.

Readiness is not monotonic when the technology itself changes materially.

59. Configuration change can reopen closed evidence

Suppose a battery chemistry changes after qualification.

The new chemistry may improve energy density while changing thermal behaviour, charging, transport rules, supplier qualification and end-of-life handling.

The programme should not carry every old readiness conclusion forward automatically.

60. Software readiness is especially configuration-sensitive

Software can change much faster than physical hardware.

A minor-looking update can alter dependencies, resource use, timing, interfaces or security behaviour.

Readiness processes therefore need version identity, regression testing and rollback capability rather than a one-time certification mindset.

61. AI systems make readiness especially multidimensional

An AI model can perform well on a benchmark and still be unready for a real workflow.

Deployment may depend on data quality, evaluation, human oversight, privacy, security, latency, cost, monitoring, failure escalation, update control and domain-specific validation.

This is a useful example of why a capability can be technically impressive while operational readiness remains incomplete.

62. Benchmark readiness is not workflow readiness

A benchmark simplifies reality into a measurable test.

That is valuable.

But real workflows contain interruptions, ambiguous inputs, changing goals, human judgement and consequences that may not appear in the benchmark.

Readiness requires testing the system where the work actually happens.

63. Readiness gates should be tied to decisions

A readiness review without a decision becomes ceremony.

Every gate should answer something:

Continue research?
Build a prototype?
Increase environmental fidelity?
Freeze an interface?
Invest in manufacturing tooling?
Begin a pilot?
Enter limited deployment?
Scale?
Hold?
Redesign?
Terminate?

The gate exists to change action based on evidence.

64. A gate should have entry evidence and exit criteria

Teams should know in advance what evidence is required to pass.

This reduces the temptation to redefine success after the test.

Strong gates state required configuration, environment, performance, unresolved risks, owner approvals and follow-up work.

65. Readiness should be allowed to HOLD

Binary pass/fail systems can create perverse pressure.

Sometimes evidence is incomplete rather than negative.

A HOLD state allows teams to say: the technology may be viable, but the evidence needed for this decision does not yet exist.

Uncertainty should not be forced into optimism or rejection.

66. Readiness reviews need dissent

Projects create momentum.

Teams become invested in success. Sponsors expect progress. Schedules become public.

Readiness assessment improves when reviewers can challenge assumptions without being punished for slowing the programme.

Independent challenge does not guarantee truth. It reduces one class of organisational bias.

67. The evidence should survive the meeting

A readiness review should leave behind more than a slide saying “green.”

The decision record should preserve the configuration, evidence, open risks, assumptions, dissent, conditions and next actions.

Future teams need to understand why the programme believed it was ready.

68. False readiness signal: the calendar says it is time

A schedule can tell you when you planned to be ready.

It cannot prove readiness.

If evidence is missing, moving the milestone does not mature the technology.

69. False readiness signal: most tests passed

Pass percentage is weak if the failed test covers the critical function.

Readiness depends on consequence-weighted evidence, not simple test counts.

Ninety-nine trivial passes cannot cancel one catastrophic blocker.

70. False readiness signal: the best unit worked

Readiness requires representative variation.

A selected prototype can hide manufacturing spread, component variation or operator sensitivity.

Production readiness grows when ordinary units perform acceptably, not only the demonstration article.

71. False readiness signal: an expert can recover it

If only the inventor can diagnose failures, the organisation has not yet inherited the capability.

Deployment readiness requires support knowledge to be distributed enough for the intended operating model.

72. False readiness signal: the technology is mature elsewhere

Commercial-off-the-shelf technology can reduce technical uncertainty dramatically.

But a mature component used in a new environment, architecture or consequence level can create new integration and validation questions.

Inherited maturity is useful evidence, not automatic readiness.

73. False readiness signal: no failures were observed

Absence of observed failure can mean the system is reliable.

It can also mean the test was too short, too clean or too insensitive.

Readiness asks whether the evidence had a realistic chance of exposing the important failure modes.

74. A field pilot is a readiness instrument, not a ceremonial launch

A good pilot is deliberately bounded.

It uses real conditions to expose operational uncertainty while limiting consequence enough that learning remains safe and reversible.

The pilot should have explicit questions, instrumentation, stop conditions and a decision route.

75. Pilot success should not be confused with scale readiness

Pilots receive attention.

Experts are nearby. User numbers are small. Failures can be repaired quickly. Supply demand is low.

Scaling removes those privileges.

The next readiness question should therefore ask what changes when support intensity falls and system size rises.

76. Deployment readiness should include failure recovery

A system is not truly ready because it can remain healthy.

It also needs a credible path back from unhealthy states.

Can it degrade safely? Can operators identify the failure? Can state be restored? Can data be recovered? Can service continue manually? Is rollback possible?

Recovery is part of readiness.

77. Reliability evidence should match intended duration

A system that works for one hour has not demonstrated one year of dependable service.

Accelerated testing, modelling and prior evidence can help, but the time horizon of the claim should remain explicit.

The reliability owner is How Reliability Works.

78. Readiness has a clock

A system can be ready today and become unready later.

Suppliers disappear. Software support ends. regulations change. skills leave. components age. threats evolve. interfaces change. data drifts.

Readiness is a maintained condition, not a permanent certificate.

79. Obsolescence is readiness decay

A technology may continue functioning while supportability deteriorates.

Parts become scarce. expertise disappears. software dependencies break. certification pathways change.

This is where readiness begins handing off to How Obsolescence Works.

80. Replacement planning should begin before readiness collapses

The worst time to plan replacement is after the old system has become unmaintainable.

Healthy readiness provides runway for migration, parallel operation, retraining and compatibility work.

See How Replacement Planning Works.

81. Technological transitions require readiness on both sides

The new system must become sufficiently ready.

The old system must remain sufficiently ready to support the handoff.

If the old technology collapses before the new technology stabilises, transition risk spikes.

The transition owner is How Technological Transitions Work.

82. Readiness becomes more important as technology becomes infrastructure

When a technology is optional, failure is inconvenient.

When other systems reorganise around it, failure becomes systemic.

Infrastructure readiness therefore includes continuity, resilience, emergency operation, renewal funding and long-term stewardship.

See How Technology Becomes Infrastructure.

83. Technology transfer can reset readiness

A technology that is fully ready in one country or organisation may lose readiness when moved.

The new environment may have different climate, infrastructure, skills, standards, legal rules or supplier access.

The physical artefact moves instantly. Readiness may need to be rebuilt.

84. Convergence can create readiness gaps between mature components

Two mature technologies can be immature as a combination.

New interfaces, common-mode failures, timing interactions and lifecycle mismatches appear only after convergence.

The convergence owner is How Technological Convergence Works.

85. General-purpose technologies create readiness work in every downstream sector

A broad enabling technology can be technically mature while each industry remains at a different stage of complementary readiness.

Hospitals, factories, schools, banks and transport systems have different data, governance, workforce and safety constraints.

The core platform can be ready while local transformation is not.

See How General-Purpose Technologies Work.

86. Readiness has externalities

One organisation can deploy immature technology and push the consequences onto others.

Weak cybersecurity can create network risk. Poor maintainability can burden public services. Fragile supply can shift emergency cost to customers. A rushed platform can force downstream organisations to build compensating controls.

The wider consequence owner is How Technological Externalities Work.

87. Example: an environmental sensor can be technically ready and operationally unready

Imagine a sensor that measures reliably in laboratory and field conditions.

Technical readiness may be strong.

But deployment can still fail if calibration services are unavailable, communications are intermittent, maintenance access is poor, timestamps drift, dashboards do not show uncertainty or no organisation owns replacement batteries.

The sensor works. The monitoring capability does not.

88. Example: a software system can be production-ready and organisation-unready

Imagine a software platform that passes testing, scales well and has strong security controls.

Deployment can still fail if staff workflows are not redesigned, legacy data is inconsistent, support ownership is unclear and users continue maintaining shadow spreadsheets because the new process does not fit their real work.

Software readiness and organisational readiness are different dimensions.

89. Example: a new battery can be technically strong and manufacturing-weak

Imagine a battery chemistry with excellent laboratory performance.

Commercial deployment can still be delayed by material purity, yield, coating consistency, tooling, safety controls, supplier capacity or quality variation.

The chemistry and the factory mature on different clocks.

90. Example: education technology can be technically ready and pedagogically unready

A learning platform can load quickly, store data reliably and provide sophisticated features.

That does not prove it improves learning.

Educational readiness also depends on lesson design, teacher use, student comprehension, assessment validity, safeguarding, accessibility and whether the technology solves a real learning problem rather than creating activity for its own sake.

91. A practical readiness vector

Dimension	Core readiness question	Typical evidence
Technical	Does the core technology perform?	Analysis, experiments, prototype and operational demonstrations.
Integration	Does it work inside the intended architecture?	Interface tests, integrated prototypes, end-to-end scenarios.
Manufacturing	Can acceptable units be produced repeatedly at required rate and quality?	Process capability, pilot production, yield, tooling and quality data.
Operational	Can the organisation run the system safely and reliably?	Procedures, drills, pilots, monitoring and incident exercises.
Human	Can users, operators and maintainers perform their roles?	Representative-user trials, competency checks, workload and recovery tests.
Supply	Can critical inputs remain available?	Qualified suppliers, lead-time analysis, alternate sources, inventory plans.
Maintenance	Can capability be sustained after failures and ageing?	Repair procedures, spares, diagnostic tests, service capacity.
Data / cyber	Are information inputs trustworthy and attack surfaces controlled?	Data-quality checks, threat testing, access controls, monitoring and rollback.
Regulatory / institutional	Is operation permitted and responsibility clear?	Approvals, certification, governance, owner and escalation maps.
Financial / scale	Can the capability survive its lifecycle economics and growth?	Total-cost model, capacity tests, support model and funding runway.
Context transfer	Does prior evidence remain valid here?	Local environmental, infrastructure, language, standards and workflow validation.

The table is an eduKateSG explanatory synthesis. It should be adapted to the formal framework appropriate to the actual domain.

92. A readiness review sequence

Define the decision: what commitment are we considering?
Define the configuration: exactly what technology version is being assessed?
Define the use: who will use it, where and for what consequence?
Identify critical technologies: which immature elements can threaten the outcome?
Select the formal framework: NASA, ESA, ISO, agency, industry or programme-specific criteria as appropriate.
Map the readiness vector: technical plus integration, manufacturing, operations, people, supply, maintenance, data/cyber, governance, finance/scale and transfer.
Identify hard blockers: which dimensions are non-compensatory?
Gather evidence: use tests, analyses, demonstrations, records and operational data matched to the claim.
Challenge the environment: include the conditions capable of overturning the conclusion.
Record uncertainty: distinguish missing evidence from failed evidence.
Make the gate decision: proceed, proceed conditionally, hold, redesign or stop.
Bind the decision to the evidence: preserve configuration, date, assumptions and open risks.
Reassess after material change: readiness is not permanent.

93. A TRL audit

Which exact TRL framework is being used?
What is the assessed technology element?
Is the level claimed for hardware, software or both?
What evidence satisfies the stated level?
Was the required environment represented?
Was the technology integrated to the degree implied by the level?
Is the configuration identical to the one being deployed?
Who assessed the level?
What uncertainty remains despite the rating?
What decision is the rating supporting?

94. A manufacturing-readiness audit

Is the product design stable enough to manufacture?
Are critical materials available?
Are suppliers qualified?
Is tooling ready?
Can the process hold required tolerances?
Is yield measured?
Are inspection and test equipment available?
Can production meet required rate?
Are workforce skills available?
Are quality-management controls operating?
Does the projected cost reflect production reality?
Can manufacturing continue if a critical supplier fails?

95. An operational-readiness audit

Are operating procedures complete?
Are roles and permissions clear?
Can operators recognise abnormal states?
Are alerts actionable?
Can the system degrade safely?
Is manual fallback available where needed?
Are incident-response routes defined?
Is monitoring sufficient to detect failure?
Can operations continue without the development team?
Are maintenance windows and service responsibilities realistic?

96. A deployment-readiness audit

Are technical claims demonstrated in the actual intended environment?
Are manufacturing, supply and maintenance aligned with deployment scale?
Are users and operators competent?
Are approvals and governance complete?
Are security and data controls ready?
Is lifecycle funding available?
Have failure recovery and rollback been exercised?
Are remaining risks explicitly accepted by an accountable owner?
Is the pilot evidence transferable to the planned scale?
What would trigger pause, rollback or redesign after deployment?

97. The education question: teach students that “working” has levels

Students often experience technology as binary.

It works or it does not.

Engineering replaces that binary with a ladder of evidence.

An idea can be scientifically plausible, experimentally demonstrated, integrated, tested in a representative environment, qualified and operationally proven—and these are not the same state.

Teaching readiness gives students a more accurate picture of how civilisation turns discovery into dependable capability.

98. Frequently asked questions

What is a Technology Readiness Level?

A Technology Readiness Level is a staged measure of technological maturity. NASA’s framework uses nine levels, from basic principles observed at TRL 1 to an actual system proven through successful mission operations at TRL 9.

What is TRL 3?

TRL 3 is associated with analytical and experimental proof of critical function or characteristic—a proof-of-concept stage rather than a complete operational system.

What is TRL 6?

NASA describes TRL 6 around demonstration of a system or subsystem model or prototype in a relevant environment.

What is TRL 9?

NASA describes TRL 9 as the actual system proven through successful mission operations.

Is TRL 9 the same as being ready for every deployment?

No. A technology proven in one system or environment may still need new integration, manufacturing, regulatory, supply, maintenance or local-context evidence when the application changes.

What is manufacturing readiness?

Manufacturing readiness concerns whether a technology or design can be produced repeatedly at the required quality, rate and cost using capable processes, suppliers, tooling, facilities and workforce. Manufacturing Readiness Levels are used in some defence and acquisition contexts alongside TRLs.

Is technology readiness the same as technological maturity?

No. Technological maturity describes the broader evolution of a technology and industry over time. Readiness is a decision-specific judgement about whether enough evidence exists for the next integration, production or deployment step.

Why is a prototype not enough?

Because a prototype can demonstrate selected technical behaviour while omitting production variability, operational support, maintenance, regulation, real users, supply chains or scale.

What is a relevant environment?

It is an environment representative enough along the dimensions that matter to the readiness claim. The specific conditions depend on the technology and intended use.

What is operational readiness?

Operational readiness means the organisation has the people, procedures, monitoring, permissions, maintenance, incident response and support structures needed to run the technology dependably in real use.

Can readiness go backwards?

Yes. Material design changes, new environments, supplier loss, software updates, regulatory changes or ageing can invalidate earlier readiness evidence.

What is the biggest readiness mistake?

Treating one strong technical demonstration—or one readiness number—as proof that the whole deployment system is ready.

99. Evidence and source boundary

The nine-level TRL descriptions in this article are grounded in NASA’s current public Technology Readiness Levels page, last updated 25 June 2026, and NASA Procedural Requirements NPR 7123.1D Appendix E, effective through July 2028 at the time this article was prepared.

ESA’s Technology Readiness Levels page is used to show that ESA also applies a nine-level scale and identifies ISO 16290 as its TRL standard.

The assessment-quality discussion draws on the U.S. Government Accountability Office’s Technology Readiness Assessment Guide, which describes technology readiness assessment as an evidence-based process and highlights the need for credible, objective, reliable and useful assessments.

The manufacturing discussion uses GAO’s documented treatment of Manufacturing Readiness Levels in defence acquisition contexts, including GAO-10-439. MRL terminology is not presented here as a universal framework for every industry.

The broader readiness vector in this article—technical, integration, manufacturing, operational, human, supply, maintenance, data/cyber, regulatory/institutional, financial/scale and context-transfer—is an eduKateSG explanatory synthesis intended to help readers avoid collapsing all deployment readiness into one score. Organisations should use the formal frameworks, laws, standards and professional controls appropriate to their actual domain.

100. The deeper lesson: readiness is the conversion of uncertainty into justified commitment

Technology begins in uncertainty.

Maybe the principle works. Maybe the material survives. Maybe the software scales. Maybe users understand the interface. Maybe the factory can reproduce the design. Maybe the supplier can deliver. Maybe the operator can recover from failure.

Readiness is the disciplined process of replacing those maybes with evidence.

At first, evidence can be narrow because commitment is small. A calculation can justify an experiment. An experiment can justify a prototype. A prototype can justify a representative test. A representative test can justify an operational pilot. Operational evidence can justify wider deployment.

The important principle is proportionality: the stronger the claim and the larger the consequence, the stronger and more representative the evidence should become.

That is why one readiness number is both useful and dangerous.

Useful, because a common scale compresses complex development into a shared language.

Dangerous, because compression can hide dimensions the number was never designed to own.

The mature readiness question is not “what number are we?” It is “what uncertainty still has enough consequence to stop the next commitment?”

Once that question becomes habitual, technology development becomes clearer. Teams stop polishing impressive demonstrations when manufacturing is the real blocker. They stop calling a pilot “scale” when support remains handcrafted. They stop treating mature components as ready systems before integration. They stop confusing training attendance with operator competence. They stop allowing schedules to substitute for evidence.

And they gain something more valuable than a high readiness score.

They gain the ability to know why the next step is justified.