# Principles

> The nine principles behind every system we build, from mapping the work before choosing a model to keeping every model replaceable.

- Web page: https://www.alesanalytics.com/engineering/principles
- Markdown: https://www.alesanalytics.com/engineering/principles.md
- Last updated: 2026-11-07
- Publisher: Ales Analytics

The nine rules every build follows. Published 2026-11-07. Last reviewed 2026-11-07. Reviewed by Ales Analytics engineering.

## The nine principles

1. Start with the work, not the model.
2. Build the smallest system that does the job.
3. Measure on your own examples, before and after every change.
4. Numbers come from code, never from a model.
5. People approve what cannot be undone.
6. Data stays in your environment by default; outside calls are explicit and logged.
7. Use vendor libraries and compilers first; write custom kernels only where profiling shows a bottleneck.
8. Keep every model replaceable.
9. Describe how we work, never promise a result we have not measured.

## What each one means in practice

### Start with the work, not the model

The first artefact on any build is a map of the task as it runs today: what arrives, in what format, which systems it passes through, who approves what, and where the waiting happens. Model choice comes after that map exists, because the map decides what the model has to be good at. A team that keys in delivery notes needs reliable field extraction from poor scans; a team answering investor questionnaires needs retrieval over approved answers. Those are different systems.

### Build the smallest system that does the job

Every component added is a component that has to be monitored, patched and explained. If a rules engine and a well-indexed search answer the question, there is no agent. If a 7-billion-parameter model meets the accuracy bar on the client's test set, there is no 70-billion-parameter model. The smaller system is usually faster to ship, cheaper to run and easier to audit.

### Measure on your own examples, before and after every change

Public benchmarks say little about a firm's own invoices, contracts or claims. Before anything is built, a frozen test set is drawn from the client's own documents and labelled by the client's own experts. Every change, whether a new prompt, a new model or a new retrieval setting, is scored against that set before it ships. See [Model adaptation and evaluation](https://www.alesanalytics.com/engineering/model-adaptation).

### Numbers come from code, never from a model

Language models read, classify, draft and map. They do not add up columns in a report that someone will sign. Every figure that leaves a system is produced by ordinary, version-controlled, unit-tested code, and carries its lineage back to the source rows.

### People approve what cannot be undone

Sending an email, filing a form, posting a payment or writing to a system of record waits for a named person. The approval is part of the workflow itself, recorded with who approved, when and what they saw, rather than a convention people are asked to follow.

### Data stays in your environment by default; outside calls are explicit and logged

Systems are deployed in the client's own cloud account or on the client's own servers. Where a hosted model is the right tool for a task, that route is configured explicitly in the gateway, approved by the client, and every call is logged.

### Use vendor libraries and compilers first; write custom kernels only where profiling shows a bottleneck

cuBLAS, cuDNN, the kernels shipped with the serving engine and `torch.compile` cover most workloads well. A custom kernel is written only when a profiler shows a specific operation dominating the time, and only with a test that compares it against a higher-precision reference.

### Keep every model replaceable

Applications talk to a gateway, not to a model. Prompts, evaluation sets and output schemas are stored with the system, so that a newer or cheaper model can be scored on the same test set and switched in configuration.

### Describe how we work, never promise a result we have not measured

The site, the proposals and the documentation describe method and design. A figure about outcomes appears only once it has been measured on delivered work, with the method stated next to it.

## Contact

solutions@alesanalytics.com, or https://www.alesanalytics.com/contact.

- Every page as Markdown: https://www.alesanalytics.com/llms.txt