How we build
How we build
How we build
We do not trust a solution we cannot reason through from the ground up. Four stages, eight decisions, and a verification model that matches them.
We do not trust a solution we cannot reason through from the ground up. Four stages, eight decisions, and a verification model that matches them.
We do not trust a solution we cannot reason through from the ground up. Four stages, eight decisions, and a verification model that matches them.
Inside Our lab
Four stages, two decisions each
Eight decisions before a line of production code
01
Define the intelligence
02
Design the process
03
Choose the technology
04
Build and verify
Define the intelligence
What behaviour are we asking for, and how will we know it is good? We set hard, measurable targets first — and we scope the behaviour narrowly enough that it can actually be delivered.
01
Design the process
Strategic role of the technology. We decide what role the technology plays. Ours is a full customer solution capture, coaching and app as one system rather than a single best-algorithm play or a network-effects play.
Operational process + complementary assets. The unglamorous half: consent (including biometric-privacy compliance), onboarding, camera-placement guidance and support. Complementary assets routinely consume the majority of the investment, and planning for them is not optional.
02
Choose the technology
Intellectual-property approach. We own the invention rather than assemble off-the-shelf parts. Patent pending.
Data strategy. What data the system actually needs. The dominant industry answer is to accumulate as much user data as possible; we deliberately took the opposite route on-device, streaming-only and consent-based. This is our strongest differentiator and what makes "Engineering Ethical Intelligence" an architectural claim rather than a slogan.
03
Build and verify
Development and verification model. A V-model systems-engineering approach, run as an iterative V per increment not one sequential pass. Every level of decomposition has a matching level of verification.
Known failure modes. Named up front rather than discovered late: body-type and lighting generalisation, bias, explainability through confidence gating, and unintended behaviour.
04
Four stages, two decisions each
Eight decisions before a line of production code
01
Browse Jobs
02
Design the process
03
Choose the technology
04
Build and verify
01
Define the intelligence
Performance targets: We fix hard, measurable targets the latency, responsiveness and repeatability the system must hit before a line of production code, and treat them as the definition of "good."
Scope of the behaviour: We deliberately narrow the behaviour to a set that can actually be delivered well: a small, validated scope, a controlled setup, and an explicitly non-medical boundary.
02
Design the process
Strategic role of the technology. We decide what role the technology plays. Ours is a full customer solution capture, coaching and app as one system rather than a single best-algorithm play or a network-effects play.
Operational process + complementary assets. The unglamorous half: consent (including biometric-privacy compliance), onboarding, camera-placement guidance and support. Complementary assets routinely consume the majority of the investment, and planning for them is not optional.
03
Choose the technology
Intellectual-property approach. We own the invention rather than assemble off-the-shelf parts. Patent pending.
Data strategy. What data the system actually needs. The dominant industry answer is to accumulate as much user data as possible; we deliberately took the opposite route on-device, streaming-only and consent-based. This is our strongest differentiator and what makes "Engineering Ethical Intelligence" an architectural claim rather than a slogan.
04
Build and verify
Development and verification model. A V-model systems-engineering approach, run as an iterative V per increment not one sequential pass. Every level of decomposition has a matching level of verification.
Known failure modes. Named up front rather than discovered late: body-type and lighting generalisation, bias, explainability through confidence gating, and unintended behaviour.
Four stages, two decisions each
Eight decisions before a line of production code
01
Define the intelligence
02
Design the process
03
Choose the technology
04
Build and verify
01
Define the intelligence
Performance targets: We fix hard, measurable targets the latency, responsiveness and repeatability the system must hit before a line of production code, and treat them as the definition of "good."
Scope of the behaviour: We deliberately narrow the behaviour to a set that can actually be delivered well: a small, validated scope, a controlled setup, and an explicitly non-medical boundary.
02
Design the process
Strategic role of the technology. We decide what role the technology plays. Ours is a full customer solution capture, coaching and app as one system rather than a single best-algorithm play or a network-effects play.
Operational process + complementary assets. The unglamorous half: consent (including biometric-privacy compliance), onboarding, camera placement guidance and support. Complementary assets routinely consume the majority of the investment, and planning for them is not optional.
03
Choose the technology
Intellectual-property approach. We own the invention rather than assemble off-the-shelf parts. Patent pending.
Data strategy. What data the system actually needs. The dominant industry answer is to accumulate as much user data as possible; we deliberately took the opposite route on-device, streaming only and consent-based. This is our strongest differentiator and what makes "Engineering Ethical Intelligence" an architectural claim rather than a slogan.
04
Build and verify
Development and verification model. A V-model systems-engineering approach, run as an iterative V per increment not one sequential pass. Every level of decomposition has a matching level of verification.
Known failure modes. Named up front rather than discovered late: body-type and lighting generalisation, bias, explainability through confidence gating, and unintended behaviour.
The failure modes we plan for
Generalisation
Body-type and lighting variation across real users.
Bias
Standards that fit one population and mislabel another.
Explainability
Confidence gating so the system knows when not to speak.
Unintended behaviour
Safety-first defaults for the cases we did not anticipate.
The failure modes we plan for
Generalisation
Body-type and lighting variation across real users.
Bias
Standards that fit one population and mislabel another.
Explainability
Confidence gating so the system knows when not to speak.
Unintended behaviour
Safety-first defaults for the cases we did not anticipate.
The failure modes we plan for
Generalisation
Body-type and lighting variation across real users.
Bias
Standards that fit one population and mislabel another.
Explainability
Confidence gating so the system knows when not to speak.
Unintended behaviour
Safety-first defaults for the cases we did not anticipate.
The method in practice: VIZHI
Performance targets
Hard latency, frame-rate and repeatability targets fixed before build began
Scope
A small validated movement set, controlled setup, explicitly non-medical
Strategic role
A full solution — capture, coaching and app as one system, not a single algorithm
Process + complementary assets
Consent, onboarding, placement guidance, support
IP approach
Own the invention rather than assemble off-the-shelf. Patent pending.
Data strategy
On-device, streaming-only, consent-based — deliberately not data accumulation
Development model
Iterative V-model systems engineering
Failure modes
Body-type and lighting generalisation, bias, confidence gating, safety behaviour
The method in practice: VIZHI
Decision
What we chose
Performance targets
Hard latency, frame-rate and repeatability targets fixed before build began
Scope
A small validated movement set, controlled setup, explicitly non-medical
Strategic role
A full solution — capture, coaching and app as one system, not a single algorithm
Process + complementary assets
Consent, onboarding, placement guidance, support
IP approach
Own the invention rather than assemble off-the-shelf. Patent pending.
Data strategy
On-device, streaming-only, consent-based — deliberately not data accumulation
Development model
Iterative V-model systems engineering
Failure modes
Body-type and lighting generalisation, bias, confidence gating, safety behaviour
The method in practice: VIZHI
Decision
What we chose
Performance targets
Hard latency, frame-rate and repeatability targets fixed before build began
Scope
A small validated movement set, controlled setup, explicitly non-medical
Strategic role
A full solution — capture, coaching and app as one system, not a single algorithm
Process + complementary assets
Consent, onboarding, placement guidance, support
IP approach
Own the invention rather than assemble off-the-shelf. Patent pending.
Data strategy
On-device, streaming-only, consent-based — deliberately not data accumulation
Development model
Iterative V-model systems engineering
Failure modes
Body-type and lighting generalisation, bias, confidence gating, safety behaviour
The method in practice: VIZHI
Decision
What we chose
Performance targets
Hard latency, frame-rate and repeatability targets fixed before build began
Scope
A small validated movement set, controlled setup, explicitly non-medical
Strategic role
A full solution — capture, coaching and app as one system, not a single algorithm
Process + complementary assets
Consent, onboarding, placement guidance, support
IP approach
Own the invention rather than assemble off-the-shelf. Patent pending.
Data strategy
On-device, streaming-only, consent-based — deliberately not data accumulation
Development model
Iterative V-model systems engineering
Failure modes
Body-type and lighting generalisation, bias, confidence gating, safety behaviour