A five-pillar architecture for evaluating whether deeptech and innovation ventures can create, capture, and sustain economic surplus under uncertainty.
Innovation Decision Architecture helps founders, investors, and corporates evaluate whether innovation ventures can create, capture, and sustain economic surplus under uncertainty.
Innovation ventures are not simply products, startups, technologies, or pitch narratives. They are economic systems operating under uncertainty. The architecture asks what must be true for value to be created, captured, sustained, validated, and translated into investment logic.
Explore Decision OutputsVenture as Designed Economic System
The product is not the unit of analysis. The innovation system is.
Create • Capture • Sustain
Value creation alone is insufficient. Surplus must be captured and defended.
Business Model as Design Space
The business model is a universe of hypotheses, not a static template.
Assumptions as Design Parameters
Critical assumptions determine whether functional requirements can be satisfied.
Progress as Uncertainty Reduction
Progress is proof that changes venture value, not activity completed.
Venture as Designed Economic System
Most innovation ventures are evaluated as if the product or solution is the primary object of analysis: the team, the product, the market, the traction, and the business model. These are important, but they do not fully explain whether the venture can work.
A deeptech or innovation venture operates inside a larger system. That system includes the customer need, the user workflow, the technology stack, the value chain, the regulatory environment, the adoption pathway, the capital structure, the partners, the channels, and the points where value can be controlled or lost.
This pillar starts by constructing system truth before judging venture quality.
How mature is the need?
Is the need emerging, intensifying, stabilising, fragmenting, or becoming commoditised?
How is the need evolving?
Is the customer problem becoming more urgent, more regulated, more distributed, more automated, more cost-sensitive, or more strategically important?
How are the components evolving?
Are the technologies, subsystems, infrastructure, standards, suppliers, channels, and ecosystem components moving from experimental to custom-built, productised, standardised, or commoditised?
Where are the control points?
Which actors, interfaces, data flows, regulations, platforms, or capabilities shape who can capture value?
What future scenarios are plausible?
How might the industry architecture change under different regulatory, technological, capital, adoption, or ecosystem conditions?
“Is this a good solution?”
“Can the venture system (that is delivering the solution) create value, deliver it, capture it, and defend it as the need, ecosystem, and industry architecture evolve?”
What this changes
It shifts evaluation from product-centred analysis to system-centred analysis.
It makes visible the dependencies that often remain hidden in pitch decks: ecosystem actors, adoption friction, control points, infrastructure gaps, market readiness, partner power, regulatory constraints, capital intensity, and value leakage.
A technically strong product may still struggle if the surrounding system does not support adoption, monetisation, integration, scale, or defensibility. Conversely, a venture becomes stronger when the system around the product is deliberately understood and designed.
What this enables
- Need maturity assessment
- Need evolution mapping
- Industry architecture mapping
- Ecosystem and component evolution analysis
- Technology and subsystem maturity mapping
- Value-chain and control-point mapping
- Choke-point identification
- Scenario construction
- Venture boundary definition
Create • Capture • Sustain
Many innovation ventures are built around a strong value-creation claim. They solve a hard problem. They improve performance. They reduce cost. They create access. They make something faster, cheaper, better, safer, or more intelligent.
But value creation is only the first economic condition.
A venture succeeds when it can create meaningful surplus, capture a meaningful share of that surplus, and sustain that capture over time. This is the economic core of the Innovation Decision Architecture.
A venture may create value but fail to capture it. It may capture value temporarily but fail to sustain it. It may scale usage while losing economic power. It may have adoption without durable rent.
This pillar makes the economic logic explicit.
Create Value
Does the venture generate surplus for customers, users, markets, or the broader system?
Capture Value
Can the venture convert that surplus into revenue, margin, pricing power, strategic position, or producer surplus?
Sustain Value
Can the venture defend that capture as competitors respond, technologies mature, markets evolve, and ecosystem power shifts?
“Does this solve a problem?”
“Does this create an economic surplus that the venture can capture and sustain?”
What this changes
It moves evaluation beyond “Does this solve a problem?” toward “Does this create an economic surplus that the venture can capture and sustain?”
It prevents innovation from being confused with technical achievement, product adoption, or market excitement alone.
What this enables
- Economic surplus analysis
- Innovation rent logic
- Value creation and value capture mapping
- Pricing and margin logic
- Producer surplus assessment
- Defensibility and rent duration analysis
Business Model as Design Space
The Business Model Canvas is often treated as a static template to be filled in. Customer segments, value propositions, channels, revenue streams, partners, activities, resources, and costs are documented as if they are known.
But in high-uncertainty innovation, the business model is not a fixed description of how the venture works. It is a design space of possible choices.
Each business model block contains multiple hypothesis elements. There may be multiple possible customer segments, multiple possible users and payers, multiple value propositions, multiple channel choices, multiple revenue models, multiple partnership structures, multiple cost architectures, and multiple ways to control access, capture value, or defend advantage.
The work is not to fill the canvas once. The work is to explore the set of plausible business model configurations and identify which choices can best satisfy the economic requirements of the venture.
Validation-oriented model to prove need, feasibility, adoption, or willingness to pay.
Model to scale revenue, improve margin, strengthen channels, and validate repeatability.
Model to control distribution, defend advantage, and sustain economic surplus.
Different stages may require different business models.
A deeptech venture may require different business models at different stages of evolution. An early stage may require a validation-oriented model to prove need, feasibility, adoption, or willingness to pay. A later stage may require a different model to scale revenue, improve margin, control distribution, or sustain advantage.
In some cases, the initial business model may be an access wedge, while the later business model becomes the economic engine. This pillar treats the business model as a staged design space — not a one-time plan.
“What is the startup’s business model?”
“Which business model choices are possible, which ones matter most, and which configuration can create, capture, and sustain economic surplus at each stage of the venture?”
What this changes
It shifts business model work from documentation to design.
It prevents premature locking into one business model. A venture may need one model to enter the market, another to validate repeatability, and another to capture durable rent.
What this enables
- Business model hypothesis mapping
- Multiple hypothesis choices across each BMC block
- Alternative venture configuration analysis
- Stage-specific business model design
- Customer–user–payer distinction
- Revenue and margin hypothesis testing
- Partner, channel, and control-point dependency analysis
- Access-wedge versus economic-engine distinction
Critical Assumptions as Design Parameters
Every startup has assumptions. But not every assumption has the same consequence.
Some assumptions are peripheral. If they fail, the venture can adapt. Others are structural. If they fail, the venture cannot create value, capture value, or sustain value capture.
This pillar introduces axiomatic design thinking into venture evaluation.
In axiomatic design, a system is evaluated by distinguishing between what the system must achieve and how the system is designed to achieve it. In venture terms, this means separating functional requirements from design parameters.
Economic requirements depend on design parameters.
These requirements are not achieved automatically. They depend on design parameters: customer adoption, workflow integration, technical performance, cost structure, pricing logic, channel access, regulatory legitimacy, ecosystem partnerships, data access, manufacturing capability, switching costs, control points, and many others.
The important move is to identify which assumptions are actually design parameters.
When assumptions become design parameters
A pricing assumption becomes a design parameter if value capture depends on it.
A partner assumption becomes a design parameter if market access depends on it.
A technical assumption becomes a design parameter if value creation depends on it.
A control-point assumption becomes a design parameter if sustainability depends on it.
This pillar treats critical assumptions not as a risk list, but as the structural variables that determine whether the venture can satisfy its economic requirements.
“What could go wrong?”
“Which assumptions determine whether the venture can satisfy its functional requirements?”
This is where axiomatic reasoning becomes powerful.
It helps reveal whether the venture is independent, decoupled, or coupled. A coupled venture may require too many things to become true at once. A decoupled venture can be sequenced. An independent design is easier to validate, communicate, and fund.
Different requirements can be satisfied without interfering with each other.
Requirements can be satisfied in a logical sequence.
Requirements are interdependent in ways that create fragility.
What this changes
It moves risk analysis from a long list of concerns to a structured map of dependencies.
Instead of treating every uncertainty as equally important, the architecture identifies which assumptions determine whether the venture can satisfy its functional requirements.
What this enables
- Functional requirement mapping
- Critical design parameter identification
- Assumption prioritisation
- Dependency mapping
- Coupling and decoupling analysis
- Structural fragility diagnosis
- Validation sequencing logic
- Clearer founder and investor communication
Progress as Uncertainty Reduction
Startup progress is often described through visible activity: product built, pilot completed, customers acquired, revenue started, funding raised, team expanded, market entered.
These are useful signals. But they do not always prove that the venture is becoming economically stronger.
In high-uncertainty innovation, progress should be measured by the reduction of uncertainty around economic surplus.
A venture is not progressing simply because it is doing more. It is progressing when it is proving more of what must be true for value to be created, captured, and sustained.
What does this stage impact?
Does this stage reduce uncertainty around value creation, value capture, value sustainability, or all three?
How much does venture value change?
Does reducing this uncertainty materially change the venture’s expected value, scenario NPV, or options value?
Each stage should reduce uncertainty around economic surplus.
The question is not whether an activity has been completed. The question is what economic uncertainty has been reduced.
Value Creation
Whether the customer need is real, urgent, valuable, and better served by the proposed solution.
Value Capture
Whether there is a credible path to revenue, margin, pricing power, producer surplus, or strategic economic control.
Value Sustainability
Whether the venture can defend its position through control points, switching costs, data advantage, ecosystem position, regulatory legitimacy, capabilities, or rent duration.
Not all proof points have the same economic weight.
Some validations improve confidence only marginally. Others materially change the venture’s expected value because they unlock a major market, reduce a structural risk, improve value capture, or extend the duration of potential rent.
This value change can be expressed through scenario NPV or options value.
How the expected economic value of the venture changes under different future conditions.
How resolving uncertainty creates the right, but not the obligation, to commit more capital, expand, partner, license, or scale.
Proof matters when it changes economic confidence.
A pilot is meaningful only if it reduces uncertainty around an economically important condition.
Revenue is meaningful only if it proves repeatable value capture.
Product development is meaningful only if it reduces technical, adoption, economic, or ecosystem uncertainty.
Funding is meaningful only if it buys the next proof point.
Each stage should answer five questions.
“What are we doing next?”
“Which uncertainty must be reduced next to increase confidence that the venture can create, capture, and sustain economic surplus — and how much does that reduction change venture value?”
What this changes
It shifts venture roadmaps from milestone tracking to surplus-risk reduction.
This creates better founder roadmaps, stronger investor diligence, and more disciplined capital allocation.
What this enables
- Economic uncertainty mapping
- Validation roadmap design
- Stage evolution mapping
- Scenario NPV logic
- Options-value reasoning
- Capital strategy implications
- Founder feedback
- Investor thesis development
- Proof-based venture progression