01Research
The scientific approach, applied to products.
02Approach
Three transformations.
Mathematics, optimization and machine learning combine along a single path. Each stage has a different failure mode, and confusing them is how projects get stuck.
Formulation
problem → model
A real-world question becomes variables, constraints and an objective. This stage is where domain knowledge enters and where most of the eventual quality is decided.
Solution
model → answer
Optimization, inference or learning produces an answer, together with an honest account of its uncertainty and the regime in which it holds.
Product
answer → decision
The answer is embedded in software that a person can act on: fast, legible, and explicit about what it does not know.
03Areas
Seven fields we work in.
Listed with the status each one honestly has at the studio today — applied in something we have shipped, actively worked on, or exploratory.
Mathematical Modelling
Choosing the representation of a system that is faithful enough to be useful and simple enough to reason about. The hardest decisions in a model are the ones about what to leave out.
- Ordinary & partial differential equations
- Dynamical systems
- Dose–response and accumulation models
- Numerical integration
- Sensitivity & uncertainty analysis
Optimization
Most decisions worth automating are constrained optimization problems. We work on the formulation as much as the solver, because a well-posed problem is most of the answer.
- Convex optimization
- Linear & mixed-integer programming
- Constraint programming
- Gradient-based methods
- Metaheuristics
Machine Learning
Learning functions from data where writing them down by hand is impractical — with validation designed to fail loudly rather than flatter the model.
- Supervised & unsupervised learning
- Time series & forecasting
- Representation learning
- Model calibration
- Robust evaluation design
Large Language Models
Applied work on grounding, retrieval, structured output and evaluation. Our interest is in the boundary: which parts of a task a language model should own, and which it should never be given.
- Retrieval-augmented generation
- Structured & constrained decoding
- Agentic tool use
- Evaluation & regression suites
- Cost and latency modelling
Computer Vision
Extracting measurements from images. We are interested in vision as instrumentation — colorimetry, detection and geometry — rather than as an end in itself.
- Image classification & segmentation
- Colorimetry (CIE-Lab)
- Camera calibration
- On-device inference
Statistics & Inference
The discipline that decides whether a result means anything. Experimental design, uncertainty quantification, and the difference between correlation and a decision.
- Bayesian & frequentist inference
- Experimental design
- Causal inference
- Survival & longitudinal analysis
- Uncertainty quantification
Operations Research
Queueing, scheduling, routing, inventory and capacity — the mathematics of how organisations actually spend their resources, and where small percentages become large sums.
- Queueing theory
- Scheduling & routing
- Inventory & capacity models
- Discrete-event simulation
- Decision analysis under risk
04Publications
Nothing here yet, and we will not pretend otherwise.
Lluyot Labs has not published peer-reviewed work. Listing papers we did not write, or preprints that do not exist, would be the fastest way to lose the only thing a young lab has.
What does exist is applied modelling work already running inside a shipped product, with its sources cited in the product itself. When there is something worth submitting, it will appear here — with a link, a date and a venue.
In the meantime, the closest thing to a technical record is the engineering journal — write-ups of real modelling decisions, including the ones that were wrong first.
05Open source
Nothing released yet. Here is the policy.
Our GitHub organisation exists and is empty, which is the accurate state of things. The intent is specific rather than aspirational: when a piece of modelling work becomes general enough to be useful outside the product it was built for, it gets extracted and released. Tools used by other engineers get corrected by other engineers, and that is worth more to us than the code being private.
Collaboration
Working on something open?
We are interested in problems where the modelling is genuinely unresolved, and in collaborations with academic groups and companies that have data and a question but no path from one to the other.