AI Perception Infrastructure

EMOPULSE

Operator state, computed on the device.

A patent-pending perception layer that turns a standard camera into a continuous, machine-readable state of the person at the controls. No wearable, no additional sensor, no network dependency. Defence, aviation, clinical research, automotive, authentication, autonomy.

UP TO 47 PARAMETERS 5 ONTOLOGICAL LAYERS 3 PATENTS PENDING ON-DEVICE DUAL-USE
01The company

One owner of the core, one layer to integrate

EmoPulse is built and owned by one company. The architecture and the source sit in the same hands, with 3 patents pending. When a programme office asks who controls the core and who signs for the delivery, the answer is the same both times.

We supply a layer, not an application. It is integrated into the partner's stack, their hardware, their security boundary and their evidence regime, and it is delivered the way defence and clinical programmes require: a written interface specification, a reproducible build with a published hash, and a signed artefact the receiving side can verify without trusting us.

Private by architecture
Processing runs on the device by default, so the data protection question is answered by the architecture and not by a policy document. That is the posture the EU AI Act and GDPR point towards, and it holds wherever the layer is deployed.
Independent core
3 patents pending. No third-party model licences in the interpretive layer. The front end uses open-source components, MediaPipe and face-api.js, and the interpretive layers above them are our own.
Built to be integrated
Edge or server, air-gapped or connected. The same core engine, configured per deployment rather than rewritten.
02The architecture

Five layers between a camera frame and a decision

The architecture computes up to 47 parameters from a standard camera in real time, and a deployment uses the subset its job needs. Voice and text enter as separate streams and are fused at the interpretive layer. No additional hardware, no cloud requirement.

1
Signal Acquisition
Raw signals from a single camera - pulse and variability from skin micro-colour, micro-expressions, gaze, action units, pupil, blink. Voice and text enter as separate streams.
2
Feature Computation
Raw signals become up to 47 normalised parameters. Not "happy" or "sad" labels - a multidimensional description of this person right now, each parameter with intensity, stability and trend.
3
Cross-Stream Coherence
Face, voice and text are checked against each other. Contradictions are detected rather than averaged away. This is where the architecture is genuinely new, and it is what the pending patents cover.
4
State Vector Assembly
Coherent signals assemble into a compact state vector that a host system can act on - risk, clarity of intent, and a living signature of the person in front of the camera.
5
Temporal Context
A personal baseline and deviation from it. The system reacts to a change in this individual, not to a population average.

The deeper description, including what we measure and what we deliberately do not, is in Under the Hood.

What a programme receives

Interface specification
Frame rate, format, timing, quality indicators and failure behaviour, written down and agreed on both sides before integration begins.
Reproducible artefact
A deterministic build with a published hash. The receiving side rebuilds it and compares, rather than trusting a binary we sent.
Signed delivery
The artefact is signed with a key held by us and verified with our public key, so provenance is a technical fact rather than a claim in an e-mail.
Deployment modes
Edge by default. Optional server mode where a second party must see the state in real time. Air-gapped operation supported, because no link is required.
03Solutions

Eight domains, one core engine

Each domain is a separate integration with its own evidence and regulatory route. The engine underneath them is the same, configured per deployment rather than rebuilt.

01
Defence and allied security
Operator state during a task: fatigue, stress load, attention. Runs on the device, works air-gapped, and never needs to send an image anywhere. This is the domain where the on-device constraint stops being a privacy nicety and becomes an operational requirement.
02
Aviation and aerospace
Continuous fatigue and micro-sleep indicators for crews and ground operators, from a camera that is already in the cockpit or the console, without a wearable and without a trial-specific rig.
03
Medicine and clinical research
Physiological indicators visible to a clinician during a consultation, and a structured record afterwards. Research instrument first: the route here runs through clinical studies, not around them.
04
Automotive
Driver monitoring against the regulatory requirement for new vehicles, using the standard camera rather than a dedicated sensor package, with the computation staying inside the vehicle.
05
Security and continuous authentication
A living signature rather than a stored template: involuntary signals re-verified through the session instead of matched once at the door. An attacker has to reproduce a person, not a picture of one.
06
AI platforms
The missing input for assistants and agents. A model that receives a state vector can tell the difference between a user who is thinking and a user who is lost, and change what it does about it.
07
Robotics and humanoids
A machine that shares physical space with a person needs to read that person continuously, on board, with no network in the loop. The state vector is exactly the input such a system lacks today.
08
Industrial and training environments
Readiness before a shift, cognitive load during it, and evidence afterwards that a procedure was performed by someone in a fit state to perform it.
04Demonstrators

Four public builds, open one and check it yourself

The same architecture in four configurations, each reachable without an account. Proof-of-concept demonstrators, not certified products.

Biometric Signature · the zero-egress build
ai.emopulse.app/signature
Open the browser's network panel before you start. After the page and the model load from our own host, the scan issues no further requests at all. Camera frames are read, a pulse signal and a liveness score are computed, and a one-off challenge is verified, entirely inside the tab. It shows that the interpretive layer needs no server, and that removing the network is a deployment setting rather than a degraded mode. Proof of concept, not a certified anti-spoofing system.
Live Dashboard · the two data regimes
emopulse.app/dashboard
The whole computation path runs in the browser: camera and microphone streams are never transmitted, and a curated subset of the state vector updates continuously on screen. Its real point is the second regime. Open the assistant chat and the page sends computed numbers, never imagery, to our server, so a model can reason about the state it is being shown. One engine, two regimes, chosen by configuration. This is what it looks like when an AI platform gets eyes.
Clinic Stack · the supervised regime
ai.emopulse.app/clinic
The same engine under consent. Video is never transmitted; only computed values leave the browser, and only after a separate biometric consent step. State is held in memory for ninety seconds, scoped to a single clinic, and readable only by an authenticated clinician of that clinic, with a regional policy that leaves the biometric module off by default wherever the law calls for it. Consent, isolation, retention and regional gating are architectural properties here, not paragraphs in a policy.
EmoCity · the architecture at consumer scale
emo.city
Our public-facing product, and the proof that this runs on ordinary hardware: a short face scan in a normal browser, on a phone or a laptop, with nothing to install. The model is served from our own origin and the scan is computed locally, so camera and microphone streams never leave the device. Only anonymous product events and, for signed-in users, summary scores reach the server, which is what makes history and comparison possible.
05Programmes

Where the architecture is being put to work

This section describes the kinds of work under way and names no institution. None of it is an endorsement, and no award, contract or grant has been made yet.

Where systems cannot send an image off the device, cannot rely on a link, and cannot expose a person's biometrics to a third party, the computation has to happen where the camera is. That constraint is the reason this architecture exists in the form it does.

Kinds of engagement

Defence, security and health on the institutional side, and on the industry side the companies that put the layer into hardware.

Research programmes

  • International research consortiumWe are the technology owner and the technical coordinator of the sensing work in an international consortium that is preparing a defence research proposal on operator state monitoring. The consortium is coordinated by an established defence electronics company.
  • Government research programmesOur proposals and technical papers on operator state and on-device perception are under review with government defence and security research programmes. None has been awarded.
  • Institutional supportThe consortium work is backed by a letter of support from a government defence institution. A letter of support is not a contract, and that institution is not a customer.

Regulators

  • Health and data protectionWe put our described use to the competent regulators in writing. The health regulator has given us a written position on where it sits, and the biometric data question is with the data protection regulator. We ask before we build, not after.

Industry

  • Device manufacturersA submission to a device manufacturer's advanced technology programme is under review, and we are in early conversations with sensor and device makers about what the layer needs from their hardware.
  • IntegratorsA published developer skill lets integrators try the state vector inside their own stack before any conversation with us.

Describing this work implies no endorsement or approval by any institution, and we do not present it as one. We have no paying customer, no paid pilot and no signed letter of intent yet.

06Partners

Who we work with

Research institutes, defence electronics and secure computing companies, sensor engineers and innovation organisations in several countries, working with us on where this layer belongs and how it plugs into their systems. We do not publish partner names while joint work is in preparation.

01
Defence electronics company
Consortium coordinator
02
Applied research institute
Human factors and ethics
03
Secure computing company
Trust and protection
04
Sensor engineering firm
Sensor front end
05
Innovation network
Exploitation
06
EmoPulse
Technology owner

Alongside them we are in early conversations with sensor and device manufacturers, which is how the layer gets built against real hardware and not against a specification sheet.

Advisory

Dr. Anastasia Vasina, MD, PhD (Pathology)
Fractional Chief Medical Officer; formerly CPO and CMO at Soter Analytics. Medical and ethical advisory: where a physiological signal may be spoken about, and where it may not.

The adviser acts in an advisory capacity. Her affiliations are her own and do not constitute an endorsement by any institution.

07Where we are

Stated plainly, because a programme office will ask

What exists, what does not exist yet, and the open technical questions, as they stand today.

Demonstrators. Four public builds are live and reachable without an account. They are proof-of-concept demonstrators, not certified products.
Customers. No paying customer, no paid pilot and no signed letter of intent yet.
Intellectual property. 3 patents pending. Pending is the whole claim: no patent has issued yet. No third-party model licence sits in the interpretive layer.
Published performance. The 93 to 96 per cent figures in the literature (Giannakakis 2025; Fontes 2024) belong to peer-reviewed studies of the underlying methods, not to this system. We do not present them as our benchmark.
Independent evaluation. Not yet performed. Measurements to date are our own, and third-party evaluation is on the roadmap as a deliverable, not as a claim.
Regulatory position. Not a medical device. Outputs are informational indicators derived from camera signal estimation, and the clinical route runs through ethics review and a study protocol.
Anti-spoofing. Liveness detection is at proof-of-concept maturity. Passive methods are not deepfake-proof and we do not describe ours as such.
Generalisation. Behaviour across skin tones, lighting and motion is an open question and is precisely what the planned evaluation campaigns address.

What funding does

The company is founder-funded to date and has no outside investors. External funding, whether a research grant or a pre-seed round, goes to evidence before anything else: independent third-party evaluation, evaluation campaigns across skin tones, lighting and motion, and the first engineering, regulatory and programme hires. We do not publish round terms on this page. Ask us in writing.

Contact

If any of this belongs in your programme

Write to us. One address, read by the people who build the thing. We answer in writing.

info@emopulse.app

EMOPULSE · AI PERCEPTION INFRASTRUCTURE