Innovation Lab
Applied research with published negative results.
Six timeboxed research tracks, each started from a problem we hit on real engagements — and each written up whether or not it worked.
6
Active research tracks
20%
Engineer research time
14
Experiments published
4
University partnerships
Current tracks
What we are working on now
Tracks are reviewed quarterly. Two are usually retired each year, which is the point of timeboxing them.
Agentic systems in production
What it takes to run tool-using models against real business systems: evaluation harnesses, rollback design, and the audit trail a regulator would accept.
- Evaluation harnesses
- Rollback design
- Decision auditability
Post-quantum readiness
Building cryptographic inventories at enterprise scale and testing hybrid key exchange in real integration estates rather than in isolation.
- Crypto inventory tooling
- Hybrid key exchange
- Migration sequencing
Edge and WebAssembly
Sandboxed plugin execution and compute close to the data source — particularly for industrial estates where round-tripping to a region is not viable.
- Plugin isolation
- Offline-first sync
- Deterministic runtime
Data contracts and lineage
Making producer-consumer contracts enforceable in pipelines, so a schema change fails in CI rather than in a board report six weeks later.
- Contract enforcement
- Automated lineage
- Breaking-change detection
High-density infrastructure
Thermal and power design for GPU workloads in facilities that were never planned for them, including retrofit economics.
- Retrofit thermal design
- Power staging
- Workload placement
Developer experience measurement
Instrumenting the cost of platform friction so investment in internal tooling can be argued with evidence rather than anecdote.
- Friction telemetry
- Lead-time analysis
- Investment modelling
How the lab runs
Four stages, one of which is admitting failure
The discipline that stops a research function becoming a hobby budget.
- 01
Stage 1
Question, not technology
Every track starts from a problem we have hit on client work. Interesting technology with no question attached does not get funded.
- 02
Stage 2
Timeboxed experiment
Six to eight weeks with a written hypothesis and a defined success criterion agreed before the work starts.
- 03
Stage 3
Published either way
Results are written up whether or not they support the hypothesis. Negative results are the more useful half of the output.
- 04
Stage 4
Radar position
Findings update our technology radar. Something only reaches Adopt after it has run in production on real client work.
Collaboration
Ways to get involved
We run joint work with clients, universities, and vendors — under terms that keep the findings publishable.
Joint experiments
Bring a problem and a real dataset. We contribute the engineering time and both parties keep the findings.
Academic partnerships
Supervised projects and internships with four universities, focused on problems with an industrial application.
Early access
Clients on strategic engagements get access to track findings ahead of publication, including the unflattering ones.
Stage gates
Five stages, and most work never leaves the second
Each stage is time-boxed with a stated exit. A track that cannot describe what would kill it does not get started.
| Stage | Question it answers | Time-boxed to | How it ends |
|---|---|---|---|
| Spike | Is this technically possible at all? | One week | A written answer, usually 'no' or 'not yet' |
| PrototypeMost work stops here | Does it work on real data rather than a demo set? | Four weeks | Measured result against a stated bar |
| Pilot | Does it hold up with real users and real load? | One quarter | Go or no-go with usage evidence |
| Productionisation | Can it be operated, supported and sold? | Two quarters | Handed to a practice or to the platform |
| Retired | Was the assumption wrong, or the timing? | Any stage | Written up publicly, including what we got wrong |
Spike
- Question it answers
- Is this technically possible at all?
- Time-boxed to
- One week
- How it ends
- A written answer, usually 'no' or 'not yet'
Prototype
Most work stops here- Question it answers
- Does it work on real data rather than a demo set?
- Time-boxed to
- Four weeks
- How it ends
- Measured result against a stated bar
Pilot
- Question it answers
- Does it hold up with real users and real load?
- Time-boxed to
- One quarter
- How it ends
- Go or no-go with usage evidence
Productionisation
- Question it answers
- Can it be operated, supported and sold?
- Time-boxed to
- Two quarters
- How it ends
- Handed to a practice or to the platform
Retired
- Question it answers
- Was the assumption wrong, or the timing?
- Time-boxed to
- Any stage
- How it ends
- Written up publicly, including what we got wrong
How we run it
Three rules that keep a lab from becoming a hobby
Falsifiability
Every track states what would kill it
A research track without a stated failure condition will run indefinitely, because there is never a moment at which stopping is obviously correct. Each track opens by writing down the result that would end it.
- Kill criteria written before the work starts
- Time box fixed at the outset and not quietly extended
- Negative results written up rather than buried
- A track that survives its kill criteria gets more funding
Real constraints
Tested against client reality, not a clean dataset
Anything that only works on curated data is not a finding. Lab work is validated against the messy, permissioned, regulated conditions our engagements actually operate under, which is where most promising ideas fail.
- Validated on production-shaped data, not benchmarks
- Regulatory and residency constraints applied from the start
- Cost per outcome modelled before anything is recommended
- Operability assessed alongside capability
Transfer
The lab is not where things go to stay
Successful work leaves — into the platform, into a practice, or into a client engagement. A research function that accumulates projects without transferring any becomes an expensive hobby.
- Every track has a named destination if it succeeds
- Handover to a practice includes the engineers who built it
- Findings published internally within two weeks of a decision
- Nothing stays in the lab beyond its stated time box
Questions
Fair scepticism about corporate innovation labs
Most are marketing. Here is how to check whether ours is.
How the lab works
Is this a real function or a marketing page?
It is a real, time-boxed allocation of engineering capacity with published kill criteria — and the honest measure is that most tracks end without shipping. If the lab had a high success rate it would mean we were only investigating things we already knew would work, which is not research.
Can clients participate?
Yes, and it is the most useful way to run a track. A client with a real constraint and real data gets early access to the work and a say in direction; we get validation that the idea survives contact with production. Terms are agreed per track, including who owns what results.
Who owns the IP from a joint track?
Agreed in writing before the track starts, and it varies. Where the client brings the problem and the data, the application is usually theirs and the generalisable technique is usually ours to reuse. Where we bring both, it stays ours. What we do not do is leave it ambiguous and argue about it later.
Have a problem worth researching?
If it is real, recurring, and nobody has a clean answer, it is exactly what the lab is for.