ChromaticsWe find the right model.
The shortlist is decided by your data, your hardware and your cost ceiling. You get the evidence in writing, and it is yours to take elsewhere.
Chromatics AI
AI that runs where your data already lives.
We design, train and run the whole system: on the machine, in your data centre, in a sovereign cloud, or embedded in the product you ship. You own what we build.
We make it yours.
We train on your examples and install the model where the work happens. The tuned model and the evaluation sets that prove it belong to you.
We keep it sharp.
Accuracy falls without announcing it. We measure against fresh data, retrain when it slips, and move routine traffic to smaller models.
Rented or owned.
Renting is not about geography. It is about what you are allowed to do. A rented model cannot be trained on your data, frozen while you certify a product around it, or taken with you when the terms change.
Owning means the weights, the training data, the evaluation sets and the deployment package are yours, wherever the system runs.
Where it runs is a decision you make on cost, latency and law. What you own is not a decision at all.
Two kinds of model, one system.
Open-weight models can be adapted and run inside your environment. Proprietary models are stronger on the hardest reasoning, but a request has to leave your building to reach one. Most systems need both, so the real question is which requests go where, and who decides.
Open-weight foundation models
- Adapted and tuned on your data.
- Run on your hardware or ours.
- Compressed to fit the target.
- Frozen when you need a stable version to certify against.
- Yours to keep.
Proprietary models
- Reached through an API.
- Strongest on rare, hard, general reasoning.
- Priced per request and versioned by the provider.
- Used sparingly, for requests that justify leaving the building.
What we actually do.
Seven things. Most customers start with two.
Architecture and design. What the system must do, talk to and never do, settled inside your team before anyone writes code.
Model selection. Candidates evaluated against your data and your hardware, with the shortlist and the evidence in writing.
Routing. The layer that decides which model answers, what stays inside, and what happens offline. Most of the running cost is won or lost here.
Training and tuning. Trained on your examples and your edge cases. The tuned model and the evaluation sets are yours.
Deployment. Compressed and compiled for its target, from an embedded module to a rack in your data centre.
Hosting and operation. Hand it to your team with the documentation, or we run it under an agreed service level. Your call.
Continuous optimisation. Once the real traffic pattern appears we retune the routing and shrink the routine models, so cost per request falls.
Where it runs is your decision.
On the machine.
An industrial computer beside the line, the cell or the vehicle.
Embedded.
Inside the product you ship, on the hardware you already put there.
Your data centre.
On your own racks, under your own access control.
Sovereign or private cloud.
In a jurisdiction you choose, operated by your team or by ours.
The same model, the same evaluation sets and the same ownership terms apply in all four.
Routing is where the economics live.
A router decides, request by request, which model answers. Routine work goes to the smallest model that clears the quality bar, on hardware you control; the rare hard case escalates under rules you write. Done well, cost per request falls as volume grows, which is the opposite of how most AI bills behave.
What decides. Task type, confidence, cost ceiling and data class, in rules you can read.
What stays. You define the data that never leaves. The router enforces it rather than trusting a prompt.
What happens offline. The local path keeps answering. Escalation degrades, the system does not stop.
What changes over time. As the traffic pattern emerges, more of it moves to smaller, cheaper models.
What physical AI actually means.
It has two shapes. In the first, a model's output informs a person or another system: inspecting, monitoring, counting, reading, predicting. In the second, the model drives an actuator and acts on the world with no human in the loop. The second is the harder problem, because a wrong answer moves something, and almost all the extra work sits in validation, safety and what the system does when it is not sure.
Both shapes are a large part of what we do. Neither is all of it.
When the model runs on a machine.
The physical case is the most demanding version of the problem, so it is worth seeing in detail. Everything below has a direct equivalent when the system runs in a data centre instead.
The box
A small industrial computer sits next to the machine, on the line or in the vehicle. It has no moving parts, it runs on the power that is already there, and it is built for heat, dust and vibration. Your cameras, sensors and controllers plug straight into it.
The model
Inside the box is one model trained for one job, not a general chatbot. It is small enough to run on that hardware and fast enough to answer while the part is still in front of the camera. It learned from your examples, and the trained model belongs to you.
The loop
The decision is made on the box and goes straight to your controller. Only summaries leave the building, and only if you allow it. If the network goes down the machine keeps working, because nothing it needs is on the internet.
Cameras and sensors feed an edge box holding your model. The decision goes to the line controller and local storage. Everything stays inside the site boundary.
It starts small, on purpose.
1. A 45-minute conversation about the job, the machine and the data.
2. A written answer in two to three weeks, at a fixed price, that you can take anywhere.
3. A working proof on one line, one vehicle or one device before you commit to more.
For your engineers
- Base models: open-weight families for language, vision, audio and vision-language-action.
Start with a conversation.
45 minutes, no slides, an honest answer.