Future Labs
The research and invention engine. Future Labs is where a system question is worked on before anyone is allowed to call it a product — and where the answer is tested against reality early enough to matter.
Applied research inside a company usually means one of two things: a lab that publishes and never ships, or an engineering team with a better name. Future Labs is neither. It sits at the front of the outcome-first process, where the questions are still about what the system should be.
Its output is not papers and not features. It is designed systems: an articulated outcome, a map of the ecosystem that produces it, a set of required capabilities, and prototypes that establish whether any of it survives contact with the physical world.
Its central subject is the conversion problem: what has to exist for a technological capability to become economic capability for a specific person in a specific environment. That question is not answered by better models, and it is the one most likely to decide whether any of this works.
Six lines of enquiry.
Future system design
Working backwards from outcomes to the structure of a system that could produce them. The core discipline everything else feeds.
Intelligence
Applying models to systems whose state is physical, partially observed, and changing — which is not the environment most models are built for.
New capabilities
Identifying what a system must be able to do that nothing currently does, and establishing whether it can be built at all.
Economic models
How value forms, moves and is captured inside a redesigned system — and who ends up better off. A design that only works for its operator is a failed design.
Physical-digital infrastructure
The seam where software meets a road, a cold chain, a collection point, a person. Most system failures happen here.
New ecosystem concepts
Examining candidate ecosystems against one test: is the outcome constrained by coordination, trust and distance rather than by effort?
From question to system.
Prototypes here are rarely just software. Testing a coordination design means running the coordination. Testing a trust design means finding out what people actually do when something goes wrong. A demo cannot answer either question.
Frontier research, applied.
Future Labs is not a university department and does not behave like one. The work is judged by whether it changes what gets built, and the fastest way to be wrong about a physical system is to reason about it from a desk for too long.
Questions, not mechanics.
We intend to be open about the problems, the framing and the reasoning, and closed about implementation: network design, economics, models and onboarding approach stay internal.