OUTKOM CATALYST — Technology Overview

Where This Sits in the Arc

The origin story earned the right to make an argument. The Problem ↔ Solution framework made it. This module proves it.

The Technology Overview is where your architecture becomes evidence. Not of how clever the engineering is — but of how directly it answers the structural problem you named in Module 2. Every design choice, every technical decision, every thing you gave up and what you gained in return: this is where those choices become narrative assets rather than engineering footnotes.

Done well, a founder's technology narrative makes a non-technical reader understand — not just believe — that a new category of solution now exists. That's the difference between a spec sheet and a story.

The Mindset Shift This Module Requires

Your technology is not the argument.
It is the proof of the argument.

This is the hardest module for most deep-tech founders. You have spent years — sometimes decades — inside the mechanism. You know every component, every tradeoff, every failure mode. That depth is real and it matters. But the narrative job of this module is not to transfer that knowledge. It is to make a non-expert feel the significance of what you built — and understand, in plain language, why no one else built it this way before. The mechanism is not the story. The meaning of the mechanism is.

What This Produces

Not a spec sheet.
A translated narrative.

The output of this module is a technology narrative that can travel without you. A non-technical investor reads it and understands why this architecture matters. A corporate partner reads it and sees where your technology fits inside their system. A potential hire reads it and wants to be part of what you're building.

It doesn't require technical fluency to land. It requires the kind of translation that only comes from a founder who knows the engineering deeply enough to leave most of it out — and precise enough to know which parts must stay in.

The Three Prompts

Work through Prompt 01 completely before moving forward. The pause band after it is not optional — it's the translation checkpoint. Prompts 02 and 03 only land if 01 has done its job.

What the Technology Replaces

Not a competitor — a paradigm. What is the fundamental mechanism, architecture, or assumption that the incumbent approach was built on? And what did you build instead? Describe the old premise and the new one in plain language. The goal is not to make the old approach sound broken — it's to make the new approach sound inevitable. Your answer here should complete the sentence your Problem ↔ Solution framework started: Module 2 named what changes in the world; this prompt names the engineering architecture that makes that change possible. This is where the argument becomes evidence.

Field note

"Traditional HVAC was built on a mechanical premise: compress a refrigerant, move air in bulk, condition the space. That architecture has been optimized for decades. What it cannot do — by design — is deliver thermal conditions at the resolution of individual people or specific points of use. We built on a different premise: solid-state thermal control, no compressors, no refrigerants, heat moved with electrons rather than moving parts. Not better HVAC. A different category of thermal system."

Field note

"The incumbent model for building climate systems is site-built assembly: different trades, different timelines, coordinated under schedule pressure in occupied or revenue-generating spaces. The premise was never questioned — it was inherited. We built on a different premise: climate infrastructure as a manufactured product, assembled off-site, tested before delivery, installed as a single connection point. Not a more efficient job site. A different delivery model entirely."

Before You Continue

The paradigm shift must land
before the mechanism can.

Read back what you wrote for Prompt 01. Find someone outside your industry — a family member, a generalist advisor, someone with no background in your sector — and read it to them. Ask one question: do you understand why this is a different kind of thing, not just a better version of the same thing? If the answer is yes, continue. If not, return to the prompt.

A Note on Discomfort

This is where the technical founder most often feels resistance. You've spent years in the mechanism — the architecture, the tradeoffs, the precision of what makes your approach work. Leaving most of that out doesn't feel honest. It feels like dumbing it down. It isn't. Translation is not simplification. It is the act of finding the one sentence that carries the full weight of the engineering without requiring the reader to earn it first. That sentence exists. This prompt is how you find it.

Test 1 — Paradigm, not product

Does your Prompt 01 describe a different way of thinking about the problem — not a better solution within the existing framework? If a competitor could read it and say "we do something similar," the paradigm shift hasn't landed yet.

Test 2 — Earned, not asserted

Does the new premise feel like the logical consequence of the problem you named in Module 2 — or does it feel like a claim you're making about yourself? The shift should feel inevitable to the reader, not impressive. Inevitable means the problem demanded it. Impressive means you're proud of it. These are not the same thing.

Prompts 02 & 03

With the paradigm shift established, the remaining two prompts build the translation: how it works, and why these choices — the design decisions that reflect conviction, not convenience.

How It Works — Translated

Explain the core mechanism in plain language — not dumbed down, translated. Write as if you're explaining it to a smart generalist: a sophisticated investor, a senior operator, a strategic partner who needs to understand the architecture without becoming an engineer. What is the core principle? What does it actually do? What does the system look like in practice, at the point of use? 200 words maximum. If you exceed it, you haven't finished editing.

Field note

"Each unit contains an array of independent thermal cassettes — compact solid-state modules that move heat with electrical current rather than compressed refrigerant. Individual cassettes can heat or cool simultaneously, at different setpoints, in the same space. The result: thermal conditions that respond to the people in a room, not the room's average. No compressors. No moving parts. No refrigerant cycles. The system degrades differently than mechanical HVAC — because there is no mechanical wear."

Field note

"The Hydropod XL consolidates heating, cooling, ventilation, and hot water into a single exterior enclosure — assembled off-site, pre-wired, pre-charged, and tested as a complete system before it arrives at the building. One enclosure serves multiple apartments from a single outdoor location. No mechanical room. No in-unit equipment. Installed in one to two days. The building's residents don't need to vacate. The climate system behaves like a product that was manufactured — because it was."

Why This Architecture — The Conviction Behind the Choices

Every design decision involves a tradeoff. What did you deliberately give up — and what did you gain? What did you choose that an incumbent player wouldn't have chosen, and why? This isn't about claiming superiority. It's about naming the conviction that shaped the architecture. The choices you made under constraint, under uncertainty, under pressure — those choices are where your technical point of view becomes a narrative asset. Name two or three specifically.

Field note

"We gave up brute-force capacity. Solid-state thermal control operates at lower power density than mechanical compression at scale — that's a real constraint. What we gained: precision, silence, durability, and digital observability at the module level. An incumbent player would not have made that trade. They would have optimized within the mechanical paradigm. We built outside it."

Field note

"We chose standard components over proprietary ones — intentionally. An integrated system built around exotic parts creates vendor lock-in and long-term service risk. We gave up the ability to differentiate on component exclusivity. What we gained: serviceability by any qualified HVAC trade, no dependency on our supply chain for ongoing operations, and an owner's total cost of ownership that we can actually defend. Integration is the product. The components are intentionally familiar."

Next Steps

From mechanism
to narrative asset.

Step 01

Translate, don't simplify

The 200-word limit on Prompt 02 is a discipline, not a constraint. If you need more words, the translation isn't finished. Edit until the mechanism is clear — not until the detail is gone.

Step 02

Test on a non-expert

The standard: after reading your technology narrative, a non-technical reader should be able to explain to a third person what your technology does and why it's different. If they can't, return to Prompt 01.

Step 03

Connect back to the arc

Read your origin story, problem statement, and technology narrative in sequence. Each should feel like the inevitable next sentence. If the technology feels disconnected from the problem, the translation hasn't done its job.

Step 04

Treat it as a source doc

This narrative is the source document for your pitch deck technology slide, your website architecture section, your OEM briefing, and your grant application technical summary. Everything derives from this. Keep it current as the technology evolves.