WHAT WE BELIEVE

Ten principles. They are not decoration. Each one exists because it settles a real argument that comes up on real projects, usually under time pressure, usually when the tempting option is the one that produces a good demo and a bad system.

1. Boring is the goal

An AI system that works is unremarkable to use. It answers correctly, it costs what you expected, it returns in the time you budgeted, and nobody has to babysit it. Nothing about it is surprising.

Getting there is not boring at all. It takes careful problem framing, honest measurement, and a lot of unglamorous engineering that never appears in a demo. But the destination should be dull, because dull is what production means.

We are suspicious of novelty for its own sake. A newer architecture, a bigger model, or a more fashionable framework has to earn its place by beating the simpler option on your data, on your metric, at your budget. Most of the time it does not.

2. Beat the baseline, or admit you cannot

Before any model, we build the simplest thing that could work. A set of rules. A keyword search. A linear model. The performance of the process you run today. Sometimes just the number a competent human hits.

Then everything we build afterwards has to beat it, measurably.

This sounds obvious and it is routinely skipped, because a baseline can be embarrassing. Teams have shipped complex systems that a fifty line rule set would have matched. We would rather be embarrassed in week one than in production.

If we cannot beat the baseline, we say so, we explain why, and we recommend keeping the baseline. That is a successful project. You now know something true about your problem, and you did not spend a year finding it out.

3. Write the evaluation before the model

An evaluation you build after the fact measures whatever you happened to build. An evaluation you build first measures whether you solved the problem.

So we define, in writing and with your agreement, what good looks like before implementation starts. What we measure, on what data, at what threshold, and what result would mean the approach has failed. We build the evaluation harness as a first deliverable, not a final one.

This is the single practice that most separates AI work that reaches production from AI work that stalls in a pilot. A demo proves that a system can succeed once, on an example chosen by the person demoing it. An evaluation tells you how often it succeeds on examples chosen by reality.

If somebody shows you an AI system and cannot show you its evaluation, you have been shown a demo.

4. Research deserves the same discipline as production code

Research code has a reputation for being scratch work. Untracked notebooks, hardcoded paths, results that nobody can reproduce two weeks later, a number in a slide that no longer matches any file on disk.

We do not accept that. Research work goes in version control. Experiments are tracked with their code version, data version, configuration, and environment. Analysis gets reviewed by a second person, the same way code does. Results are reproducible by someone other than their author.

This is the practice most often missing from otherwise excellent research teams, and it is the reason their good ideas take so long to become products. Discipline here is not bureaucracy. It is what allows you to trust a result enough to build on it, and it is what allows work to survive somebody going on holiday.

5. The data decides more than the model does

Model selection gets the attention. Data quality decides the outcome.

Label noise, leakage between training and test sets, a distribution that has quietly shifted since the export, a field that means something different in the system that produces it than in the documentation that describes it. These are the reasons AI projects fail, far more often than an inadequate architecture.

So we look at the data first, and we look at it properly. Not summary statistics, but actual records, including the ugly ones. We ask where each field comes from, who fills it in, and what happens when they are in a hurry. We check whether the historical data resembles what the system will see in production.

When the data is not good enough, the honest answer is that fixing the data is the project, and modelling comes after.

6. Ship learning every week

No client should wait months to find out how it is going.

Every week we show what we learned, what changed as a result, and what we intend to do next. In a build phase that means working software. In a research phase it means measured results, including the ones that did not go our way.

Long silences in AI projects are almost always hiding something: an approach that is not working, a data problem nobody wants to raise, or scope that has quietly doubled. A weekly obligation to show real output makes those things surface early, while they are still cheap.

7. A negative result is a result worth paying for

Some questions can only be answered by trying. Will retrieval over these documents actually answer these questions? Can this model run inside that latency budget on that hardware? Is the signal in this data strong enough to predict that outcome?

We answer those questions in weeks, with a timebox and criteria agreed in advance for what would mean the current plan is not going to work. When the answer is no, we report it plainly, with the evidence, and we explain what we would have needed for a different result.

Usually that changes the plan rather than ending the project. The point of agreeing the stopping criteria early is not to give ourselves an exit. It is to make sure the decision to change course gets made in week three, while it is cheap, rather than in month six, when it is a write-off.

Finding out in four weeks that an idea does not work is worth a great deal. It is worth far more than finding out in twelve months, and it is worth immeasurably more than never quite finding out at all, which is how a surprising number of AI initiatives end.

8. Sometimes the answer is not AI

We will say so when we think it.

There are problems where a deterministic rule is better than a model: it is cheaper, it is auditable, and it does not surprise anybody. There are problems where the data required does not exist and no amount of cleverness compensates. There are problems where the cost of a wrong answer is high enough that a probabilistic system is the wrong tool. And there are problems where the real blocker is an unowned process rather than a missing algorithm.

Common signs that a problem is not an AI problem:

• The rules are known, stable, and writable. You want software, not a model.
• There is no data, or the data that exists was never collected with this question in mind.
• Nobody can write down which workflow this changes, and by how much. If the goal cannot be stated as a measurable change, no result will settle anything.
• There is no baseline and no agreed measure of success, so no result could be judged.
• Nobody owns the decision the system is meant to support, so nothing will change when it produces an answer.
• A single error costs more than a year of the automation saves, and no human review step is planned.

Telling a client this costs us work in the short term. It is also the reason clients come back, and the reason they send other people to us.

9. Everything we build is yours to run

Code, model weights, datasets, evaluation suites, documentation, infrastructure definitions. All of it is yours, and we hand over what is needed to run it without us.

We do not build on a proprietary platform of our own. We do not keep a critical piece in an account only we can access. We do not leave a system that only works while we are still being paid.

If the option to walk away is not real, everything else in a working relationship is theatre.

10. We aim to become unnecessary

The best outcome of an engagement is a client who no longer needs us for that thing.

So we write things down while we build. We explain choices rather than only recording them. We work in your repositories, in your review process, alongside your engineers where you have them. When you are building an internal team, we help you hire it, we help you onboard it, and we reduce our involvement as it takes over.

We would rather be asked back for the next hard problem than retained forever on the last one.

---

These principles decide arguments. The next page describes what an engagement actually looks like week to week.

Next: How We Work