We break things on purpose.

The Lab is REKA’s research engine: where we prototype the technology most companies only read about, and where tomorrow’s products start as today’s experiments.

Explore the frontiersPropose a project
An oscilloscope reading a test signal on a REKA electronics bench
Field research since
2016Malaysia’s first self-driving car, and the first in Southeast Asia on public highways
Experiments on record
6Each opened with a falsifiable question
Became products
2Kinetik and PLExyz
Active frontiers
3Autonomy, AI and quantum

We build where the physical world runs out of tools.

Most technology defaults to the digital: software that runs on data, cloud services that retry on failure, models that live on a screen. The physical world follows different rules. Failure has real consequences. Latency kills. Privacy is not optional. Data does not always leave the building.

Most research ignores this. We do not. Every frontier we pursue passes four filters.

REKA archive photograph of a real development board from the 2017 RIG Photoshoot archive. Hardware-origin context, not an exact multi-sensor test-rig photograph.
  1. IdeaA frontier worth a look
  2. Physical worldIt runs on matter
  3. Built for matterToday’s tools assume retry
  4. Right timingMature science, early market
  5. Bounded proofA minimum case exists
  6. ExperimentOpened with a falsifiable question

Fails any filter: we do not start.

Does it operate in the physical world?

Machines, sensors, infrastructure, spaces, bodies. If the problem only lives in software, someone else will solve it. REKA’s work runs on matter.

Were the existing tools built for data, not for matter?

Digital automation assumes it can retry. Physical operations cannot. Most platforms were designed for a world where failure is reversible. We build for the world where it is not.

Is the timing right to be here now?

The science must be mature enough to attempt and the market early enough that our work compounds. We do not chase what is already crowded, and we do not start what the physics cannot yet support.

Can it be proved in a bounded domain?

We need a minimum case where the question can be answered cleanly and in a reasonable time. If there is no path to a real proof, we do not start. We begin small and widen from ground we have proven.

REKA archive photograph from the Murata media kit showing real sensing-module preparation. The exact location and people are not newly identified.

Go to the root.

radicalradixrootLatin: “the origin from which a thing grows”

Not the symptom. Not the technology that happens to be trending. The actual structure of the problem, inside its domain, governed by its physics or its science. We go there first, before we name a tool, before we write a brief, before we run a model.

That is not a process we follow. It is the only honest way to do research. Every experiment is held to three principles.

AI-generated illustration of researchers framing a physical engineering constraint using a bracket, ruler and simple unlabelled sketch; not actual staff or project evidence.

Hold the uncomfortable position.

The most defensible position is rarely the most popular one. We hold the position the evidence supports, and we say so out loud, even when it makes us harder to sell, less quotable in a press release, or less exciting to a prospect who wants to hear that their technology of choice is the answer.

We declined to call our self-driving work “Level 5 capable” when the industry was using that language to raise capital. We called it what it was: a bounded-domain system on a proven operating domain. We did the same when everyone reached for the largest frontier model. We did the same on quantum.

Tell the truth about the timeline.

What works today, what is one to seven years out depending on the frontier, and what is speculative are three different things that require three different responses. We build for the first, prepare for the second, and refuse to sell the third as imminent. The timeline shapes the experiment. The experiment does not bend to the timeline.

The Now, Near and Far tables on every frontier page were written before the belief sections above them. We established what the evidence actually supports, then wrote the position. That order is not cosmetic. It is the discipline.

Research earns its place.

Every experiment has a defined exit condition: it becomes a product, it becomes a service, or it stops. We do not carry work indefinitely on the basis that it might eventually be useful. If it cannot close back to something a client can deploy, we document what it taught us and move on.

EXP-01 became Kinetik after proving bounded autonomy on Malaysian public roads. EXP-04 became PLExyz after proving edge-computed spatial tracking at operational accuracy. Every active experiment is a candidate, not a commitment.

Three frontiers, each with an honest horizon.

Each frontier passed the four filters. Each holds a position that is contrarian but defensible. Each has a time horizon we are honest about.

REKA archive photograph of real autonomy electronics in the test-bed boot at Malaysia Autoshow 2023; hardware context, not a plantation deployment.

Autonomous Driving

Kinetik division

We do not chase drive-anywhere. We engineer autonomy that runs and pays inside a known operating domain, on an open, auditable stack, with a human always one step away through teleoperation. Then we widen it.

Autonomy is a domain problem, not a model problem.
Now
Bounded domains shipping and paying
Near
Coordinated fleets over secure networks
Far
The domain widens as hardware matures
Explore autonomy AI-generated illustration of private server hardware. It is not an actual REKA or client installation.

AI & LLMs

Heuristik division

Most teams reach for the biggest frontier model in someone else’s cloud and build backward. We start from the constraints: privacy, latency, scale, the actual task. The answer is usually a smaller, private, grounded system that runs where your data already lives.

Stop starting with the model.
Now
Private grounded systems in production
Near
Domain-tuned grounded agents
Far
Model commoditises; your data is the edge
Explore AI and the router AI-generated illustration of a quantum computer. REKA does not claim to own this machine or to have achieved a quantum-computing result.

Quantum

Heuristik division

Most “quantum wins” today are quantum-inspired classical methods that run on ordinary hardware. We frame hard problems the quantum way, solve them with what runs today, and build the formulation that will transfer to real quantum hardware when it earns its place.

It is overhyped. That is exactly why to move now.
Now
Quantum-inspired methods, usable today
Near
Narrow advantage in simulation & optimisation
Far
Fault-tolerant scale: the long bet
Explore quantum

The long view behind two of them: the autonomy journey, from the 2016 car to bounded autonomy, and the quantum journey, a research notebook.

Three frontiers, each with an honest horizon Each frontier in years: Now is what works today; Near is one to seven years out depending on the frontier, 1–3 years for Autonomous Driving, 1–2 years for AI & LLMs and 3–7 years for Quantum, on each frontier page; Far is speculative. Nowbuild Nearone to seven years outprepare Farspeculativerefuse to sellas imminent Autonomous DrivingKinetik division↗1–3 years AI & LLMsHeuristik division↗1–2 years QuantumHeuristik division↗3–7 years Three frontiers, each with an honest horizon Now is what works today; Near is one to seven years out depending on the frontier: 1–3 years for Autonomous Driving, 1–2 years for AI & LLMs, 3–7 years for Quantum; Far is speculative. Nowbuild Nearprepare Farrefuse to sellas imminent Near: one to seven years outdepending on the frontier Autonomous DrivingKinetik division↗1–3 years AI & LLMsHeuristik division↗1–2 years QuantumHeuristik division↗3–7 years
Seth Linton, REKA’s Systems Cartographer, scanning

SETHWhat works today, what is one to seven years out depending on the frontier, and what is speculative are three different things.

ReadoutNow, Near and Far for each frontier. Hover or tap a frontier to read it.

Before we build anything.

Most technology work starts with a tool and looks for a problem to justify it. We start earlier than that. Every experiment in the Lab opens the same way, with five questions that have to be answered before anything is built or bought.

Seth Linton, REKA's Systems Cartographer, a hexagonal sentinel core with question marks on his LED face
Seth Linton · Systems Cartographer · state: question

“Systems whisper before they scream.”

  • What is the governing science here?

    We map the domain first. What are the physical constraints? What does the relevant science say about what is possible and at what cost? The tool, the model, the platform: all of that comes after. If the physics does not support the claim, no amount of compute changes that.

  • What would prove us wrong?

    Every experiment begins with a question that can be answered with evidence. Not “can we apply X to this space?” but “does method Y solve problem Z under constraints A, B and C?” If we cannot articulate what a failure looks like, we do not have an experiment. We have a hope.

  • Better than what, exactly?

    Before we claim any improvement, we establish what the current state actually achieves. A result without a baseline is not a result. We measure against the real alternative, including doing nothing, not against an absence of comparison.

  • What is the smallest version we can prove?

    We find the tightest domain where the question can be answered cleanly, then we answer it there. Expanding scope before proof is how research becomes unfalsifiable. We prove the minimum case, document it honestly, then ask whether it is worth widening.

  • Does this close back to something that runs?

    At a defined point in every experiment we ask whether the work can become something a client operates. If yes, it graduates. If no, it closes. The Lab is not a holding space for interesting ideas. It is a pipeline with a decision at the end.

  • AI-generated illustration of a production engineer observing and timing an existing process before automation; not an actual REKA or client assessment.
Before we build anything: five questions Every experiment in the Lab opens the same way and passes five questions in order: What is the governing science here? What would prove us wrong? Better than what, exactly? What is the smallest version we can prove? Does this close back to something that runs? Then a decision at the end: if yes, it graduates; if no, it closes. They have to be answered before anything is built or bought. Every experimentopens the same way the physicsWhat is the governingscience here?? What would proveus wrong?evidence? a baselineBetter than what,exactly?? What is the smallestversion we can prove?the minimum case? a client operatesDoes this close back tosomething that runs?? a decisionat the end If yesit graduates If noit closes five questions that have to be answered before anything is built or bought Before we build anything: five questions Every experiment passes five questions in order, then a decision at the end: if yes, it graduates; if no, it closes. Every experimentopens the same way the physicsWhat is the governingscience here?? evidenceWhat would proveus wrong?? a baselineBetter than what,exactly?? the minimum caseWhat is the smallestversion we can prove?? a client operatesDoes this close back tosomething that runs?? a decision at the end If yesit graduates If noit closes answered before anything is built or bought

ReadoutFive questions that have to be answered before anything is built or bought. Hover or tap a question to read it.

What the Lab has built.

Every experiment the Lab has undertaken, with its current status. The Lab is not a cost centre; it is our pipeline. Two experiments have earned their way into products; the others are active candidates or ongoing research.

EXP-01Kinetik
EXP-04PLExyz
EXP-02 · 03 · 05 · 06Candidates
REKA archive photograph of actual mechanical and electronic prototype hardware. It provides engineering context rather than evidence of a current team review.
IDExperimentThe questionWhere it stands
EXP-01

Self-Driving Car

ML · Robotics · AutowareProductised		Can a retrofit sensor suite and an open-source autonomy stack prove bounded self-driving on Malaysian public roads, without purpose-built hardware?Proven. A bounded operating domain on a modular, auditable stack, running on our own edge hardware across vehicle types. The question was whether it was achievable without a bespoke platform. It was.→ Kinetik
EXP-02

UVC Sterilisation

Virology · MicrobiologyActive		Can autonomous UV-C delivery be controlled precisely enough to sterilise a space at a reliable germicidal dose, without human exposure, at repeatable accuracy?Active. The science is dose-response biology and robotic path planning for even coverage. The hard part is the safety interlock architecture: knowing when the system must stop regardless of task completion.
EXP-03

Cube Satellite

Microelectronics · AerospaceResearch		Can commercial off-the-shelf microelectronics, hardened for low-Earth orbit conditions, carry a functional sensing payload within a 1U CubeSat envelope and budget?Research stage. The discipline is radiation-tolerant electronics and miniaturised sensor integration. Most of the early work is component selection and failure-mode analysis before anything goes near a launch manifest.
EXP-04

GPS & Asset Tracking

IoT · Edge computingProductised		Can edge-computed, low-power location inference deliver the accuracy a real operation requires, without continuous cloud dependency or a camera in the loop?Proven. Dead-reckoning fused with GNSS and adaptive connectivity switching, inference running at the edge. The constraint that shaped it: environments where connectivity is intermittent and privacy is non-negotiable.→ PLExyz
EXP-05

IoT Dev Board

Microelectronics · PCBActive		Can a unified, open hardware platform cut the time from sensing concept to deployable prototype to under four weeks, across different sensor modalities?Active. The work is PCB architecture for mixed-signal sensing, firmware design for sensor fusion, and power budget optimisation for field conditions. On the third revision, driven by sensing use cases that keep emerging from PLExyz deployments.
EXP-06

Quantum × AI

Quantum · OptimisationFrontier		Can quantum-inspired optimisation methods outperform classical solvers on the routing, allocation and scheduling problems already present in our product domains, before quantum hardware is required?Frontier. The method is reformulating known hard problems as QUBO or Ising models and solving with quantum-inspired classical solvers, proving value on our existing baselines. The hardware question comes after the formulation question.→ Heuristik
See the products