Machine learning · Models you can run and check

A model is a component, not a strategy. The work is the data around it, the evaluation under it, and the honest answer about what it cannot do.

Assessment from 3 days · engineering 110 EUR an hour · inference on your own hardware from 39 EUR a month · no VAT added

What would a good answer look like?

The first question decides most of these projects: what would a good answer look like, and how would you know you got one?

Most of these projects arrive as a technology looking for a job: somebody has seen what a model can do and wants one. The useful first conversation runs the other way round.

What decision or piece of work is this meant to change? What does a good answer look like, concretely enough that two people would agree on whether a given answer was good? And what happens when it is wrong, because it will be wrong sometimes and that has to be survivable.

A recommendation to solve the problem some other way is a normal outcome here rather than a failed sale, and it usually turns on one of two things: the data to learn from does not exist yet, or a rule would do the job more cheaply and be explainable as well.

What gets established first

The task, stated as an outcome rather than as a technology
What a good answer looks like, and who decides
What happens when the answer is wrong, and how that is noticed
Whether the data to learn from exists, and whether you may lawfully use it
Whether a rule, a lookup or a better form would do it instead
What the thing is worth if it works, which sets the budget for trying

What comes back

A written statement of the task and the acceptance criteria
An honest read on whether the data supports it
The simplest approach that could work, tried first
A cost for finding out, separated from the cost of building
The recommendation not to proceed, where that is the right one

Not included: a model chosen before the task is stated. That order is how an organisation ends up owning a demonstration.

The data, which is most of the work.

The model is the easy part. Getting clean, traceable, lawful data into it is not.

Every hour that looks like it was spent on a model was mostly spent on the data: finding it, cleaning it, labelling it, and being able to say later where each piece came from.

Provenance is not paperwork. When somebody asks why the system said what it said, the answer starts with what it learned from, and an estate that cannot answer that has a model it cannot defend.

Getting it in

Pipelines from the systems you already run, versioned like any other code
Cleaning and de-duplication, with the rules written down rather than ad hoc
Labelling: who labels, to what guideline, and how disagreement is resolved
A held-out set put aside before anyone looks at the data
Provenance recorded per record, so a later question has an answer

Keeping it lawful

A lawful basis established before the first pipeline runs
Personal data minimised, and pseudonymised where the task allows
Retention that matches the obligation rather than the convenience
The right to erasure made technically possible, not merely promised
A record of processing that covers training as well as inference

Not included: scraping data you do not have the right to use. If the provenance cannot be stated, the model cannot be defended.

Running it where you can see it.

Inference on hardware you hold, so nothing has to leave to be useful.

Open-weight models are good enough for most of the work an organisation actually has, and running them yourself means the input never leaves.

That matters most exactly where the value is: the documents you cannot send anywhere, the correspondence, the records. A model that has to be fed over somebody else's API is a model you cannot use on your interesting data.

Deployment

Model selection against your task rather than against a leaderboard
Quantisation and batching sized to the hardware you actually have
GPU provisioning, or an honest answer that the CPU will do
An inference service with limits, queues and a health check
Versioned weights, so an answer can be reproduced months later
Fallback behaviour when the model is unavailable, decided in advance

Operating it

Latency and cost measured per request, not estimated
Capacity planning against real traffic
Upgrades rehearsed, because a new model is a behaviour change
A record of which version answered which request
Monitoring for the failure mode that matters: confident and wrong

Not included: a promise that local inference is always cheaper. Past a certain volume it is; below it, an API is, and we will do that arithmetic honestly.

Answers grounded in your own documents.

Answers grounded in your own documents, with the source attached to each one.

The most useful thing most organisations can build is not a model that knows things, but one that can find the right paragraph in what they already have and say where it came from.

That is retrieval, and the interesting work is in the retrieval rather than in the generation: what gets indexed, how it is chunked, how freshness is handled, and whether the citation actually supports the sentence it is attached to.

Building it

Indexing across the stores you already run, with permissions carried through
Chunking that follows the document rather than a fixed character count
Embeddings you can regenerate, from a model you keep
Freshness: how quickly a changed document changes the answer
Citations attached to every claim, and checked in evaluation

Keeping it honest

A visible "I do not know", used rather than decorated
Answers refused where the retrieved evidence does not support one
Permissions enforced at retrieval, so nobody reads what they should not
Evaluation against questions with known answers, run on every change
A path for a person to correct an answer, and for that to change the index

Not included: a system that cannot be wrong. Retrieval reduces invention; it does not abolish it, and a citation makes the error checkable rather than impossible.

A number you can defend.

A number you can defend, taken the same way every time, or it is a demonstration.

Without evaluation there is no difference between a system that works and one that impressed somebody once. The test set is written before the build, from real cases, with the answers agreed by people who know the domain.

It is run the same way every time, on every change, and the number is kept even when it goes down.

How it is measured

A held-out set of real cases, agreed before anyone builds
Metrics chosen for the task, not for how well they show
The same harness on every change, so numbers are comparable
Human review on a sample, because some things no metric catches
Drift watched after launch, because the world moves and the model does not

What is reported

The score, including the runs where it fell
Where it fails, characterised rather than averaged away
The cases it should refuse, and whether it refused them
Cost and latency alongside quality, because all three are the product
A recommendation to stop, where the numbers do not justify continuing

Not included: a benchmark score as evidence that it works for you. A public benchmark measures a public task.

What it is allowed to decide.

What the system is allowed to decide, what it must escalate, and the record that shows which happened.

A system that suggests and a system that decides are different products with different obligations, and the line between them is a design decision rather than an emergent property.

So it is drawn explicitly: what it may decide alone, what it must escalate, and what it must refuse outright. Then the record shows which of the three happened, for every request.

Controls

A written statement of what the system decides and what it only suggests
An escalation path with a person on the other end of it
A refusal list: the questions it must not answer at all
Rate limits and abuse handling, because a model is an open door
Prompt and output logging with a retention period that matches the obligation

Records

Which version answered, on what evidence, at what time
A record of processing that covers training as well as inference
An impact assessment where the use calls for one
The evaluation history, kept rather than summarised
Documentation written for whoever inherits this, not for whoever built it

Not included: legal advice on the AI Act or any other regime. We build the record and the controls; your counsel reads them.

start

Start with the task.

Tell us the task, what you would accept as a good answer, and what data you already hold. Not which model you want.
You get back an honest read on whether the data supports it, the simplest approach worth trying first, and a cost for finding out that is separate from the cost of building.

Write to: hello@ave17.com
About: Machine learning

Not included: a fixed quote from a first message. Whether this is possible at all is itself a piece of work.

How a machine learning project runs.

Five stages. The first two are where the money is saved, and both of them can end the project on purpose.

Stage	What happens	What comes out
Frame	State the task as an outcome, and what a good answer looks like concretely.	A written task statement with acceptance criteria two people would agree on.
Look	Read the data that exists: how much, how clean, how traceable, how lawful.	An honest read on feasibility, including "not with this data".
Baseline	Try the simplest thing that could work — a rule, a lookup, a small model.	A number to beat, and sometimes a finished system nobody needed a model for.
Build	The pipeline, the inference service, the retrieval, the evaluation harness.	A running system, versioned, with a score taken the same way every time.
Watch	Drift, cost, refusals and the confident wrong answers.	A review with the numbers, including the ones that fell.

Not included: a delivery date from the first conversation. Until the data has been looked at, any date is a guess with a number on it.

Where it goes wrong.

Five failures this field produces reliably, named in advance. None of them is technical.

The demonstration that never ships

It worked on the twenty examples somebody picked. There was no held-out set, so nobody ever found out whether it worked on the other thousand.

Guard: the test set is written before the build, from cases nobody chose.

Confident and wrong

The system answers everything, because answering is what it was built to do. The errors are the same shape as the successes, so nobody notices.

Guard: a refusal path, and evaluation that scores refusals as successes.

The data was not ours to use

Discovered late, usually by somebody outside the project, and it invalidates the work rather than delaying it.

Guard: the lawful basis is established before the first pipeline runs.

It works and nobody uses it

Built beside the work instead of inside it, so using it is an extra step and the extra step does not get taken.

Guard: the first question is which existing piece of work this changes.

Nobody owns it after launch

Models drift, sources change, costs move. Six months later it is quietly worse and there is no owner to notice.

Guard: an owner named at handover, with the hours, and a review booked.

Not included: a claim that we avoid all five. We name them so that you can check, mid-project, whether one is happening.

What we will not claim.

The short list. Every item is something that gets claimed in this field and should not be.

We will not claim

That a model understands anything. It predicts, and prediction is enough for a great deal of useful work
That a benchmark score transfers to your task
That more data always helps; past a point better data does and more does not
That the system cannot be wrong, or that a citation makes it correct
That we can explain why a large model produced a particular sentence

What we will say

The simplest approach that could work, before the interesting one
When a rule would beat a model, and be explainable as well
When the honest answer is that the data does not exist yet
What it will cost to find out, separately from what it will cost to build
Which of the five failures above is starting to happen

The word for this field is machine learning. Artificial intelligence is the market's word for something that does not exist, and using it makes every other sentence harder to check.

Not included: exceptions for a large enough contract. That is why this is on a public page rather than in a proposal.

What it costs.

Inference on infrastructure, moved around until it looks like yours. Nothing is sent anywhere; this runs in your browser and is an estimate, not a quote.

Where the machine stands	What it is	Per month
Your own hardware or cloud	you provide the machine	39 EUR / month
Ours · Small	2 cores, 4 GB, 40 GB	69 EUR / month
Ours · Medium	4 cores, 8 GB, 80 GB	119 EUR / month
Ours · Large	8 cores, 16 GB, 160 GB	199 EUR / month

Bolted on	Rate
Each bridge, bot or extra service	10 EUR each a month, up to 24

Support	What it is	Per month
Standard	included	included
Priority	199 EUR / month	199 EUR / month

Setup, once: 590 EUR
Engineering outside scope: 110 EUR an hour
An assessment: from 3 days at 110 EUR an hour
Above 1000 users: the ladder stops and we quote

No VAT is added: we are not registered for it, so the figure shown is the whole figure.

Setup is charged once; everything else is monthly. Engineering is 110 EUR an hour. A model that needs a GPU is priced against the card it actually needs, after the evaluation says which one that is.

Not included: the engineering, and not the graphics card. Both are quoted against the scope the assessment produced.

What support covers, and what it does not.

The same two levels as every other deployment we run, and the line between operating a model and improving one is where the boundary sits.

	Standard	Priority
Price	included	199 EUR / month
Requests per 30 days	2	4
Beyond the allowance	charged at the hourly rate	charged at the hourly rate
Response time	within 2 working days	within 8 working hours
Outages	counted, never charged	counted, never charged
Channel	email	a room with us, in chat

Working hours, Monday to Friday, excluding public holidays: a request sent on Friday evening is answered on the next working day. Three separate asks in one message count as three requests.

Covered

The machine is down, unreachable or returning errors
A component installed as part of the deployment has failed, the serving stack and the index included
System-level trouble: disk, memory, certificates, backups
Reconfiguration you ask for: swap a model, change a limit, rebuild an index from documents you already hold
Upgrades of what we installed, and anything that breaks during one

Not covered

A model answering badly. That is an evaluation question and it is engineering with a scope, not a support request
Retraining, fine-tuning, or building an index over a new corpus
Explaining why a large model produced one particular sentence. Nobody can, and the panel on what we will not claim says so
A third-party model behaving differently after its own authors change it
Writing the application that calls the model
Deciding what the system is allowed to decide. That is yours; what we build is the record of which decision was taken

Not included: a 24-hour rota. Response times are working hours and are stated rather than implied, and clause 7 makes no availability promise.

What you keep, and how to leave.

The argument for running a model on your own hardware is worth nothing if the pieces cannot leave with you. These are the pieces, named, and what happens to each one.

The weights were never ours: The models we run are open-weight files published by their own authors under their own licences. We do not licence them to you and we cannot take them back: what you are paying for is the installing, the evaluating and the operating.
The index and the embeddings: The vector index, the embeddings and the pipeline that built them sit on the machine and go across with it as they are, rather than being converted into a farewell archive. The pipeline is written down, so a successor can rebuild the index from your own documents.
The evaluation set is the asset: The held-out cases, the scoring code and every score ever taken are yours and are handed over with the rest. Without them the next engineer is guessing whether a change made the system better, which is the position the work exists to get you out of.
The prompts and the configuration: Under version control and reviewable by your own engineers, with every deviation from a default recorded beside the reason for it.
Your data was always yours: It stays where you put it. Nothing has to leave your estate to be useful, nothing you send us is put into a model, and customer data is never training data. The processing agreement binds this commitment.
The act of leaving is free: 1 month's notice either way, no exit fee, and access withdrawn on request. Handover work is charged at 110 EUR an hour; leaving itself is not. Clause 13, and the leaving page in full.

What we cannot hand over is a model we never ran and data we never held. Where a card was bought for the work it is yours and stays where it is; where the model runs on a machine of ours the deployment moves the same way any other deployment moves.

Not included: a claim over anything of yours. There is no wording in our terms granting us a licence to your data, your documents or the output, and the privacy notice says so in its own section.

What is agreed in time.

The periods this work is held to, each with the clause it comes from. None of them changes because the deployment has a model in it.

Before anything starts: An order becomes a contract when we confirm it in writing, and anything said before that is an estimate. Setup begins once the first invoice is paid and you have provided what the deployment needs: a domain, access to the machine where it is yours, and any directory we are asked to join. Clause 4.
A support request, standard: 2 in 30 days, answered within 2 working days, included with the machine. Working hours, Monday to Friday, excluding public holidays: a request sent on Friday evening is answered on the next working day.
A support request, priority: 4 in 30 days, answered within 8 working hours, at 199 EUR a month. The same working hours. Anything past either allowance is charged at 110 EUR an hour.
An invoice: Payable within 14 days. Setup once before the work begins, maintenance monthly in advance, and work outside the agreed scope quoted before it starts and invoiced when it is done. Clause 5.
A price change: At least 30 days before it applies to you, and never to a month already invoiced. Clause 5.
A change to these documents: At least 30 days before a material change applies, and you may end the contract before it takes effect. The date a version came into force is printed on the document, with every earlier date listed under it. Clause 14.
Notice to stop: 1 month in writing, either way. No reason is required and there is no exit fee of any kind. Clause 13.
A breach: Either side may end it at once where the other commits a material breach and has not fixed it within 14 days of being told. Clause 13.
Your data after you stop: Personal data we hold for you as processor is deleted within 30 days of termination, sooner if you ask, unless the law requires us to keep it. Clause 13.
Cancelling as a consumer: Where you ordered as an individual rather than as an organisation, 14 days from the day the contract is made, and the refund within 14 days of your telling us, less the value of any work you asked us to begin inside the window. Clauses 4 and 5a.

Start and delivery dates are agreed in the written scope before the first invoice. Support is counted in working hours under clause 6 of the terms.

Delivery dates are agreed in the written scope for your project.

Who you are dealing with.

Who you are dealing with, and the paperwork that goes with it.

Company	AVE17 LTD, registered in England and Wales, number 17254143
Address	128 City Road, London, EC1V 2NX, United Kingdom
Data protection	Registered with the Information Commissioner's Office, reference ZC225076
Contact	hello@ave17.com
Engineering rate	110 EUR an hour. We are not registered for VAT, so none is added
Assessment	From 3 days at 110 EUR an hour, fixed against a written scope
Inference	From 39 EUR a month on hardware you hold. A card is priced against the one the model actually needs, after the evaluation says which that is
Payment	Bank transfer or card. Invoices payable within 14 days
Notice	1 month either way, no reason required and no exit fee of any kind
Processing agreement	An Article 28 data processing agreement is published and in force for every customer, at no charge
Training data	Nothing you send us trains anything, and customer data is never pooled or used to improve something we sell to somebody else

The terms of service, the privacy notice and the Article 28 processing agreement are published on this site, in full, before anybody is asked to sign anything.

Write to: hello@ave17.com
About: Machine learning

Not included: legal advice. This states our own position; your own obligations under the EU AI Act or anywhere else are yours to take advice on, and we write the engineering documents your counsel reads.

If it does not suit.

Including the outcome this page names more often than any other: the evaluation comes back and the honest answer is that the task is not worth doing. That is a finished piece of work and it is invoiced as one.

If the answer is not to proceed: An assessment that ends in stay where you are is a finished piece of work, and the invoice is the same as one that ends in a build. That is the outcome we are paid for rather than the outcome we prefer, and it is why the assessment is priced small enough to commission before anyone is committed.
If the work is not what was agreed: Where you ordered as a consumer the Consumer Rights Act 2015 requires it to be carried out with reasonable care and skill and lets you require the work to be done again, or the price reduced; no contract can take that away and clause 5a says so. Where you ordered as an organisation, clause 12 limits our total liability in any twelve-month period to what you paid us in it, and nothing above that figure is promised.
If you want to leave: 1 month's notice, either way, and the act of leaving costs nothing. You get the deployment as it stands — database, file store and configuration — rather than a farewell export, and access is withdrawn on request. Handover work is charged at 110 EUR an hour; leaving is not. Clause 13, and the leaving page in full.
If we would be the wrong supplier: Where a mainstream hosted product already does the job, nobody on your side will own the result, or the deciding factor is the lowest price this quarter, we would decline the work. We would rather lose it than find out in month three.
If something is broken: An outage is counted and never charged, on either support level. There is no availability promise behind that and clause 7 says so: what is promised is how quickly we answer, not that nothing will fail.

Every line above is in the terms of service, the data processing agreement or the leaving page, all three published in full before anyone is asked to sign anything. Where one of them changes it changes there first and here second, and the date it took effect is printed on the document.

Not included: a promise about a number the model has not been measured at. An accuracy figure agreed before the evaluation would be a figure invented before the evaluation, and panel C says so.

How it works

A · How a machine learning project runs
B · Where it goes wrong

Before you buy

C · What we will not claim
D · What it costs
E · What support covers, and what it does not
G · What is agreed in time

Before you trust

F · What you keep, and how to leave
H · Who you are dealing with
I · If it does not suit