Frontier Technologies
Explore early. Commit on evidence.
ColdAI's frontier technologies practice helps organizations decide which emerging technologies deserve money now, which deserve watching and which should be dropped. It covers extended reality, brain-computer interfaces, smart-city IoT and quantum computing, and puts every candidate through the same discipline: a named problem, a credible conventional baseline, evaluation criteria fixed before results arrive, and a staged commitment to scale, watch or stop.
The opportunity
Start with a decision
worth improving.
A leadership team hears that several emerging technologies could reshape its sector within a decade. It needs to know which deserve investment now, which deserve monitoring and what evidence would change that decision.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Scan the horizon
Map candidate technologies to the organization's own problems rather than to general trend reports. Record the technical maturity, regulatory position and dependencies of each before ranking them.
Test against a baseline
Design small experiments that compare the frontier approach with the best conventional alternative. Fix the evaluation criteria before results arrive so enthusiasm does not set the bar.
Decide the next commitment
Turn results into a staged decision: scale, keep watching or stop. Write down the triggers, such as cost, maturity or regulation, that would reopen a paused option.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
A prioritized frontier technology map
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Baseline-controlled experiments
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Staged investment and review triggers
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper into frontier decision methods
Two method pages that apply across every frontier domain: how to run your own horizon scan, and how to rate a technology's readiness for your use case before piloting it.
- 01GuideHow to run emerging technology horizon scanningA repeatable method for emerging technology horizon scanning: framing questions from your own problems, signal sources, a scoring rubric and a watch list.
- 02ChecklistTechnology readiness level assessment: a checklistAssess how mature an emerging technology is for your use case: TRL 1 to TRL 9 in plain language, the evidence for each level and the mis-ratings to avoid.
The frontier portfolio loop: scan, test, decide, revisit
A frontier portfolio is never finished. Options that were paused come back when their triggers fire, and options that were scaled leave the portfolio for ordinary delivery.
- Scan against problems
Map candidate technologies to the organization's own open problems, not to trend lists.
- Rate real maturity
Judge technical and adoption readiness from evidence, not from vendor material.
- Test against a baseline
Run a small experiment that the best conventional option is also measured against.
- Scale, watch or stop
Make a staged decision using criteria that were agreed before results arrived.
- Set review triggers
Write down the cost, maturity or regulatory change that would reopen a paused option.
Four frontier domains through one portfolio lens
The domains differ technically, but the portfolio questions are the same. The detail for each lives on its own page; this table shows how they compare when they compete for the same budget.
| Portfolio question | Extended reality | Brain-computer interfaces | Smart-city IoT | Quantum computing |
|---|---|---|---|---|
| Typical first problem | A spatial, hands-busy or hazardous task such as guided repair or rare-event training | A research or assistive interaction where conventional input is slow or impossible | A city or campus service that lacks reliable, shared data about assets and conditions | A hard optimization or simulation problem, or cryptography exposed to future quantum attack |
| Conventional baseline to beat | Tablets, video calls, better documentation or classroom training | Eye tracking, switches, speech or other assistive input | Manual inspection, existing SCADA data or periodic surveys | Strong classical solvers and heuristics; for cryptography, there is no baseline, only migration timing |
| Main constraint | Comfort, device management and camera or eye-tracking privacy | Neural data protection and, for medical uses, a regulated device pathway | Long asset lifecycles, operational-technology security and vendor lock-in | Hardware maturity for computing; for post-quantum migration, inventory and dependencies |
| Common reason for "not yet" | A cheaper device or better process solves the problem well enough | Signal quality or regulation does not yet support the intended use | Procurement cannot yet guarantee interoperability or data ownership | Classical methods still win on the instances that matter |
| Where to go deeper | Extended reality | Brain-computer interfaces | IoT and smart cities | Quantum computing |
Rows summarize the portfolio view only. Technology choices, standards and architectures for each domain are covered on the linked pages.
Scale, watch or stop: what each decision commits you to
- If
The experiment beat the conventional baseline on the criteria agreed in advance, and the constraints look manageable
ThenScale into a bounded production pilot with an operating owner, a budget line and a plan for support and security.
A frontier result only matters once someone is accountable for running it.
- If
The approach looks promising but maturity, cost or regulation blocks it today
ThenWatch: record the evidence, name the trigger that would reopen it and set a review date.
Paused options with written triggers can be revived quickly instead of being rediscovered from scratch.
- If
The baseline won, or the problem changed so the frontier option no longer fits
ThenStop, publish a short note on why and release the budget.
A documented stop is a useful result and protects against the same idea returning unexamined.
- If
Nobody can name the problem or the owner who would fund a small test
ThenDo not start an experiment; return the idea to the scan.
Experiments without an owner tend to become demonstrations that never reach a decision.
What a frontier proposal should bring before an experiment is funded
These items keep enthusiasm from setting the bar. A proposal that cannot provide them is usually a scan entry, not yet an experiment.
Failure patterns in emerging technology portfolios
Pilot purgatory
Early signalPilots keep being extended without a scale or stop decision.
MitigationGive every experiment a decision date and an owner who must choose scale, watch or stop on that date.
Vendor-led evaluation
Early signalThe success criteria and test data come from the supplier being evaluated.
MitigationDefine criteria and baseline independently, and test on your own data and environment.
Sunk-cost momentum
Early signalTeams argue for continuing because of what has already been spent.
MitigationDecide on forward-looking evidence only, and treat a well-documented stop as a success.
Regulatory surprise
Early signalA proposed rule or standard would change the economics, and nobody is tracking it.
MitigationMake regulatory position a scored field in the scan and a named review trigger.
Single-person dependency
Early signalOnly one enthusiast understands the experiment.
MitigationPair every experiment with a delivery team member who would own it in production.
How the practice draws on ColdAI's research and engineering
Frontier technologies sit between commissioned research and production delivery. Where a question is still open, such as whether a decoding model or quantum method works at all on a client's problem, the work draws on our Frontier R&D practice, which starts from a written question and fixes the evaluation before experiments run. Where the answer is known and the task is integration, it draws on our AI and distributed ledger engineering, so a scaled pilot is built and operated like any other production system1.
A typical engagement produces three things: a prioritized frontier technology map tied to the organization's problems, baseline-controlled experiments for the few candidates that justify one, and a staged investment plan with review triggers for everything else. We ask clients for a named business or research problem, an owner willing to fund small tests and tolerance for a "not yet" answer, because a credible engagement may conclude that a conventional system, or waiting, is the better choice for now. For engineering-wide adoption standards, see our technology capability; for funding new ventures that emerge from this work, see business building.
Frequently asked questions
Which frontier technologies does ColdAI work with?
Four domains: extended reality, brain-computer interfaces, connected city and campus infrastructure, and quantum computing, including post-quantum cryptography. Each has its own page with domain detail. This practice handles the portfolio question across them: which deserve investment, how to test them fairly and when to stop.
How is this different from running a technology radar?
A technology radar governs which tools engineering teams may adopt, using rings such as adopt, trial, assess and hold. Frontier work sits earlier and wider: it scans for technologies that could change the business, tests a few against conventional baselines and stages investment. A frontier result that succeeds usually ends up on the radar once it is ready for general engineering use.
Does ColdAI build frontier systems or only advise on them?
Both. The portfolio and experiment design is advisory, but experiments are real builds tested against real baselines, and a candidate that earns a scale decision is built and operated with the same engineering discipline as our AI and distributed ledger work. Medical brain-computer interface uses follow a regulated device pathway with qualified clinical partners, and we make no clinical claims.
What happens if the answer is not yet?
The option goes onto a watch list with the evidence gathered so far and the specific triggers that would reopen it, such as a hardware milestone, a cost change or a regulation being finalized. That record means the organization can move quickly when conditions change, rather than repeating the evaluation from the beginning.
How do you keep vendor claims out of the evaluation?
By fixing the problem, the baseline and the evaluation criteria before any supplier is involved, and by testing on the client's own data and environment. Vendor material is treated as a lead to investigate, not as evidence. Where several suppliers compete, they are measured against the same baseline and criteria.
Who in our organization should own the frontier portfolio?
Usually a strategy, innovation or CTO office, with a sponsor who controls a small experiment budget and business owners for each problem. The owner's job is to make scale, watch and stop decisions on time. Without that authority, the portfolio becomes a list of interesting ideas rather than a way of allocating money.
Sources
Connect the architecture
Go deeper into the stack.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A named business or research problem
- An owner willing to fund small tests
- Tolerance for a "not yet" answer