Skip to content

Engineering & Research

Research-driven engineering, grounded in real products.

We build products to solve real problems and treat the engineering behind them as research. This page sets out what we work on today, how we do it, and the directions we intend to pursue. Where something is a direction rather than a result, we say so.

01Current work

What we build today.

Every area here is in working code, in products that are in testing or development. Results are described in words, not marketing numbers.

1.1

Event detection from everyday sensors

In Resku

Resku detects possible vehicle collisions using the accelerometer, gyroscope and GPS of an ordinary phone. A single strong reading is never enough. The decision draws on several independent signals: the shape of the impact, rotation, the change in speed, and what the phone and the vehicle do afterwards. It waits for the vehicle to come to rest before it alerts anyone.

Most of the difficulty is in the look-alikes: potholes and speed breakers, a phone dropped or tossed onto a bed, someone sitting down hard. A person on foot struck by a vehicle produces a very different signature from a collision inside a car, so it is detected separately.

  • Several independent signals combined into one judgement
  • No alert until the vehicle is confirmed to have stopped, then a countdown the person can cancel
  • Separate detection for people on foot struck by a vehicle
  • Everyday look-alikes modelled and tested explicitly

1.2

Software for weak networks and constrained phones

In Resku

Coverage drops out on highways and in the hills, and phones close background apps to save battery. Resku is engineered for both. An alert that cannot be sent waits on the phone and goes out the moment there is signal. Sensors run at full rate only when there is an event to check, and location tracking is built to survive the power-saving behaviour of Android and iOS.

We also map where signal is lost. Phones that take part contribute anonymous coverage readings on a coarse grid, and a statistical model separates genuine no-signal stretches from momentary drops, so the app can warn people before they reach one. The model was first trained on simulated journeys that run the app’s own capture code, and is built to be refitted on real readings.

  • Alerts queued on the phone and sent as soon as signal returns
  • Sensing that steps up only when there is something to verify
  • Location tracking designed around Android and iOS power saving
  • Anonymous coverage readings, classified by a statistical model

1.3

Privacy-preserving data for learning

In Resku

Detection improves with real data, but crash data is sensitive. With consent, Resku keeps an anonymous summary of each impact it judges: the physics of the event and whether it turned out to be real, without the time, the device or the person.

Summaries leave the phone only after a delay, and the server’s raw event logs are purged on a schedule, so a summary cannot easily be joined back to an individual. This is the data we intend to train future detection models on.

  • Physics and outcome only: no time, device or person
  • Uploaded only after a delay, with consent
  • Raw event logs purged on a schedule
  • Consent can be withdrawn, which clears what is waiting to upload

1.4

Operations platforms and assistive AI

In Resku Business

Resku Business is an operations platform for passenger transport operators. At its core, every change, whether a person makes it or software does, passes through typed, validated commands and is recorded. Permissions are enforced in the database as well as in the application.

Rules that differ between countries, such as language, tax and messaging, live in separate packs on a neutral core, so the same system can serve operators in different places. We are designing AI assistance for the platform to work inside explicit limits on what it may do, with people deciding how much it is trusted.

  • Every change made through typed, validated commands, and recorded
  • Access controlled by role, enforced in the database as well as the application
  • Country-specific rules kept in separate packs on a neutral core
  • AI assistance being designed to act only within limits people set

1.5

Language and access

In Resku and Resku Business

A safety alert is only useful if the person receiving it understands it at once. Resku is available in seven languages, and each notification reaches its recipient in their own language, whatever language the sender uses.

We also prefer plain descriptions to numbers people cannot interpret, and say nothing at all when the evidence is too thin.

  • Resku available in seven languages
  • Notifications delivered in each recipient’s own language
  • Plain descriptions in place of opaque scores

02How we work

Engineering as a research practice.

We treat our own systems as subjects of study. The habits below are how we keep what we build honest.

  1. 01

    Specify, then implement

    Detection logic is written and tested first as a reference model, then mirrored in the app, with conformance tests that hold both to the same expected results.

  2. 02

    Replay before release

    We run the app’s real code against modelled sensor and GPS data for many scenarios, including collisions, near misses and everyday look-alikes, before a change reaches a phone.

  3. 03

    Trace every false alarm

    Alerts from field testing are reviewed, and a false alarm is traced to a cause before anything is changed.

  4. 04

    Write it down

    Decisions, assumptions and open questions are documented, so knowledge belongs to the company rather than to one person.

03Research directions

Where the work is heading.

These are directions, not results. Each grows out of the current work above, and each will take years. As the work matures, we intend to publish engineering notes and findings here.

  • On-device intelligence

    Moving from hand-tuned detection towards models trained on consented, anonymised field data and running on the phone itself.

  • Connectivity-aware systems

    Systems that plan for the network they will actually have: predicting coverage, deferring work and degrading gracefully.

  • Assistive AI with human authority

    AI that helps run day-to-day operations while people keep authority over what it may do, with autonomy granted gradually and measured.

  • Indian-language interfaces

    Products that work as well in Indian languages as in English, including by voice.

  • Dependable digital infrastructure

    The long-term aim: platforms that institutions and essential services can build on, engineered for reliability, privacy and scale.

Next

See where this engineering is used, or talk to us about it.