Selling RISC-V into safety-critical markets: trust is built on the evidence you publish

In automotive, aerospace and defence, buyers check your evidence before they agree to a call. At the RISC-V panel at Microelectronics 2026, chaired by Andy Moore of RISC-V International, Markus Willems of MIPS and John Ronco of SiFive described what that evidence looks like: certified cores, a safety process that starts on day one, and named customers such as Infineon and Microchip.

Most of that evidence never reaches a RISC-V company's website. It sits in certificates, NDAs and the heads of the sales team. My first blog from the panel looked at why buyers still ask whether RISC-V is ready. This one is for anyone selling RISC-V into regulated markets, where the buyer's own research decides who makes the shortlist.

"Is RISC-V open source?" Your buyers may think so

John Ronco raised a misconception he hears often: because RISC-V is an open standard, people assume RISC-V processors are open source. Some are. Most cores that go into safety critical products are licensed from a company, and in Ronco's words, many customers "want to buy from a trusted party". He said safety is a big part of that market, because those buyers want high quality processors with a supplier who stands behind them.

To a safety buyer, "open source" can sound like nobody is responsible when something goes wrong. If your website leans on the word "open" and says little about support, some buyers will take that reading away with them, and they won't ask you to correct it.

What to do: answer "Is your product open source?" in your FAQ, in two or three sentences. Say what is open (the instruction set), what you license, who supports it and for how long.

Safety is a process. Show buyers yours

Markus Willems was clear that safety can't be bolted on at the end. "You really need to think safety from day one, from a documentation perspective, from a verification perspective." The features come on top of that process: dual-core lockstep, where two cores run the same code and check each other's results; memory protection; safety mechanisms you can configure to the level the application needs; and software test libraries. He added that safety depends as much on system knowledge as on the core itself.

A functional safety lead wants to know how you got to the certificate. How were requirements traced? How was the core verified? What documentation ships with it? Many vendor safety pages show a certificate logo and a feature list, and leave the buyer to ask for everything else.

What to do: write a safety page that walks through your process in order: how you capture requirements, how you verify, what documentation you supply (safety manual, failure analysis reports) and which safety levels each core supports. Explain lockstep and ASIL (the automotive safety integrity levels, A to D) in a line each, for readers outside the safety team.

Give every certification a permanent page

Safety covers what happens when hardware fails. Cybersecurity covers what happens when someone attacks it, and automotive buyers now ask about both. Ronco and Willems both brought up ISO/SAE 21434, the automotive cybersecurity standard. SiFive and MIPS have each certified processor IP to it, within days of each other .

Most vendors announce a certification in a press release, and the release slides down the news page. When a buyer later searches for an ISO/SAE 21434 certified RISC-V core, or asks ChatGPT the same question, they find a dated announcement or a competitor's product page.

What to do: publish one page listing each standard you hold, with what it covers in plain words, which products it applies to, the date and who certified you. Link to it from every product page and from your sales decks.

Name your customers, with their permission

The panel named two programmes. Willems said Infineon's architecture for automotive control is based on RISC-V, with MIPS supplying the cores and bringing the safety experience it built on its earlier proprietary architecture. Ronco said Microchip's next-generation space microprocessor, with safety and robustness features built in, is built around SiFive cores and is going into several US programmes.

An automotive buyer who sees Infineon's name knows that a company with the same safety requirements has already done the due diligence on that core. Getting permission to name a customer usually starts with the account owner, well before marketing writes anything.

What to do: ask your top three customers for one public step each: a joint announcement, a quote you can use, or a shared conference talk. Give each one that agrees a page of its own.

Defence buyers are asking for RISC-V. Can they find you?

Willems said much of the aerospace and defence work MIPS sees is confidential. What he could say is that some requests for information (RFIs) now require RISC-V, partly for geopolitical reasons. These programmes bring many design starts at low volumes, and he called that a tremendous opportunity.

Defence buyers tend to research and shortlist before they contact a supplier. They want to know where your IP was developed, how your supply chain works and how long you will support a product. If your website doesn't cover those points, you may never learn you were considered.

What to do: publish an aerospace and defence page covering where your IP comes from, your supply chain, your support commitments and who to contact. Keep it factual, because the buyer will check every line.

Safety plus AI: the message few vendors have written

Ronco recalled a talk Infineon gave at a RISC-V summit. Its automotive microcontrollers have always needed real-time control, and now they also need "a bit of AI". RISC-V lets Infineon add the capabilities each job needs to a common core. Willems said physical AI, from sensing to robots, is a growing focus for MIPS, helped by GlobalFoundries' sensor business.

Safety buyers will ask how you add AI without weakening the safety case. An AI feature changes what the system does, so an assessor will want to know how it is kept apart from safety functions, how it is verified and how it is documented. Few RISC-V vendors answer that on their websites yet.

What to do: add a short section to your safety page on where AI features sit in your safety case: which safety levels they support, how they are separated from safety functions and what your verification covers.

Where to start

Everything the panel described is evidence a safety buyer looks for: an accountable supplier, a documented process, certifications, named customers and a plan for AI. Most RISC-V companies already hold some of it. Put it on your website in plain language, and buyers find it while they research, before they ever speak to your sales team.

If you want to see what those buyers find today, we run a free Signal Check focused on trust signals: your certifications, references and safety content, scored for search and AI answer engines, with the fixes ranked by impact.

I’m Dale Kaszycki- Co-Founder of Latent, a B2B marketing consultancy for deep tech. I help companies build brands and revenue pipelines that get specified by AI-tools.

Book a 30-minute call

Will AI replace your MarTech Stack?

Some of it already can. Here’s how to tell which tools are real products and which are features an LLM can absorb.

Grid of 100 hollow squares with three in amber, joined into one bar, labelled “Paid.” and “Built.”

Do you remember Peach?

It was a social network app that, for a brief few weeks a decade or so ago, was going to be the new Facebook.

Hot new social apps blew up and died, or got acquired and killed, quite a lot. Most of them deserved to die. They were too easy to copy before network effects could take hold.

Right now, AI in MarTech feels eerily similar to me.

Why are there so many MarTech tools?

Since starting Latent, I have been pitched half a dozen AI CRMs and at least a dozen AEO tools. I've lost count of how many sentences start "we're the AI-native version of..."

This is on top of established software platforms rushing to the party with their own AI features (usually on the next pricing tier up), or their MCPs letting you bring your own LLM.

And then there's the LLM platforms themselves, whether it's GPT, Claude, Muse, Copilot, or Gemini... There's a new capability and a new model being released almost every week. With everyone already concentrated on these platforms, they’re not just essential tools, they have become the new networks.

Is your software a product or a feature?

What feels all too familiar to the early social days, is that companies are launching products which can be made into features by the networks (Claude/ChatGPT). Think Instagram copying Snapchat.

A real example: I don't have to upgrade my CRM because I can build workflow automation with Claude and read/write to fields using my CRM's API or MCP.

The legacy CRM wants to sell workflow automation as a product, the new "AI native CRM" is using AI built into their platform to do it. But it's just a feature, I've already built it and moved on.

Whatever your task, there are a dozen tools all trying to lock you into 2 year contracts with 5-10% price increases on renewal. And most of us are paying for a premium tier with 100 features because 3 of them are essential while the other 97 are irrelevant.

Why the SaaSpocalypse will be slower than expected

For big enterprises, the trade off is harder. They have IT, Legal, Ops, Procurement, Finance... who all have processes, standards, annual budget reviews. You have to think about risk mitigation, maintenance, scalability. When shit hits the fan, it needs to have left an audit trail.

Without a broader organizational change, continuing to pay for the dedicated tool will often be the easy route, even though you can replace it using the AI platform the enterprise is already paying for. I think this is one of the biggest reasons "SaaSpocalypse" will be slower and less evenly distributed than first thought. Ask people who work in digital transformation and they will tell you change is slow if it ever even happens at all.

But for startups and smaller companies, the opportunity to build your software stack, processes and teams as AI-first is huge. With the right knowledge, access to a model and time, you can build a stack which operates with the functionality of a stack 100x the cost.

How should you audit your MarTech Stack?

I'd start with why you think you need the software in the first place. What is the repeated task or outcome you need to automate? Does that outcome really need software to be achieved? I have been surprised how often the answer to that question is "not anymore".

If evaluating an existing stack, ask:

"What is a feature, not a product?"

(An easy tell: is it just a UI on top of an API call?)

If it is, it's worth thinking seriously about how you could re-build and manage the workflow. Think setup, maintenance, auditing, scaling, hosting.

While you won't replace your CRM overnight, what about your orchestration tool, or BI tool, or social management tool, or URL shortener, or SEO/AEO platform, or competitive insight tool, or data enrichment platform, or intent platform, or personalization tool...

It might sound unrealistic or not worth the bother, but just this month I have built my own UTM builder, multiple orchestration workflows, an AEO tool, and a reporting tool. Costing all of that up, it's just shy of $19,000 a year equivalent of SaaS platform costs.

If I can save a few tens of thousands of dollars, so can a whole lot of other folks.

Where's the money going to go? Right now, it looks like it will go to the same place it went to with social media... the big platforms. What will happen to undifferentiated 'AI native' platforms? they'll probably end up like Peach. Eaten.

---

Simon Jared is Co-Founder of Latent, a B2B marketing consultancy for deep tech. He helps companies build AI-first marketing operations.

Book a call.

RISC-V has won the embedded argument. So why are your buyers still asking if it's ready?

Amber circuit trace labelled RISC-V is ready runs from a chip, then breaks into gaps before an empty receiver, showing the RISC-V proof gap

The technical argument for RISC-V in embedded applications is over. I sat in on the RISC-V panel at Microelectronics 2026, with Andy Moore of RISC-V International, John Ronco of SiFive and Markus Willems of MIPS (now part of GlobalFoundries), and nobody on stage spent a minute defending whether RISC-V works. They talked about billions of chips shipped, automotive design wins, space processors, and Linux distributions that ran on new silicon within days.

Yet the people who sell RISC-V products still hear the same questions on every call. Are the tools ready? Won't all these custom extensions fragment the ecosystem? Who else is using it?

That gap sits in marketing and sales, not engineering, and the good news is most RISC-V companies can close it with material they already have. Below are six places where the panel showed the story exists, and what to do so your buyers hear it.

Arm has deprioritised Cortex-M. Are your buyers hearing that from you?

John Ronco ran product management for Arm's CPUs for years before he moved to SiFive, so his view of Arm's embedded roadmap is sound. On stage, he said Arm stopped developing its embedded roadmap about 18 months ago, which leaves anyone who wants an Arm embedded core "stuck with a legacy".

Arm’s take on this is more nuanced. Lionel Belnet, Arm's senior director of edge computing, told eeNews Europe in July that "it's not a priority to push the performance for Cortex-M" and that Cortex-A is "the next logical step". Either way, the direction is the same. Arm's effort is going into bigger cores, and the engineers who built their careers and devices on Cortex-M have noticed.

Part of what's happening is that the old split between microcontrollers and application processors has blurred. A microcontroller in 2026 often needs to run applications and some AI, which puts it closer to an applications processor from ten years ago. Cortex-M and Cortex-A don't share an instruction set, so Arm has two product lines to bridge. RISC-V uses the same base ISA from a small controller up to a many-core server, with extensions added for the workload.

A roadmap change like this is a trigger event. Engineering leads who never had a reason to look beyond Arm now have one, and their first move is a search, or more and more often a question to ChatGPT or Claude. If your website doesn't answer "what is the alternative to Arm Cortex-M?", an answer engine will answer it for you, and it will probably name a competitor.

What to do: write one page that answers the migration question directly. Cover what moving from Cortex-M to your core involves, what carries over, how long it takes and who has done it. Write it for the engineer, then give your sales team the link.

"Are the tools ready?" Where is your answer?

Markus Willems made the point that standardisation is what lets the ecosystem grow around RISC-V. Debuggers support it out of the box, and compilers are available from open source projects and from the vendors themselves. He has been in the industry for 25 years, and he said the growth of that community over the last five is the clearest sign of momentum he has seen. Vendors don't build tools for a market they don't believe in.

So the answer to "are the tools ready?" is yes. The problem is where that answer lives. On most RISC-V company websites, tool support is a row of partner logos or a line buried in a datasheet. The engineer evaluating you can't see which toolchain versions you support, which RTOS ports exist or which debug probes work. They ask your sales team instead, and your sales team answers the same question by hand, call after call.

What to do: build a tools and ecosystem page that names every compiler, debugger, RTOS and IDE you support, with versions and links. Then turn it into a one-page objection sheet for sales. Every question that page answers is one your sales people no longer have to field.

"Differentiation, not fragmentation" only works if you say it

John Ronco gave us the line of the session: "It's differentiation, not fragmentation." RISC-V lets every vendor build something different while keeping software compatible across vendors and chips. He said SiFive is committed to 100% standard RISC-V, with anything custom built on top and proposed to RISC-V International for standardisation. Markus Willems said MIPS takes the same position.

That position fits how RISC-V is meant to work. Extensions are designed in the open, then voted on and ratified by RISC-V International's working groups, and the ratified library now covers most of what a product needs. Profiles go further. If you build to one, you rarely need a custom extension at all.

Fragmentation is the fear buyers rarely say out loud. They see a vendor promoting its custom extensions and wonder whether their software will still run elsewhere, or whether they're swapping one lock-in for another. The flexibility RISC-V companies most like to talk about is exactly what triggers that worry.

What to do: lead with the standard. State which RISC-V profile each product supports and which ratified extensions it uses. If you offer custom extensions, present them as an option on a standard base, and say who maintains the software for them. One sentence on each product page answers an objection most buyers will never raise with you directly.

Billions of chips shipped. So where are your named customers?

The panel was full of proof. Billions of RISC-V chips are shipping. John Ronco pointed out that his own Samsung phone contains chips from three different vendors that use SiFive cores. GlobalFoundries bought MIPS in 2025, then acquired Synopsys's ARC processor business in 2026, and built both on RISC-V. Companies don't make acquisitions like that on a hunch.

All of that proof reached the audience as anecdotes from a stage. Much of RISC-V's success sits inside chips where the core is invisible to the end customer, and under NDAs that stop vendors naming who uses them. Answer engines can't cite a panel anecdote. They cite named case studies, published results and third-party coverage.

What to do: aim for one approved customer story each quarter. If the customer won't be named, anonymise the story but keep the numbers: the power saved, the time to first silicon, the software that ported. A specific anonymous story does more work than a famous logo with nothing behind it.

RVA23: the story progressive RISC-V companies need to tell now

RVA23 is a RISC-V profile: a fixed set of extensions that an application processor must support, so software can target one baseline and run on chips from different vendors. John Ronco compared it to Armv9. It matters because the software world has chosen it. Red Hat, Ubuntu and Android all treat RVA23 as the baseline they support. I find a closer comparison is the x86-64 microarchitecture levels. Each level is a named baseline that software can target, so code built for that level runs on any chip that meets it.

The panel showed how far that has come. Andy Moore ran his notes from a laptop built on an RVA23 chip. SiFive has announced a 32-core RVA23 server developer platform, and when it shared early units with Red Hat, Ubuntu and others, their response, in Ronco's words, was that "it just worked". Everything was running within days.

For RISC-V companies with RVA23 products, this advantage won't last long. Software buyers will soon treat RVA23 support as a checkbox. Today, few vendors explain what it means for the person buying: which operating systems run, what they no longer have to port and what it costs them to switch. The companies that explain it clearly first will own the search results for it.

What to do: publish an RVA23 page in plain language. Say what RVA23 is, what runs on your product today, your compliance status and what's on your roadmap. Write it so a software lead who has never touched RISC-V can follow it.

Edge AI: lead with programmability, not TOPS

Both panellists described the same trend: RISC-V cores built inside AI accelerators. The accelerator does the heavy lifting, and the RISC-V core handles everything around it, which keeps the design programmable when the models change. Markus Willems added that RISC-V can also run AI workloads natively, using the vector extensions available now and the matrix extensions being defined, with software stacks using IREE as their entry point.

He summed it up: "AI is not about hardware, sorry to say. AI is about the software." Moving data in and out efficiently, and giving developers one way to program the chip, matters more than the peak number on the spec sheet.

Most AI chip messaging still leads with TOPS, a number buyers can't compare across vendors and rarely trust. The panel pointed to a better selling point: a design that stays useful when next year's model looks nothing like this year's.

One caveat for buyers: the matrix extensions aren't ratified yet, and there may end up being two or three approaches. If a vendor's AI roadmap depends on matrix support, ask which approach they're backing and what happens if the standard goes another way.

What to do: rewrite your AI messaging around software, data movement and future proofing. Show the toolchain, show a model running and explain what happens when the model changes.

So is RISC-V now the default choice for embedded?

For new deeply embedded designs, the control processors and companion cores that no end customer ever programs, the panel made a strong case that it already is. For general-purpose microcontrollers, where developers pick the chip and its ecosystem, RISC-V is still earning that position, with Infineon and Microchip among the companies moving it forward.

It's worth being clear on terms. Every microcontroller is an embedded device, but not every embedded device is a microcontroller. When John Ronco talked about Arm's embedded roadmap, he meant Cortex-M. Plenty of RISC-V embedded processors now run Linux and AI inference on dies smaller than a microcontroller's was five years ago.

What stands between RISC-V and default status in the rest of embedded is visibility. The proof exists, but it sits in datasheets, partner logos and panel anecdotes, where buyers and answer engines can't find it. The RISC-V companies that move that proof onto their own websites, in plain language, will be the ones buyers find first.

If you want to see how your company looks to search engines and AI answer engines today, we run a free Signal Check: a scored audit of your SEO and AEO visibility, with the fixes ranked by impact.

Book a 30 minute call

I’m Dale Kaszycki, Co-founder of Latent and I’m a firm believer in not hiding your light under a bushel.

Three conversations, one problem

Flat vector illustration of a hammer poised above a screw, representing deep tech companies aiming the wrong solution at a customer's problem

Cambridge Tech Week, September 2026

Three separate sessions at Cambridge Tech Week covered the same problem by accident: a podcast on the train ride, a panel on UK deep tech investment, and a keynote from Innovate UK. All of them described a marketing failure without ever realising it was a marketing problem.

The problem is the distance between building good technology and being able to explain its value to the people who fund it or buy it.

De-risking is their duty

Tom Adeyoola, Exec Chair of Innovate UK, put the establishment framing plainly:

"De-risking is what we are trying to do."

Tom makes a good point, because it describes what public money is for. Innovate UK does not exist to pick winners. It exists to take enough risk out of a technology that private capital will follow, and that a customer will sign.

Risk is not only technical. A buyer looking at a novel compute architecture or a quantum security product is weighing two risks at once: will it work, and will it solve the thing I need solving. Grant funding and technical milestones address the first, yet almost nothing in a typical deep tech company addresses the second.

A separate Tech Week session on the UK investor landscape made the same point from the other side. Risk appetite among UK investors is low, which everyone in the room already knew. But the question is: how much of that gap is the technology, and how much is the articulation of it. An investor who cannot understand what the company does, who needs it, and why now is not assessing a technical risk. They are assessing a comprehension risk, and they price that in.

The 1 in 1,000

The wonderful Anne Dobrée, was a guest on the BritChips Podcast and accompanied me on the train ride to Tech Week and framed it as a numbers problem. Most companies never break through to get noticed or funded. She put it at roughly 1 in 1,000, and her point was that the 999 are not failing on technology. They are failing to stand out. The credit for that framing is hers, and it stuck with me because it names the thing everyone avoids saying: the technology being good is not the differentiator as plenty of good technology dies quietly.

So what separates the 1 from the 999?

The answer showed up in a quote from a defence sector buyer, talking about the quantum companies pitching him later that day:

"Please solve the problems I have, not the problems quantum people think I have."

That is the whole disparity in one line. Brilliant technical people build forward from what is possible. Buyers live backward from what is needed. Often, deep tech companies build the technology first and then go looking for a use case that fits it, which is exactly the wrong order, and the buyer can tell immediately.

Working back from customer value

The fix isn’t about producing more content. The fix is starting from a real customer problem and working back.

That sounds obvious written down. It is rare in practice, for reasons that are easy to sympathise with:

•    Founders are often the strongest technologists in the room, and the technology really is novel, so the temptation is to lead with the novelty and to showcase how smart they are.

•    Roadmaps get built around technical milestones, because those are the things the team controls.

•    Customer problems are messy, specific, and unglamorous next to a nice benchmark number.

A company that works back from customer value answers the de-risking question without being asked. The buyer sees their own problem described accurately, which removes the comprehension risk. The investor sees a defined market with a named pain and a reason to pay, which removes a chunk of the commercial risk. Nothing about the underlying technology changed. What changed is that the risk is now legible.

What marketing is actually for

Marketing in deep tech is not awareness. Marketing is the translation layer between what the technology can do and what someone needs done, and it is the cheapest de-risking available to a company that already has the hard part solved.

This is the gap Latent was set up to close. Simon and I spent years at Arm watching strong technology struggle to find its story, and that’s becoming even more prevalent the more time we spend with these brilliant founders: the companies that break through are the ones that can explain themselves in their customer’s words, not their own.

The technology is rarely the bottleneck. The articulation of it usually is.

How do you position a technology that takes value from your own partners?

Diagram: a signal from a chip splits into three paths labelled Holds, Distorts and Stops Short.

There's a version of this problem that sounds like a good problem to have. You've done the work. You understand where the value actually sits in the supply chain. Your client's technology shifts the economics: it compresses time to market, reduces integration overhead, and moves a capability that used to live downstream to a point higher up the chain. The story resonates, and the data backs it up. Yet when you say it out loud, the room goes quiet in the wrong way. 

We ran into this when marketing compute subsystems. The technology did exactly what it claimed: reorganising how compute was delivered across a complex hardware architecture in a way that changed what was possible. The problem was that telling that story clearly also meant telling a story about who was losing something, possibly implying that some of our efforts rendered them redundant, when we were sparing them from the mundane tasks and freeing them to add value elsewhere. The OEMs we needed to bring with us were the same people who felt, not incorrectly, that the value we were articulating was coming at their expense. 

This isn't a communications failure. It's a structural tension that no amount of redrafting resolves on its own. When a technology shifts value from one part of a supply chain to another, the people at the losing end of that shift will feel it in the positioning before they feel it in their contracts. Positioning travels through whitepapers, analyst briefings, and conference keynotes. They often hear your story before you've had a chance to frame it for them directly. 

When Arm began moving into AI silicon in a way that put them in direct competition with companies that had built their businesses on Arm's architecture, the technical argument was sound, plus the opportunity and capability were there. But the message that reached their ecosystem said, essentially: the partner relationship you've been building for years is now also a competitive one. The market heard it. Partners heard it. And there was a risk of them hedging. 

This is what makes value shift positioning difficult. The story isn't wrong. The same story lands differently depending on who's reading it. In deep tech, where ecosystems are tightly interconnected, and relationships run long, the people you're pitching to and the people you need to keep onside are often the same people. 

The answer isn't to soften the claim. Diluting the positioning to avoid the friction usually means losing the clarity that made it worth saying in the first place. The answer is to separate the messages and build a version for each seat at the table. 

What you say to an investor about a compute subsystem is not what you say to an OEM partner. For the investor, the story is about market structure: where value is concentrating, what the defensible position looks like, why now. For the OEM, the story has to be about their outcome specifically. Not what the technology does in the abstract, but what it unlocks for the engineer in their organisation who is currently spending six months on integration work they'd rather not be doing. Shorter delivery cycles. Less overhead carrying hardware complexity they didn't choose. More time and budget directed toward the part of the product only they can build. 

Same technology. Same underlying truth about where the value sits. But completely different framing. 

We've had to rebuild positioning mid-engagement because we went too far in the other direction: we went too hard on the structural argument in a room that needed the operational one first. The tell is usually resistance that doesn't quite match the logic. If smart people are pushing back on a claim that's demonstrably true, the problem isn't usually the claim. It's that the frame you've built around it is threatening something they're not ready to give up. 

When that happens, you pull it apart. You go back to the individual. You find the specific outcome they care about and start there. You earn the structural argument by demonstrating you understand their situation before you tell them how it's changing. 

The hardest version of this is when the value shift is real, significant, and ultimately unavoidable, and your client needs to lead that conversation rather than respond to it. In those cases, positioning isn't just a marketing question. It's about managing the sequence in which different parts of an ecosystem understand what's happening and why. Get that sequence wrong and you create resistance that slows the adoption of something that would have helped the people resisting it.  

Get it right and you can bring the supply chain with you, even when the supply chain is, in some sense, the thing that's changing. 

I'm Dale, co-founder and director at Latent. Let me know if you'd like to have a chat about your positioning.

CUDA just got real on RISC-V. Here's how to capitalise on that limelight

In July 2025, Nvidia told the RISC-V Summit in China it would bring CUDA to RISC-V, so a RISC-V chip could act as the main processor in a CUDA-based AI system. It was a promise with no timeline. This month at Hot Chips 2026, the promise turned into a product: Nvidia published the technical bar a RISC-V platform has to clear (RVA23 compliance, vector extensions with predication, ACPI support via the newly ratified BRS spec, PCIe cache coherency), and SiFive demoed the BigSky SF-2U870, a rack server running RHEL 10 and CUDA on real workloads, available today. SiFive's CEO put it well: "RISC-V in the datacenter isn't a distant aspiration any more, it is happening right now." A year ago this was a slide. Now it's a spec sheet and a server you can order.

That's the news. What matters more for anyone working in or around RISC-V is what happens next, because a moment like this only comes along once or twice a year, and most of the ecosystem will let it pass by with a LinkedIn share and nothing else.

A rising tide raises all ships

This announcement doesn't just benefit Nvidia or SiFive. It's a credibility event for RISC-V as a category. Every company selling RISC-V IP, tooling, silicon, or services just got a stronger answer to the question every RISC-V vendor has been fielding for years: is this actually ready for serious compute, or is it still an embedded and edge story? Datacenter-class CUDA support, backed by a shipping server and a mainstream enterprise Linux distribution, is a genuinely different answer than the ecosystem had a year ago.

Search and AI answer engine interest in RISC-V as a category will tick up over the next few weeks, because interest in RISC-V-in-the-datacenter as a whole ticks up whenever a proof point like this lands, not just interest in Nvidia or SiFive specifically. Buyers who'd parked RISC-V as "watch this space" will go looking for more, and the companies who show up with something substantive when they look are the ones who benefit. The rising tide is real. Whether it lifts your ship in particular depends entirely on whether you're in the water when it comes through.

How to actually capitalise on it

Move in the window, not after it. The broad tech press covers a story like this for a few days, then moves on. There's then a two to four week window where people are still actively searching and asking AI tools about it, but almost nothing published so far actually explains the substance rather than repeating the announcement. That window is the opportunity. A same-week or same-fortnight piece that goes past the press release will outrank a more polished piece that shows up a month later, because both search and answer engines weight recency heavily on a live story.

Write for the next question, not the headline. The generic query "Nvidia CUDA RISC-V" is already crowded with rewrites of the same three facts. The gap is in what a technical buyer or engineer actually types next: does CUDA work on RISC-V yet, which RISC-V chips support CUDA, is RISC-V ready for AI datacenters, how does this compare to Arm for AI infrastructure, can I buy a RISC-V server that runs CUDA today. Build content that answers those directly, in plain sentences, and you're building for the question volume that's still coming rather than the one that's already spent.

Get named alongside the primary sources. RISC-V International, SiFive, and Red Hat are the accounts most likely to be treated as authoritative on this story by search and by AI answer engines. A piece that cites them accurately, links out properly, and adds something they didn't cover (a translation for a specific buyer audience, a caveat the coverage missed, a comparison the announcement didn't make) has a real shot at being picked up or referenced by the people already covering this space. That's worth more than any amount of keyword stuffing.

Make the honest caveat part of the pitch. BigSky ships in limited quantities. ACPI support has historically been patchy even on Arm after years of standardization, so the realistic read is narrower than "RISC-V datacenters have arrived": the technical blocker is gone and there's now a real product, not that this is mass-market yet. Naming that yourself, credibly, is what makes a piece trustworthy to an engineer and it's good practice for answer engines too, which tend to favor sources that show both sides rather than pure hype.

Turn one good piece into several formats while it's still current. A single well-researched explainer is the anchor. From it: a LinkedIn post making the sharpest single point (promise to production in a year is the strongest hook), a short technical breakdown of just the platform requirements for an engineering audience, and a follow-up comparison piece once competitors respond, because they will. One piece done properly beats three thin ones chasing the same keyword.

Connect it back to what you actually do. The highest-value version of this content isn't neutral commentary, it's commentary that lands on "here's what this means for you, and here's where we fit," whether that's IP, tooling, infrastructure, or services. That's the difference between a piece that gets read once and a piece that starts a conversation.

Structure it so both a person and a machine can use it. Clear headers that state a claim rather than a vague label, a direct answer near the top before the color and caveats, and the technical detail laid out plainly rather than buried in a paragraph. That's what a busy engineer scanning on their phone wants, and it's exactly what an AI answer engine is looking for when it picks a passage to cite.

The tide is rising for the whole ecosystem right now. The companies that publish something real on this in the next couple of weeks, rather than a share and a hot take, are the ones whose ships actually go up with it.

Dollar in, dollars out: The over-simplification of ROI

The first time I had an espresso martini I felt like a poser.

Not because I was surrounded by advertising types far cooler than me. Though I was. But because it was at a Twitter Christmas party which I’d been invited to as a client from a high growth startup, which had gone bust a month earlier. The good folks at Twitter didn’t pull the invites, but it made the name badge situation more awkward. 

Twitter at that time, like Google and Facebook, felt like magic to me. Put this many dollars in, get this many results out, and scale as much as possible. Brilliant. My colleagues and I would stress over CPAs and LTVs and CACs and there’d be long arguments about attribution models, brand vs performance budgets, and ROI. You could, with a straight face, say things like “If we look at last click data PoP, the ROI based on current CPAs looks down because our CAC is rising, but LTV is actually up…” and people would nod their heads gravely. Good times.

The promise and simplicity of spend more on a channel, get this result was very compelling. Largely because it gave marketing hard numbers to send back to finance to justify cost, with return, and forecast more scale for more budget. Never mind that those compelling promises were from platforms that simultaneously sold the ads, the inventory and the black-box measurement touting their own efficacy…

The apparent data transparency from digital has created a lasting expectation that ROI in modern marketing is easy to figure out because everything is measurable. Most marketers I speak to, or whose work I follow, understand the real-world complexity. They get that return on this quarter, or this year’s investment will not be fully ‘returned’ this quarter or this year, or even next year, that different channels come with different measures, that much of marketing is probabilistic rather than deterministic, as Rory Sutherland reminds us.

Subsequently, a lot of folks a lot smarter than me are fed up with basic ROI as a metric. I get it. But does your Finance Business Partner, or CFO, or CEO? Or have they come up through the last-click, demand-harvesting, PPC era where dollar in = dollars out?

AI creates yet more promise, because in theory it has the capacity to move everyone closer to the data, get questions answered faster, with more specific context. But even if your AI platform can access and make sense of your marketing data (…that’s a whole other post), if you ask it the wrong question it will still answer using the framework you give it, and you may well then pay that answer forward.

If you're chasing a closed loop concept of money spent - measurable data touch points - money returned, you’ll always be chasing. Marketing is a growth engine for the enterprise. Where you're forecasting market share growth, product sales growth, revenue growth, those are all outcomes where marketing is having an influence. And for each there will be measurement concepts that everyone at the table needs to have an understanding of in order to properly articulate marketing's value creation.

Some of that includes direct return from advertising, but some of it will be the result of years of good work creating fame which compounds over time, and creates more opportunity for potential upside as it compounds. Using the language of finance alone without the deeper work of a shared understanding of how value is being created over time leaves you at risk of feeling much like I did, in East London at a tech platform party drinking espresso martinis… like a poser.

If you want to get specific on how you’re measuring and demonstrating your marketing impact, get in touch, I’d love to help.

Simon Jared is a Co-Founder of Latent and directly manages all Build Operations engagements.

State of Marketing: RISC-V

RISC-V chip shown below a market surface line — detailed circuit visible below, pixelated above, illustrating the RISC-V commercial visibility gap.

RISC-V is making great strides.
Here’s how to make sure the market knows it.

RISC-V Summit Europe just wrapped in Bologna. If you were there, you already felt the momentum. If you weren't, the signal is the same: this ecosystem is moving. NVIDIA ships over a billion RISC-V cores across its GPU products. Qualcomm has more than 650 million in Snapdragon. SiFive counts two billion devices powered by the ISA it helped create. The open standard once dismissed as a niche academic project is now embedded in the infrastructure of AI.

Speaking fresh from his opening keynote, RISC-V International CEO Andrea Gallo points to a confluence of factors making 2026 a genuine turning point: growing investment across the ecosystem, the ratification of the RISC-V Server Platform specification, and real RVA23 silicon that is shifting RISC-V from "inevitable" to "now."

But if now is the moment, the technical momentum isn't the issue. The issue is whether the commercial narrative is keeping pace with it.

We spent the last month auditing the marketing and content presence of every full member of RISC-V International — 27 companies across Premier and Strategic tiers. What we found is a sector with genuine technical credibility and a significant, largely untapped opportunity to convert that credibility into a commercial pipeline.

The range is wide. The highest score across the cohort was 62 out of 100, and a number of companies are genuinely punching above their weight — building strong content with lean teams and getting the technical story in front of the right audiences. What's encouraging is that the companies with the most headroom also have the most to gain, and in most cases the fixes don't require a single new hire.

It's worth saying that these aren't scores against some idealised benchmark. They reflect what's achievable with the resources most companies in this space are working with. The companies at the top of the range are doing this well under real constraints.

What's consistent across the cohort is a shared set of quick wins that show up regardless of company size, funding stage, or geography. The companies already acting on them are pulling ahead fast.

What the audit found

Five patterns stood out across almost every site.

1. The comparison conversation is up for grabs

Every buyer in this ecosystem — evaluating processor IP, development tools, or silicon infrastructure — will at some point search "RISC-V versus Arm" or compare two vendors directly. Those searches carry the highest commercial intent in the category. Right now, they mostly resort to third-party editorial: EE Times, AnandTech, Stack Overflow. The opportunity to own those conversations is wide open, and the companies that move first will define how the category is understood.

2. Proof points deserve more than a press release

Shipped volumes, funded amounts, customer wins — these numbers are the commercial backbone of any deep tech company's credibility. The quick win here is giving them a permanent home. A dedicated page with context, citations, and a narrative holds onto search authority indefinitely rather than fading after a few weeks. It's consistently one of the highest-return moves we identified.

3. The hub page is often missing

For many companies in the cohort, the content is already there — it's just distributed across product sub-pages and developer portals on separate subdomains. Consolidating it around a single hub page is one of the fastest ways to see outsized returns from work that's already been done.

4. Partnerships get announced. They rarely get capitalised

A hyperscaler co-marketing deal or a Tier 1 OEM partnership is a landmark moment — and it creates a keyword cluster that could drive qualified traffic for years. The companies getting the most from this treat each partnership as a content asset to keep building on. A handful of members have cracked this, and the traffic differential versus peers is significant.

5. Developer documentation is a double-edged asset

Technical documentation is often the most authoritative content a company produces — and in this ecosystem it frequently lives on a separate subdomain. Every Stack Overflow citation, every GitHub reference, every developer forum link builds authority that doesn't feed back to the commercial site. The fix isn't to merge documentation into the main site — it's to create deliberate bridges between the two.

Why the next 18 months matter

RISC-V has proven its place. What happens now is about visibility and commercial translation — which companies can make their proposition legible to enterprise procurement teams, to non-specialist investors, to the partner ecosystem that determines distribution at scale.

The companies in this ecosystem that build their content and credibility infrastructure now will be the ones that define how the category is understood — by buyers, by investors, and by the press. The technical story is already there. The marketing resource to carry it is established.

That's the RISC-V marketing opportunity. It's measurable, it's consistent across the cohort, and for the companies already doing well on the technical side, it's the natural next move.

Latent works with deep tech companies to build the marketing credibility that makes complex technical propositions commercially legible. Curious where your company landed in the audit? A few scored higher than they expected — and the gaps that did show up were often simpler to address than assumed. If you'd like to compare notes or discuss how to close the gap, get in touch. We'd love to talk.

Deep tech built the AI. Deep tech can't get found by it.

What auditing 101 deep tech websites taught us about being wrong in public.

Somewhere in this dataset are the chips, the compute providers, and the infrastructure layers that the models behind ChatGPT, Claude, Perplexity and Gemini run on. So we asked those same systems a simple question: what do these companies do? For a third of the sample, the honest answer wasn't in the company's own words. It was assembled from press coverage, distributor listings, and archived articles, some of them years out of date.

We didn't set out looking for that story. We set out to test a different one, and got it wrong in a useful way.

We spent several weeks scoring deep tech websites. Not skimming them. Opening each one, reading what a buyer would read, checking what a crawler would find, hunting for the third-party record that exists about the company somewhere other than its own domain. A hundred and one companies across silicon, cloud AI, edge AI, robotics and quantum.

Deep tech is struggling to get recommended by the technology it helped build

We started with a hypothesis that felt obvious. Deep tech companies have real technical substance and bad websites, so they should score badly on traditional search and better on answer engines, because models can assemble an answer from the substance even when the site structure is poor.

The first segment we audited in full was silicon and semiconductor. Thirty-four companies, every one scored on both dimensions. The result was emphatic: answer engine scores ran twenty-four points ahead of search scores on average. Some individual gaps were forty points and more.

We had our thesis, with data behind it. So, we wrote the report around it.

Then we scored the other four segments

Cloud AI came back level. Edge AI, four points. Physical AI, minus three. Quantum, minus four.

The pattern we had built the report on did not exist. There was no sector-wide gap between search and answer engine performance. There was one segment with an enormous gap and four segments where the two scores sat more or less on top of each other, two of them tilting the other way entirely.

Silicon was not the illustration of a rule, but the exception, and we had generalised from it because it was the first segment we finished.

Which is a better finding than the one we lost

Once we stopped trying to make silicon representative, the actual explanation was straightforward, and more useful than the thing it replaced.

Semiconductor companies sit inside an unusually dense external record. Trade press covers them. Distributors list their parts with specifications. Standards bodies publish their membership. Academic papers cite their architectures. The listed ones have a ticker symbol that anchors their identity beyond any ambiguity. Ask a model what one of these companies does and it can assemble a confident, accurate answer without that company's own website contributing much at all.

That is why the segment scores forty-two on its own websites and sixty-six on answer engines. The ecosystem is carrying them.

We started calling it borrowed visibility, because it is not the same thing as being visible. These companies are being described accurately by systems their buyers use, on the strength of a record they neither wrote nor control. It looks like health on one score and failure on the other, and the honest diagnosis is neither.

It works until it doesn't. One company in the study has an external record that still confidently describes product lines it exited two years ago, because that is what the archived coverage says and nobody has restated the position clearly on the company's own domain. The record went stale and there was nothing on the site to correct it.

The finding that should worry people more

Quantum and physical AI run the gap in the opposite direction, and that is the more expensive problem, because it is invisible from a conventional SEO report.

These are not neglected websites. They have clean technical setups, good crawlability, active publishing schedules, genuine press coverage in the Financial Times, Bloomberg, IEEE Spectrum. On traditional search they score respectably. On answer engine readiness they fall behind, and the individual cases are stark. One Nasdaq-listed quantum company scores sixty-one on search and thirty-two on answer engines. Another, with a strong content and press engine, falls twenty-four points, because it presents a dual identity across two categories and a model cannot resolve what the company actually is.

The cause is not neglect. It is that the content is written to build a narrative rather than to state a fact. Deep tech marketing copy is often genuinely good writing, structured as an argument that unfolds. Answer engines do not read arguments. They extract claims. A page that never states a fact in one self-contained sentence gives them nothing to lift, no matter how well it is written.

These companies are doing the expensive work already. They are losing on the packaging layer, which is the cheapest layer to fix and the one nobody is checking, because their SEO dashboard says everything is fine.

Three other things we did not expect

Funding predicts nothing. One company in the sample has raised past a billion dollars across its rounds and its entire public website amounts to a company name and a careers link. Wikipedia currently carries a fuller description of what it does than its own homepage. Meanwhile a six-person pre-seed company in Malmö scores seventy-eight, ahead of most of its far better-funded peers, because someone there wrote a good llms.txt and a clear entity statement. That is a few hours of work, not a budget.

Having an llms.txt is not the same as having a useful one. Several companies technically have the file. At least one is auto-generated CMS output listing popup themes and slider taxonomies. The company's actual white papers and case studies never made it in. The file exists, the box is ticked, and it does nothing.

The most common gap is also the cheapest to close. Across a hundred and seventy-two individual findings, forty-three per cent were quick wins: one page, one tag, one file. Only nineteen per cent needed sustained content investment. Most of what is broken here could be shipped inside a week by one developer who knew what to fix.

What we would tell you to do with twenty minutes

Ask two questions, in order, against your own site.

●          Does dedicated content exist for what you do, beyond a homepage and a press release archive? Real product pages, technical explainers, case studies. If no, that is the first problem, and it is a content problem measured in months.

●          If yes, is that content structured so a model can extract it? An llms.txt file, direct-answer or FAQ formatting, structured data, one plain sentence stating what you are. If no, that is a packaging problem, and it is usually measured in weeks.

Then a third thing, which is not on that list because it is not a yes or no. Ask an answer engine what your company does, and read the reply as a buyer would. If the description that comes back is assembled entirely from press coverage and directory listings rather than your own words, you are being sold by other people, in their framing, with their emphasis, at whatever level of currency their archive happens to have.

That is borrowed visibility. The industry that built the machine still has to teach it who they are, one llms.txt, one FAQ, one plainly stated fact at a time. A third of the companies we audited haven't started.

The full Deep Tech Signal Report covers all 101 companies, five segment benchmarks, and the complete methodology. It is published as a web page rather than a gated PDF, which given the subject matter felt like the minimum we could do.

Read the report: lttps://www.latentconsulting.com/get-found-or-get-ignored

Book a Surfacing Call: https://outlook.office.com/book/SurfacingCall@latentconsulting.com

How to find the story before the technology is ready

The conversations I find most interesting right now are with companies that are somewhere in the middle. They’re not early-stage, where the story is mostly about potential and team and why the problem matters. Not mature, where the technology speaks for itself and marketing is largely execution. The middle — where the technology works, the use cases are real, but the market doesn't yet have a way to evaluate it. 

The middle ground

Quantum computing is the clearest current example. We're speaking to companies navigating the shift from trapped-ion qubits in university labs to commercially scalable quantum processing units that can sit alongside traditional server racks in a 19-inch chassis. The engineering is sound. The commercial opportunity is vast. And yet the dominant public narrative around quantum is still somewhere between science fiction and perpetual ten-years-away scepticism, which means that every conversation with a potential customer or investor starts from a deficit of credibility rather than a foundation of it.  

Quantum’s credibility gap

The instinct, when you're in this position, is to reach for scale. To try to collapse the credibility gap by making the biggest possible claim about what the technology will eventually be able to do. I get the logic. It's also usually the wrong move. 

The problem with marketing ahead of the technology's maturity is that the audience you most need to convince — the CTOs, the infrastructure engineers, the people who will actually integrate this into a production environment — are precisely the people who will see through over-claiming first. They've heard the roadmap pitch before. They've been burned by it. And once you've lost that audience, getting them back is significantly harder than earning them in the first place. 

Why over-claiming backfires

The other failure mode is the opposite one: waiting. Holding back the story until the technology is fully optimised, fully proven, fully ready for the case study. The problem is that by then, someone else is already writing the category. The framing that will shape how buyers evaluate every solution in the space — including yours — is already being built without you. You can enter a mature conversation, but you can't own it. 

The other trap is silence

So you're caught between over-claiming and silence, and neither works. What does work is finding the story that sits at the intersection of what's true today and what's becoming true — and being honest about which is which. 

For quantum, that means not pretending the use cases are the same as classical HPC. That's like claiming Concorde was going to replace your daily commute. It means finding the specific computational problem that classical hardware genuinely cannot solve efficiently — optimisation at scale, molecular simulation, certain classes of machine learning — and anchoring the conversation there. Not "quantum will change everything" but "here is the specific class of problem where quantum changes the economics, here is what that's worth to the person who has that problem, and here is where we are on the journey to delivering it reliably." 

The qualifying phrase at the end is the one most marketing instinct wants to cut. It's also the one that earns you the credibility to be heard on the rest. 

Finding the intersection

We saw this with ambient intelligence. When the term started gaining traction, the vision was genuinely compelling — environments that understood and responded to human behaviour without requiring explicit input. The use cases that actually got adopted were narrower, more specific, more dependent on particular hardware configurations than the original narrative had allowed for. When the market's actual adoption pattern became clear, the brands that had over-indexed on the expansive vision had to do expensive repositioning. The ones that had built their story around specific, solvable problems in specific contexts were already there. 

The same thing is happening in robotics right now. The general-purpose humanoid narrative is running well ahead of the operational reality. That gap will close — parts of it are closing faster than most people expected. But the companies building durable market positions in robotics are the ones that have found the specific industrial problem where their particular system performs reliably, and are building credibility there, rather than trying to own a category that doesn't yet correspond to anything a buyer can act on. 

There's a craft to writing ahead of the technology that's different from writing about the technology as it is. It requires being precise about what's proven and what's directional. It requires understanding your audience well enough to know what claims they'll accept on evidence and what claims they'll only accept on trust — and building that trust first. And it requires the willingness to update the story as the technology and the market both evolve, without treating that update as a failure. 

The frame you build now shapes how your audience evaluates you when the technology does arrive. Build it too far ahead and you've created a credibility problem. Build it too conservatively and you've created a perception problem. The job is to find the version of the story that's honest about where you are, ambitious about where you're going, and specific enough about the problem to give someone a reason to stay in the conversation until both things are true.

I’m Dale, a Co-Founder here at Latent, and I love these kinds of conversations.

Ready for space, not ready to be understood

I spent a day at a deep tech summit recently talking to founders across the funding spectrum, from freshly minted Series A companies to businesses that have been shipping for over a decade. Each was at a different stage, in different markets, with different technologies. But one problem kept surfacing, almost word for word, across five separate conversations.

None of them could tell me what their company was worth.

They could all tell me what it was, in precise, fluent, technically correct detail. But when I asked the simple question every investor and every customer is really asking, "what does it do for me," the answer kept coming back as a spec sheet.

Here is the clearest example, with the company kept anonymous because the founder was incredibly smart, generous with their time, and building something important. Which is rather the point.

We got talking. I asked what the company did. Without a word, he reached into his pocket, produced some hardware, and walked me through its technical specifications. I asked again: what does it do? He answered by telling me, in detail, what the componentry does. Not what it changes. Not what it protects. Not what it is worth to the person holding it.

That evening I went to the website. It added a second layer of fog. Clean enough, but it read like a parts catalogue, somewhere between a Screwfix listing and an Amazon product page. Nothing on it told me what the thing was for.

So I dug. And here is what that company actually has. The product is an entropy source: the component that generates the raw randomness sitting underneath encryption. That still sounds dry until you follow the thread. Every encryption key depends on randomness. If the randomness is predictable, the key is guessable, and it does not matter how advanced the algorithm sitting on top of it is. This is the quiet foundation that the whole of digital security rests on. Most systems today produce that randomness in software, using deterministic maths to imitate chance. It holds until someone with enough compute and enough motivation decides to work backwards.

Asking a piece of deterministic software to produce true unpredictability is a bit like asking a calculator to write poetry. It can approximate the shape. It cannot do the thing.

This company's board draws its randomness from physics itself, which is about as close to truly unpredictable as it gets.

Now add the timing. Adversaries are already recording and storing encrypted data they cannot yet read. The bet is simple: capture it now, decrypt it later, once quantum machines can break today's encryption. It is called harvest now, decrypt later, and the harvesting is happening today while the decryption waits in the near future. Warehouses of hoarded data are sitting quietly, waiting for the day the locks stop working. Post-quantum cryptography regulation is arriving to force the migration, with 2030 already marked on the calendar as a line in the sand.

So this is the foundational security layer for the post-quantum age, built on elemental physics, aimed squarely at nation-state adversaries and the kind of threats that keep governments and enterprises awake. And the proof was all there. Patented. Tested in low Earth orbit and proven in zero gravity, which is a decent hint it can cope inside a data centre. Trusted by four major OEMs. Cheap. A clear path from a USB key you can hold in your hand up to rack-scale deployment. A regulatory tailwind, and an investor story that stood up. All of it real, none of it landing, while I was being handed a board and a list of specs.

The distance between what that company is and how it was described was enormous. And it was not a one-off. It was the fifth version of the same conversation I had that day.

This bit is key- This is not a criticism of founders. It is the norm among brilliant technical people, and there is a good reason for it. When you have spent years inside a technology, you understand it at the level of how it works. The value it creates for someone standing outside it is a different language, and fluency in one does not hand you fluency in the other. The founder was not failing to communicate. They were communicating the wrong layer, because the technical layer is the one they’ve lived through 50-hour weeks for years.

The cost of that gap is heavy and mostly invisible. In a room full of people who cannot easily tell a real breakthrough from a forgettable one, the companies that win attention are not the best ones. They are the ones that are easiest to understand. Investors nod politely and move on. Customers file it under "not sure I need that." Partners never make the call. The technology does not fail in the lab. It fails to get out of it.

This is the problem we built Latent to solve, and it is why we describe ourselves as the translation layer. Deep tech companies are often technically extraordinary and commercially invisible at the same time, and the distance between those two states is not more engineering. It is positioning, narrative, and the discipline of leading with value instead of specification.

The work has a natural order to it. First you make the technology legible: you find the one sentence that tells a stranger why it matters, before anyone else defines the company for them. That is what turns a board in a pocket into "the foundational security layer for the post-quantum world." Then you build the credibility around it, the proof and the presence that make serious buyers take it seriously. Then, and only then, you turn that into pipeline and revenue. Lab, to market, to commercial traction. Most deep tech companies are stuck at that first step, and most do not realise it is where they are stuck.

We spent years at Arm doing exactly this for compute categories that people could not yet explain. AI silicon, compute subsystems, inference at the edge. None of them sold themselves. The job was turning opaque propositions into language that investors, OEMs and enterprise buyers acted on. The companies I met at that summit need the same thing- Some of them get it, and we’re meeting again this week.

The technology in that room was ready for space. It simply was not ready to be understood. And in this market, being understood is the part that decides whether you make it to revenue.

If you are building something remarkable and watching people not quite get it, that gap is fixable, and it is usually the highest-return work you are not yet doing. The best technology does not always win. The clearest usually does.

I’m Dale, I’m a Co-Founder here at Latent, and I love these kinds of conversations.

Build Credibility

Is the UK exporting all it’s innovation?

We spent the day at CWTEC26, Cambridge Wireless's annual event, listening to the people building the UK's semiconductor industry. Charles Sturman from TechWorks opened with the numbers, and they're worth recounting. UK semiconductor companies generate around £11bn in direct revenue, about 2% of the global market. Three hundred companies work directly on chip design and manufacture. Another four hundred are doing semiconductor-adjacent development. Roughly 27,000 people are employed in the sector, and it's backed by a strong university research base and a startup and spinout culture that keeps producing new companies worth watching.

None of that is small. But it's also not where it could be, and the reason isn't a lack of ideas.

The UK is great at the early part of the journey. It's where a lot of the world's most interesting semiconductor and photonics IP still gets invented, in university labs in Cambridge, Manchester, and beyond, then carried out into spinouts by people who've spent a decade or more on the underlying science. Paragraf is a good example. Their graphene process came out of research at the University of Manchester in 2004, and it took until 2018 for that discovery to become a company, and years more to build the manufacturing capability to actually produce anything at volume. Their COO - Tony Pearce talked candidly at CWTEC about how much slower and more expensive the build was in the UK compared to somewhere like the US, where capital and complementary companies are easier to find.

That's the pattern we keep seeing. A technology survives years of research, funding rounds, and the genuinely hard work of turning a lab discovery into something manufacturable. By the time it's close to contributing to that £11bn figure, an enormous amount has already been spent getting it there. Custom Interconnect's John Boston put the wider problem well when he talked about the UK's tendency to invent the technology and then treat manufacturing as something beneath it, work that gets sent elsewhere once the hard science is done. The result is that most of the value created in UK labs ends up being captured overseas, by whoever picks up the manufacturing and the commercial relationship once the risky part is finished.

You can see the same shape in SCI Semiconductor's CHERI work, for different reasons. Haydn Povey highlighted that memory safety vulnerabilities were first identified in 1972 and are still one of the most common routes into modern systems, costing an estimated $10.5 trillion a year globally, according to McKinsey. CHERI, developed through years of UK university research and Ministry of Defence and GCHQ-backed funding, closes off most of that risk at the architecture level rather than patching it after the fact, and Google's own testing found it improves performance rather than costing anything for the added security. With the EU's Cyber Resilience Act now in force and the UK government committing £26m to CHERI adoption, the timing for this kind of technology is about as good as it gets. It's a strong illustration of just how much can go right on the fundamentals of a UK deep tech story, decades of research, real funding, strong regulatory tailwind, and still leave the hardest part of the journey, getting it adopted at scale, still ahead.

That's really the point. None of this is about the UK lacking good technology. It has plenty. The risk sits in the last stretch, after the science works and the manufacturing is built, when what's needed is a clear proposition and a pipeline that turns capability into adoption. Get that wrong, or leave it too late, and a technology that's already cost years and millions to develop can lose momentum right at the point it was supposed to start paying that investment back.

Given how much has already gone into a technology by the time it reaches that stage, treating the commercial side as an afterthought is the most expensive mistake a UK deep tech company can make. It's usually the smallest remaining piece of the journey, and the one most likely to determine whether everything before it was worth it.

This is the part of the journey we work in. Not manufacturing, and not the underlying science, but making sure the story, positioning, and pipeline are in place before a technology needs them, so the UK doesn't do the hard part brilliantly and then lose the value at the finish line. If that gap sounds familiar, it's worth a conversation.

The legacy vendor AI repositioning problem

There is a particular kind of pressure that doesn't get talked about in deep tech marketing conversations, because the companies feeling it most acutely are the ones least likely to admit it publicly. 

They've been in market for twenty, thirty years. They have real customers, real revenue, and a reputation earned the hard way across generations of product cycles. And somewhere in the last two years, the conversation shifted. The buyers they've been selling to are now asking a different set of questions. The competitors they've spent years outmaneuvering have repositioned as AI companies. The analysts who used to write about them in predictable ways are starting to frame the category differently. 

The problem isn't that these companies don't have an AI story. Most of them do. But like everyone else who stamped AI on their product, it sounds like everyone else's.

There's a version of AI repositioning that almost every legacy vendor defaults to. They take the existing product description, add the words 'AI-powered' or 'AI-enabled', update the website headline, and brief the PR team to find an AI angle for the next product launch. It ticks the box. It does not move the market. I’ll admit I’ve been asked ‘Can you make this more AI-washed?’ and the best answer in my experience tends to be ‘no’. 

The reason it doesn't work is that technically sophisticated buyers; the CTOs and architects and procurement leads at the OEMs and hyperscalers and enterprise customers that these companies are trying to reach have seen this exact skulduggery from fifteen different vendors in the past eighteen months. They know what it looks like, they have a filter for it and when your repositioning looks like wallpaper, you don't just fail to gain credibility — you actively lose it, because the attempt signals that you don't have a story worth telling. 

What Arm went through is a useful reference point. The business had built its position over three decades on a clear, defensible model: IP licensing to chip designers who built the hardware that everyone else then built on top of. That model was well understood. The relationships built around it were real and deep. And then the AI infrastructure buildout created a moment where the architecture question — what compute is the world's most demanding AI workloads going to run on — was genuinely up for grabs. 

The challenge wasn't technical. Arm's position in AI infrastructure was already strong. NVIDIA runs on Arm. AWS, Google, Microsoft, and Meta were all building custom silicon on Arm Neoverse. The trajectory was there, but the challenge was commercial: how do you reposition as a company at the center of the AI infrastructure story without disrupting the licensing relationships that built the business, and without making claims that your ecosystem of partners will immediately fact-check and find wanting? 

The answer wasn't a campaign. The proof points that were specific, verifiable and credible to a technical audience. The broader narrative came second, built around those proof points rather than built in advance of them. And the message was calibrated differently for each audience: for the investor, the story was about where AI compute was concentrating and why Arm's architecture was structurally advantaged; for the OEM and the chip designer, the story was about what specifically had changed in the tools, the ecosystem, and the programme support available to them. 

That sequencing, with proof before narrative, and different narrative for each seat is what most legacy vendor AI repositioning gets wrong. The instinct is to announce the position before the proof is assembled, because the competitive pressure feels urgent and the board wants to see something in market. The result is a claim without substance reaching the exact audience most skilled at identifying claims without substance. 

The other failure mode is narrowing too early. Legacy vendors often try to claim AI relevance in the specific product category they already occupy, because that's the safest ground. What they miss is that the more interesting and defensible AI story is often structural — about where they sit in the supply chain, what they enable that nothing else can, and why the AI transition makes that position more valuable rather than less. That's a harder argument to make, but it's the one that lands with the buyers and investors who are trying to understand what the next five years look like. 

The companies getting this right are the ones who've accepted that AI repositioning is not a marketing exercise. It's a commercial strategy question that marketing then has to express. The sequence is: understand where you actually sit in the AI value chain, build the proof that substantiates that position, then build the narrative. In that order. Reversed, it produces exactly the kind of repositioning the market has learned to ignore. 

Dale Kaszycki is a Co-Founder of Latent